Subject: Re: [manet] OLSRv2 - suggestions for enhancing message forwarding

From: Richard Ogier <[email-masked]>
Date: Fri, 01 May 2009 15:04:46 -0700

Teco Boot wrote:

>On the second case, think of:
> - There is no symmetric neighbor on this interface
> - There is only one symmetric neighbor on this interface,
>   and the to be relayed message was received on this interface
> - All neighbors on this interface report full connectivity
>   to all other neighbors on this interface, and the to be 
>   relayed message was received on this interface
>The check is: does relay the message on this interface results to
>reception on a node, that did not received the message before? 
>If the answer is no, the message SHOULD NOT be relayed on this
>interface. Looks like a no-brainer to me.
>  
>

Indeed this is a no-brainer, and OSPF-MDR does this. At first, I didn't
think it would help much with MPRs, since no MPRs would be selected in
the cases you mention above if there is only a single interface.
However, if there are two interfaces then there can be lots of MPRs.
For example, suppose a MANET has 100 nodes that are all neighbors
of each other, and suppose each node also has another interface that
is connected to a local network. Then the MPR properties in Section 14
imply that every node must select every other node as an MPR!
Furthermore, if one of the nodes originates a TC message, then the
other 99 nodes must forward the TC message on both interfaces!
Wow. It's good that you pointed this out before the RFC is published.

Obviously something needs to be changed. Personally, I prefer your
scheme that uses multiple MPR types, so that in the above example,
all MPRs would be of type MPR_other_interfaces. But the above
check should be done anyway, in case some routers choose not to
use multiple MPR types.

Richard

>There is no need for mathematical proof for the enhanced MPR 
>selection mechanism, as it complies with the MPR selection
>criteria. It is just more selective.
>  
>
>>For each OLSRv2 interface a router MUST select a set of MPRs.  This
>>set MUST have the properties that:
>>
>>o  All of the selected MPRs are willing symmetric 1-hop neighbors,
>>   AND;
>>
>>o  If the selecting router sends a message on that OLSRv2 interface,
>>   and that message is successfully forwarded by all of the selected
>>   MPRs for that interface, then all symmetric strict 2-hop neighbors
>>   of the selecting router through that OLSRv2 interface will receive
>>   that message on a symmetric link.
>>    
>>
>
>Maybe there is an additional requirement for MPR selection that I am
>not aware of. In that case, it shall be added in the draft.
>
>If not, I prefer modifying the OLSRv2 mechanism for supporting the 4 mode
>MPR selection status. Nodes are free to use it or not; i.e. use only the
>no_MPR and
>MPR_all_interfaces.
>Populating the Advertised Neighbor Set is not affected, all MPR selectors
>must be included; i.e. MPR_this_interface, MPR_other_interfaces and
>MPR_all_interfaces.
>
>
>Teco.
>
> 
>|
>|I'm afraid I'm not going to work through your second case.
>|I'm not interested in ad hoc "this might work" modifications
>|of the MPR flooding until backed by a mathematical proof that
>|there are no problems. We've seen enough examples of ideas
>|that look plausible but actually fail.
>|
>|--
>|Christopher Dearlove
>|Technology Leader, Communications Group
>|Networks, Security and Information Systems Department
>|BAE Systems Advanced Technology Centre
>|West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
>|Tel: +44 1245 242194  Fax: +44 1245 242124
>|
>|BAE Systems (Operations) Limited
>|Registered Office: Warwick House, PO Box 87,
>|Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
>|Registered in England & Wales No: 1996687
>|
>|-----Original Message-----
>|From: [email-masked] [mailto:[email-masked]] On Behalf
>|Of Teco Boot
>|Sent: 23 April 2009 11:10
>|To: [email-masked]
>|Subject: [manet] OLSRv2 - suggestions for enhancing message forwarding
>|
>|
>|                    *** WARNING ***
>|
>|  This message has originated outside your organisation,
>|  either from an external partner or the Global Internet.
>|      Keep this in mind if you answer this message.
>|
>|
>|Here two suggestions for enhancing message forwarding:
>|
>|
>|Missed 1-hop TC:
>|================
>|
>|If the following condition for a received message is true:
>|
>|   msg-orig-addr is a MPR selector,
>|   source address of message is not MPR selector,
>|   message is not seen before,
>|
>|the message is discarded. However, this is a message that
>|should have been received, or is to be received soon. Repair
>|of loss of messages sent from a first hop neighbors could be
>|beneficial for loop prevention.
>|
>|Suggested change: relay such a message.
>|
>|
>|
>|Eliminate useless relaying:
>|===========================
>|
>|If the relaying node has the same set of symmetric neighbors
>|or a subset symmetric neighbors on this link than the MPR
>|selector, relaying messages received from this MPR selector
>|on this link is not useful.
>|
>|Suggested change: Do not relay messages from such a MPR
>|selector on the link which the message was received on.
>|
>|Alternative approach:
>| o  Introduce manually configured interface type:
>|        full-connected [ no | yes ]
>| o  Enhance MPR selection and signaling algorithm,
>|    with MPR types:
>|         [ no_MPR | MPR_this_interface |
>|           MPR_other_interfaces | MPR_all_interfaces ]
>|    MPR selection shall guarantee that all 2-hop neighbors
>|    receive the message at least once.
>|
>|Here a scenario where the enhanced MPR selection would
>|benefit a lot:
>|
>|
>|                 **R7
>|                 *
>|        ________R4
>|       /        /
>| R1-----------R2-------\
>|**     \      |*        |
>|*       \     | *R10    |
>|*        \    |         |
>|*         -----R3-------R5**R8
>|R9              *
>|                **R6
>|
>|Lines: low bandwidth - long reach, e.g. UHF low
>|Asterisks: high bandwidth - short range, e.g. UHF high
>|
>|On |-segment, R1 selects R2 as MPR_all_interfaces and (R4, R3) as
>|MPR_other_interfaces. R2 selects (R1, R3, R4, R5) as
>|MPR_other_interfaces.
>|
>|Scenario: R9 sends TC message.
>|R1 relays TC.
>|R4, R2 and R3 receive this TC in parallel, all relay
>|    on *-interface. Only R2 relays on |-interface.
>|R5 receives TC from R2 and relays on *-interface only.
>|
>|The TC is sent 2 times (instead of 5) on the |-segment.
>|
>|
>|Thoughts?
>|
>|Teco.
>|
>|
>|
>|_______________________________________________
>|manet mailing list
>[email-masked]
>|https://www.ietf.org/mailman/listinfo/manet
>|
>|
>|********************************************************************
>|This email and any attachments are confidential to the intended
>|recipient and may also be privileged. If you are not the intended
>|recipient please delete it from your system and notify the sender.
>|You should not copy it or use it for any purpose nor disclose or
>|distribute its contents to any other person.
>|********************************************************************
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/manet
>
>  
>

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 2 May 2009 09:27:46 +0200

