Received: from lax-mailout1.raytheon.com (lax-mailout1.raytheon.com [199.46.200.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0S1614i029776 for ; Tue, 27 Jan 2009 17:06:01 -0800 Received: from dmoutw00.directory.ray.com (dmoutw00.directory.ray.com [147.25.146.122]) by lax-mailout1.raytheon.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0S14w12025862 for ; Wed, 28 Jan 2009 01:04:59 GMT Received: from dmsmtpw00.directory.ray.com (dmsmtpw00.directory.ray.com [147.25.146.123]) by dmoutw00.directory.ray.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0S152pm007310 sender Sung_Park@raytheon.com for ; Wed, 28 Jan 2009 01:05:16 GMT Received: from es2-msg02.raymail.ray.com (es2-msg02.ess.us.ray.com [147.16.196.99]) by dmsmtpw00.directory.ray.com (8.12.11/8.12.11) with ESMTP id n0S15LNv007471 sender Sung_Park@raytheon.com for ; Wed, 28 Jan 2009 01:05:21 GMT Received: from ZFUAD312962 ([147.19.104.159]) by es2-msg02.raymail.ray.com (Lotus Domino Release 8.0.2) with ESMTP id 2009012717051932-138 ; Tue, 27 Jan 2009 17:05:19 -0800 From: "Sung Park" To: "'Bush, Jeff'" , References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> <003101c97846$08d30220$1a790660$@com> <29705F5F232FBC4C96D1CAE867538F0B0A8778B1CA@IMCMBX4.MITRE.ORG> <008701c97b40$90cedfd0$b26c9f70$@com> <29705F5F232FBC4C96D1CAE867538F0B0A8778B682@IMCMBX4.MITRE.ORG> In-Reply-To: <29705F5F232FBC4C96D1CAE867538F0B0A8778B682@IMCMBX4.MITRE.ORG> Date: Tue, 27 Jan 2009 17:05:17 -0800 Organization: Raytheon Message-ID: <009f01c980e4$7bb4e000$731ea000$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQBcbRfEAAsbQYoAANnEJwACstj8ABPXmvoA== X-MIMETrack: Itemize by SMTP Server on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/27/2009 17:05:19, Serialize by Router on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/27/2009 17:05:21, Serialize complete at 01/27/2009 17:05:21 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01C980A1.6D91A000" Content-Language: en-us Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sung_Park@raytheon.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2009 01:06:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A0_01C980A1.6D91A000 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" 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:jbush@mitre.org] Sent: Wednesday, January 21, 2009 9:40 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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:Sung_Park@raytheon.com] Sent: Tuesday, January 20, 2009 3:49 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Tuesday, January 20, 2009 6:21 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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:Sung_Park@raytheon.com] Sent: Friday, January 16, 2009 8:51 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net 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=". 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 ------=_NextPart_000_00A0_01C980A1.6D91A000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

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<= /span>

 

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Wednesday, January 21, 2009 9:40 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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:Sung_Park@raytheon.com]
Sent: Tuesday, January 20, 2009 3:49 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Tuesday, January 20, 2009 6:21 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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:Sung_Park@raytheon.com]
Sent: Friday, January 16, 2009 8:51 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff = [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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=3Deth0

 

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=3Deth0 local_addr=3D224.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=3Deth0 = remote_eid=3Ddtn://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:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
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=3D<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

 

 

 

------=_NextPart_000_00A0_01C980A1.6D91A000-- Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0NMZQi3026395 for ; Fri, 23 Jan 2009 14:35:26 -0800 Received: from senshu.bbn.com ([128.89.80.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LQUTU-0007kA-AT; Fri, 23 Jan 2009 17:26:04 -0500 Message-ID: <497A43FC.2020606@bbn.com> Date: Fri, 23 Jan 2009 17:26:04 -0500 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <497A3959.10204@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] new check-in to head of DTN2 tree, requires recompile/relink X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:35:27 -0000 Burleigh, Scott C wrote: > Sorry, Chris, I should have caught this when you mentioned it in your earlier email. The BP version number in the bundles must *not* change from 6 to 7, because the protocol has not changed; only the DTN2 implementation has changed. Other implementations will all still be at version 6, which is the latest version of BP and is the version number specified by RFC 5050 (see 4.5.1), and DTN2 will need to remain interoperable with them. > > BTW, the 64-bit limit on the size of the bundle creation time and all other SDNV fields is indeed explicitly called out in RFC5050, in the next-to-last paragraph of 4.1. To clarify -- this the version number of the protocol used for the app interface ONLY and has nothing at all with the bundle protocol. The bundles will remain exactly as they are, at version 6. -Dan Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0NMRn7s026015 for ; Fri, 23 Jan 2009 14:27:50 -0800 Received: from mail.jpl.nasa.gov (ums-smtp.jpl.nasa.gov [128.149.137.72]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0NMFTvO025553 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Fri, 23 Jan 2009 22:18:27 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Fri, 23 Jan 2009 14:18:59 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Fri, 23 Jan 2009 14:18:19 -0800 Thread-Topic: [dtn-users] new check-in to head of DTN2 tree, requires recompile/relink Thread-Index: Acl9o/fmCRhvJtsLSEq3ll4uuKg6xAAA1MsA Message-ID: References: <497A3959.10204@bbn.com> In-Reply-To: <497A3959.10204@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0NMRn7s026015 Subject: Re: [dtn-users] new check-in to head of DTN2 tree, requires recompile/relink X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 22:27:50 -0000 Sorry, Chris, I should have caught this when you mentioned it in your earlier email. The BP version number in the bundles must *not* change from 6 to 7, because the protocol has not changed; only the DTN2 implementation has changed. Other implementations will all still be at version 6, which is the latest version of BP and is the version number specified by RFC 5050 (see 4.5.1), and DTN2 will need to remain interoperable with them. BTW, the 64-bit limit on the size of the bundle creation time and all other SDNV fields is indeed explicitly called out in RFC5050, in the next-to-last paragraph of 4.1. Scott > -----Original Message----- > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > bounces@maillists.intel-research.net] On Behalf Of Christopher Small > Sent: Friday, January 23, 2009 1:41 PM > To: dtn-users mailing list > Subject: [dtn-users] new check-in to head of DTN2 tree, requires > recompile/relink > > I have checked in some code to the head of the DTN2 tree that changes > how DTN2 handles bundle creation time, bundle sequence numbers, and > bundle expiration time. Previously DTN2 required each of these values > to > fit into 32 bits; they now can be as large as 64 bits (which is > implied, > but not explicitly called out, in RFC5050). > > This required a change to the RPC messages that move between a DTN2 > application and a DTN2 daemon, requiring recompilation and relinking of > DTN2 applications against the new DTN2 code. I believe that there > should > be no source changes necessary for application code. > > Among other things, the internal version number of the protocol has > changed (from 6 to 7), so you'll be told pretty quickly if you run an > old application against a new DTN2 daemon or vice versa. > > If you are using a DTN2 daemon to forward bundles you should notice no > difference. > > This change was motivated by the BBN DTN implementation's use of large > sequence number values (greater than 2^32), per RFC5050. > > If anyone has problems with this change please let me know. > > - Chris > > -- > Dr. Christopher Small 617.873.6261 (vox) > Networking Research 617.873.6091 (fax) > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0NLo2mk024309 for ; Fri, 23 Jan 2009 13:50:03 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LQTlZ-0007Am-CF for dtn-users@mailman.dtnrg.org; Fri, 23 Jan 2009 16:40:41 -0500 Message-ID: <497A3959.10204@bbn.com> Date: Fri, 23 Jan 2009 16:40:41 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: dtn-users mailing list X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-users] new check-in to head of DTN2 tree, requires recompile/relink X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 21:50:03 -0000 I have checked in some code to the head of the DTN2 tree that changes how DTN2 handles bundle creation time, bundle sequence numbers, and bundle expiration time. Previously DTN2 required each of these values to fit into 32 bits; they now can be as large as 64 bits (which is implied, but not explicitly called out, in RFC5050). This required a change to the RPC messages that move between a DTN2 application and a DTN2 daemon, requiring recompilation and relinking of DTN2 applications against the new DTN2 code. I believe that there should be no source changes necessary for application code. Among other things, the internal version number of the protocol has changed (from 6 to 7), so you'll be told pretty quickly if you run an old application against a new DTN2 daemon or vice versa. If you are using a DTN2 daemon to forward bundles you should notice no difference. This change was motivated by the BBN DTN implementation's use of large sequence number values (greater than 2^32), per RFC5050. If anyone has problems with this change please let me know. - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0LHlbpV012137 for ; Wed, 21 Jan 2009 09:47:37 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0LHdZkC006619 for ; Wed, 21 Jan 2009 12:39:35 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0LHdZSX006586; Wed, 21 Jan 2009 12:39:35 -0500 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 21 Jan 2009 12:39:34 -0500 From: "Bush, Jeff" To: "Sung_Park@raytheon.com" , "dtn-users@maillists.intel-research.net" Date: Wed, 21 Jan 2009 12:39:33 -0500 Thread-Topic: [dtn-users] NORM CL multicast session configuration question Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQBcbRfEAAsbQYoAANnEJwACstj8A= Message-ID: <29705F5F232FBC4C96D1CAE867538F0B0A8778B682@IMCMBX4.MITRE.ORG> References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> <003101c97846$08d30220$1a790660$@com> <29705F5F232FBC4C96D1CAE867538F0B0A8778B1CA@IMCMBX4.MITRE.ORG> <008701c97b40$90cedfd0$b26c9f70$@com> In-Reply-To: <008701c97b40$90cedfd0$b26c9f70$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01C97BC5.4FFCEF80" MIME-Version: 1.0 Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 17:47:38 -0000 ------=_NextPart_000_0005_01C97BC5.4FFCEF80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C97BC5.4FFCEF80" ------=_NextPart_001_0006_01C97BC5.4FFCEF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:Sung_Park@raytheon.com] Sent: Tuesday, January 20, 2009 3:49 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Tuesday, January 20, 2009 6:21 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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:Sung_Park@raytheon.com] Sent: Friday, January 16, 2009 8:51 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net 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=". 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 ------=_NextPart_001_0006_01C97BC5.4FFCEF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:Sung_Park@raytheon.com]
Sent: Tuesday, January 20, 2009 3:49 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff = [mailto:jbush@mitre.org]
Sent: Tuesday, January 20, 2009 6:21 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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:Sung_Park@raytheon.com]
Sent: Friday, January 16, 2009 8:51 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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=3Deth0

 

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=3Deth0 local_addr=3D224.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=3Deth0 = remote_eid=3Ddtn://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:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
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=3D<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

 

 

 

