[OLSR-users] Interoperability with INRIA code

[Cedric Adjih]

Hello all,

> 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:
 <http://www1.ietf.org/proceedings_new/04nov/slides/manet-6.pdf>
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 ; 224.0.0.1 ; 
  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
  OLSR implementation).
  - 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 :-)

Best regards,
-- Cedric

> 
> 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.