Subject: RE: [Ospf-manet] evaluation plan for OSPF MANET

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 30 Nov 2005 22:00:24 -0800

> -----Original Message-----
> From: Abhay Roy [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2005 3:57 PM
> To: Henderson, Thomas R
> Cc: Richard Ogier; [email-masked]
> Subject: RE: [Ospf-manet] evaluation plan for OSPF MANET
> 
> As a default mode of operation (saving overhead) we suggested 
> that the flooding should NOT happen on Unsynchronized 
> Adjacency (UA) links. But then we did allow it as an optional 
> enhacement if it becomes valuable.
> 
> Note that the flooding or no flooding "mode" needs to be 
> consistent on all the nodes, since it influences the relay 
> election logic.
> 
> So yes, if we can use Hello's for 2-hop discovery, we might 
> be able to use some of the partial topology techniques with ORCAs.
> 
>
Abhay, it is not clear to me how they would interact.  From your recent
smart peering draft (section 4.4):

   "If flooding is disabled,
   then the relay election algorithm needs to prune neighbors that are
   connected via an Unsynchronized Adjacency from our 1-hop and 2-hop
   neighbor lists."

There seems to be a circular dependency in this process-- relays need to
be elected to disseminate the LSA information that is needed to
determine whether a neighbor is synchronized or unsynchronized
adjacency.  Or are initial relays perhaps deselected and the adjacencies
torn down once more network information is learned?

Can you explain in what order the following events take place, and
whether they are jointly decided?  Such as for a node that powers on in
an already established OSPF MANET?
- selection of relay set for the node
- decision (on a per-neighbor basis) whether to become adjacent or stay
"unsynchronized"
- decision of which neighbors to include in the router-LSA

Tom

p.s. "Unsynchronized Adjacency" seems to be a misnomer-- the nodes are
indirectly synchronized (via a multiple-hop path of other adjacencies),
but not really adjacent (FULL)

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

---

From: Richard Ogier <[email-masked]>
Date: Thu, 01 Dec 2005 23:43:04 -0800

>torn down once more network information is learned?

The circular dependence that Tom mentioned does not prevent the
protocol from working, since a neighbor will by default become
adjacent unless the router has received LSA information that indicates
there exists a synchronized path to the neighbor.
(Tom's comment may have implications in terms of performance,
but that would show up in simulations.)

Preferably, the flooding process and MPR selection should be
independent of the choice of LSAs (partial or full).
(Tom also mentioned this.)
This implies that full 2-hop neighbor information (from Hellos)
should be used to select MPRs, so that the 2-hop neighbor
information does not depend on the choice of LSAs.

This does not imply that the choice of MPRs must be independent
of which neighbors are adjacent, since the selection of adjacent
neighbors is independent of the choice of LSAs, assuming that LSAs
always contain fully adjacent neighbors.
So, it is OK to require MPRs to be adjacent neighbors (i.e.,
to exclude UA neighbors).

HOWEVER, this will mean that MPRs no longer provide min-hop
paths, which implies that LSAs based on MPRs cannot be used
for min-hop routing.  (But the min-cost LSAs of OSPF-MDR could
be used.)  This could also affect flooding performance, since
LSAs will no longer be flooded along min-hop paths.

Therefore, it seems like it is best to select MPRs based on
full 2-hop neighbor information from Hellos, and NOT to confine
MPRs and flooding to adjacent neighbors (i.e., not to disable
flooding on unsynchronized adjacencies).
On the other hand, there may also be drawbacks of selecting
MPRs independently of adjacencies, so it is not obvious
which way is better.  (Note that OSPF-MDR automatically selects
adjacencies to be aligned with MDRs.)

Richard

---

From: Richard Ogier <[email-masked]>
Date: Fri, 02 Dec 2005 09:21:08 -0800

>>>an already established OSPF MANET?

I will let Roy answer the above question, but this reminds me that
we need to include events of the above type in simulations!
It seems to me that the simulation statistics (in GTNetS) are
counted only after all nodes have joined the network.
Several months ago, we seemed to agree that the simulations
should have new nodes join the network and old nodes drop out.
For example, every 10 seconds we could have a new node
join the network and an old node drop out.

We might also simulate a few special scenarios to see how
the protocols perform in some circumstances that are not
represented by the random wavepoint model.
I also think we should consider non-mobile networks, i.e.
a node speed of zero. (The statistics would be averaged
over several different random topologies.)
With mobile networks, any problems that occur initially do
not show up in the statistics, but with non-mobile networks,
if relays and adjacencies are selected poorly initially,
then we are stuck with them for a long time.

Richard

---

From: Acee Lindem <[email-masked]>
Date: Tue, 06 Dec 2005 13:24:52 -0500

Hi Tom,
Since I was also involved in the Smart Peering draft, let me attempt to 
answer
the questions below.

>- selection of relay set for the node
The relay set selection is as it was before or precedence should be 
given to neighbors with whom
we already have adjacencies. I don't believe this has been done yet in 
our GTNetS modifications.
Once a neighbor is selected as a relay, an adjacency will be formed. 
This is what section 4.4 tries
to capture but the possibility of flooding to unsynchronized neighbors 
obscures that.  I think more
thought needs to go into the possibilty of selecting a node as a relay 
and flooding but not forming
an adjacency (section 4.3).

>- decision (on a per-neighbor basis) whether to become adjacent or stay
Depends on whether we are already connected via the SPT via synchronized 
paths. The draft
introduces other metrics (SPT cost or hop count) but these aren't in our 
GTNetS mods. Also,
the results we have obtained heretofore are without any pruning (which, 
as has been pointed
out before, either takes a lot of CPU or is a heuristic).

>- decision of which neighbors to include in the router-LSA
I'd say to advertise adjacencies and unsynchronized adjacencies  in 
order to provide
the best possible path.

Thanks,
Acee

---

From: Richard Ogier <[email-masked]>
Date: Sun, 11 Dec 2005 09:05:30 -0800

Acee,  I have a few question below.

Acee Lindem wrote:

> Hi Tom,
> Since I was also involved in the Smart Peering draft, let me attempt 
> to answer
> the questions below.
>
(snip)

> This is what section 4.4 tries 

I assume you mean that once a neighbor is selected as  a relay, the 
first adjacency
will be formed with that relay neighbor.  This will happen when 2-hop 
neighbor
information is received from some neighbor (in an LSA).  But how are 
LSAs received
reliably from neighbors if there are initially no adjacencies?  If you 
plan to have
nodes learn 2-hop neighbor info from Hellos, then that will help.  Also, 
since there
are no MPRs in a fully connected network, does that mean that 
adjacencies will never
be formed in such a network?  After the first adjacency is formed with 
the first
MPR, then do you wait for the adjacency to become full before deciding 
whether to
form an adjacency with another neighbor?  Or is an adjacency also formed 
with
the next MPR that is selected if the first adjacency is not yet full?
Is a neighbor *required* to be an MPR before an adjacency is formed with it?

Note that OSPF-MDR does not have any of these issues, and is more completely
specified, and has already been shown to perform well in networks with 
110 nodes.
So why is effort needed to come up with another solution?
Is this what people mean when they say "politics always wins"?
I have put a huge amount of effort into OSPF-MDR, for the sole purpose of
creating the best possible extension of OSPF to offer to the world, without
any IPR claims.  I was happy when Tom Henderson was selected to evaluate
the different proposals in a fair manner.  This gave me hope that maybe
the best solution would be selected.  But I am starting to believe
that the IETF may fail to provide the best solution.

More comments below.

> Depends on whether we are already connected via the SPT via 
> synchronized paths. The draft
> introduces other metrics (SPT cost or hop count) but these aren't in 
> our GTNetS mods. Also,
> the results we have obtained heretofore are without any pruning 
> (which, as has been pointed

I think this is a significant advantage of OSPF-MDR.  The pruning is 
straightforward
and is similar to what OSPF does in a broadcast network.  I.e., it is based
on the requirement that each adjacency must have an MDR or BMDR as one 
endpoint.

> I'd say to advertise adjacencies and unsynchronized adjacencies  in 

You are still using the term "unsynchronized adjacencies".  In OSPF, a 
neighbor
that is in state Exchange is adjacent, but is not yet synchronized.
That seems to make it an "unsynchronized adjacency".  But that does not
seem to agree with your definition.  Do you agree?

Richard

---

From: Acee Lindem <[email-masked]>
Date: Thu, 15 Dec 2005 15:56:49 -0500

Hi Richard,

Meant to respond to this earliar but am behind these days.

Richard Ogier wrote:

>> we already have adjacencies. I don't believe this has been done yet 
>> in our GTNetS modifications.
> nodes learn 2-hop neighbor info from Hellos, then that will help.  
> Also, since there
> form an adjacency with another neighbor?  Or is an adjacency also 
> formed with

Only nodes with whom we have adjacencies can be relays. All this says is 
that
an advertised 2-way neighbor cannnot be selected.

> that the IETF may fail to provide the best solution.

While there are differences in the fundamental flooding reduction and 
adjacency
reduction mechanisms, there are also some similarities (e.g., use of LLS 
and
advertisement of unsynchronized neighbors). My opinion is that the 
existance and
competition between the two proposals has made both of them better.

>
> More comments below.
>
>
>>
>> to capture but the possibility of flooding to unsynchronized 
>> neighbors obscures that.  I think more
>> thought needs to go into the possibilty of selecting a node as a 
>> relay and flooding but not forming

I agree that pruning is more simpler and more intuitive than with smart 
peering.  However,
what matters the most are the other metrics (overhead, delivery ratio, 
stretch factor) in
the various mobility scenarios.

> seem to agree with your definition.  Do you agree?

The term is used to describe a neighbor in 2-way state but less than
full state that is advertised for purposes of providing an optimal data
path. I believe that this is a component of both proposals.

Thanks,
Acee

---

From: Richard Ogier <[email-masked]>
Date: Tue, 20 Dec 2005 09:16:16 -0800

Acee, Please see my replies below.

 >> You are still using the term "unsynchronized adjacencies".  In OSPF, 
a neighbor

 > path. I believe that this is a component of both proposals.

Maybe I was not clear.
According to Section 4.3 of the smart peering draft, unsynchronized
adjacencies remain in the 2-way state, i.e., database synchronization
is postponed.  A neighbor in state Exchange need not be an
unsynchronized adjacency according to the definition in the draft,
but since it is considered an adjacency in RFC 2328, and is not yet
synchronized, it *is* an unsynchronized adjacency according to RFC 2328.
I am just saying that the term "unsynchronized adjacency" is not really
consistent with RFC 2328.  Note that the term "routable neighbor" in
the MDR draft consists of Full neighbors and what you call "unsynchronized
adjacencies".

adjacency
 > reduction mechanisms, there are also some similarities (e.g., use of 
LLS and
existance and
 > competition between the two proposals has made both of them better.

Yes, I agree that the competition has improved both drafts.  Cisco
seemed satisfied for a long time to use full-topology adjacencies,
until I proposed a partial-topology solution and introduced the concept
of routable neighbors in draft-ogier-manet-ospf-extension-03.txt and at
the IETF meeting on March 8 (the term "synchronized" neighbor was used
then, and was later changed to "routable" neighbor):

http://www3.ietf.org/proceedings/05mar/slides/ospf-5/sld9.htm

The smart peering draft was introduced on July 10.

What bothers me, though, is that I may end up getting no credit
for my contributions.  For example, the smart peering draft
cites only draft-spagnolo-manet-ospf-wireless-interface-01.txt,
as previous related work in which database exchange is not
performed, whereas the MDR draft is much more closely related,
since it used partial-topology adjacencies and introduced the
concept of routable neighbors.  But the smart peering draft does
not even mention my name or the MDR draft.
(Even though you could argue that your usage is different,
it seems that some recognition of the related previous work
is appropriate.)

BTW, thanks for mentioning my database exchange optimization
on the OSPF list.  This reduces the DD overhead by about 50%,
with no tradeoffs or drawbacks (since it simply avoids sending
unnecessary LSA headers).  Therefore, if is is applicable to
both proposals, then it should be used by both proposals
when evaluating them (e.g., in simulations).  Perhaps this will
be included in Cisco's proposal (with proper credit given).

Richard

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Dec 2005 15:59:56 -0500

Hi Richard,

Richard Ogier wrote:

> >> You are still using the term "unsynchronized adjacencies".  In 
> OSPF, a neighbor

Ok - I get what you are saying and think we should come up with a better 
term.
The important point is that connectivity to the neighbor is advertised 
even though
the state < FULL. However, as adjacency is defined (for flooding 
purposes) as
soon as the EXCHANGE state is reached.

>
>
> > While there are differences in the fundamental flooding reduction 
> and adjacency

I didn't follow the chronology closely but the internal discussion of
smart peering overlapped both your draft and the smart peering. My
apologies for the oversight of not mentioning this work. Much of the
draft was copied from an earliar unpublished document.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Dec 2005 16:06:09 -0500

Hello again,

One more comment. .

Acee Lindem wrote:

> Ok - I get what you are saying and think we should come up with a 
> better term.
>> > reduction mechanisms, there are also some similarities (e.g., use 
>> of LLS and
This is definitely a mechanism that is applicable to non-MANET
environments as well. I'd truly like to see as much common ground
as possible in the OSPF MANET extensions. I also will work to
assure the origins of the mechanisms are honestly represented.

Thanks,
Acee