Subject: Re: [dtn-users] NORM CL multicast session configuration question
From: "Sung Park" <[email-masked]>
To: "'Bush, Jeff'" <[email-masked]>, <[email-masked]>
Date: Tue, 27 Jan 2009 17:05:17 -0800
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

Jeff, 

Thanks for taking the time to checking it out.  Unfortunately, I am not
getting the same result as you are.  I am thinking that it may have to do
with my network setup since I am using VM environment for most of my
testing.  I will also try it with the latest build.  The build we are using
is from last December, DTN2-16f28eaf2d3c.tar.gz.     

Here are my dtnsend and dtnrecv commands. 

Receiver:  dtnrecv dtn://mgroup/recv

Sender: dtnsend -N -s dtn://n1.dtn -d dtn://mgroup/recv -e 1000 -t m -p
"hello"

I will let you know if I get around this issue.  Thanks again for all your
help.   

Sung

 

From: Bush, Jeff [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2009 9:40 AM
To: [email-masked]; [email-masked]
Subject: RE: [dtn-users] NORM CL multicast session configuration question

Sung,

I just got a chance to test your scenario here and got different results.
The sender (running dtnsend and dtnrecv) gets two copies of the message
while other receivers (running only dtnrecv) get one copy.  dtnsend ran
without the -N flag.  I guess I need to figure out why.

However, I don't believe your problem is related to the norm cl.  The code
you referenced in NORMSender handles bundle-queued events.  After receiving
one, NORMSender attempts to reference the first bundle on the link queue.
In your case we get a bundle-queued event but there's nothing on the link
queue - strange.

Please make sure you have the latest code and send me your dtnsend and
dtnrecv command lines.

Thanks,

Jeff

From: Sung Park [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2009 3:49 PM
To: Bush, Jeff; [email-masked]
Subject: RE: [dtn-users] NORM CL multicast session configuration question

Jeff, 

-N option doesn't seem to have any effect.  Maybe I am not using it
correctly.  Have you gotten it working? 

Without understanding too much of the code, I did some poking around to see
where the bundle is being blocked.  

Whenever there is a local registration (through dtnrecv), bref in
NORMSender::handle_bundle_queued() is being set to NULL which subsequently
prevents the bundle from being processed by the convergence layer.  I didn't
understand too much of the code to know why this is the case. I just know
that's where the flow stops when dtnsend is issued (regardless of whether -N
option is specified) with an existing local registration.  Let me know if
you have further insight.  Thanks for all your help. 

Sung

 

From: Bush, Jeff [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2009 6:21 AM
To: [email-masked]; [email-masked]
Subject: RE: [dtn-users] NORM CL multicast session configuration question

Sung,

Have you tried dtnsend with the -N option?  -N asserts the destination
endpoint is not a singleton.  This should cause the router to deliver
locally and send bundles out the multicast link.

-Jeff

 

From: Sung Park [mailto:[email-masked]] 
Sent: Friday, January 16, 2009 8:51 PM
To: Bush, Jeff; [email-masked]
Subject: RE: [dtn-users] NORM CL multicast session configuration question

Hi Jeff, 

I just ran into a snag with norm multicast, and wanted to see if you have a
potential work around.  It may not be big of an issue if I use the dtn API
directly instead of using the dtnrecv and dtnsend apps.  Nonetheless, here
is what I am seeing.  

I am setting up a 3-node network where all nodes are connected to each other
through a LAN.  As you have indicated, after registering the multicast link,
I launched dtnrecv at each receiver with dtn://mgroup.  When dtnsend is
executed at the sender, all the receivers that have registered dtn://mgroup
successfully receives the message from the sender.  However, the problem
arises when the sender also registers the same multicast address as the
receiver.  If the sender also registers dtn://mgroup (by running dtnrecv),
the message doesn't go out to the rest of the group when dtnsend is
executed.  I am assuming this is because the sender has a local registration
to dtn://mgroup and BPA is simply skipping the forwarding. 

The only work around that I can think of is to let sender unregister the
multicast group address before sending multicast bundle.  However, this work
around will cause the sender node to lose data for the brief moment that it
unregisters the address if it received the bundle for the multicast group
address registration.      I am hoping there is a better work around than
the one I am thinking of, preferably a work around that doesn't require BPA
modification.  I would very much appreciate your thoughts on this issue.
Thanks. 

Sung

 

From: Bush, Jeff [mailto:[email-masked]] 
Sent: Thursday, December 18, 2008 8:39 AM
To: [email-masked]; [email-masked]
Subject: RE: [dtn-users] NORM CL multicast session configuration question

Hi Sung,

For unicast norm links, the local_addr parameter value is used to uniquely
identify the dtn node in a norm session.  (There's one norm session per
unicast link.)  I'm really just looking for a norm session unique 32-bit
number - not necessarily an IP address.  If not specified the norm engine
will use the computer's "default" ip address to identify the dtn node's
presence in the session.  To understand exactly why you needed to use the
local_addr parameter, I'd need to know more about your test network.

Here's how to configure a one-to-many multicast norm link (i.e. last-hop DTN
fanout).  On your receiver nodes, add norm interfaces with something like:

interface add norm0 norm multicast_interface=eth0

By default, this will cause dtnd to join the multicast group 239.255.0.1 on
interface eth0.  If you want to join a different multicast group, use the
local_addr parameter.  Here, the local_addr parameter actually needs to be a
multicast IP address.

interface add norm0 norm multicast_interface=eth0 local_addr=224.0.1.20

Norm interfaces listen on port 4558 by default.  Currently, this is
hard-coded.  On the sending side, add a multicast link.  For example:

link add multicast_link 239.255.0.1:4558 ALWAYSON norm
multicast_interface=eth0 remote_eid=dtn://mgroup

Test using dtnsend/dtnrecv.  With dtnrecv, you can register whatever
destination eid you choose - it doesn't have to be related to the local_eid
of the local dtn daemon.  On your receiver nodes, try:

dtnrecv dtn://mgroup

Now you should be able to multicast a file using dtnsend to the destination
eid dtn://mgroup

-Jeff

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sung
Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: [email-masked]
Subject: [dtn-users] NORM CL multicast session configuration question

Hi all, 

I just learned of the inclusion of NORM CL into DTN and jumped in right
away.  Got a clean install on ubuntu x86-32bit as a previous poster has
indicated.  I did notice that on the link add option, I had to add local
addr field to get the ping working.  So instead of adding "link add
norm_link remote_host:4557 ALWASYON norm" as the doc suggested, I had to use
the following line "link add norm_link remote_host:4557 ALWASYON norm
local_addr=<my local ip>".  Not sure if anybody else has experienced the
same issue.  

I am also wondering how to setup the CL for a multicast session.  I was
trying to create a multicast session by creating a multicast group with
three nodes all sharing a common NORM link to the multicast group.  Would
this be possible with the current implementation?  Or would the multicast
sender need to create a separate link per receiver to be able to perform
multicast transmission.  If it's the latter case, I have to assume that NORM
CL is solely for transport mechanism and not as a mechanism to create
multicast session.  Is that true?  I did see the multicast_interface link
option in the document.  Any example of how to setup a multicast session
using NORM CL is greatly appreciated.  Thanks. 

Regards, 

Sung