Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22)

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 1 Jun 2012 13:11:56 +0200

Hi Charlie, Don, and All

I want to add another optional enhancement for this Integrated-Network
(LLN+MANET=I-NET);  5) the node ability (energy consumption issue,
routing issue, and environment-event issue), it is good for some
originators to know the node ability ( to route, or continue to route,
minimal-routing, or node-survive, or other abilities), but not sure if
it is available in the DYMO nor sure if it can make side effects to
performance. The node-ability may be joined with enhancement-1 or -2,
in their tables or some technique.

To trad-off among points of the Don's enhancement-points and Charlie's
protocol-issue-points

Protocol Enhancements
>>>> 1)  Neighbor table management supported by exchanging one hop messages
>>>> containing LQI between one hop neighbors.  This would be nicely supported
>>>> via Packet BB.
>>>> 2)  Pruning of neighbor table entries to ensure two way communication
>>>> (allows for use of forward routing path as the return routing path)
>>>> 3)  Multicast route replies from data sink devices (many to one feature)
>>>> 4)  Optimization of route tables to reduce size (have a look at AODV Jr in
>>>> SourceForge)

Protocol-Issues
>>>  1. protocol complexity
>>>  2. packet size
>>>  3. neighborhood detection

the simplicity is needed within all LLN-routers but not important in
some MANET-routers, therefore, node-ability is good to be known
between neighbors to enhance the overall I-NET performance. The
routing-overheads is always the issue in ad hoc nets, but using
multicast, and anycast will help alot in the I-NET. Regarding
neighborhood detection and enhancement-1&2,  I think DLEP or
underlaying detections may solve it for the MANET-routers, but these
solution may not apropriate for LLN-routers. In conclusion,
AODV-network multihop management-optimizations are able to be
simplified if the protocol recognises different node/router abilities.

Regards,

Abdussalam Baryun
University of glamorgan, UK

