Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt

From: [email-masked]
Date: Tue, 18 Mar 2003 10:32:27 -0800

All,

Section 5.4 (TC Message Generation) of the OLSR draft says: 

"The list of addresses can be partial in each TC message (e.g. due to
message size limitations, imposed by the network), but parsing of all
TC messages describing the advertised link set of a node MUST be
complete within a certain refreshing period (TC_INTERVAL)."

"Parsing" is usually done when a message is received, not sent.
Should this be changed to "generating"?  Since messages are not 
sent reliably, a node might not even *receive* all of the partial 
TC messages describing the advertised link set of a node, so it 
cannot be required to parse all of them.

This can cause a problem when processing partial TC messages,
since step 3 of Section 5.6 (TC Message Processing) says that
upon receiving a TC message with higher sequence number, all
tuples in the topology set with lower sequence numbers MUST be 
removed.  Suppose, for example, that the advertised link set of
some node U is broken into 5 partial TC messages, with 1 second
between consecutive messages.  Also suppose that topology changes
are frequent enough so that some change to the advertised link set
occurs at least once during each TC_INTERVAL = 5 sec (so that the 
sequence number is incremented).  As soon as the first partial TC 
message with a higher sequence number is received by some node I, 
node I must remove all tuples originating from U that are not 
included in that first partial TC message.  Node I will then not 
have all of the tuples for U until 4 seconds later, shortly before 
the sequence number is incremented again.  Also, it is possible
that not all of the 5 partial TC messages are received by node I.
Thus, node I unnecessarily deletes useful topology information, 
which can result in the loss of routes to some destinations.

OSPF for IPv6 avoids this problem for Router LSAs by using 
Link-State IDs, and for Network LSAs by not allowing them to be partial.  
Similarly, OLSR could be fixed by assigning different Link-State IDs to 
different subsets of the advertised link set (to allow partial TC messages), 
or by requiring each TC message to include the entire advertised link set
(i.e., don't allow partial TC messages).  

In order to truly allow differential topology updates, e.g., to report 
a single link failure immediately without having to send a full update, 
it must be possible for a node to process such a differential update 
without deleting all previously received updates originating from 
the same node. TBRPF does this by using a combination of differential
updates (including delete updates) and periodic full updates.

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]
------------------------
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 19 Mar 2003 20:40:58 +0100

Well, it looks like a non-issue. A TC which contains only the
originator MPR selector set should fit the MTU limitation. If the
avertized set contains more than the MPR selector set and does not
fit the MTU limitation, then a node should first send a TC with the
new MPR selector set (such that routes through the originator of the TC
are immediately available), then send the remans of the advertized
link set in other TC's with small interval jitters.

On the other hand, I don't think it is safe to mixte differential updates
with full
updates, this may lead to unconsistency problems.

Philippe

---

From: [email-masked]
Date: Wed, 19 Mar 2003 13:14:38 -0800

> link set in other TC's with small interval jitters.

A node with a large value for Willingness might have an MPR selector
set that includes all of its neighbors, which might not fit the MTU 
limitation.  So, OLSR must either limit the number of neighbors that
can be reported as MPR selectors, or must sometimes send TC messages
that do not include the entire MPR selector set (resulting in the
temporary deletion of useful information), or must sometimes 
require IP fragmentation (no big deal if only two packets).

In any case, some change to the OLSR draft is needed, such as:
"A TC Message with a new sequence number SHOULD include the entire MPR 
selector set whenever possible."

> with full updates, this may lead to unconsistency problems.

It can be done safely if you are careful (e.g., as in TBRPF and DSDV).
Since the full updates are periodic, all nodes will
eventually have the correct information even if some 
packets are not received, or are received out of order.

Regards,
Richard

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 20 Mar 2003 18:23:55 +0100

On Wed, 19 Mar 2003 13:14:38 -0800
[email-masked] wrote:

<SNIP>
 
> "A TC Message with a new sequence number SHOULD include the entire
> MPR selector set whenever possible."

No need. As you said yourself: "since the full updates are periodic,
all nodes will eventually have the correct information even if some
packets are not received, or are received out of order."

--thomas

---

From: [email-masked]
Date: Thu, 20 Mar 2003 10:18:34 -0800

> packets are not received, or are received out of order."

But according to the OLSR draft, TC Messages don't have to be full,
they can be partial.  Someone might think it is OK to report
a single link addition  (i.e., a differential update),
which would imply that all the other links (MPR selectors)
should be deleted.  So there needs to be a statement that
TC messages should be full when possible.

Richard