------=_NextPart_001_0006_01C97BC5.4FFCEF80-- ------=_NextPart_000_0005_01C97BC5.4FFCEF80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w OTAxMjExNzM5MzNaMCMGCSqGSIb3DQEJBDEWBBRRZBc7q87ElDgcXLDCLZNocmGG4jBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgB4+DdzQ/DQLpXF5N1E7dITWJkbkCqPQSdi3DlelGcej82MiPhBLqWepeYMOkd18GSVN TkntRbSXz8m9wjWejfWZoZ6mQbXhL+3Hs+1BiAi/kE5tzKu5Q4W2ep/iAFq72Xpb0Dq2dGiOUaJm LiqR2UyqO6kE4YuRZW8hc099YwHcAAAAAAAA ------=_NextPart_000_0005_01C97BC5.4FFCEF80-- Received: from lax-mailout1.raytheon.com (lax-mailout1.raytheon.com [199.46.200.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0KKvMB7020041 for ; Tue, 20 Jan 2009 12:57:23 -0800 Received: from dmoutw00.directory.ray.com (dmoutw00.directory.ray.com [147.25.146.122]) by lax-mailout1.raytheon.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0KKn80B027864; Tue, 20 Jan 2009 20:49:09 GMT Received: from dmsmtpw00.directory.ray.com (dmsmtpw00.directory.ray.com [147.25.146.123]) by dmoutw00.directory.ray.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0KKnM73028367 sender Sung_Park@raytheon.com; Tue, 20 Jan 2009 20:49:25 GMT Received: from es2-msg02.raymail.ray.com (es2-msg02.ess.us.ray.com [147.16.196.99]) by dmsmtpw00.directory.ray.com (8.12.11/8.12.11) with ESMTP id n0KKnOpw026812 sender Sung_Park@raytheon.com; Tue, 20 Jan 2009 20:49:25 GMT Received: from ZFUAD312962 ([147.19.104.159]) by es2-msg02.raymail.ray.com (Lotus Domino Release 8.0.2) with ESMTP id 2009012012492315-82 ; Tue, 20 Jan 2009 12:49:23 -0800 From: "Sung Park" To: "'Bush, Jeff'" , References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> <003101c97846$08d30220$1a790660$@com> <29705F5F232FBC4C96D1CAE867538F0B0A8778B1CA@IMCMBX4.MITRE.ORG> In-Reply-To: <29705F5F232FBC4C96D1CAE867538F0B0A8778B1CA@IMCMBX4.MITRE.ORG> Date: Tue, 20 Jan 2009 12:49:19 -0800 Organization: Raytheon Message-ID: <008701c97b40$90cedfd0$b26c9f70$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQBcbRfEAAsbQYoAANnEJw X-MIMETrack: Itemize by SMTP Server on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/20/2009 12:49:23, Serialize by Router on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/20/2009 12:49:24, Serialize complete at 01/20/2009 12:49:24 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C97AFD.82AB9FD0" Content-Language: en-us Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sung_Park@raytheon.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 20:57:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01C97AFD.82AB9FD0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" 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:jbush@mitre.org] Sent: Tuesday, January 20, 2009 6:21 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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:Sung_Park@raytheon.com] Sent: Friday, January 16, 2009 8:51 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net 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=". 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 ------=_NextPart_000_0088_01C97AFD.82AB9FD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII"

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<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Tuesday, January 20, 2009 6:21 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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:Sung_Park@raytheon.com]
Sent: Friday, January 16, 2009 8:51 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff = [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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=3Deth0

 

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=3Deth0 local_addr=3D224.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=3Deth0 = remote_eid=3Ddtn://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:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
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=3D<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

 

 

 

------=_NextPart_000_0088_01C97AFD.82AB9FD0-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0KESawj002487 for ; Tue, 20 Jan 2009 06:28:36 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KELGYr007701 for ; Tue, 20 Jan 2009 09:21:16 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n0KELGTq007665; Tue, 20 Jan 2009 09:21:16 -0500 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 20 Jan 2009 09:21:15 -0500 From: "Bush, Jeff" To: "Sung_Park@raytheon.com" , "dtn-users@maillists.intel-research.net" Date: Tue, 20 Jan 2009 09:21:13 -0500 Thread-Topic: [dtn-users] NORM CL multicast session configuration question Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQBcbRfEAAsbQYoA== Message-ID: <29705F5F232FBC4C96D1CAE867538F0B0A8778B1CA@IMCMBX4.MITRE.ORG> References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> <003101c97846$08d30220$1a790660$@com> In-Reply-To: <003101c97846$08d30220$1a790660$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C97AE0.6EB294B0" MIME-Version: 1.0 Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 14:28:37 -0000 ------=_NextPart_000_0000_01C97AE0.6EB294B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C97AE0.6EB505B0" ------=_NextPart_001_0001_01C97AE0.6EB505B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:Sung_Park@raytheon.com] Sent: Friday, January 16, 2009 8:51 PM To: Bush, Jeff; dtn-users@maillists.intel-research.net 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:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net 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=". 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 ------=_NextPart_001_0001_01C97AE0.6EB505B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:Sung_Park@raytheon.com]
Sent: Friday, January 16, 2009 8:51 PM
To: Bush, Jeff; dtn-users@maillists.intel-research.net
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<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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=3Deth0

 

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=3Deth0 = local_addr=3D224.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=3Deth0 = remote_eid=3Ddtn://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:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
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=3D<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

 

 

 

