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:romain.thouvenin at gmail.com]
Sent: den 2 mars 2007 15:38
To: Christer Wibom
Cc: manet at ietf.org
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.
So Neighbors are 1-hop nodes.
Hope it helps,
Romain
On 3/2/07, Christer Wibom <exjcwi at telecom.lth.se> wrote:
>
>
>
>
> 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
> manet at ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>
_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet