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

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 3 May 2012 22:15:49 +0200

Hi Ian Chakeres,

i have completed my work for commenting on AODVv2, I hope you can
answer my questions.  thanking you,

Abdussalam Baryun (AB)
University of Glamorgan, UK
========================

AB>Overall> The dymo-22 draft is well organized and represents the
protocol operations, operation location, and messages (when initiating
its process, its conditions, and how processed) in section-by-section
basis. However, it was difficult to read because I think the concept
of version 2 and because the introduction and presentation was not
representing the new issues added to the old version and even not seen
the DSR-idea use in this version as mentioned.The draft lacks
explanations of the relationship between AODV and AODVv2, because both
protocols carry the similar name it is preferable to give more details
to avoid misunderstanding. The similar name may indicate that both
protocols can work together, or that AODVv2 router understands
correctly AODV router, or they may be integrated in some network
solutions.

AB> Suggesting>  that section 3 put before section 2 to clarify the
definition of some items of the protocol introduction presentation.

AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July
26 2010, sub:dymo-21:
C2B>The nets do not have to be mobile, and DYMO may be applicable in low power
C2B>lossy sensor networks. Without lots of details about a particular network
C2B>deployment and application traffic, it is very hard to make
C2B>generalizations in MANET.

AB> suggest> Preferable to be mentioned in overview this discussion explanation.
AB> suggest> If this protocol is able to be used in LLN nets as well
as MANET, it is important to clarify it (LLN was only mentioned in
acknowledgement section) and its relation with LLN information
exchange requirements, because the protocol applicable to other nodes
(e.g. LLN node) including MANET nodes.

AB>thought and questions>The word “node” was used without indicating
that it is MANET node, which its node may be a router. In addition,
Originating Node (OrigNode) in the terminology is not defined to be a
MANET node (e.g. if we compare with AODV RFC3561). So could it be a
MANET node or it could not? This makes the network architecture used
not clear. Are all nodes in this network architecture, MANET nodes? If
all messages/packets are MANET-units as RFC5444 therefore, all nodes
are MANET. Moreover, the draft has some indirect indications that
there MAY be more than one routing protocol (other than AODVv2) per
net-interface in some nodes which is preferable to be mentioned.

AB>thought and questions>Is the protocol a specific purpose or general
purpose or both, this should be specified. All MANET routing protocols
need the purpose statement that specifies clearly its location in
practical situation.

AB>thought and questions>The draft has not categorized the network’s
devices/nodes (using only the word routing instead of nodes). The
draft does not make explaination of the protocol’s interaction with ad
hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router).

AB> The draft had some paragraph that not followed the RFC2119, but
some amended as (there may be other, that needs to be amended):
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AB>page-10>required> A RteMsg REQUIRES the following information:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>page-25>required> If no UnreachableNode addresses remain in the
RERR, no other handling is REQUIRED and the RERR is discarded.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>page-27>required> In table title: “REQUIRED Administratively
Configured Parameters”
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to
LL-MANET-Routers on all their AODVv2 interfaces.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>page-32>must> Note that if multicast is used, any confidentiality
and integrity algorithms used MUST permit multiple receivers to handle
the message.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#Abstract

>The Dynamic MANET On-demand (AODVv2) routing protocol is intended for
>use by mobile routers in wireless, multihop networks. AODVv2
>determines unicast routes among AODVv2 routers within the network in
>an on-demand fashion, offering on-demand convergence in dynamic
>topologies.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest change> “The Dynamic MANET On-demand (AODVv2)”, to be
changed to “The Dynamic MANET On-demand Distance Vector (D-AODVv2)”,
because the term “AODVv2” has letter “A” which is presented in the
second letter of the abbreviation word MANET, but AODVv2 has the D and
V letters which is the abbreviation of Distance Vector. Regarding the
word Dynamic an abbriviation “D” preferable to be added. The “v2” may
be left to indicate its origin protocol source-idea RFC3561 AODV,
however, this can be explained in the overview.

AB>general comment> AODVv2 is a routing protocol that determines
unicast routes within the mobile routers.

AB> due to mentioning the protocol route-determination and on-demand,
It is useful to specify in abstract, to mention the protocol special
method/technique (e.g. its name or what it uses) used for this
determination and/or the convergence (i.e. to differentiate it from
other reactive protocols for summary or future purposes).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#In (Content)

>4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> Routing Messages.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#In section (1. Overview)

>Route discovery is performed when an AODVv2 router receives a packet from a
>node under its responsibility to a destination for which it does not have a
>route.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>idea not clear> which kind of node under responsibility of another?
An ad hoc node responsible for another ad hoc node, IMO may mean that
the node gets its routing information from another! (dependent-node).

AB>Statements seen after, in section-2, page-5> “other nodes, attached
via participating or non-participating interfaces”.
This was not described well, and not sure if it has relation with the
shared address among routers mentioned later in section-2, page-5.

AB> does it mean that it only performs discovery when . . . , as if
the router itself cannot be a source of demand.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>During route discovery, the originator’s AODVv2 router initiates
>dissemination of a Route Request (RREQ) throughout the network to
>find a route to a particular destination, via the AODVv2 router
>responsible for this destination.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>not clear> originator; what did this node originate? Do we mean the
router’s responsible for one, and it request for a connection to
destination (as the responsibility is at destination or at source
side.

AB>suggest adding words> “Route Request message (RREQ)”.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>During this hop-by-hop dissemination process, each intermediate AODVv2
>router records a route to the originator.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> During the hop-by-hop dissemination process,
each intermediate AODVv2 router receiving the RREQ message records a
route to the originator.
AB> the target also should records a route to the originator..
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>AODVv2 uses sequence numbers to ensure loop freedom [Perkins99].
>Sequence numbers enable AODVv2 routers to determine the temporal
>order of AODVv2 route discovery messages, thereby avoiding use of
>stale routing information.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> “AODVv2 uses routers’ sequence numbers”.
Or
AB>suggest amendments> “AODVv2 uses routers’ AODVv2 sequence numbers (SeqNum)”.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#In section (2. Applicability Statement)

>AODVv2 handles a wide variety of mobility patterns by dynamically
>determining routes on-demand. AODVv2 also handles a wide variety of traffic
>patterns. In networks with a large number of routers, AODVv2 is best suited
>for sparse traffic scenarios where routers forward packets to only a small
>portion of the other AODVv2 routers, due to the on-demand nature of route
>discovery and route maintenance.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>idea not clear> the word “other” confused, one side large and
another side small of MANET network.

AB>maybe because> where the large number (portion) of AODVv2 routers
forward packets to other small portion (number) of AODVv2 routers,

AB>idea not clear> “due to the on-demand nature of route discovery and
route maintenance”, what is the problem with both on-demand(discovery)
or reactive(maintenance) nature? Do both create the different portion
sides of routes?

AB>discussion> Does the reason of the protocol suitability include
traffic pattern and network density? Even though the paragraph claims
AODVv2 handles them as mentioned. In the paragraph there is no clear
relation between traffic and on-demand nature, even though on-demand
is traffic oriented, so it seems positive to use an on-demand (the
negative is not clear). Also for the route maintenance is related with
route changes, which is positive.

It is preferable to change the paragraph to describe both ideas; what
AODVv2 cannot handle more suitable, with mentioning what it is best
suitable. However, mentioning the reactive nature suitability will
relate/reflect to all MANET Reactive Protocols not just AODVv2. This
can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>AODVv2 is applicable to memory constrained devices, since little
>routing state is maintained in each AODVv2 router. Only routing
>information related to active sources and destinations is maintained,
>in contrast to most proactive routing protocols that require routing
>information to all routers within the routing region be maintained.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> “information related routes to active sources
and to destinations is maintained”.
AB>suggest replace> “proactive routing protocols” with “MANET
Proactive Routing protocols (MPRs)”
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>At any time within an AODVv2 routing region, only one AODVv2 router
>SHOULD be responsible for, i.e. "own", any particular address.
>Coordination among multiple AODVv2 routers to distribute routing
>information correctly for a shared address (i.e. an address that is
>advertised and can be reached via multiple AODVv2 routers) is not
>described in this document. The router behavior for shifting
>responsibility for an address from one AODVv2 router to another is
>mentioned in Appendix C.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> At all times within an AODVv2 routing region,
only one AODVv2 router SHOULD be responsible for (i.e. the
routing-address region owner) any particular address. The coordination
among multiple AODVv2 routers to distribute routing information
correctly for a shared address (i.e. an address that is advertised and
can be reached via multiple AODVv2 routers) is not described in this
document. The AODVv2 router operation of shifting
responsibility for an address from one AODVv2 router to another is
mentioned in Appendix C.

AB>not sure question> Is router behavior responsible for the address
or for the address assignment? Not sure.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AB>RFC2119> “Otherwise, persistent packet loss MAY occur”.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>AODVv2 only utilizes bidirectional links. In the case of possible
>unidirectional links, either blacklists (see Section 7.2) or other
>means (e.g. adjacency establishment with only neighboring routers
>that have bidirectional communication as indicated by NHDP
>[I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality
>is recommended. Otherwise, persistent packet loss may occur.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>not clear> How does it not utilize unidirectional links, while
mentioned, or who does this blacklisting, is it another protocol? Not
sure why mention in this protocol draft while it is not clear what
operates the blacklisting. This was not clear even in section 7.2.
Usually some routing protocols operate the blacklisting, so does this
mean that any/some AODVv2 router(s) in such situation may use
blacklisting which does not affect the network’s routings.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>The routing algorithm in AODVv2 may be operated at layers other than
>the network layer, using layer-appropriate addresses.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be
operated at another layer than the network layer, using the layer’s
appropriate addresses.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#In section (3. Terminology)

>AODVv2 Sequence Number (SeqNum)
>An AODVv2 Sequence Number is maintained by each AODVv2 router
>process. This sequence number is used by other AODVv2 routers to
>identify the temporal order of routing information generated and
>ensure loop-free routes.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> An AODVv2 Sequence Number is maintained by each
AODVv2 router process. The AODVv2 router’s sequence number is used by
other AODVv2 routers to identify the temporal order of routing
information generated and
ensure loop-free routes.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>Originating Node (OrigNode)
>The originating node is the source, its AODVv2 router creates a
>AODVv2 control message on its behalf in an effort to disseminate
>some routing information. The originating node is also referred
>to as a particular message’s originator.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> The originating node is the data source node.
Its AODVv2 router or responsible AODVv2 router creates a AODVv2
control message on its behalf in an effort to disseminate some routing
information. The originating node is also referred to as a particular
message’s originator.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>This Node (ThisNode)
>ThisNode corresponds to the AODVv2 router process currently
>performing a calculation or attending to a message.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>confused!> the term ThisNode is not indicating to its definition
(which makes the draft reading misunderstanding), maybe
“RouterProcess” is more closer and clear. The word “node” is used in
draft as a router is responsible for, therefore, the node may not
perform route process, so it the term “ThisNode” may confuse while
reading elsewhere.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Type-Length-Value structure (TLV)
>A generic way to represent information, please see [RFC5444] for
>additional information.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>idea not clear> which kind of represent-information, does it only
include routing or discovery information or other? Maybe say “routing
information”.
AB> add> the explanation of such types of information as:
A generic way to represent information (add suitable types: routing,
control, monitoring, Adjacency, etc.),
AB>question> does the AODVv2 use RFC5444 if not, it will confuse.
Refering to 5444 for more information may mean that 5444 is used in
AODVv2 format.
AB> suggested amendment> A generic way to represent information and as
TLV is defined in RFC5444.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>Unreachable Node (UnreachableNode)
>An UnreachableNode is a node for which a forwarding route is unknown.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest amendments> Unreachable Node (UnreachableNode)
An UnreachableNode is a node for which its forwarding route is unknown.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In addition to using this IP protocol number, AODVv2 may use the UDP
port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number
17 (UDP).
AB> if it may use the 269 port I think only if it uses 5444. I don’t
see statement that how will AODVv2 use 5444 info-format, and may not.

#In section 4.2.1. Generalized Packet and Message Structure:

>For interoperability with other AODVv2 routers, all AODVv2 messages
>specified in this document SHOULD sent using the IP protocol number
>(138) reserved for manet protocols [RFC5498]; or the UDP destination
>port (269) reserved for manet protocols [RFC5498] and IP protocol
>number for UDP.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>suggest> delete the “with other”, it seems like they are different
routers, we may replace with “among all”.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>A packet is made up of messages. A message is made up of a
>message header, message TLV block, and zero or more address blocks.
>Each of the address blocks may also have an associated address TLV
>block.

AB> is it an IP packet made up of messages or it is another type of
packets? The packet should be clarified. Maybe it is “5444 packet” or
we have a name for it as MANET-Packet. Are the messages AODV messages
or UDP encapsulating AODV messages? The answer is not clear her
neither in RFC5444 that this document refers to. Messages can be
AODVv2 messages, but what about addresses.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

>Most AODVv2 messages are sent with the IP destination address set to
>the link-local multicast address LL-MANET-Routers [RFC5498] unless
>otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to
>LL-MANET-Routers [RFC5498] for receiving control packets.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>not sure> what is control packet, is it routing control? Please amend.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

#In section 5.3.3

>For each of the additional addresses considered, ThisNode first
>checks the that the address is a multihop-capable unicast address.
>If the address is not a unicast address, the address and all related >information MUST be removed.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AB>delete and add> delete “the” in “checks the that”
Add “then” before “address and all related”.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

# section 6
>If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible >for its own addresses.

AB> does it have a list of its addresses that are its responsibility,
and does it have a list of its addresses that are not its
responsibility (i.e. possibility some its addresses is other router
responsibility).

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 May 2012 22:02:23 -0700

Hello Abdul,

I am catching up on things after a long delay (many reasons!!)

> University of Glamorgan, UK

Point noted.  In fact, AODVv2 is a transitional document and the 
continuing transition
should as you mention include text to better motivate the changes.

> (e.g. LLN node) including MANET nodes.

It is intended that AODVv2 should be useful in LLNs but by no means 
restricted to only
LLNs.  For some networks (perhaps with larger populations) additional 
mechanisms
may be desirable, which should be specified in other documents.  The 
mechanism for
intermediate RREP fits in this category, probably along with expanding rings
multicast.

> net-interface in some nodes which is preferable to be mentioned.

Here, "Originating Node" is always an AODVv2 node.

The reliance on RFC 5444 is still under discussion, I reckon.
Also, we cannot restrict nodes from running other protocols in
addition to AODVv2.  If there is some additional state introduced
that affects the operation of AODVv2, that needs to be handled.

> need the purpose statement that specifies clearly its location in

AODVv2 is intended to be quite general purpose.

> hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router).

To be completely accurate in answering this question, one must first 
answer the
question if a node becomes a router when it acquires a single additional 
host route.
It is perhaps an ambiguity which should not impair understanding of the 
actual
operation of the protocol.

> some amended as (there may be other, that needs to be amended):

Thanks for these observations.  I will make the appropriate changes.

>> node under its responsibility to a destination for which it does not have a

If an AODVv2 node is routing for a subnet, it has responsibility for the 
nodes on that subnet.

> the router itself cannot be a source of demand.

But the router can indeed be the source of demand.  I'll think of some 
wordsmithing.

O.K.

O.K.

O.K.

>> discovery and route maintenance.

I'm not sure what is wrong here -- do you have suggested text?

> traffic pattern and network density?

Yes, both are important.

>   Even though the paragraph claims

I'm not yet clear on how to improve this.  If you can suggest text, that 
would be
helpful...

O.K. but I probably won't use that abbreviation since it seriously 
collides with
another use.

>> responsibility for an address from one AODVv2 router to another is

O.K.

> or for the address assignment? Not sure.

The router is NOT necessarily responsible for the address assignment, 
although it could be.

I'll look to see how to make this more clear.

Check.

More later -- it's way too late here.

Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 16 May 2012 14:28:12 +0200

Hi Charlie,

> Here, "Originating Node" is always an AODVv2 node.
As in the below definition in the terminology it does not mention that
this node is always AODVv2 node, I got a feeling while review that
there is a possibility that originating nodes MAY become AODVv2 or MAY
not, and this can be seen in the below definition because the source
may be a device that is a responsibility of AODVv2 router.

Originating Node (OrigNode):

> that affects the operation of AODVv2, that needs to be handled.

I suggest not to use 5444 packet, but AODVv2 uses its technique, so it
may be coupled with it or use it in the future. IMO 5444 is more
suitable for proactive routing protocols, but not sure because not
proved yet.

> AODVv2 is intended to be quite general purpose.
is it possible to mention in the document, otherwise I am not sure if
we should specify this in each document, but I prefer to declare that
per document.

> I'm not sure what is wrong here -- do you have suggested text?

AB>I don’t mean something is wrong, but something is not clear to
read, the meaning of “other AODVv2 routers” , these other routers are
smaller portion than a larger, what is the issue here? I understand
that this scenario of traffic from large portion to small routers
portion the AODVv2 is best. Why it is best suited, the draft reason is
because AODVv2 is on-demand but there are also other protocols, what
is special here for AODVv2?

> I'm not yet clear on how to improve this.  If you can suggest text, that

I am not sure if I am able to suggest a correct paragraph replacing
that, because I may missunderstood, however, I will use what I
understood:

AB> suggest replace to>
Due to the on-demand nature of route discovery and route maintenance
many MANET reactive protocols are not suited for high density routers
and/or traffic load. AODVv2 handles a wide variety of mobility
patterns and of traffic patterns. In networks with a large number of
routers, and sparse traffic scenarios the AODVv2 is best suited
because routers forward packets to only a small portion of other
AODVv2 routers.

>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>

yes your right, thanks,

> The router is NOT necessarily responsible for the address assignment,

This information is important if mentioned and will delet many of my doughts,

+++++++

Thanking you for your reply on the comments,

Abdussalam Baryun