------=_NextPart_001_0001_01C97AE0.6EB505B0-- ------=_NextPart_000_0000_01C97AE0.6EB294B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w OTAxMjAxNDIxMTBaMCMGCSqGSIb3DQEJBDEWBBQ7Xu3PVZrentgtsOLu/0HVv3qB6zBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgA3G4JxUf9wTnkMOsucneIdKVW7K2r3fjM2U4nyPnY5MVz4q0NNjYFFP6Mh/zVgRt45Z eciIKEd87kN0tSQB2Qx1qhEcc6sQdnYqBD15nI81Xv/Q6KJKSrnX6eAj5mGfBtAbRZkiz37bz5AR 7bYIJPRllkqSycWFw/clY6y68PLDAAAAAAAA ------=_NextPart_000_0000_01C97AE0.6EB294B0-- Received: from lax-mailout1.raytheon.com (lax-mailout1.raytheon.com [199.46.200.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0H1uFY5002768 for ; Fri, 16 Jan 2009 17:56:15 -0800 Received: from dmoutw00.directory.ray.com (dmoutw00.directory.ray.com [147.25.146.122]) by lax-mailout1.raytheon.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0H1oM1p006343; Sat, 17 Jan 2009 01:50:23 GMT Received: from dmsmtpw00.directory.ray.com (dmsmtpw00.directory.ray.com [147.25.146.123]) by dmoutw00.directory.ray.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0H1ocpN022717 sender Sung_Park@raytheon.com; Sat, 17 Jan 2009 01:50:38 GMT Received: from es2-msg02.raymail.ray.com (es2-msg02.ess.us.ray.com [147.16.196.99]) by dmsmtpw00.directory.ray.com (8.12.11/8.12.11) with ESMTP id n0H1ovnR002413 sender Sung_Park@raytheon.com; Sat, 17 Jan 2009 01:50:57 GMT Received: from ZFUAD312962 ([147.19.104.159]) by es2-msg02.raymail.ray.com (Lotus Domino Release 8.0.2) with ESMTP id 2009011617505684-215 ; Fri, 16 Jan 2009 17:50:56 -0800 From: "Sung Park" To: "'Bush, Jeff'" , References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> In-Reply-To: <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> Date: Fri, 16 Jan 2009 17:50:54 -0800 Organization: Raytheon Message-ID: <003101c97846$08d30220$1a790660$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQBcbRfEA= X-MIMETrack: Itemize by SMTP Server on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/16/2009 17:50:57, Serialize by Router on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 01/16/2009 17:50:57, Serialize complete at 01/16/2009 17:50:57 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C97802.FAAFC220" Content-Language: en-us Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sung_Park@raytheon.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2009 01:56:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0032_01C97802.FAAFC220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" 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:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net 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: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net 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=". 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 ------=_NextPart_000_0032_01C97802.FAAFC220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

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<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
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=3Deth0

 

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=3Deth0 = local_addr=3D224.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=3Deth0 = remote_eid=3Ddtn://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:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
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=3D<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

 

 

 

------=_NextPart_000_0032_01C97802.FAAFC220-- Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0GDcXjG001855 for ; Fri, 16 Jan 2009 05:38:33 -0800 Received: from [128.89.252.235] (helo=sneetch.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LNopR-0006B2-EC; Fri, 16 Jan 2009 08:33:41 -0500 Message-ID: <49708CB5.4050103@bbn.com> Date: Fri, 16 Jan 2009 08:33:41 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Travis Friesen References: <496F761E.7080706@bbn.com> <1232053140.8145.28.camel@sphere> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 13:38:34 -0000 I'd do something simple like run "dpkg -l | sort >manifest" on each machine and then diff the two. My guess is you didn't install one of the -dev packages. - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0FLxQll023964 for ; Thu, 15 Jan 2009 13:59:26 -0800 Received: by rv-out-0708.google.com with SMTP id c5so1534515rvf.34 for ; Thu, 15 Jan 2009 13:54:59 -0800 (PST) MIME-Version: 1.0 Sender: rexstuff@gmail.com Received: by 10.141.99.2 with SMTP id b2mr45568rvm.3.1232056499289; Thu, 15 Jan 2009 13:54:59 -0800 (PST) In-Reply-To: References: <496F761E.7080706@bbn.com> <1232053140.8145.28.camel@sphere> Date: Thu, 15 Jan 2009 15:54:59 -0600 X-Google-Sender-Auth: 6e4bd65d1f47db37 Message-ID: From: Travis Friesen To: alex.mcmahon@cs.tcd.ie Content-Type: multipart/alternative; boundary=000e0cd1b57afbbecf04608c81a7 Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 21:59:26 -0000 --000e0cd1b57afbbecf04608c81a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, this is a bit embarrassing, but the dtn2 head compiles fine on my Ubuntu 8.10 x86-64 Ubuntu server box (the problem compile occurs on my laptop). I'm really not sure what the difference between the two computers would be to cause this problem, and am very open to suggetions at this point. Thanks for all your help. On Thu, Jan 15, 2009 at 3:26 PM, Travis Friesen wrote: > Thanks for the help, but no go. > > After installing all listed packages (NB: libdb4.7-dev does seem to work, > and the package in question is libxerces-c28 and/or libxerces-c2-dev), I was > able to configure and install the oasys head without problems. > > > However, with dtn2 head, I get the following compie error (NB that this is > the same error I got with the dtn-2.6.0 tarball): > > -snip- > > g++ -g -fno-inline -fPIC -DPIC -MMD -MP -MT "bundling/SequenceID.o > bundling/SequenceID.E" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -I.. -I.. -I/home/trav/oasys-1.3.0/include > -I/home/trav/oasys-1.3.0/include/oasys/ext -I../servlib > -I/usr/include/tcl8.4 -Wall -W -Wcast-align -c bundling/SequenceID.cc -o > bundling/SequenceID.o > > In file included from > bundling/SequenceID.cc:22: > > ../oasys/util/SafeRange.h:35: error: expected `)' before > 'offset' > > ../oasys/util/SafeRange.h:36: error: 'size_t' does not name a > type > > ../oasys/util/SafeRange.h:39: error: 'size_t' has not been > declared > > ../oasys/util/SafeRange.h:42: error: declaration of 'operator[]' as > non-function > ../oasys/util/SafeRange.h:42: error: expected ';' before '(' token > In file included from /usr/include/c++/4.3/ios:45, > from /usr/include/c++/4.3/ostream:45, > from /usr/include/c++/4.3/iostream:45, > from ../oasys/util/../debug/Log.h:94, > from ../oasys/util/StringAppender.h:22, > from bundling/SequenceID.cc:23: > /usr/include/c++/4.3/exception:40: error: expected `;' before end of line > /usr/include/c++/4.3/exception:40: error: expected `}' before end of line > In file included from bundling/SequenceID.cc:22: > ../oasys/util/SafeRange.h: In constructor > 'oasys::SafeRange<_Type>::SafeRange(_Type*, int)': > ../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type>' does > not have any field named 'array_' > ../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type>' does > not have any field named 'size_' > In file included from /usr/include/c++/4.3/ios:45, > from /usr/include/c++/4.3/ostream:45, > from /usr/include/c++/4.3/iostream:45, > from ../oasys/util/../debug/Log.h:94, > from ../oasys/util/StringAppender.h:22, > from bundling/SequenceID.cc:23: > /usr/include/c++/4.3/exception: At global scope: > /usr/include/c++/4.3/exception:40: error: expected unqualified-id before > end of line > /usr/include/c++/4.3/exception:40: error: expected `}' before end of line > /usr/include/c++/4.3/exception:40: error: expected declaration before end > of line > make[1]: *** [bundling/SequenceID.o] Error 1 > make[1]: Leaving directory `/home/trav/DTN2/servlib' > make: *** [servlib] Error 2 > > > My few attempts at modifying the source have not been able to even cahnge > the error messages. A quick perusal of SafeRange.h, and it looks fine to me. > > > On Thu, Jan 15, 2009 at 2:59 PM, Alex McMahon wrote: > >> After installing the following packages with apt >> >> tcl8.4-dev >> tclx8.4-dev >> tclreadline >> tcllib >> libxerces28-dev >> libdb4.6-dev >> >> the oasys & DTN2 sourceforge tip compile on Ubuntu 8.10 (x86-64) without >> modifcation. substituting tcl8.5 & libdb4.7 should work too but I >> haven't tried this. >> >> Alex >> >> >> >> On Thu, 2009-01-15 at 12:00 -0600, Travis Friesen wrote: >> > I was trying to compile the oasys 1.3.0 tarball. After modifying the >> > source as I have mentioned, I did manage to get it to compile. >> > >> > I had no luck with the DTN 2.6.0 tarball, for different reasons. I'll >> > give the head of the tree a try. >> > >> > Thanks >> > Travis >> > >> > On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small >> > wrote: >> > Are you trying to build the 2.6.0 tarball or the head of the >> > tree? The >> > tarball is known to not work on Ubuntu 8.10; the head of the >> > tree is >> > supposed to. >> > >> > -- >> > Dr. Christopher Small 617.873.6261 >> > (vox) >> > Networking Research 617.873.6091 >> > (fax) >> > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, >> > 02138 >> > >> > >> > _______________________________________________ >> > dtn-users mailing list >> > dtn-users@maillists.intel-research.net >> > http://maillists.intel-research.net/mailman/listinfo/dtn-users >> >> > --000e0cd1b57afbbecf04608c81a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, this is a bit embarrassing, but the dtn2 head compiles fine on my Ubu= ntu 8.10 x86-64 Ubuntu server box (the problem compile occurs on my laptop)= . I'm really not sure what the difference between the two computers wou= ld be to cause this problem, and am very open to suggetions at this point.<= br>
Thanks for all your help.

On Thu, Jan= 15, 2009 at 3:26 PM, Travis Friesen <travis_friesen@ieee.org> wrote:
Thanks for the help, but no go.

After installing all listed packages= (NB: libdb4.7-dev does seem to work, and the package in question is libxer= ces-c28 and/or libxerces-c2-dev), I was able to configure and install the o= asys head without problems.


However, with dtn2 head, I get the following compie error (NB that = this is the same error I got with the dtn-2.6.0 tarball):

-snip-
=  
g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "bundling/= SequenceID.o bundling/SequenceID.E"  -DHAVE_CONFIG_H -D_LARGEFILE= _SOURCE -D_FILE_OFFSET_BITS=3D64 -I.. -I.. -I/home/trav/oasys-1.3.0/include= -I/home/trav/oasys-1.3.0/include/oasys/ext -I../servlib -I/usr/include/tcl= 8.4  -Wall -W -Wcast-align  -c bundling/SequenceID.cc -o bundling= /SequenceID.o          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;   
In file included from bundling/SequenceID.cc:22:    &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =
../oasys/util/SafeRange.h:35: error: expected `)' before 'offs= et'           &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; 
../oasys/util/SafeRange.h:36: error: 'size_t' does not name a type&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           
..= /oasys/util/SafeRange.h:39: error: 'size_t' has not been declared&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;          
../oasys/util/SafeRange.h:42: error: declaration of 'operator[]' as= non-function
../oasys/util/SafeRange.h:42: error: expected ';' = before '(' token
In file included from /usr/include/c++/4.3/ios:= 45,
            &nb= sp;    from /usr/include/c++/4.3/ostream:45,
            &nb= sp;    from /usr/include/c++/4.3/iostream:45,
  = ;            &n= bsp;  from ../oasys/util/../debug/Log.h:94,
    = ;             f= rom ../oasys/util/StringAppender.h:22,
     &nb= sp;           from bundli= ng/SequenceID.cc:23:
/usr/include/c++/4.3/exception:40: error: expected `;' before end of li= ne
/usr/include/c++/4.3/exception:40: error: expected `}' before end= of line
In file included from bundling/SequenceID.cc:22:
../oasys/ut= il/SafeRange.h: In constructor 'oasys::SafeRange<_Type>::SafeRang= e(_Type*, int)':
../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type&g= t;' does not have any field named 'array_'
../oasys/util/Saf= eRange.h:40: error: class 'oasys::SafeRange<_Type>' does not = have any field named 'size_'
In file included from /usr/include/c++/4.3/ios:45,
   &nb= sp;            = from /usr/include/c++/4.3/ostream:45,
     &nb= sp;           from /usr/i= nclude/c++/4.3/iostream:45,
       &n= bsp;         from ../oasys/util/../= debug/Log.h:94,
            &nb= sp;    from ../oasys/util/StringAppender.h:22,
 &nbs= p;            &= nbsp;  from bundling/SequenceID.cc:23:
/usr/include/c++/4.3/excepti= on: At global scope:
/usr/include/c++/4.3/exception:40: error: expected = unqualified-id before end of line
/usr/include/c++/4.3/exception:40: error: expected `}' before end of li= ne
/usr/include/c++/4.3/exception:40: error: expected declaration before= end of line
make[1]: *** [bundling/SequenceID.o] Error 1
make[1]: Le= aving directory `/home/trav/DTN2/servlib'
make: *** [servlib] Error 2


My few attempts at modifying the sou= rce have not been able to even cahnge the error messages. A quick perusal o= f SafeRange.h, and it looks fine to me.


On Thu, Jan 15, 2009 at 2:59 PM, Alex McMahon <alexmcm@gmail.com> wrote:
After installing the following packages with apt

tcl8.4-dev
tclx8.4-dev
tclreadline
tcllib
libxerces28-dev
libdb4.6-dev

the oasys & DTN2 sourceforge tip compile on Ubuntu 8.10 (x86-64) withou= t
modifcation. substituting tcl8.5 & libdb4.7 should work too but I
haven't tried this.

Alex



On Thu, 2009-01-15 at 12:00 -0600, Travis Friesen wrote:
> I was trying to compile the oasys 1.3.0 tarball. After modifying the > source as I have mentioned, I did manage to get it to compile.
>
> I had no luck with the DTN 2.6.0 tarball, for different reasons. I'= ;ll
> give the head of the tree a try.
>
> Thanks
> Travis
>
> On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small <csmall@bbn.com>
> wrote:
>         Are you trying to build the 2.6.0 tarball = or the head of the
>         tree? The
>         tarball is known to not work on Ubuntu 8.1= 0; the head of the
>         tree is
>         supposed to.
>
>         --
>         Dr. Christopher Small      =                   617.873.626= 1
>         (vox)
>         Networking Research       &= nbsp;                   617.87= 3.6091
>         (fax)
>         BBN Technologies | MS 6/5C | 10 Moulton St= | Cambridge MA,
>         02138
>
>
> _______________________________________________
> dtn-users mailing list
> http://maillists.intel-research.net/mailman/li= stinfo/dtn-users



