Subject: [manet] New OLSR draft

From: [email-masked]
Date: Tue, 2 Jul 2002 16:25:54 +0200 (CEST)

Dear All,

We've submitted the revised OLSR draft to the secretariat. However I am
afraid that we missed the official deadline.

Still, the revised draft is available from here:

http://byzantium.inria.fr:8080/OLSR-draft/draft-ietf-manet-olsr-07.txt

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: [email-masked]
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------

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

---

From: [email-masked]
Date: Sun, 14 Jul 2002 08:05:55 -0700

I have read the OLSR updates and have a few comments.

The new "relay willingness" field in the HELLO message
is certainly a good thing, and we have already been
planning to add a similar field (called "relay priority") 
to TBRPF HELLO messages.  For example, a node with a very low
battery level would have a low relay priority.  (Note that 
TBRPF already supports non-relay nodes simply by sending
only HELLOs but no topology updates.)

The new OLSR parameter TC_REDUNDANCY results in additional
topology information being reported (up to the full topology).  
Since TBRPF already allowed additional topology information
to be reported, I'm glad to see that INRIA agrees with us.

However, I do not see an *efficient* method for reporting 
sufficient topology information to provide each node with 
two disjoint paths to each destination (without providing
each node with the full topology).  Setting MPR_COVERAGE 
to 2 does provide each node with two disjoint paths to each 
destination (if such paths exist), but not only does it 
double the number of links flooded, it also doubles the 
number of MPRs that need to forward each TC message, 
which seems to multiply the TC overhead by 4.  
(In TBRPF, the factor is 2 since the number of nodes 
reporting each update does not increase.)
Since our ns-2 simulations show that OLSR generates more than 
twice as much overhead as TBRPF, this would likely give TBRPF 
an even bigger advantage in overhead.

Speaking of ns-2 simulations, I am still waiting for the updated 
ns-2 code that INRIA has been promising for a long time.
The code at their web site is still for version 03 of OLSR.
Since several changes have been made to OLSR in the last year,
I really would like to run ns-2 simulations to compare TBRPF
to the new OLSR.  

In fact, the ns-2 code at the INRIA site still has the bug (affecting 
packet size) that I discovered several months ago.  So someone using 
that code who does not know about the bug fix will get incorrect 
results. 

Regarding TBRPF, there is no TBRPF presentation scheduled at the 
meeting this week, but we plan to submit an update to the draft 
by September, which will include more readable descriptions of 
the TBRPF procedures, in addition to a few other changes.
As I previously posted, an updated IPR statement has been 
submitted to the IETF Secretariat.

We have received dozens of requests for our ns-2 code in
the last few weeks, so occasionally there may be a delay
in processing a request, and we apologize for this.

Although some recent changes have been made to OLSR that remove
some of the advantages that TBRPF previously had (e.g., OLSR introduced
REFRESH_INTERVAL so that all neighbors need not be reported every 
HELLO_PERIOD), I believe TBRPF still has several advantages over OLSR,
such as:

  - Less overhead, better performance in simulations (using old OLSR code).
  - Modular (1-hop) neighbor discovery.
  - Differential topology updates.
  - Avoids disadvantages of MPRs as discussed previously.
  - Parent computation based only on RIDs, avoiding the redundancy of 
    selecting MPRs to cover all 2-hop interfaces.  
  - Each HELLO sent on only one interface (like OSPF), reducing overhead.
  - Link metrics may be used to select better routes.
  - Note that TBRPF can employ hysteresis similar to OLSR.

Regards,
Richard

-----------------------
Richard Ogier
Sr. Research Engineer
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
Tel: 650-859-4216
Fax: 650-859-4812
Email: [email-masked]
------------------------

---

From: [email-masked]
Date: Sun, 14 Jul 2002 08:05:55 -0700

Regards,
Richard

-----------------------
Richard Ogier
Sr. Research Engineer
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
Tel: 650-859-4216
Fax: 650-859-4812
Email: [email-masked]
------------------------

---

From: John Tapsell <[email-masked]>
Date: Tue, 16 Jul 2002 16:11:09 +0100

Hi,
  What implementations (actual or simulators) are there for the various
ways of doing QoS on a manet?
  I couldn't find any code for QOSPF, and draft-zhang-qos-01.txt (or
something) has expired...
  I found a 2.2 implementation of RSVP over mobile ip, which isn't quite the
same as a manet - are there any dRSVP implementations or anything?

Thanks

JohnFlux

--

---

From: John Tapsell <[email-masked]>
Date: Tue, 16 Jul 2002 16:11:09 +0100

Hi,

Thanks

JohnFlux

--

---

From: "Philippe Jacquet" <[email-masked]>
Date: Tue, 23 Jul 2002 17:25:17 +0200

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 14, 2002 5:05 PM
Subject: Re: [manet] New OLSR draft

> to be reported, I'm glad to see that INRIA agrees with us.
Not really. As far as I understand TBRPF, an extra link is known by a remote
known only if there exists a chain of nodes from this link to the remote
node where all nodes agree adding this extra link in their respective
reported link sets.  In absence of a specified consensus protocol this may
be difficult to implement. In OLSR only the node which owns the link needs
to decide to advertize it or not. Adding extra links in the TC may be
triggered by local considerations such as:
-    willingness to act as a router
-    unreliable links needing back-up links
In the limit, the nodes can advertize their full neighborhood leading to
full topology knowledge in the network as with OSPF. The TC are greater and
similar to OSPF LSA, but the bandwidth is still saved since only MPRs
forward the information. The credits for this nice idea are to Joe Macker.

> an even bigger advantage in overhead.
Not exactly. The MPR_COVERAGE parameter is about the broadcast reliability
over MPRs. If the links to your MPRs are not reliable enough, then you may
need redundant MPR sets. The problem may be more critical for TBRPF since
you have less flexibility in parent selection (always select the node with
the smallest ID). Maybe it can be solved by selecting the k-smallest ID node
as parent, with k=MPR_COVERAGE.

Thank you for your interesting comment.

Regards,

Philippe

---

From: "Philippe Jacquet" <[email-masked]>
Date: Tue, 23 Jul 2002 17:25:17 +0200

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, July 14, 2002 5:05 PM
Subject: Re: [manet] New OLSR draft

Regards,

Philippe