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

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 09 Dec 2005 13:55:49 +0100

>> IMO this is rather important point. If only synchronized adjacencies 
>> are to be advertized and used for routing,
>> then we have to be very careful about route stretching if topology 
>> reduction is used based on a CDS backbone.
>> Basically, using only synchronized adjcencies for routing may 
>> invalidate CDS topology reduction approaches.
>> The only known topology reduction that can then be envisionned is to 
>> reduce topology to MPR selection adjacencies,
>> which may yield more adjacencies but will anyways keep optimal paths.
>
>
> To see how this works, I would like to consider a simple example: A 
> fully connected
> (single-hop) MANET.  In such a network, there are no MPRs or MPR 
> selectors.
> The good news is that for this simple example your approach does NOT 
> yield more
> adjacencies than the CDS approach. The bad news is that your approach 
> yields
> ZERO adjacencies, so an OSPF extension based on your approach does not 
> work.

Are you here talking about a MANET that is disconnected from the 
Internet? In this case,
this example is not so relevant. In my opinion, adjacencies are 
important for compatibility with regular
OSPF, as an OSPF MANET is connected to a traditional OSPF network. Hybrid
nodes (nodes which run OSPF on wireless interfaces as well as on other 
types of interfaces)
should then become adjacent with all their wireless neighbours, a fact 
that ensures that :

(i) there are adjacencies even in the special full-meshed case you have 
mentionned,
(ii) the graph of MPR selection adjacencies is guaranteed to be 
connected, and
(iii) the routes across traditional and wireless parts of OSPF are 
optimal, even with MPR topology reduction.

We have observed that using all the hybrid adjacencies do not yield a 
significant increase in overhead.
About the last point (iii) if a design is based on routes that are not 
using only adjacencies (therefore using links that are not advertized)
routes will suffer some stretch factor, especially if you consider 
routes from wired parts to wireless parts of
the OSPF network, in which case it may yield substantially longer routes.

> For general topologies, your approach still does not work, since the 
> resulting
> adjacency graph is not guaranteed to be connected. I previously gave 
> some examples
> on the design team list.  I also described a variation of the approach 
> that does
> work, but my simulations showed that it resulted in many more 
> adjacencies than
> OSPF-MDR.  More importantly, it resulted in a much higher rate of new 
> adjacencies
> than OSPF-MDR.  This is important because database exchange is 
> required for each
> new adjacency.  Anyway, if you have a detailed spec for such a 
> solution, then maybe
> it can be implemented in GTNetS and evaluated.  Cisco is designing a 
> solution based
> on MPRs, but apparently they have decided not to take the approach you 
> suggest
> (maybe for the reasons I give above?).
>
> Another relevant point is that OSPF already allows a non-adjacent 
> neighbor to
> be used as a next hop in a broadcast network (if the router and 
> neighbor are
> both fully adjacent with the DR). So if OSPF allows it, it is 
> reasonable for
> the OSPF extension to allow it.  We have made these points before on the
> design team list.
>
> Richard

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

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 09 Dec 2005 14:46:20 +0100

Dear all,

Just adding my penny. I have been very surprised that most the 
discussions and simulations produced so far on the wireless OSPF design 
have been exclusively devoted to the wireless part. This should not be a 
MANET discussion, the wireless part is connected to wired parts and the 
main question should be how the wired part will see the wireless part, 
and how the wireless part will see the wired part, and how to make them 
working together the most efficient possible way under OSPF. I have a 
tendancy to see the discussion heading toward the design of a new MANET 
protocol.

Best regards,
Philippe

Emmanuel Baccelli wrote:

>> ZERO adjacencies, so an OSPF extension based on your approach does 
>> not work.
>
>
>
> (i) there are adjacencies even in the special full-meshed case you 
> have mentionned,
>> on the design team list.  I also described a variation of the 
>> approach that does
>> on MPRs, but apparently they have decided not to take the approach 
>> you suggest

---

From: Abhay Roy <[email-masked]>
Date: Fri, 9 Dec 2005 10:05:45 -0800 (PST)

I am not sure why is this subject of so much interest. The designs 
so far are merely extending OSPF to allow for a new interface type, 
which is capable of doing optimized flooding (and other tweaks) when 
it speaks on the wireless side. The way we represent the wireless 
peerings is fully compatible (looks like p2mp) on the wired side 
peers, and no OSPF change is necessary.

This was one of the hard requirements laid out when the design team 
was formed, that the extensions should seamlessly work with existing 
ospf (wired) deployments.

