Subject: [manet] Dymo hopcount update implementation question.

From: "Christer Wibom" <[email-masked]>
Date: Fri, 2 Mar 2007 15:24:14 +0100

Hi.

At the moment I'm doing my masters thesis at Lund University (Sweden) and we
are looking at dymo and trying to understand the drafts.

My question is as follows:

                      Should you update the hopcount, Add.TLV.Node.Hopcnt,
in each element before you update the local routing table, RT, or after
updating the RT? (Does it matter?)

                      We are worried that in some circumstances it would
matter. (We haven't found any yet. But are speculating about an installation
of nodes where different vendors implementation of DYMO are being used,
where the have different implementations on the hopcount increment)

We are using NS, using the latest DYMOUM implementation, to do some
simulations. To clarify my point I'm going to give you an example:

Let's assume the following static node distribution:

                                            0

1                                                                      5

2                                                                      4

3

Each node can only communicate with its closest neighbour.

Node 0 wants to send some data to node 3.

Possible ways are 0-5-4-3 or 0-1-2-3

In my NS simulation the RREQ yhat first comes to node 3 comes from node 4
and looks like this:

node 3: generic_process_message: RREQ received in nsif from 4

r 10.005081676 _3_ RTR  --- 70 DYMOUM 72 [0 ffffffff 4 800] ------- [4:255
-1:255 1 0] [ RE 0 0 52 8 0 1 3 0 0 [0 0 2 0 2 78] [0 0 1 5 2 78] [0 0 0 4 2
78] ]

Some explanations to NS log file ( truncated to only show relevant parts )  

[ RE 0 0 52 8 0 1 3 0 0 [ g-bit prefix hop_count node_address node_seq_nbr
energyLevel ] [.] [.] ]

RT for node 3 after processing RREQ from node 4. NS timeStamp 10.005081676

[ 4, 4, 1, 2 ]

[ 5, 4, 2, 2 ]

[ 0, 4, 3, 2 ]

Where every RT entry should be interpreted is as follows:

[destination, next hop, nbr. hops to destination, seq. nbr. of destination ]

Here we se that the original code of DYMOUM updated hopcount to node 0
before adding it to the RT.

When the second RREQ reaches node 3 ( from 2 ) it should be dropt as
inferior ( and so it is)

We changed the DYMOUM code to increment hopcount after info was added to the
RT, with the following result:

r 10.005081676 _3_ RTR  --- 70 DYMOUM 72 [0 ffffffff 4 800] ------- [4:255
-1:255 1 0] [ RE 0 0 52 8 0 1 3 0 0 [0 0 2 0 2 78] [0 0 1 5 2 78] [0 0 0 4 2
78] ]

node 3: generic_process_message: RREQ received in nsif from 4

RT for node 3 after processing RREQ from node 4. NS timeStamp 10.005081676

[ 4, 4, 0, 2 ]

[ 5, 4, 1, 2 ]

[ 0, 4, 2, 2 ]

Here we see that the routing entry to host 0 hopcount matches info that we
got in RM.

We get the same result as before when the RREQ comes from node 2.

We consulted the Dymo draft 07 section 4.1 and found the following entry:

Route.HopCnt

The number of intermediate node hops traversed before reaching the

Route.Address node. Route.HopCnt assists in determining whether

received routing information is superior to existing known

information.

We don't know how to interpreter this. should it be 2 hops from node 3 to
node 2 or should it be 3 hops..

Yours sincerely

                      Christer Wibom

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

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 2 Mar 2007 15:38:29 +0100

Hi,

I didn't read all the description of your example, but here is what I can say :
According to the draft, MsgHdr.HopCnt and each AddTLV.HopCnt are
incremented before processing anything (5.3.4 - RM processing). And I
think it does matter.

So Neighbors are 1-hop nodes.

Hope it helps,
Romain

On 3/2/07, Christer Wibom <[email-masked]> wrote:
> matter. (We haven't found any yet… But are speculating about an installation
> 1
>            5
> 2
>            4
> energyLevel ] […] […] ]
> We don't know how to interpreter this… should it be 2 hops from node 3 to
> node 2 or should it be 3 hops….
>
>
>
>
>
> Yours sincerely
>
>                       Christer Wibom
>
>

---

From: "Christer Wibom" <[email-masked]>
Date: Tue, 6 Mar 2007 10:42:01 +0100

Hi Romain.

One thought that pops into my mind is that when you do the comparison if the
information in the RM is better than the information that you have in your
routing table and seq. nbr. is the same  and it is an RREP you will compare
node.hopcount > Route.hopcount + 1. That means that that node.hopcount must
be 2 hops more to trigger this part.

Yours sincerely
Christer Wibom

-----Original Message-----
From: Romain Thouvenin [mailto:[email-masked]] 
Sent: den 2 mars 2007 15:38
To: Christer Wibom
Cc: [email-masked]
Subject: Re: [manet] Dymo hopcount update implementation question.

Hi,

I didn't read all the description of your example, but here is what I can
say :
According to the draft, MsgHdr.HopCnt and each AddTLV.HopCnt are
incremented before processing anything (5.3.4 - RM processing). And I
think it does matter.

Hope it helps,
Romain

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 6 Mar 2007 13:30:03 -0800

In my haste to meet the ID submission deadline, I did not get a chance
to properly revise the inferior section.

Here is my revised text, I think it addresses your concern. Please let
me know if it doesn't.

Ian

   3. Inferior
      If the information is not loop-possible AND Node.SeqNum ==
      Route.SeqNum, the incoming information may be inferior; additional
      information must be examined.  If Node.HopCnt == to Route.HopCnt,
      the current route is not Broken, and the message is a RREQ, then
      the new information is inferior.  This rule will stop RREQ
      propagation if the HopCnt is equivalent.  If Node.HopCnt == to
      Route.HopCnt + 1, the current route is not Broken, and the message
      is a RREQ, then the new information is inferior.  This rule will
      stop RREQ propagation if the HopCnt is larger.  If Node.HopCnt ==
      Route.HopCnt + 1, the current route is not Broken and the message
      is RREP, then the new information is inferior.  This rule will
      stop RREP propagation if the HopCnt is larger, but allows it to
      propagate if equivalent.  Inferior routes will not cause routing
      loops if introduced, but should not be used since better
      information is already available.

      !(Loop-Possible) AND
      (Node.SeqNum == Route.SeqNum) AND
      (Route.Broken == false) AND
      ((Node.HopCnt == Route.HopCnt) AND (RM is RREQ))
       OR ((Node.HopCnt == Route.HopCnt + 1) AND (RM is RREQ))
       OR ((Node.HopCnt == Route.HopCnt + 1) AND (RM is RREP)))