Thanks for the support.
Yes, in some scenarios the enhancement is very helpful. I think it is
important.
FYI, recent olsr.org code supports a manual configured interface type,
similar to ospf interface types "manet" and "broadcast". 
My proposal does not need configuration and works better. At cost of
(optional) slightly increased signaling and the logic for selecting the 3
types of MPRs (also optional).
Teco.

|-----Oorspronkelijk bericht-----
|Van: Richard Ogier [mailto:[email-masked]]
|Verzonden: zaterdag 2 mei 2009 0:05
|Aan: Teco Boot
|CC: 'Dearlove, Christopher (UK)'; [email-masked]
|Onderwerp: Re: [manet] OLSRv2 - suggestions for enhancing message
|forwarding
|
|Teco Boot wrote:
|
|>On the second case, think of:
|> - There is no symmetric neighbor on this interface
|> - There is only one symmetric neighbor on this interface,
|>   and the to be relayed message was received on this interface
|> - All neighbors on this interface report full connectivity
|>   to all other neighbors on this interface, and the to be
|>   relayed message was received on this interface
|>The check is: does relay the message on this interface results to
|>reception on a node, that did not received the message before?
|>If the answer is no, the message SHOULD NOT be relayed on this
|>interface. Looks like a no-brainer to me.
|>
|>
|
|Indeed this is a no-brainer, and OSPF-MDR does this. At first, I didn't
|think it would help much with MPRs, since no MPRs would be selected in
|the cases you mention above if there is only a single interface.
|However, if there are two interfaces then there can be lots of MPRs.
|For example, suppose a MANET has 100 nodes that are all neighbors
|of each other, and suppose each node also has another interface that
|is connected to a local network. Then the MPR properties in Section 14
|imply that every node must select every other node as an MPR!
|Furthermore, if one of the nodes originates a TC message, then the
|other 99 nodes must forward the TC message on both interfaces!
|Wow. It's good that you pointed this out before the RFC is published.
|
|Obviously something needs to be changed. Personally, I prefer your
|scheme that uses multiple MPR types, so that in the above example,
|all MPRs would be of type MPR_other_interfaces. But the above
|check should be done anyway, in case some routers choose not to
|use multiple MPR types.
|
|Richard
|
|>There is no need for mathematical proof for the enhanced MPR
|>selection mechanism, as it complies with the MPR selection
|>criteria. It is just more selective.
|>
|>
|>>For each OLSRv2 interface a router MUST select a set of MPRs.  This
|>>set MUST have the properties that:
|>>
|>>o  All of the selected MPRs are willing symmetric 1-hop neighbors,
|>>   AND;
|>>
|>>o  If the selecting router sends a message on that OLSRv2 interface,
|>>   and that message is successfully forwarded by all of the selected
|>>   MPRs for that interface, then all symmetric strict 2-hop neighbors
|>>   of the selecting router through that OLSRv2 interface will receive
|>>   that message on a symmetric link.
|>>
|>>
|>
|>Maybe there is an additional requirement for MPR selection that I am
|>not aware of. In that case, it shall be added in the draft.
|>
|>If not, I prefer modifying the OLSRv2 mechanism for supporting the 4
|mode
|>MPR selection status. Nodes are free to use it or not; i.e. use only
|the
|>no_MPR and
|>MPR_all_interfaces.
|>Populating the Advertised Neighbor Set is not affected, all MPR
|selectors
|>must be included; i.e. MPR_this_interface, MPR_other_interfaces and
|>MPR_all_interfaces.
|>
|>
|>Teco.
|>
|>
|>|
|>|I'm afraid I'm not going to work through your second case.
|>|I'm not interested in ad hoc "this might work" modifications
|>|of the MPR flooding until backed by a mathematical proof that
|>|there are no problems. We've seen enough examples of ideas
|>|that look plausible but actually fail.
|>|
|>|--
|>|Christopher Dearlove
|>|Technology Leader, Communications Group
|>|Networks, Security and Information Systems Department
|>|BAE Systems Advanced Technology Centre
|>|West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
|>|Tel: +44 1245 242194  Fax: +44 1245 242124
|>|
|>|BAE Systems (Operations) Limited
|>|Registered Office: Warwick House, PO Box 87,
|>|Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
|>|Registered in England & Wales No: 1996687
|>|
|>|-----Original Message-----
|>|From: [email-masked] [mailto:[email-masked]] On Behalf
|>|Of Teco Boot
|>|Sent: 23 April 2009 11:10
|>|To: [email-masked]
|>|Subject: [manet] OLSRv2 - suggestions for enhancing message forwarding
|>|
|>|
|>|                    *** WARNING ***
|>|
|>|  This message has originated outside your organisation,
|>|  either from an external partner or the Global Internet.
|>|      Keep this in mind if you answer this message.
|>|
|>|
|>|Here two suggestions for enhancing message forwarding:
|>|
|>|
|>|Missed 1-hop TC:
|>|================
|>|
|>|If the following condition for a received message is true:
|>|
|>|   msg-orig-addr is a MPR selector,
|>|   source address of message is not MPR selector,
|>|   message is not seen before,
|>|
|>|the message is discarded. However, this is a message that
|>|should have been received, or is to be received soon. Repair
|>|of loss of messages sent from a first hop neighbors could be
|>|beneficial for loop prevention.
|>|
|>|Suggested change: relay such a message.
|>|
|>|
|>|
|>|Eliminate useless relaying:
|>|===========================
|>|
|>|If the relaying node has the same set of symmetric neighbors
|>|or a subset symmetric neighbors on this link than the MPR
|>|selector, relaying messages received from this MPR selector
|>|on this link is not useful.
|>|
|>|Suggested change: Do not relay messages from such a MPR
|>|selector on the link which the message was received on.
|>|
|>|Alternative approach:
|>| o  Introduce manually configured interface type:
|>|        full-connected [ no | yes ]
|>| o  Enhance MPR selection and signaling algorithm,
|>|    with MPR types:
|>|         [ no_MPR | MPR_this_interface |
|>|           MPR_other_interfaces | MPR_all_interfaces ]
|>|    MPR selection shall guarantee that all 2-hop neighbors
|>|    receive the message at least once.
|>|
|>|Here a scenario where the enhanced MPR selection would
|>|benefit a lot:
|>|
|>|
|>|                 **R7
|>|                 *
|>|        ________R4
|>|       /        /
|>| R1-----------R2-------\
|>|**     \      |*        |
|>|*       \     | *R10    |
|>|*        \    |         |
|>|*         -----R3-------R5**R8
|>|R9              *
|>|                **R6
|>|
|>|Lines: low bandwidth - long reach, e.g. UHF low
|>|Asterisks: high bandwidth - short range, e.g. UHF high
|>|
|>|On |-segment, R1 selects R2 as MPR_all_interfaces and (R4, R3) as
|>|MPR_other_interfaces. R2 selects (R1, R3, R4, R5) as
|>|MPR_other_interfaces.
|>|
|>|Scenario: R9 sends TC message.
|>|R1 relays TC.
|>|R4, R2 and R3 receive this TC in parallel, all relay
|>|    on *-interface. Only R2 relays on |-interface.
|>|R5 receives TC from R2 and relays on *-interface only.
|>|
|>|The TC is sent 2 times (instead of 5) on the |-segment.
|>|
|>|
|>|Thoughts?
|>|
|>|Teco.
|>|
|>|
|>|
|>|_______________________________________________
|>|manet mailing list
|>[email-masked]
|>|https://www.ietf.org/mailman/listinfo/manet
|>|
|>|
|>|********************************************************************
|>|This email and any attachments are confidential to the intended
|>|recipient and may also be privileged. If you are not the intended
|>|recipient please delete it from your system and notify the sender.
|>|You should not copy it or use it for any purpose nor disclose or
|>|distribute its contents to any other person.
|>|********************************************************************
|>
|>_______________________________________________
|>manet mailing list
|>[email-masked]
|>https://www.ietf.org/mailman/listinfo/manet
|>
|>
|>