Regards,
-Roy-

On 12/09/05+0100 at 2:46pm, Philippe Jacquet writes:

> Dear all,
>
> Just adding my penny. I have been very surprised that most the discussions 
> and simulations produced so far on the wireless OSPF design have been 
> exclusively devoted to the wireless part. This should not be a MANET 
> discussion, the wireless part is connected to wired parts and the main 
> question should be how the wired part will see the wireless part, and how the 
> wireless part will see the wired part, and how to make them working together 
> the most efficient possible way under OSPF. I have a tendancy to see the 
> discussion heading toward the design of a new MANET protocol.
>
> Best regards,
> Philippe
>
> Emmanuel Baccelli wrote:
>
>> 
>>  Are you here talking about a MANET that is disconnected from the Internet?
>>  In this case,
>>  this example is not so relevant. In my opinion, adjacencies are important
>>  for compatibility with regular
>>  (ii) the graph of MPR selection adjacencies is guaranteed to be connected,
>>  and
>>  routes will suffer some stretch factor, especially if you consider routes
>>  from wired parts to wireless parts of
>> >  than OSPF-MDR.  This is important because database exchange is required 
>> >  for each
>> >  new adjacency.  Anyway, if you have a detailed spec for such a solution, 
>> >  then maybe
>> >  be used as a next hop in a broadcast network (if the router and neighbor 
>> >  are
>> >  both fully adjacent with the DR). So if OSPF allows it, it is reasonable 
>> >  for

---

From: Emmanuel Baccelli <[email-masked]>
Date: Sat, 10 Dec 2005 02:40:49 +0100

Without partial topology, there isn't any interest in this subject, 
agreed. But once we start looking at partial topology, it is interesting 
to know how this will integrate with wired part. It is interesting to 
control how much routing inefficiency (if at all) is induced accross the 
whole OSPF network (wired and wireless parts included).

Emmanuel

Abhay Roy wrote:

> I am not sure why is this subject of so much interest. The designs so 
> far are merely extending OSPF to allow for a new interface type, which 
> is capable of doing optimized flooding (and other tweaks) when it 
> speaks on the wireless side. The way we represent the wireless 
>> discussions and simulations produced so far on the wireless OSPF 
>> design have been exclusively devoted to the wireless part. This 
>> should not be a MANET discussion, the wireless part is connected to 
>> wired parts and the main question should be how the wired part will 
>> see the wireless part, and how the wireless part will see the wired 
>> part, and how to make them working together the most efficient 
>> possible way under OSPF. I have a tendancy to see the discussion 
>> heading toward the design of a new MANET protocol.
>>
>> Best regards,
>> Philippe
>>
>> Emmanuel Baccelli wrote:
>>
>>>
>>> > >  IMO this is rather important point. If only synchronized 
>>> adjacencies > >  are to be advertized and used for routing,
>>> > >  then we have to be very careful about route stretching if 
>>> topology > >  reduction is used based on a CDS backbone.
>>> > >  Basically, using only synchronized adjcencies for routing may > 
>>> > >  The only known topology reduction that can then be envisionned 
>>> is to > >  reduce topology to MPR selection adjacencies,
>>> > > > >  To see how this works, I would like to consider a simple 
>>> example: A >  fully connected
>>> >  The good news is that for this simple example your approach does 
>>> NOT >  yield more
>>> >  adjacencies than the CDS approach. The bad news is that your 
>>> approach >  yields
>>> >  ZERO adjacencies, so an OSPF extension based on your approach 
>>> does not >  work.
>>>
>>>
>>>
>>> Internet?
>>> have
>>> connected,
>>> >  For general topologies, your approach still does not work, since 
>>> the >  resulting
>>> >  adjacency graph is not guaranteed to be connected. I previously 
>>> gave >  some examples
>>> approach >  that does
>>> >  work, but my simulations showed that it resulted in many more >  
>>> adjacencies than
>>> >  OSPF-MDR.  More importantly, it resulted in a much higher rate of 
>>> new >  adjacencies
>>> required >  for each
>>> solution, >  then maybe
>>> >  it can be implemented in GTNetS and evaluated.  Cisco is 
>>> designing a >  solution based
>>> >  on MPRs, but apparently they have decided not to take the 
>>> approach you >  suggest
>>> > >  Another relevant point is that OSPF already allows a 
>>> non-adjacent >  neighbor to
>>> neighbor >  are
>>> reasonable >  for