--000e0cd1b57afbbecf04608c81a7-- Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.245]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0FLVAv8022694 for ; Thu, 15 Jan 2009 13:31:10 -0800 Received: by rv-out-0708.google.com with SMTP id c5so1522112rvf.34 for ; Thu, 15 Jan 2009 13:26:44 -0800 (PST) MIME-Version: 1.0 Sender: rexstuff@gmail.com Received: by 10.141.106.14 with SMTP id i14mr832001rvm.27.1232054803937; Thu, 15 Jan 2009 13:26:43 -0800 (PST) In-Reply-To: <1232053140.8145.28.camel@sphere> References: <496F761E.7080706@bbn.com> <1232053140.8145.28.camel@sphere> Date: Thu, 15 Jan 2009 15:26:43 -0600 X-Google-Sender-Auth: e8b38cb569a4ddbb Message-ID: From: Travis Friesen To: alex.mcmahon@cs.tcd.ie Content-Type: multipart/alternative; boundary=000e0cd1387eeebba404608c1c88 Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 21:31:10 -0000 --000e0cd1387eeebba404608c1c88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the help, but no go. After installing all listed packages (NB: libdb4.7-dev does seem to work, and the package in question is libxerces-c28 and/or libxerces-c2-dev), I was able to configure and install the oasys head without problems. However, with dtn2 head, I get the following compie error (NB that this is the same error I got with the dtn-2.6.0 tarball): -snip- g++ -g -fno-inline -fPIC -DPIC -MMD -MP -MT "bundling/SequenceID.o bundling/SequenceID.E" -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I.. -I.. -I/home/trav/oasys-1.3.0/include -I/home/trav/oasys-1.3.0/include/oasys/ext -I../servlib -I/usr/include/tcl8.4 -Wall -W -Wcast-align -c bundling/SequenceID.cc -o bundling/SequenceID.o In file included from bundling/SequenceID.cc:22: ../oasys/util/SafeRange.h:35: error: expected `)' before 'offset' ../oasys/util/SafeRange.h:36: error: 'size_t' does not name a type ../oasys/util/SafeRange.h:39: error: 'size_t' has not been declared ../oasys/util/SafeRange.h:42: error: declaration of 'operator[]' as non-function ../oasys/util/SafeRange.h:42: error: expected ';' before '(' token In file included from /usr/include/c++/4.3/ios:45, from /usr/include/c++/4.3/ostream:45, from /usr/include/c++/4.3/iostream:45, from ../oasys/util/../debug/Log.h:94, from ../oasys/util/StringAppender.h:22, from bundling/SequenceID.cc:23: /usr/include/c++/4.3/exception:40: error: expected `;' before end of line /usr/include/c++/4.3/exception:40: error: expected `}' before end of line In file included from bundling/SequenceID.cc:22: ../oasys/util/SafeRange.h: In constructor 'oasys::SafeRange<_Type>::SafeRange(_Type*, int)': ../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type>' does not have any field named 'array_' ../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type>' does not have any field named 'size_' In file included from /usr/include/c++/4.3/ios:45, from /usr/include/c++/4.3/ostream:45, from /usr/include/c++/4.3/iostream:45, from ../oasys/util/../debug/Log.h:94, from ../oasys/util/StringAppender.h:22, from bundling/SequenceID.cc:23: /usr/include/c++/4.3/exception: At global scope: /usr/include/c++/4.3/exception:40: error: expected unqualified-id before end of line /usr/include/c++/4.3/exception:40: error: expected `}' before end of line /usr/include/c++/4.3/exception:40: error: expected declaration before end of line make[1]: *** [bundling/SequenceID.o] Error 1 make[1]: Leaving directory `/home/trav/DTN2/servlib' make: *** [servlib] Error 2 My few attempts at modifying the source have not been able to even cahnge the error messages. A quick perusal of SafeRange.h, and it looks fine to me. On Thu, Jan 15, 2009 at 2:59 PM, Alex McMahon wrote: > After installing the following packages with apt > > tcl8.4-dev > tclx8.4-dev > tclreadline > tcllib > libxerces28-dev > libdb4.6-dev > > the oasys & DTN2 sourceforge tip compile on Ubuntu 8.10 (x86-64) without > modifcation. substituting tcl8.5 & libdb4.7 should work too but I > haven't tried this. > > Alex > > > > On Thu, 2009-01-15 at 12:00 -0600, Travis Friesen wrote: > > I was trying to compile the oasys 1.3.0 tarball. After modifying the > > source as I have mentioned, I did manage to get it to compile. > > > > I had no luck with the DTN 2.6.0 tarball, for different reasons. I'll > > give the head of the tree a try. > > > > Thanks > > Travis > > > > On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small > > wrote: > > Are you trying to build the 2.6.0 tarball or the head of the > > tree? The > > tarball is known to not work on Ubuntu 8.10; the head of the > > tree is > > supposed to. > > > > -- > > Dr. Christopher Small 617.873.6261 > > (vox) > > Networking Research 617.873.6091 > > (fax) > > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, > > 02138 > > > > > > _______________________________________________ > > dtn-users mailing list > > dtn-users@maillists.intel-research.net > > http://maillists.intel-research.net/mailman/listinfo/dtn-users > > --000e0cd1387eeebba404608c1c88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the help, but no go.

After installing all listed packages= (NB: libdb4.7-dev does seem to work, and the package in question is libxer= ces-c28 and/or libxerces-c2-dev), I was able to configure and install the o= asys head without problems.


However, with dtn2 head, I get the following compie error (NB that = this is the same error I got with the dtn-2.6.0 tarball):