---

From: Henning Rogge <[email-masked]>
Date: Sat, 2 May 2009 09:34:27 +0200

> types of MPRs (also optional).
The idea behind this "interface mode" is that Freifunk/Funkfeuer networks 
often have several 1-mac80211-interface routers connected by ethernet. Because 
ethernet has a closed broadcast domain, you don't need to send a received OLSR 
package from the ethernet interface back into it (everyone already got it).

Henning

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 2 May 2009 12:36:42 +0200

This is the classical "back-to-back radio relay" topology,
that is often used in military networks. The enhancement
is not that important for Ethernets, as there would not be
a constraint in capacity.
Where a wireless segment connects many of these clustered
routers, all routers on the segment become MPR, for both 
the Ethernet and "back to the wireless segment" interfaces. 
Here, the unneeded overhead is unacceptable, especially where 
low capacity - long range radios are used in a segment with 
large number of the clustered routers.

My proposal makes the "interface type" self-learning.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: zaterdag 2 mei 2009 9:34
|Aan: [email-masked]
|CC: Teco Boot; 'Richard Ogier'; 'Dearlove, Christopher (UK)'
|Onderwerp: Re: [manet] OLSRv2 - suggestions for enhancing message
|forwarding
|
|On Samstag 02 Mai 2009 09:27:46 Teco Boot wrote:
|> Thanks for the support.
|> Yes, in some scenarios the enhancement is very helpful. I think it is
|> important.
|> FYI, recent olsr.org code supports a manual configured interface type,
|> similar to ospf interface types "manet" and "broadcast".
|> My proposal does not need configuration and works better. At cost of
|> (optional) slightly increased signaling and the logic for selecting
|the 3
|> types of MPRs (also optional).
|> Teco.
|The idea behind this "interface mode" is that Freifunk/Funkfeuer
|networks
|often have several 1-mac80211-interface routers connected by ethernet.
|Because
|ethernet has a closed broadcast domain, you don't need to send a
|received OLSR
|package from the ethernet interface back into it (everyone already got
|it).
|
|Henning