( One may be wrong, or may be right, but it does not matter if we work
as a group to discuss and resolve all issues )
********************************************************************
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.
********************************************************************
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On 5/31/12, Don Sturek <[email-masked]> wrote:
> Hi Charlie,
>
> I think updating AODV would be a great idea.   We have some experience with
> AODV in a commercial deployment.  Here are some enhancements to consider:
> 1)  Neighbor table management supported by exchanging one hop messages
> containing LQI between one hop neighbors.  This would be nicely supported
> via Packet BB.
> 2)  Pruning of neighbor table entries to ensure two way communication
> (allows for use of forward routing path as the return routing path)
> 3)  Multicast route replies from data sink devices (many to one feature)
> 4)  Optimization of route tables to reduce size (have a look at AODV Jr in
> SourceForge)
>
> Overall, AODV has many benefits that would be useful as an enhanced RFC.
>
> Don
>
> From:  "Charles E. Perkins" <[email-masked]>
> Organization:  Saratoga Blue Skies
> Date:  Thursday, May 31, 2012 8:47 AM
> To:  Abdussalam Baryun <[email-masked]>
> Cc:  manet <[email-masked]>
> Subject:  Re: [manet] A view on packet-BB
>
>  Hello Abdussalam,
>
>  DYMO was exactly designed as "AODVv2" and "DSRv2".  The source routing
> feature
>  of DSR was renamed to be "Path Accumulation".  We did a lot of testing and
> discovered
>  that path accumulation was strangely unhelpful for improving performance.
> There
>  may be circumstances for which accumulating a source route is advantageous
> for
>  routing, but they haven't been clearly articulated to my knowledge.  On
> the
> other
>  hand, accumulating a source route does present advantages for security.
>
>  After a too-long hiatus in progress with DYMO, I had found that AODV had a
>  lot better name recognition and I thought, with some encouragement from
> other
>  people, that since path accumulation was no longer mandated, there was
> much
>  to be gained by reverting to the better-recognized name of AODV, but with
> the
>  clear intention of aligning the protocol with recent experience.
>
>  The value of having one standard reactive protocol instead of two
>  experimental ones is, in part, to make it easier for customers to know
>  which protocol to use.   This is still a good idea, regardless of various
>  specializations that have occurred.
>
>  Regards,
>  Charlie P.
>
>
>  On 5/31/2012 4:30 AM, Abdussalam Baryun wrote:
>>
>> Hi Charlie, and All
>>
>> I don't mind to have DYMO and AODVv2 without divergence, just from the
>> protocol name and draft-understanding, DYMO was derived from AODV+DSR,
>> and
>> from the change of name to AODVv2 it made me think more about the
>> extending of
>> AODV. Therefore, I may suggest that it is interested to see DSRv2 ( which
>> I
>> thought new DYMO may take that direction), and was thinking if the authors
>> of
>> DSR or others in WG are happy to extend that protocol.
>>
>> If we can get a new DSRv2 that is able to use RFC5444 or use a modified
>> format
>> of RFC5444, it will be great. Because if OLSRv2-15 is now deleting its
>> source-routing option as was included in OLSRv2-14, and AODVv2 is not
>> doing
>> source routing, then it is interested to have a routing protocol that is
>> able
>> to source route.
>>
>>
>>
>> Abdussalam Baryun,
>>
>> University of Glamorgan, UK.
>>
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>> On Wed, May 30, 2012 at 8:12 PM, Charles E. Perkins
>> <[email-masked]>
>> wrote:
>>
>>>
>>>  Hello folks,
>>>
>>>  I think it's a good idea to enable alternate metrics in AODVv2/DYMO
>>>  and for LOADng for that matter.  In fact, LOADng already has a form of
>>>  alternate metric.
>>>
>>>
>>>  On 5/29/2012 6:07 AM, Abdussalam Baryun wrote:
>>>
>>>> I have another thought for AODVv2 and RFC5444 (some call it
>>>>  packet-bb). I think it is possible to change hop-count-distance to
>>>>  metric-type in AODVv2, and to add metric-type in the RFC5444 (modified
>>>>  format) if you think it is better for the protocol, this is a way that
>>>>  makes AODVv2 more different than LOADng. Having in mind not to worry
>>>>  about using any RFC now, because any update to a RFC or draft is
>>>>  possible but as long as it is convensing and discussed on the list.
>>>>
>>>
>>>
>>>  Check.
>>>
>>>
>>>
>>>>
>>>>> to be clear, we can standardize AODVv2 *with* packet-BB
>>>>>  right now, and submit for consideration another document for
>>>>>  AODVv2 that does not require packet-BB.  Or, we can enable both
>>>>>  ways in the next revision.  Or, we can standardize AODVv2
>>>>>  that does NOT use packet-BB, and then submit for consideration
>>>>>  another document that DOES use packet-BB.  All cases are just
>>>>>  fine with me, depending on what the working group wants.
>>>>>
>>>>  In MANET reactive protocols may be good idea to have DYMO without
>>>>  5444-format (special formats for DYMO), and AODVv2 with using
>>>>  modified-5444-format (as below suggestion of adding metric-type), and
>>>>  LOADng fully using RFC5444. So we may join LOADng in MANET.
>>>>
>>>
>>>
>>>
>>>  I understand this point.  However, I have always believed that AODV is
>>> also
>>>  applicable for LLNs and sensor networks.  Previous work to focus AODV
>>> for
>>>  better performance in specific networks has produced quite interesting
>>> and
>>>  good results.  It would have been very appropriate to bring these
>>> modifications
>>>  into the [manet] WG for adoption into the evolved WG documents.  Making
>>>  an oversimplification, it seems that the areas where DYMO/AODV have
>>> been
>>>  viewed as inadequate for networks with reduced-functionality nodes are
>>>  mostly as follows:
>>>  1. protocol complexity
>>>  2. packet size
>>>  3. neighborhood detection
>>>
>>>  1) is clearly an area where discussion in [manet] should have happened,
>>>      and is happening now thanks to LOADng development
>>>  2) is a problem sometimes difficult to solve in the IETF
>>>  3) was mostly resolved by specifically enabling DYMO/AODVv2 to use
>>>      any appropriate neighborhood detection algorithm.  In fact, this
>>> was
>>>      always possible even with AODV, but somehow the HELLO messages
>>>      were viewed as a central part of AODV even after the publication of
>>>      SMURF and other related efforts.
>>>
>>>  In particular I would not be happy to see any divergence between a
>>> protocol
>>>  named "DYMO" and a protocol named "AODVv2".
>>>
>>>  Regards,
>>>  Charlie P.
>>>
>>
>>
>>
>
>
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________ manet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/manet
>
>