[OLSR-users] Interoperability with INRIA code
Tue Dec 21 05:41:19 CET 2004
> A representative from UniK was at the interop. olsrd was, as far
> as I know, found to be the only implementation that needed no
> modifications to work in a RFC3626 compliant manner :)
Hmm, I don't know where this strange rumor originated from, but
fortunatly it is incorrect :-)
I am probably to blame for not having written a report, sorry about
that ; you can find some info from MANET guru Thomas Clausen at:
Here is a short summary:
- All implementations were found to interoperate in IPv4 for
basic functionality (one implementation didn't implement properly
multiple messages processing but this was fixed in minutes).
- The major difficulty was probably to set up the broadcast/multicast
address (IPv4, 3 choices: 255.255.255.255 ; 220.127.116.11 ;
network broadcast like 192.168.0.255 ; IPv6 several choices also).
- Extended functionality was tested (against INRIA OLSR in IPv4),
and a few problems occured:
- one (non-free) implementation didn't implement properly some
multiple interface functionality due to some unclear explanation
in the RFC [blame me again ;-)].
- I think the Unik OLSR IPv4 port to Windows was found, at the time,
to generate incorrect packets (which would crash/make stop another
- one free implementation didn't implement MID processing: NRL
OLSR. This is by design ; This is because NRL (Navy Research Labs)
was very active in contributing to the OLSR specification, and
experimenting it, so started re-implementing OLSR in 2001 (the
pre-RFC drafts), and had to track many changes in many OLSR drafts
; the last change in OLSR draft broke many things in MID which lead
to NRL not follow them yet (and INRIA re-implementing OLSR from
scratch). Still to be fair with NRL, one should not forget that they
are major early contributors to the OLSR specification, for instance
the suggesting, implementing, and testing the link-hysteresis
features found in the RFC (and some others) ; they added OLSR
message decoding in ethereal ; and their implementation had/has many
extra features (simplified multicast, ToS/QoS routing,
load-balancing, fish-eye, packet rate slowing-down in stable
networks...) - as far as I know they are even the official
implementation of routing protocol which should be used to test new
tactical radio systems proposed to DARPA, i.e. for US Army and NATO.
. Anyway in all those cases, missing functionality resulted only in
some routes being not computed inside the non-compliant code (i.e. they
still interoperate very well).
In IPv6, 3 implementations were tested, and found to interoperate after
multicast/HNA problems were solved ; the two free implementations which
joined the test were:
- qolyester (qolsr) (which has now also many interesting QoS features).
- CRC olsr, (which was derived from old INRIA OLSRv3 olsrd) and which
was modified comprehensively to bring it to IPv6 and RFC compliance.
I heard this version was also tested extensively to make experiments
between several countries in a NATO project.
(at that time INRIA OLSR IPv6 support was found to have been broken by
the porting to Windows, and a similar problem occured with NRL
OLSR I think).
Incidentally, as things turned out, the only freely available
implementation which joined both the IPv4 and IPv6 tests, happened
to be Qolyester (qolsr), this time - so it is a good start to test
interoperability of another version :-)
(and I'd say, sine INRIA OLSR which was used as "reference" for IPv4,
it is also decent choice for IPv4 :-))
The conclusion is that, anyway, all recent versions of OLSR can
interoperate, which is pretty good result :-)
> I hope we will se dome report from the interop soon.
> - Andreas
> Christophe Preguica wrote:
> > Hi,
> > I would like to know if interoperability tests have been performed with
> > the INRIA OOLSR code. Were you at the OLSR Interop on August 6-7 2004 ?
> > Regards,
> > Chris.
More information about the Olsr-users