Subject: [manet] UniK OLSR implementatin

From: Andreas Tønnesen <[email-masked]>
Date: Wed, 3 Dec 2003 13:11:19 +0100 (MET)

FYI - the UniK OLSR implementation now has IPv6 support. IPv4 and IPv6 is
supported in the same binary. If you are interested drop by:

http://heim.ifi.uio.no/~andreto/uolsrd/index.cgi

Thanks.

Andreas Tønnesen
UniK University Graduation Center
University of Oslo
http://heim.ifi.uio.no/~andreto/uolsrd/index.cgi

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Joe Macker <[email-masked]>
Date: Wed, 03 Dec 2003 18:38:50 -0500

Andreas/All:

I announced in Minneapolis, that the nrloslrd 
(independent implementation from previous NRL/INRIA nolsrd code you worked with) 
also supports both IPv4 and IPv6 and is available publicly.

CRC (in Canada) has also performed a IPv6 port but like yours is also based upon
the nolsrd codebase.

The packet formats should also be up to the recent spec.
Except the MID functionality is pending.

Since the packet formats are likely the same, we would be interested in a possible 
INTEROP test for both IPv4 and IPv6?

http://pf.itd.nrl.navy.mil/projects/olsr
has several code project related to OLSR.

There is also an ethereal parser you could try.
------------------------

One question I have regarding the UniK modifications relates
to neighbor management.

The early neighbor sensing hysteresis code in that release was based 
upon monotonically increasing hello sequence numbers (in version 3 code) that is no 
longer applicable in newer packet formats.  In nrlolsrd, we converted the 
algorithm to one that is self-clocking.
 
(with less dependence on monotonically increasing seq numbers in HELLO packet space).

Did you look into this issue or modify this portion of the code?

-Joe

---

From: Andreas Tønnesen <[email-masked]>
Date: Thu, 4 Dec 2003 09:24:13 +0100 (MET)

Thankyou for your reply mr Macker. I've commented in-line and I am
sending this to the manet-list as well, just in case somebody is
interested :-)

> INTEROP test for both IPv4 and IPv6?

I would most definetly be interested.
But I have still not gotten around to implement proper Vtime handling,
the implementation still sets the holding time based on its own emission
interval values.
As soon as this is done some INTEROP testing would be very interesting.

> There is also an ethereal parser you could try.

To be quite honest I never looked too much into the hysteresis
implementation :-( As I started to use the emission intervals proposed in
the draft(2 sec HELLO interval) the hysteresis caused the process of
registering(getting a high enough HYSAVG) neighbors to be ~8 seconds if I
remember correctly. Since the hysteresis functionallity was marked SHOULD
int he draft, I just "temporarly" removed it(the hysteresis). Its been
gone ever since ;-)

Perhaps not the best thing to do... The RFC2119 states regarding SHOULD:
"the full implications must be understood and carefully weighed before
choosing a different course"... and I guess claiming to have done to much
"careful weighing" would be an overstatement. But I intend to re-implement
it at some stage.

The whole project just started out with the aim of implementing MID
functionallity to the (draft 3)INRIA/NRL implementation. I guess it just
got out of hand somewhere. After all coding is _so_ much more fun than
writing some thesis :-D

Comments and/or suggestions are appreciated.

regards
Andreas T

Andreas Tønnesen

---

From: Joe Macker <[email-masked]>
Date: Thu, 04 Dec 2003 09:56:44 -0500

>int he draft, I just "temporarly" removed it(the hysteresis). Its been

Yes, sensing stability is sacrificed for sensing delay.

Once you upgraded the packet formats and handling, 
turning it off in that code was probably good in the sense 
that the older method would have not been suitable for the way sequence 
numbers are used in recent specs since nolsrd. So unless you modified it,
turning it off was the right thing to do.

>"careful weighing" would be an overstatement. But I intend to re-implement

The beaconing hysteresis is not the best thing either, but can improve
decision stability with time varying conditions,etc at the sacrifice of some
sensing delay.

Integrating some lower layer feedback is the best approach in general, 
but sometimes we do what we can do at L3..;-)

>got out of hand somewhere. After all coding is _so_ much more fun than

I think its great you implemented the MID functionality.
That would be very interesting for more people to test.

---

From: "Philippe Jacquet" <[email-masked]>
Date: Fri, 5 Dec 2003 11:38:20 +0100

Hi,

We were thinking about it long time ago, and the time seems now to be
appropriate. We plan to organise an OLSR interop meeting soon. We could have
a two day meeting. One day of short presentations and technical results,
another day of interoperability tests. Location and date are under
investigation and will depend on feedback.

Philippe

---

From: Andreas Tønnesen <[email-masked]>
Date: Fri, 5 Dec 2003 12:28:22 +0100 (MET)

Hi,

I would most definetly be interested. The uOLSR implementation should soon
be reasy for interop testing soon. I have started implementing the
Vtime/Htime processing and handeling which as far as I can see is the last
big issue for interoperability concerning uOLSR.

Andreas T

Andreas Tønnesen