-snip-
=  
g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "bundling/= SequenceID.o bundling/SequenceID.E"  -DHAVE_CONFIG_H -D_LARGEFILE= _SOURCE -D_FILE_OFFSET_BITS=3D64 -I.. -I.. -I/home/trav/oasys-1.3.0/include= -I/home/trav/oasys-1.3.0/include/oasys/ext -I../servlib -I/usr/include/tcl= 8.4  -Wall -W -Wcast-align  -c bundling/SequenceID.cc -o bundling= /SequenceID.o          &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;   
In file included from bundling/SequenceID.cc:22:    &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =
../oasys/util/SafeRange.h:35: error: expected `)' before 'offset'&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =
../oasys/util/SafeRange.h:36: error: 'size_t' does not name a type &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           
../oasys/u= til/SafeRange.h:39: error: 'size_t' has not been declared   =             &nb= sp;            =             &nb= sp;            =             &nb= sp;       
../oasys/util/SafeRange.h:42: error: declaration of 'operator[]' as non-fun= ction
../oasys/util/SafeRange.h:42: error: expected ';' before '(' token=
In file included from /usr/include/c++/4.3/ios:45,
   = ;            &n= bsp; from /usr/include/c++/4.3/ostream:45,
            &nb= sp;    from /usr/include/c++/4.3/iostream:45,
  = ;            &n= bsp;  from ../oasys/util/../debug/Log.h:94,
    = ;             f= rom ../oasys/util/StringAppender.h:22,
     &nb= sp;           from bundli= ng/SequenceID.cc:23:
/usr/include/c++/4.3/exception:40: error: expected `;' before end of li= ne
/usr/include/c++/4.3/exception:40: error: expected `}' before end= of line
In file included from bundling/SequenceID.cc:22:
../oasys/ut= il/SafeRange.h: In constructor 'oasys::SafeRange<_Type>::SafeRange(_T= ype*, int)':
../oasys/util/SafeRange.h:40: error: class 'oasys::SafeRange<_Type>' = does not have any field named 'array_'
../oasys/util/SafeRange.h:40: err= or: class 'oasys::SafeRange<_Type>' does not have any field named 'si= ze_'
In file included from /usr/include/c++/4.3/ios:45,
   &nb= sp;            = from /usr/include/c++/4.3/ostream:45,
     &nb= sp;           from /usr/i= nclude/c++/4.3/iostream:45,
       &n= bsp;         from ../oasys/util/../= debug/Log.h:94,
            &nb= sp;    from ../oasys/util/StringAppender.h:22,
 &nbs= p;            &= nbsp;  from bundling/SequenceID.cc:23:
/usr/include/c++/4.3/excepti= on: At global scope:
/usr/include/c++/4.3/exception:40: error: expected = unqualified-id before end of line
/usr/include/c++/4.3/exception:40: error: expected `}' before end of li= ne
/usr/include/c++/4.3/exception:40: error: expected declaration before= end of line
make[1]: *** [bundling/SequenceID.o] Error 1
make[1]: Le= aving directory `/home/trav/DTN2/servlib'
make: *** [servlib] Error 2


My few attempts at modifying the sou= rce have not been able to even cahnge the error messages. A quick perusal o= f SafeRange.h, and it looks fine to me.

On Thu, Jan 15, 2009 at 2:59 PM, Alex McMahon <alexmcm@gmail.com> wrote:
After installing the following packages with apt

tcl8.4-dev
tclx8.4-dev
tclreadline
tcllib
libxerces28-dev
libdb4.6-dev

the oasys & DTN2 sourceforge tip compile on Ubuntu 8.10 (x86-64) withou= t
modifcation. substituting tcl8.5 & libdb4.7 should work too but I
haven't tried this.

Alex



On Thu, 2009-01-15 at 12:00 -0600, Travis Friesen wrote:
> I was trying to compile the oasys 1.3.0 tarball. After modifying the > source as I have mentioned, I did manage to get it to compile.
>
> I had no luck with the DTN 2.6.0 tarball, for different reasons. I'= ;ll
> give the head of the tree a try.
>
> Thanks
> Travis
>
> On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small <csmall@bbn.com>
> wrote:
>         Are you trying to build the 2.6.0 tarball = or the head of the
>         tree? The
>         tarball is known to not work on Ubuntu 8.1= 0; the head of the
>         tree is
>         supposed to.
>
>         --
>         Dr. Christopher Small      =                   617.873.626= 1
>         (vox)
>         Networking Research       &= nbsp;                   617.87= 3.6091
>         (fax)
>         BBN Technologies | MS 6/5C | 10 Moulton St= | Cambridge MA,
>         02138
>
>
> _______________________________________________
> dtn-users mailing list
> dtn-users@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/li= stinfo/dtn-users


--000e0cd1387eeebba404608c1c88-- Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0FL3Uvb021451 for ; Thu, 15 Jan 2009 13:03:31 -0800 Received: by ewy14 with SMTP id 14so1621150ewy.10 for ; Thu, 15 Jan 2009 12:59:04 -0800 (PST) Received: by 10.210.29.17 with SMTP id c17mr792740ebc.59.1232053144129; Thu, 15 Jan 2009 12:59:04 -0800 (PST) Received: from ?192.168.11.2? (84-203-70-61.mysmart.ie [84.203.70.61]) by mx.google.com with ESMTPS id m5sm487106gve.18.2009.01.15.12.59.02 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Jan 2009 12:59:03 -0800 (PST) From: Alex McMahon To: Travis Friesen In-Reply-To: References: <496F761E.7080706@bbn.com> Content-Type: text/plain Organization: Trinity College Dublin Date: Thu, 15 Jan 2009 20:59:00 +0000 Message-Id: <1232053140.8145.28.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 21:03:32 -0000 After installing the following packages with apt tcl8.4-dev tclx8.4-dev tclreadline tcllib libxerces28-dev libdb4.6-dev the oasys & DTN2 sourceforge tip compile on Ubuntu 8.10 (x86-64) without modifcation. substituting tcl8.5 & libdb4.7 should work too but I haven't tried this. Alex On Thu, 2009-01-15 at 12:00 -0600, Travis Friesen wrote: > I was trying to compile the oasys 1.3.0 tarball. After modifying the > source as I have mentioned, I did manage to get it to compile. > > I had no luck with the DTN 2.6.0 tarball, for different reasons. I'll > give the head of the tree a try. > > Thanks > Travis > > On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small > wrote: > Are you trying to build the 2.6.0 tarball or the head of the > tree? The > tarball is known to not work on Ubuntu 8.10; the head of the > tree is > supposed to. > > -- > Dr. Christopher Small 617.873.6261 > (vox) > Networking Research 617.873.6091 > (fax) > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, > 02138 > > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.248]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0FI4oNx013337 for ; Thu, 15 Jan 2009 10:04:50 -0800 Received: by rv-out-0708.google.com with SMTP id c5so1430841rvf.34 for ; Thu, 15 Jan 2009 10:00:29 -0800 (PST) MIME-Version: 1.0 Sender: rexstuff@gmail.com Received: by 10.141.203.7 with SMTP id f7mr737042rvq.125.1232042429164; Thu, 15 Jan 2009 10:00:29 -0800 (PST) In-Reply-To: <496F761E.7080706@bbn.com> References: <496F761E.7080706@bbn.com> Date: Thu, 15 Jan 2009 12:00:29 -0600 X-Google-Sender-Auth: af3f1ddf087e74ba Message-ID: From: Travis Friesen To: Christopher Small Content-Type: multipart/alternative; boundary=000e0cd20c3e56ac170460893b4e Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 18:04:50 -0000 --000e0cd20c3e56ac170460893b4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was trying to compile the oasys 1.3.0 tarball. After modifying the source as I have mentioned, I did manage to get it to compile. I had no luck with the DTN 2.6.0 tarball, for different reasons. I'll give the head of the tree a try. Thanks Travis On Thu, Jan 15, 2009 at 11:45 AM, Christopher Small wrote: > Are you trying to build the 2.6.0 tarball or the head of the tree? The > tarball is known to not work on Ubuntu 8.10; the head of the tree is > supposed to. > > -- > Dr. Christopher Small 617.873.6261 (vox) > Networking Research 617.873.6091 (fax) > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 > > --000e0cd20c3e56ac170460893b4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was trying to compile the oasys 1.3.0 tarball. After modifying the source= as I have mentioned, I did manage to get it to compile.

I had no lu= ck with the DTN 2.6.0 tarball, for different reasons. I'll give the hea= d of the tree a try.

Thanks
Travis

On Thu, Jan 15, 2009= at 11:45 AM, Christopher Small <csmall@bbn.com> wrote:
Are you trying to build the 2.6.0 tarball or the head of the tree? The
tarball is known to not work on Ubuntu 8.10; the head of the tree is
supposed to.

--
Dr. Christopher Small               &nbs= p;         617.873.6261 (vox)
Networking Research                =           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138


--000e0cd20c3e56ac170460893b4e-- Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0FHnNrW012613 for ; Thu, 15 Jan 2009 09:49:24 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LNWH8-00056Z-ES; Thu, 15 Jan 2009 12:45:02 -0500 Message-ID: <496F761E.7080706@bbn.com> Date: Thu, 15 Jan 2009 12:45:02 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Travis Friesen References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 17:49:24 -0000 Are you trying to build the 2.6.0 tarball or the head of the tree? The tarball is known to not work on Ubuntu 8.10; the head of the tree is supposed to. -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0ELM6l9021627 for ; Wed, 14 Jan 2009 13:22:06 -0800 Received: by rv-out-0708.google.com with SMTP id c5so872982rvf.34 for ; Wed, 14 Jan 2009 13:18:16 -0800 (PST) MIME-Version: 1.0 Sender: rexstuff@gmail.com Received: by 10.141.87.13 with SMTP id p13mr203572rvl.81.1231967895970; Wed, 14 Jan 2009 13:18:15 -0800 (PST) Date: Wed, 14 Jan 2009 15:18:15 -0600 X-Google-Sender-Auth: 1dcb8b9a0a62764a Message-ID: From: Travis Friesen To: dtn-users@maillists.intel-research.net Content-Type: multipart/alternative; boundary=000e0cd1519ad06464046077e0a2 Subject: [dtn-users] Oasys compile issues X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 21:22:06 -0000 --000e0cd1519ad06464046077e0a2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello all - I'm not sure if this has been dealt with yet, but here goes: After performing the aclocal/gcc.ac fix in order to compile on Ubuntu 8.10 (x86-64), I ran a number of missing #includes: Missing #include : util/StringUtils.h tclcmd/TclCommand.h thread/Timer.cc Missing #include util/Getopt.cc util/MD5.cc util/OptParser.cc Missing #include util/InitSequencer.cc Missing #include util/Getopt.cc After adding the approrpiate line to each of the files, I was able to successfully compile oasys. Now let's see how I fare with the dtn package... Travis --000e0cd1519ad06464046077e0a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello all - I'm not sure if this has been dealt with yet, but here goes:

After performing the aclocal/gcc.ac fix in order to compile on Ubuntu 8.10 (x86-64), I ran a number of missing #includes:

Missing #include <limits.h>:

util/StringUtils.h

tclcmd/TclCommand.h

thread/Timer.cc

Missing #include <string.h>

util/Getopt.cc

util/MD5.cc

util/OptParser.cc

Missing #include <alogirthm>

util/InitSequencer.cc

Missing #include <stdlib.h>

util/Getopt.cc

After adding the approrpiate line to each of the files, I was able to successfully compile oasys.

Now let's see how I fare with the dtn package...

Travis

--000e0cd1519ad06464046077e0a2-- Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0E9X1TR021540 for ; Wed, 14 Jan 2009 01:33:02 -0800 Received: by ewy14 with SMTP id 14so527249ewy.10 for ; Wed, 14 Jan 2009 01:29:30 -0800 (PST) Received: by 10.210.22.16 with SMTP id 16mr3791624ebv.61.1231925370267; Wed, 14 Jan 2009 01:29:30 -0800 (PST) Received: by 10.210.63.7 with HTTP; Wed, 14 Jan 2009 01:29:29 -0800 (PST) Message-ID: Date: Wed, 14 Jan 2009 09:29:29 +0000 From: "Andy Scott" To: "Moore, Brad" In-Reply-To: <0119B6D93B00714F84D6C33DBBA5E56F01513486@CGYSVW100.gdcan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <0119B6D93B00714F84D6C33DBBA5E56F01513486@CGYSVW100.gdcan.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0E9X1TR021540 Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2009 09:33:02 -0000 On 13/01/2009, Moore, Brad wrote: > > > > > Ø I'll try to continue on with it then. I will see how far I can get > with it. > > Ø Andy > > > > I am also very much interested in a Windows port of the reference > implementation. > > Have you had a chance to make any progress on this yet, or have you > developed a > > better feel for the amount of work required? > > > > Regards, > > Brad > Hi there Sorry due to holidays &c I didn't get much of a chance to continue on with it after updating to the Apache branch. Though I have started up looking it over againg this week - trying hard to get my brain out of holiday mode :-) I'll keep you posted as I get on with it. Andy -- Brain upgrade required: a working hypothalamus Received: from gdcanada.com (smtp2.gdcanada.com [209.29.4.40]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id n0DHoRvf010983 for ; Tue, 13 Jan 2009 09:50:28 -0800 Received: from gdcanada.com ([172.16.7.212]) by gdcanada.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 12:45:12 -0500 Received: from CGYSVW100.gdcan.com ([172.31.27.211]) by gdcanada.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jan 2009 12:46:45 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C975A6.E5F168B9" Date: Tue, 13 Jan 2009 10:46:43 -0700 Message-ID: <0119B6D93B00714F84D6C33DBBA5E56F01513486@CGYSVW100.gdcan.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dtn-users] Windows Build? thread-index: Acl1puYM34J0JCHVSS+r9zNB/6BVHA== From: "Moore, Brad" To: X-OriginalArrivalTime: 13 Jan 2009 17:46:45.0089 (UTC) FILETIME=[E69DC510:01C975A6] Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 17:50:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C975A6.E5F168B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * I'll try to continue on with it then. I will see how far I can get with it.=20 * Andy=20 =20 I am also very much interested in a Windows port of the reference implementation. Have you had a chance to make any progress on this yet, or have you developed a=20 better feel for the amount of work required? =20 Regards, Brad The information contained in this e-mail message is PRIVATE. It may = contain confidential information and may be legally privileged. It is = intended for the exclusive use of the addressee(s). If you are not the = intended recipient, you are hereby notified that any dissemination, = distribution or reproduction of this communication is strictly = prohibited. If the intended recipient(s) cannot be reached or if a = transmission problem has occurred, please notify the sender immediately = by return e-mail and destroy all copies of this message.=20 Thank you.=20 ------_=_NextPart_001_01C975A6.E5F168B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ø      I'll try to continue on = with it then. I will see how far I can get with it.

Ø      Andy

 

I am also very much interested in a Windows port of = the reference implementation.

Have you had a chance to make any progress on this = yet, or have you developed a

better feel for the amount of work = required?

 

Regards,

Brad

The information contained in this = e-mail message is PRIVATE. It may contain confidential information and = may be legally privileged. It is intended for the exclusive use of the = addressee(s). If you are not the intended recipient, you are hereby = notified that any dissemination, distribution or reproduction of this = communication is strictly prohibited. If the intended recipient(s) = cannot be reached or if a transmission problem has occurred, please = notify the sender immediately by return e-mail and destroy all copies of = this message.
Thank you. =

------_=_NextPart_001_01C975A6.E5F168B9-- Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0DHNCEs009636; Tue, 13 Jan 2009 09:23:13 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id C08F4100415B8; Tue, 13 Jan 2009 17:20:05 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeAHMkNV86j3; Tue, 13 Jan 2009 17:20:04 +0000 (GMT) Received: from [192.168.3.126] (unknown [192.168.3.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id CDDB51004158A; Tue, 13 Jan 2009 17:20:02 +0000 (GMT) Message-ID: <496CCD9D.9010206@cs.tcd.ie> Date: Tue, 13 Jan 2009 17:21:33 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Marc Blanchet References: <496CCB9D.9060500@viagenie.ca> In-Reply-To: <496CCB9D.9060500@viagenie.ca> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-interest@mailman.dtnrg.org, dtn-users@mailman.dtnrg.org, dtnbone@korgano.eecs.ohiou.edu, Simon Perreault Subject: Re: [dtn-users] [dtnbone] A new service on the DTNbone: DTN News X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 17:23:13 -0000 Nice! Stephen. Marc Blanchet wrote: > Hello, > > We are proud to announce a new service on the DTNbone: DTN news. > > The service enables you to receive any RSS/Atom feed available on the > Internet (currently on Earth) delivered through the DTNbone. Any feed > such as slashdot, cnn or any your liking. > > The concept is simple. You register to the service with your dtnbone > node information and the feeds you want to receive. We continually poll > RSS and Atom feeds. At the frequency of your choosing, we will package a > news bundle and deliver it reliably over bundle protocol to your dtnbone > node. > > For example, a node which is intermittently connected may receive his > preferred news feed as it connects to the dtnbone, then disconnects and > reads them offline. > > See http://reeves.viagenie.ca for details and how to sign up. > > Marc and Simon(who implemented it). Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0D0qasf029171 for ; Mon, 12 Jan 2009 16:52:37 -0800 X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ptbb2b.girton.cam.ac.uk ([128.232.240.168]:37166) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1LMXTe-0007tf-O4 (Exim 4.70) for dtn-users@mailman.dtnrg.org (return-path ); Tue, 13 Jan 2009 00:49:54 +0000 Received: by ptbb2b.girton.cam.ac.uk (Postfix, from userid 500) id 0DF0078066; Tue, 13 Jan 2009 00:49:54 +0000 (GMT) To: dtn-users@mailman.dtnrg.org From: Peter TB Brett Organization: Integral Informatics Ltd X-Face: $N}{5?\D>xr}zi]BChHp)X[G,\Z"lc+zdwps1*EiY,=?utf-8?q?=7B!=26t+x49=5DlIKpn=60*U4cV=7E=5E-4=7ClNw=0A=092T9+3y?=@-cV}7TSB[F8'Cglfe#b6BrI.^AI-7|$; O@d6Ons!`h0\{-I/U6D]8v=P Date: Tue, 13 Jan 2009 00:49:53 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1326266.6gySX4Novr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200901130049.53776.peter@peter-b.co.uk> Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 00:52:37 -0000 --nextPart1326266.6gySX4Novr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 13 January 2009 00:34:24 Jason Redi wrote: > Why not distributed time sync? That might be possible, but it an open > (unsolved) area of research in the ad hoc networking community, and you > might not have any idea of which node has the better time anyway. I've been working on this. I have some preliminary results, but they're not= =20 very useful yet. Peter =2D-=20 Peter Brett Cambridge University Engineering Department --nextPart1326266.6gySX4Novr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBJa+UxZ7Gbq7g7vpoRAgilAJ45Fngf4c4s6ZdXWW9cEArlBJ760QCdFWwj oKDYLHf8DVhkczLxxgvI3JQ= =c6NA -----END PGP SIGNATURE----- --nextPart1326266.6gySX4Novr-- Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0D0bVPs028452 for ; Mon, 12 Jan 2009 16:37:31 -0800 Received: from mproxy01.bbn.com ([192.1.122.23]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMXF4-000687-BM; Mon, 12 Jan 2009 19:34:50 -0500 Received: from [173.48.210.200] (helo=Oteil) by mproxy01.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LMXF4-00099Z-DZ; Mon, 12 Jan 2009 19:34:50 -0500 From: "Jason Redi" To: "'Daniel Ellard'" , "'Burleigh, Scott C'" References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> <496BB0B3.7000708@bbn.com> In-Reply-To: <496BB0B3.7000708@bbn.com> Date: Mon, 12 Jan 2009 19:34:24 -0500 Organization: BBN Technologies Message-ID: <01b101c97516$b2b07990$18116cb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl0+Z3OSzjhnXM3RAeyyxlWCWvZhAAG9NHQ Content-Language: en-us Cc: 'dtn-users mailing list' Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: redi@bbn.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2009 00:37:32 -0000 > -----Original Message----- > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > bounces@maillists.intel-research.net] On Behalf Of Daniel Ellard > Sent: Monday, January 12, 2009 4:06 PM > To: Burleigh, Scott C > Cc: dtn-users mailing list > Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > other BPAs) > > Burleigh, Scott C wrote: > > Dan, just to pursue this a little further: > > > >>>> The original designers of the BBN BPA noted that this is a "may" > and not > >>>> a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided > to take > >>>> advantage of this. One of the target hardware platforms has a > >>>> poor clock and therefore, to ensure uniqueness, it was decided to > >>>> augment the sequence number with an instance number, and these > instance > >>>> numbers occupy the upper 32 bits of the sequence number. > Therefore the > >>>> smallest possible BBN BPA sequence number is 2*32 + 1, so our very > >>>> first bundle is trouble. > > > > On re-reading this I am confused. When you say that one of your > target hardware platforms has a poor clock, do you mean it has a clock > that can't be kept accurately synchronized with reference UTC or do you > mean a clock that is not a monotonically increasing counter, e.g., it > sometimes runs backward? If the former, why aren't the time values > reported by that clock -- inaccurate as they are -- suitable as > "instance" or "epoch" numbers (which would make the instance number in > the high-order 32 bits of sequence number unnecessary)? > > I'm afraid, since I joined the project relatively recently, that I > don't > have all the details about this platform beyond the pragma that the > clock values should not be trusted to signify anything definitive. It > wouldn't surprise me if they could moved backwards, when, for example, > two nodes established a link and tried to negotiate a common time. > (this might happen in other situations as well, when nodes have > inaccurate clocks and are using ntp to get in sync and the difference > is > larger than can be fixed by scaling) Background on the platform being discussed: The platform being described is a DoD handset. Like most DoD devices (and most handheld devices like phones), there is no battery backed up clock. Batteries leak and are a logistical problem when stored or maintained for years and years. Some nodes might have GPS, but we can't assume that GPS is guaranteed. So upon bootup, clocks are monotonically increasing, but a node might reboot and reset it's concept of time. There is no easy way to know which nodes have better time than others. We don't want to require users to enter the correct time every time the nodes boot up. Why not NTP? NTP assumes a hierarchy of servers where some nodes have known better time. In this kind of ad hoc network we can't assume servers or advantaged nodes. Why not distributed time sync? That might be possible, but it an open (unsolved) area of research in the ad hoc networking community, and you might not have any idea of which node has the better time anyway. Jason Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CLc5Fm020430 for ; Mon, 12 Jan 2009 13:38:05 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CLYS3w019097 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 12 Jan 2009 21:35:28 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 12 Jan 2009 13:35:35 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Mon, 12 Jan 2009 13:35:18 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl09fCqaQ4O2nMWQM26vCR+KUPfnAABpIoQ Message-ID: References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> In-Reply-To: <496BAA89.8080903@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CLc5Fm020430 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 21:38:06 -0000 > -----Original Message----- > From: Daniel Ellard [mailto:dellard@bbn.com] > Sent: Monday, January 12, 2009 12:40 PM > To: Burleigh, Scott C > Cc: dtn-users mailing list > Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > other BPAs) > > Burleigh, Scott C wrote: > >> -----Original Message----- > >> From: Daniel Ellard [mailto:dellard@bbn.com] > >> Sent: Monday, January 12, 2009 11:36 AM > >> To: Burleigh, Scott C > >> Cc: dtn-users mailing list > >> Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > >> other BPAs) > >> > >> No matter what approach we take to resolving this, it seems that the > >> spec might require a small revision to make the definition of the way > >> timestamps are created more constrained. Even implementations that do > >> begin with a sequence number of 0 can fail if, for example, they > >> satisfy the "monotonically increasing" requirement by incrementing by a billion > >> -- it would be silly, but it would comply with the spec. > > > > They wouldn't fail, really, they'd just generate unnecessarily > bloated bundles that receiving BPAs would have trouble with unless they > made this same kind of modification. Modifying the spec to note this > seems kind of legalistic to me. I personally would rather not augment > the spec with a list of prohibitions against all possible silly things > an implementer could do. > > I agree that the spec shouldn't be a list of silly things not to do > (because that list is probably infinite), but at the same time I'd argue > that being "legalistic" is the entire purpose of a spec -- to make sure > that different implementations that match the spec can interoperate. > Right now we have implementations that match the spec but don't > interoperate, so I think we have a problem that needs to be addressed. Except I thought your point was that an implementation that can't handle a timestamp sequence number in excess of 4G, presented in a well-formed SDNV, doesn't fully conform to the spec. Which I think is a defensible point, otherwise I wouldn't be contemplating a code modification. Scott Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CLTYcN020018 for ; Mon, 12 Jan 2009 13:29:35 -0800 Received: from mail.jpl.nasa.gov (ums-smtp.jpl.nasa.gov [128.149.137.72]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CLQGEW013622 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 12 Jan 2009 21:26:58 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Mon, 12 Jan 2009 13:26:49 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Mon, 12 Jan 2009 13:26:32 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl0+PkW2nWOrnaSQXC8OH2KJt6CrAAAU8gw Message-ID: References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> <496BAF9A.40205@bbn.com> In-Reply-To: <496BAF9A.40205@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: ums-smtp.jpl.nasa.gov [128.149.137.72] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CLTYcN020018 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 21:29:35 -0000 > -----Original Message----- > From: Christopher Small [mailto:csmall@bbn.com] > Sent: Monday, January 12, 2009 1:01 PM > To: Burleigh, Scott C > Cc: dtn-users mailing list > Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > other BPAs) > > Burleigh, Scott C wrote: > > On re-reading this I am confused. When you say that one of your > target hardware platforms has a poor clock, do you mean it has a clock > that can't be kept accurately synchronized with reference UTC or do you > mean a clock that is not a monotonically increasing counter, e.g., it > sometimes runs backward? > > We can't guarantee that it'll never be reset to zero (e.g. if the > batteries die completely), so using it as a counter is not particularly > safe. Okay, but your epoch system depends on your epoch counter likewise not resetting, right? So you must have some way of retaining the last value of your epoch counter in some sort of non-volatile storage, yes? If so, why not just record the current value of the clock as the current value of your epoch counter, once per second, and always use the epoch counter value -- rather than the current clock value (which might drop back to zero for a while) -- as the value of the seconds counter in the creation timestamp? Sorry, I don't mean to spend a lot of time second-guessing your design here -- we can abandon this thread now if you druther. I'm just wondering about the problem space and how ION would need to handle it. Scott Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CL8U4f019095 for ; Mon, 12 Jan 2009 13:08:30 -0800 Received: from senshu.bbn.com ([128.89.80.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMTyt-0003WL-AK; Mon, 12 Jan 2009 16:05:55 -0500 Message-ID: <496BB0B3.7000708@bbn.com> Date: Mon, 12 Jan 2009 16:05:55 -0500 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 21:08:30 -0000 Burleigh, Scott C wrote: > Dan, just to pursue this a little further: > >>>> The original designers of the BBN BPA noted that this is a "may" and not >>>> a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided to take >>>> advantage of this. One of the target hardware platforms has a >>>> poor clock and therefore, to ensure uniqueness, it was decided to >>>> augment the sequence number with an instance number, and these instance >>>> numbers occupy the upper 32 bits of the sequence number. Therefore the >>>> smallest possible BBN BPA sequence number is 2*32 + 1, so our very >>>> first bundle is trouble. > > On re-reading this I am confused. When you say that one of your target hardware platforms has a poor clock, do you mean it has a clock that can't be kept accurately synchronized with reference UTC or do you mean a clock that is not a monotonically increasing counter, e.g., it sometimes runs backward? If the former, why aren't the time values reported by that clock -- inaccurate as they are -- suitable as "instance" or "epoch" numbers (which would make the instance number in the high-order 32 bits of sequence number unnecessary)? I'm afraid, since I joined the project relatively recently, that I don't have all the details about this platform beyond the pragma that the clock values should not be trusted to signify anything definitive. It wouldn't surprise me if they could moved backwards, when, for example, two nodes established a link and tried to negotiate a common time. (this might happen in other situations as well, when nodes have inaccurate clocks and are using ntp to get in sync and the difference is larger than can be fixed by scaling) -Dan Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CL3nWF018880 for ; Mon, 12 Jan 2009 13:03:50 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LMTuM-0003To-As; Mon, 12 Jan 2009 16:01:14 -0500 Message-ID: <496BAF9A.40205@bbn.com> Date: Mon, 12 Jan 2009 16:01:14 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 21:03:50 -0000 Burleigh, Scott C wrote: > On re-reading this I am confused. When you say that one of your target hardware platforms has a poor clock, do you mean it has a clock that can't be kept accurately synchronized with reference UTC or do you mean a clock that is not a monotonically increasing counter, e.g., it sometimes runs backward? We can't guarantee that it'll never be reset to zero (e.g. if the batteries die completely), so using it as a counter is not particularly safe. -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CKq9nQ018335 for ; Mon, 12 Jan 2009 12:52:09 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CKnRuo018217 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 12 Jan 2009 20:49:33 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 12 Jan 2009 12:49:44 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Mon, 12 Jan 2009 12:49:27 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl09fCqaQ4O2nMWQM26vCR+KUPfnAAAGYPA Message-ID: References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> <496BAA89.8080903@bbn.com> In-Reply-To: <496BAA89.8080903@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CKq9nQ018335 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 20:52:09 -0000 Dan, just to pursue this a little further: > >> The original designers of the BBN BPA noted that this is a "may" and not > >> a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided to take > >> advantage of this. One of the target hardware platforms has a > >> poor clock and therefore, to ensure uniqueness, it was decided to > >> augment the sequence number with an instance number, and these instance > >> numbers occupy the upper 32 bits of the sequence number. Therefore the > >> smallest possible BBN BPA sequence number is 2*32 + 1, so our very > >> first bundle is trouble. On re-reading this I am confused. When you say that one of your target hardware platforms has a poor clock, do you mean it has a clock that can't be kept accurately synchronized with reference UTC or do you mean a clock that is not a monotonically increasing counter, e.g., it sometimes runs backward? If the former, why aren't the time values reported by that clock -- inaccurate as they are -- suitable as "instance" or "epoch" numbers (which would make the instance number in the high-order 32 bits of sequence number unnecessary)? Scott Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CKgGwT017855 for ; Mon, 12 Jan 2009 12:42:16 -0800 Received: from dhcp89-069-105.bbn.com ([128.89.69.105]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMTZV-0002zJ-AI; Mon, 12 Jan 2009 15:39:41 -0500 Message-ID: <496BAA89.8080903@bbn.com> Date: Mon, 12 Jan 2009 15:39:37 -0500 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 20:42:16 -0000 Burleigh, Scott C wrote: >> -----Original Message----- >> From: Daniel Ellard [mailto:dellard@bbn.com] >> Sent: Monday, January 12, 2009 11:36 AM >> To: Burleigh, Scott C >> Cc: dtn-users mailing list >> Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and >> other BPAs) >> >> Burleigh, Scott C wrote: >> >>> I think I see. ION will reject as invalid any SDNV in a received >> bundle whose total length exceeds 10 octets (which would accommodate a >> 70-bit number); section 4.1 is the justification for this. But if the >> SDNV is well-formed and the value that it contains happens to be too >> large to fit into a C "unsigned long" [which is 32 bits on a 32-bit >> machine and seems typically to be 64 bits on 64-bit machines] the SDNV >> will be accepted but some high-order bits of the value will be lost. >>> So the large timestamp would be honored in the sense that the bundle >> would not be discarded out of hand upon parsing, but ION would in this >> case have a hard time accepting custody: the timestamp of the bundle is >> stored internally as a pair of unsigned long integers, not as the >> original SDNV strings, so the acknowledged bundle's creation timestamp >> (in the admin record) wouldn't come out right. >>> I was hoping not to need to accommodate this kind of thing, but if it >> is going to be a problem I will look into doing the additional native- >> SDNV storage. Are you really expecting your creation timestamp >> sequence numbers to exceed 4 billion? That is, you might be issuing >> more than 4 billion bundles in one second? >> >> We're not expecting to create 4 billion bundles each second, but we get >> into this situation in a different manner. The spec says that the >> sequence number is a "monotonically increasing positive integer ... >> that may be reset to zero whenever the current time advances by one second." >> >> The original designers of the BBN BPA noted that this is a "may" and not >> a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided to take >> advantage of this. One of the target hardware platforms has a >> poor clock and therefore, to ensure uniqueness, it was decided to >> augment the sequence number with an instance number, and these instance >> numbers occupy the upper 32 bits of the sequence number. Therefore the >> smallest possible BBN BPA sequence number is 2*32 + 1, so our very >> first bundle is trouble. >> >> We would prefer to see the SDNV code extended to deal with larger >> numbers in a portable manner. If the 32-bit limit doesn't bite us >> here, it will bite us eventually somewhere (data length, probably). > > I see. Well, the SDNV code itself is already handling this case fine; the only 32-bit limit we're dealing with here is the limit imposed by the CPU architecture. But for interoperability with your implementation I guess I will need to modify the internal representation of bundles to retain the original SDNV text of the creation timestamp sequence number. > >> No matter what approach we take to resolving this, it seems that the >> spec might require a small revision to make the definition of the way >> timestamps are created more constrained. Even implementations that do >> begin with a sequence number of 0 can fail if, for example, they >> satisfy the "monotonically increasing" requirement by incrementing by a billion >> -- it would be silly, but it would comply with the spec. > > They wouldn't fail, really, they'd just generate unnecessarily bloated bundles that receiving BPAs would have trouble with unless they made this same kind of modification. Modifying the spec to note this seems kind of legalistic to me. I personally would rather not augment the spec with a list of prohibitions against all possible silly things an implementer could do. I agree that the spec shouldn't be a list of silly things not to do (because that list is probably infinite), but at the same time I'd argue that being "legalistic" is the entire purpose of a spec -- to make sure that different implementations that match the spec can interoperate. Right now we have implementations that match the spec but don't interoperate, so I think we have a problem that needs to be addressed. -Dan Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CJw1Rj015839 for ; Mon, 12 Jan 2009 11:58:01 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CJsxVH012917 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 12 Jan 2009 19:55:27 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 12 Jan 2009 11:55:22 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Mon, 12 Jan 2009 11:55:05 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl07RtWHXTonwl4R7CMCRM3JXGdUAAALtwA Message-ID: References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> <496B9BBB.8030606@bbn.com> In-Reply-To: <496B9BBB.8030606@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CJw1Rj015839 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 19:58:02 -0000 > -----Original Message----- > From: Daniel Ellard [mailto:dellard@bbn.com] > Sent: Monday, January 12, 2009 11:36 AM > To: Burleigh, Scott C > Cc: dtn-users mailing list > Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > other BPAs) > > Burleigh, Scott C wrote: > > > > > I think I see. ION will reject as invalid any SDNV in a received > bundle whose total length exceeds 10 octets (which would accommodate a > 70-bit number); section 4.1 is the justification for this. But if the > SDNV is well-formed and the value that it contains happens to be too > large to fit into a C "unsigned long" [which is 32 bits on a 32-bit > machine and seems typically to be 64 bits on 64-bit machines] the SDNV > will be accepted but some high-order bits of the value will be lost. > > > > So the large timestamp would be honored in the sense that the bundle > would not be discarded out of hand upon parsing, but ION would in this > case have a hard time accepting custody: the timestamp of the bundle is > stored internally as a pair of unsigned long integers, not as the > original SDNV strings, so the acknowledged bundle's creation timestamp > (in the admin record) wouldn't come out right. > > > > I was hoping not to need to accommodate this kind of thing, but if it > is going to be a problem I will look into doing the additional native- > SDNV storage. Are you really expecting your creation timestamp > sequence numbers to exceed 4 billion? That is, you might be issuing > more than 4 billion bundles in one second? > > We're not expecting to create 4 billion bundles each second, but we get > into this situation in a different manner. The spec says that the > sequence number is a "monotonically increasing positive integer ... > that may be reset to zero whenever the current time advances by one second." > > The original designers of the BBN BPA noted that this is a "may" and not > a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided to take > advantage of this. One of the target hardware platforms has a > poor clock and therefore, to ensure uniqueness, it was decided to > augment the sequence number with an instance number, and these instance > numbers occupy the upper 32 bits of the sequence number. Therefore the > smallest possible BBN BPA sequence number is 2*32 + 1, so our very > first bundle is trouble. > > We would prefer to see the SDNV code extended to deal with larger > numbers in a portable manner. If the 32-bit limit doesn't bite us > here, it will bite us eventually somewhere (data length, probably). I see. Well, the SDNV code itself is already handling this case fine; the only 32-bit limit we're dealing with here is the limit imposed by the CPU architecture. But for interoperability with your implementation I guess I will need to modify the internal representation of bundles to retain the original SDNV text of the creation timestamp sequence number. > No matter what approach we take to resolving this, it seems that the > spec might require a small revision to make the definition of the way > timestamps are created more constrained. Even implementations that do > begin with a sequence number of 0 can fail if, for example, they > satisfy the "monotonically increasing" requirement by incrementing by a billion > -- it would be silly, but it would comply with the spec. They wouldn't fail, really, they'd just generate unnecessarily bloated bundles that receiving BPAs would have trouble with unless they made this same kind of modification. Modifying the spec to note this seems kind of legalistic to me. I personally would rather not augment the spec with a list of prohibitions against all possible silly things an implementer could do. Scott Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CJd1eX014958 for ; Mon, 12 Jan 2009 11:39:01 -0800 Received: from senshu.bbn.com ([128.89.80.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMSaJ-00020k-C1; Mon, 12 Jan 2009 14:36:27 -0500 Message-ID: <496B9BBB.8030606@bbn.com> Date: Mon, 12 Jan 2009 14:36:27 -0500 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 19:39:01 -0000 Burleigh, Scott C wrote: > > I think I see. ION will reject as invalid any SDNV in a received bundle whose total length exceeds 10 octets (which would accommodate a 70-bit number); section 4.1 is the justification for this. But if the SDNV is well-formed and the value that it contains happens to be too large to fit into a C "unsigned long" [which is 32 bits on a 32-bit machine and seems typically to be 64 bits on 64-bit machines] the SDNV will be accepted but some high-order bits of the value will be lost. > > So the large timestamp would be honored in the sense that the bundle would not be discarded out of hand upon parsing, but ION would in this case have a hard time accepting custody: the timestamp of the bundle is stored internally as a pair of unsigned long integers, not as the original SDNV strings, so the acknowledged bundle's creation timestamp (in the admin record) wouldn't come out right. > > I was hoping not to need to accommodate this kind of thing, but if it is going to be a problem I will look into doing the additional native-SDNV storage. Are you really expecting your creation timestamp sequence numbers to exceed 4 billion? That is, you might be issuing more than 4 billion bundles in one second? We're not expecting to create 4 billion bundles each second, but we get into this situation in a different manner. The spec says that the sequence number is a "monotonically increasing positive integer ... that may be reset to zero whenever the current time advances by one second." The original designers of the BBN BPA noted that this is a "may" and not a "MUST" (or even a "SHOULD", as defined in RFC2119) and decided to take advantage of this. One of the target hardware platforms has a poor clock and therefore, to ensure uniqueness, it was decided to augment the sequence number with an instance number, and these instance numbers occupy the upper 32 bits of the sequence number. Therefore the smallest possible BBN BPA sequence number is 2*32 + 1, so our very first bundle is trouble. We would prefer to see the SDNV code extended to deal with larger numbers in a portable manner. If the 32-bit limit doesn't bite us here, it will bite us eventually somewhere (data length, probably). No matter what approach we take to resolving this, it seems that the spec might require a small revision to make the definition of the way timestamps are created more constrained. Even implementations that do begin with a sequence number of 0 can fail if, for example, they satisfy the "monotonically increasing" requirement by incrementing by a billion -- it would be silly, but it would comply with the spec. -Dan Received: from mail.jpl.nasa.gov (sentrion1.jpl.nasa.gov [128.149.139.105]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CIYCRA012039 for ; Mon, 12 Jan 2009 10:34:12 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CIVco2015328 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL) for ; Mon, 12 Jan 2009 18:31:39 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 12 Jan 2009 10:31:46 -0800 From: "Burleigh, Scott C" To: dtn-users mailing list Date: Mon, 12 Jan 2009 10:31:29 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl04M58p/0118YyS4yD3PgAd35TgAAAQoJw Message-ID: References: <496B76A0.8060907@bbn.com> <496B8718.5080200@bbn.com> In-Reply-To: <496B8718.5080200@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CIYCRA012039 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 18:34:12 -0000 > -----Original Message----- > From: Daniel Ellard [mailto:dellard@bbn.com] > Sent: Monday, January 12, 2009 10:08 AM > To: Burleigh, Scott C > Cc: Christopher Small; dtn-users mailing list > Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and > other BPAs) > > Burleigh, Scott C wrote: > >> -----Original Message----- > >> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn- > users- > >> bounces@maillists.intel-research.net] On Behalf Of Christopher Small > >> Sent: Monday, January 12, 2009 8:58 AM > >> To: dtn-users mailing list > >> Subject: [dtn-users] Support for 64-bit timestamps in DTN2 (and other > >> BPAs) > >> > >> DTN2 doesn't support 64-bit timestamps (the timestamp code was written > >> before the spec was changed to 64 bits). > >> > >> 1. Is anyone already working on updating DTN2 to support 64 bit > >> timestamps? (If not, I or someone else at BBN will do it.) > >> > >> 2. Do other BPAs (e.g. DASM, ION, pydtn) handle 64-bit timestamps > >> gracefully (if they receive them)? > >> > >> - Chris > > > > Chris, I believe the spec doesn't actually say the timestamps are 64- > bits; it says they are SDNVs, which means they might be as short as 7 > bits (except that the creation time seconds is the count of seconds > since 2000, which won't fit into 7 bits). They might in theory be even > longer than 64 bits except for the caveat in section 4.1. Certainly a > bundle with a creation timestamp comprising a 28-bit count of seconds > (in a 4-byte SDNV) and a 7-bit sequence number (in a 1-byte SDNV) is > valid. > > > > ION's SDNV encoder and decoder functions will handle SDNV > representations of integer values occupying more than 32 bits, but on a > 32-bit machine the high-order bits above 32 will be shifted out and > lost in decoding. There didn't seem to be justification at this point > for invoking 64-bit arithmetic on 32-bit machines in a way that would > port to all of the operating systems we need to support, since there > doesn't yet seem to be any numeric value in the bundles we're > processing that won't fit into 32 bits. > > > Let me try to ask the question a different way. > > The DTN-RI cannot support timestamps whose fields have a native > representation (not SDNV) cannot fit into 32 bits. In fact, it does not > simply truncate them to 32 bits; it flags them as invalid. This means > that the BBN BPA, which can create sequence numbers with more than 32 > bits, cannot interoperate with the DTN-RI, becaues the DTN-RI treats > bundles with such sequence numbers in their timestamp as illegal. > > We don't care whether a specific BPA implementation uses 64-bit > timestamp elements -- no need to add 64-bit arithmetic to any existing > BPAs. We do care, however, whether those BPAs will honor timestamps too > large to fit into 32 bits but that are correct according to the spec. I think I see. ION will reject as invalid any SDNV in a received bundle whose total length exceeds 10 octets (which would accommodate a 70-bit number); section 4.1 is the justification for this. But if the SDNV is well-formed and the value that it contains happens to be too large to fit into a C "unsigned long" [which is 32 bits on a 32-bit machine and seems typically to be 64 bits on 64-bit machines] the SDNV will be accepted but some high-order bits of the value will be lost. So the large timestamp would be honored in the sense that the bundle would not be discarded out of hand upon parsing, but ION would in this case have a hard time accepting custody: the timestamp of the bundle is stored internally as a pair of unsigned long integers, not as the original SDNV strings, so the acknowledged bundle's creation timestamp (in the admin record) wouldn't come out right. I was hoping not to need to accommodate this kind of thing, but if it is going to be a problem I will look into doing the additional native-SDNV storage. Are you really expecting your creation timestamp sequence numbers to exceed 4 billion? That is, you might be issuing more than 4 billion bundles in one second? Scott Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CIAteY010934 for ; Mon, 12 Jan 2009 10:10:55 -0800 Received: from senshu.bbn.com ([128.89.80.164]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LMRD6-0000Yf-A6; Mon, 12 Jan 2009 13:08:24 -0500 Message-ID: <496B8718.5080200@bbn.com> Date: Mon, 12 Jan 2009 13:08:24 -0500 From: Daniel Ellard Organization: BBN Technologies User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Burleigh, Scott C" References: <496B76A0.8060907@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-users mailing list Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 18:10:56 -0000 Burleigh, Scott C wrote: >> -----Original Message----- >> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >> bounces@maillists.intel-research.net] On Behalf Of Christopher Small >> Sent: Monday, January 12, 2009 8:58 AM >> To: dtn-users mailing list >> Subject: [dtn-users] Support for 64-bit timestamps in DTN2 (and other >> BPAs) >> >> DTN2 doesn't support 64-bit timestamps (the timestamp code was written >> before the spec was changed to 64 bits). >> >> 1. Is anyone already working on updating DTN2 to support 64 bit >> timestamps? (If not, I or someone else at BBN will do it.) >> >> 2. Do other BPAs (e.g. DASM, ION, pydtn) handle 64-bit timestamps >> gracefully (if they receive them)? >> >> - Chris > > Chris, I believe the spec doesn't actually say the timestamps are 64-bits; it says they are SDNVs, which means they might be as short as 7 bits (except that the creation time seconds is the count of seconds since 2000, which won't fit into 7 bits). They might in theory be even longer than 64 bits except for the caveat in section 4.1. Certainly a bundle with a creation timestamp comprising a 28-bit count of seconds (in a 4-byte SDNV) and a 7-bit sequence number (in a 1-byte SDNV) is valid. > > ION's SDNV encoder and decoder functions will handle SDNV representations of integer values occupying more than 32 bits, but on a 32-bit machine the high-order bits above 32 will be shifted out and lost in decoding. There didn't seem to be justification at this point for invoking 64-bit arithmetic on 32-bit machines in a way that would port to all of the operating systems we need to support, since there doesn't yet seem to be any numeric value in the bundles we're processing that won't fit into 32 bits. Let me try to ask the question a different way. The DTN-RI cannot support timestamps whose fields have a native representation (not SDNV) cannot fit into 32 bits. In fact, it does not simply truncate them to 32 bits; it flags them as invalid. This means that the BBN BPA, which can create sequence numbers with more than 32 bits, cannot interoperate with the DTN-RI, becaues the DTN-RI treats bundles with such sequence numbers in their timestamp as illegal. We don't care whether a specific BPA implementation uses 64-bit timestamp elements -- no need to add 64-bit arithmetic to any existing BPAs. We do care, however, whether those BPAs will honor timestamps too large to fit into 32 bits but that are correct according to the spec. -Dan Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CHfqta009604 for ; Mon, 12 Jan 2009 09:41:52 -0800 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n0CHbDBB020040 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Mon, 12 Jan 2009 17:37:48 GMT Received: from ALTPHYEMBEVSP10.RES.AD.JPL ([128.149.137.81]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Mon, 12 Jan 2009 09:37:55 -0800 From: "Burleigh, Scott C" To: Christopher Small , dtn-users mailing list Date: Mon, 12 Jan 2009 09:37:38 -0800 Thread-Topic: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) Thread-Index: Acl015O7Ql7oLFFtSMitJ/mY0EoLmgAAQNSQ Message-ID: References: <496B76A0.8060907@bbn.com> In-Reply-To: <496B76A0.8060907@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id n0CHfqta009604 Subject: Re: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 17:41:52 -0000 > -----Original Message----- > From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- > bounces@maillists.intel-research.net] On Behalf Of Christopher Small > Sent: Monday, January 12, 2009 8:58 AM > To: dtn-users mailing list > Subject: [dtn-users] Support for 64-bit timestamps in DTN2 (and other > BPAs) > > DTN2 doesn't support 64-bit timestamps (the timestamp code was written > before the spec was changed to 64 bits). > > 1. Is anyone already working on updating DTN2 to support 64 bit > timestamps? (If not, I or someone else at BBN will do it.) > > 2. Do other BPAs (e.g. DASM, ION, pydtn) handle 64-bit timestamps > gracefully (if they receive them)? > > - Chris Chris, I believe the spec doesn't actually say the timestamps are 64-bits; it says they are SDNVs, which means they might be as short as 7 bits (except that the creation time seconds is the count of seconds since 2000, which won't fit into 7 bits). They might in theory be even longer than 64 bits except for the caveat in section 4.1. Certainly a bundle with a creation timestamp comprising a 28-bit count of seconds (in a 4-byte SDNV) and a 7-bit sequence number (in a 1-byte SDNV) is valid. ION's SDNV encoder and decoder functions will handle SDNV representations of integer values occupying more than 32 bits, but on a 32-bit machine the high-order bits above 32 will be shifted out and lost in decoding. There didn't seem to be justification at this point for invoking 64-bit arithmetic on 32-bit machines in a way that would port to all of the operating systems we need to support, since there doesn't yet seem to be any numeric value in the bundles we're processing that won't fit into 32 bits. Scott Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id n0CH0cOv007724 for ; Mon, 12 Jan 2009 09:00:38 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LMQ77-0000ls-D1 for dtn-users@mailman.dtnrg.org; Mon, 12 Jan 2009 11:58:09 -0500 Message-ID: <496B76A0.8060907@bbn.com> Date: Mon, 12 Jan 2009 11:58:08 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: dtn-users mailing list X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-users] Support for 64-bit timestamps in DTN2 (and other BPAs) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 17:00:38 -0000 DTN2 doesn't support 64-bit timestamps (the timestamp code was written before the spec was changed to 64 bits). 1. Is anyone already working on updating DTN2 to support 64 bit timestamps? (If not, I or someone else at BBN will do it.) 2. Do other BPAs (e.g. DASM, ION, pydtn) handle 64-bit timestamps gracefully (if they receive them)? - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138