---

From: Richard Ogier <[email-masked]>
Date: Sat, 02 May 2009 10:25:06 -0700

>My proposal makes the "interface type" self-learning.

Absolutely.  Often it won't be known in advance whether a MANET
will form a single hop network (with diameter 1).
But even if the MANET has diameter 2, routers that are not on
the edge will still have a neighbor set that includes all other
routers on the MANET segment, so both of the proposed modifications
will still help a lot.

Moreover, the scheme with multiple MPR types can be very helpful
even if the MANET segment has a large diameter.  This is because
each MANET router will still select all MANET neighbors as MPRs
(because of the Ethernet interfaces).  With the proposed scheme,
only a few of these neighbors will be of type MPR_all_interfaces,
and the rest will be of type MPR_other_interfaces.

Richard

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 5 May 2009 09:31:09 +0100

> imply that every node must select every other node as an MPR!

Nonsense. Each node advertises that local interface as a local
non-MANET interface, and then no node has any strict two hop
neighbours, and no MPRs are selected.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 6 May 2009 08:19:38 +0200

|> For example, suppose a MANET has 100 nodes that are all neighbors
|> of each other, and suppose each node also has another interface that
|> is connected to a local network. Then the MPR properties in Section 14
|> imply that every node must select every other node as an MPR!
|
|Nonsense. Each node advertises that local interface as a local
|non-MANET interface, and then no node has any strict two hop
|neighbours, and no MPRs are selected.

It depends. When the local interface is used for attachment of 
other MANET routers, then of course it shall be configured as
a MANET interface.

If it is a MANET interface, and no other MANET router is attached,
there is no 2-hop neighbor on it and thus it does not affect MPR
selection. Why did you think so?

This MANET interface without a connected MANET router is an example
of useless relaying, when the MANET router was selected as MPR.
I suggested an enhancement that relaying only takes place to MANET
interfaces that have symmetric neighbor(s).

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 May 2009 09:34:33 +0100

> other MANET routers, then of course it shall be configured as

That's not the scenario I commented on, which says "local network".
Another MANET router is not a local network.

> selection. Why did you think so?

I didn't. I pointed out that the sensible configuration involves
no MPRs.

---

From: Richard Ogier <[email-masked]>
Date: Wed, 06 May 2009 23:25:58 -0700

Dearlove, Christopher (UK) wrote:

>>|> is connected to a local network. Then the MPR properties in Section
>>    
>>
>14
>  
>

OK, we are using the term "local" in different ways.  It is easy to
modify the scenario slightly to make the same point.  Just replace
"local network" with a short-range MANET segment.  Thus, there is
a long-range MANET segment, and each router attached to this
segment is also attached to a short-range segment.

More specifically, consider a MANET with two segments: short range
and long range.  All nodes have a short-range interface,
but only half the nodes have a long-range interface.
The long-range segment has diameter 1, and the short-range
segment has a much larger diameter (and might not be connected).
Each node with a long-range interface will select a large number
of neighbors as MPRs, to cover all 2-hop neighbors that do not
have a long-range interface.  These MPRs will forward each
TC message on *both* interfaces, even though all neighbors
on the long-range interface already received the message.
With Teco's proposal, all MPRs on the long-range interface
will be of type MPR_other_interfaces, thus avoiding this
unnecessary flooding.

As already mentioned, the proposed scheme can greatly improve
efficiency even if the diameter of the long-range segment is
greater than 1.

Richard

---

From: Philippe Jacquet <[email-masked]>
Date: Thu, 07 May 2009 13:34:56 +0200

Hello,

We are no longer discussing MPR per node versus interface? It seems to 
me that the discussion is now clearly in favor of per interface 
selection, or am I wrong?

I don't understand well the example of Richard, because I didn't follow 
well the thread. If nodes are in different segments, then we have a 
MANET as a transit network, and there will be default routes toward each 
segment, no needs to share TC's between the segments.

If nodes are systematically connected to two segments, then wouldn't it 
be equivalent to have a single MANET with two kinds of interfaces? And 
in this case the MPRs that cover the two hop neighbors on the slow 
interface will likely cover the two hop neighbors on the fast interface 
and there is an advantage to retransmit on both interfaces.

In the exotic case of a MANET with several distinct segments within 
which we would like to anyhow share TC's, there could be some economy in 
distinguishing MPR wrt to output interface, in the case where one 
neighbor is the only neighbor to a two hop neighbor and this on another 
interface.

That means that we would like to tell a node that it is a kind of 
restricted MPR, by identifying the interface(s) where it is authorized 
to retransmit, or conversely where it should not retransmit. It seems 
this may introduce an increasing signaling complexity for some non 
scalable cases.

We could also complicate the problem by distinguishing the 
retransmission with respect to the input interface and notify to the 
selected MPR the rule of retransmission as a boolean matrix of input 
interfaces and output interfaces.

Best regards,
Philippe

Richard Ogier a écrit :
>>> It depends. When the local interface is used for attachment of other 
>>> MANET routers, then of course it shall be configured as
>>> a MANET interface.
>>>   
>>

---

From: Richard Ogier <[email-masked]>
Date: Fri, 08 May 2009 00:15:50 -0700

> selection, or am I wrong?

I think that OLSRv2 should allow the option of selecting MPRs without 
requiring 2-hop neighbors to be redundantly covered by MPRs on all 
possible interfaces.  Thus, I don't think that the router should be 
required to select a *complete* set of MPRs for each interface.  There 
is still a (possibly incomplete) set of MPRs for each interface.  One 
reason given for this requirement was the race condition, but there are 
other ways to avoid this problem (e.g., using jitter or giving priority 
to "better" interfaces), so it should be possible to remove this 
requirement and thus avoid redundant flooding over multiple interfaces.

>
> I don't understand well the example of Richard, because I didn't 
> follow well the thread. If nodes are in different segments, then we 
> have a MANET as a transit network, and there will be default routes 
> toward each segment, no needs to share TC's between the segments.

I am using Teco's definition of a MANET segment (repeated below).  A 
segment is associated with a single interface.  A node that has two 
interfaces belongs to two segments.  Both segments in my example are 
part of a transit MANET.   If you prefer, the short-range segment can be 
divided into multiple local MANET segments/clusters, one for each router 
in the long-range segment.  However, I am assuming that the union of all 
segments forms a single MANET, so TC messages are flooded to all 
routers.  Also, it is possible for a router to move from one cluster to 
another without changing its IP address.  Thus, each cluster may not 
have its own prefix.  This is just one example that shows the 
inefficiency of having each MPR forward each TC message on *all* 
interfaces, and how the simple scheme proposed by Teco can improve 
efficiency by using different MPR types.

In general there may not be "clusters".  Instead, there is a single 
MANET in which every router has a short-range interface and only some 
routers have a long-range interface.  Surely, you would like OLSRv2 to 
be efficient in this case.

>
> If nodes are systematically connected to two segments, then wouldn't 
> it be equivalent to have a single MANET with two kinds of interfaces? 
> And in this case the MPRs that cover the two hop neighbors on the slow 
> interface will likely cover the two hop neighbors on the fast 
> interface and there is an advantage to retransmit on both interfaces.

In my example, there is a short-range interface and a long-range 
interface, so the above does not apply.  In my example, there is never 
any need to retransmit on the long-range interface.

> which we would like to anyhow share TC's, there could be some economy 
> in distinguishing MPR wrt to output interface, in the case where one 
> neighbor is the only neighbor to a two hop neighbor and this on 
> another interface.
>

Yes, I mentioned something similar in my message on 4/29:  "I think that 
maximum efficiency would require somehow indicating exactly which of the 
n interfaces the packet should be forwarded on.  But of course this is 
more complex."

But Teco's scheme seems to be a good compromise between efficiency and 
simplicity. He defines 3 MPR types:

MPR_this_interface:  Forward only on the same interface
MPR_other_interfaces:  Forward on all other interfaces.
MPR_all_interfaces: Forward on all interfaces.

Richard

 MANET segment

    Wireless communication facility which may interconnect
    MANET interfaces, when within radio range to each other.
    A MANET interface connects a MANET router to a single 
    MANET segment.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 8 May 2009 10:06:09 +0200

Reading back my definition on MANET segment:

| MANET segment
|
|    Wireless communication facility which may interconnect
|    MANET interfaces, when within radio range to each other.
|    A MANET interface connects a MANET router to a single
|    MANET segment.

In fact, the communication facility does not have to be wireless.
Cabled links can be MANET segments also.

Question here is: What is a MANET interface? It is used for two
different things: 
 a) Interface to a wireless communication facility that may suffer
    time varying connectivity, asymmetry and non-transitivity.
 b) Interface with a MANET protocol active on it.

I think a MANET segment is part of a MANET routing domain and can be
wired or wireless. New attempt for definitions:

****

 MANET segment

   Sub-IP layer communication facility which may interconnect
   MANET interfaces. A MANET interface connects a MANET router
   to a single MANET segment. MANET segments may use wireless
   or wired communication facilities and may suffer time varying
   connectivity, asymmetry and non-transitivity.

 MANET interface 

  Interface with a MANET protocol active on it.

****

I am aware I am flip-flopping on definition for MANET interface constantly.
For this reason, I retrigger this discussion over and over, hopefully
resulting in convergence some day.
Problem here is OSPF-MANET, where OSPF_Interface_Type = MANET is 
definition a) **and** b), where in the MANET WG discussions definition b)
is meant. In Autoconf WG, we flip-flop day to day.

Teco.