Subject: Re: [dtn-interest] Meeting at next IETF
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Sun, 27 Jan 2008 00:19:58 +0200
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

>>I've just requested a slot for us to meet at the next
>>IETF meeting, March 9-14 [1].
>>
>>I'll send a call for agenda items closer to the date.
>>
>>There was some talk about doing another interop then.
>>If you'd like to take part in that please say so and
>>we can start to get organised.
>>  
> 
> I think that would be worthwhile, especially now that RFC 5050 is out 
> and we've got a fixed point of reference for a while.  And I'd like to 
> try inserting the ION implementation of LTP into an LTP interop as well.

Just to add further support for this idea.

Joerg

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Sat, 26 Jan 2008 08:32:55 -0800
Subject: Re: [dtn-interest] DTN from space - Low Earth Orbiting Satellite
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

We are currently trying to get an official slot on friday.  This is  
subject to the IETF scheduling process, so its still in flux.

- K

On Jan 26, 2008, at Jan 267:53 AMPST, Ivancic, William D. (GRC-RCN0)  
wrote:

> Yes,  I plan on attending.  When are you meeting - Friday all day?  I
> just want to make sure I make the proper flight arrangements.
>
> Will
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> Fall, Kevin
>> Sent: Friday, January 25, 2008 11:12 PM
>> To: Delay Tolerant Networking Interest List
>> Subject: Re: [dtn-interest] DTN from space - Low Earth
>> Orbiting Satellite
>>
>> Yes, this seems quite interesting.  Would you be willing/able
>> to present this at the IETF in Philidelphia?
>>
>>
>> - K
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> Scott Burleigh
>> Sent: Friday, January 25, 2008 1:48 PM
>> To: Delay Tolerant Networking Interest List
>> Subject: Re: [dtn-interest] DTN from space - Low Earth
>> Orbiting Satellite
>>
>> Ivancic, William D. (GRC-RCN0) wrote:
>>> The following a status of some recent tests - very recent.
>>>
>>> We have learned quite a lot in the past month and in
>> particular during
>>> the past two days regarding operations of a global DTN network.  We
>> will
>>> be getting our lessons learned documented and send those out.
>> Congratulations, Will.  This is a great first step; I'll be
>> very interested to read your lessons learned.
>>
>> Scott
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Date: Sat, 26 Jan 2008 09:53:14 -0600
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] DTN from space - Low Earth Orbiting Satellite
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Yes,  I plan on attending.  When are you meeting - Friday all day?  I
just want to make sure I make the proper flight arrangements.

Will

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Fall, Kevin
> Sent: Friday, January 25, 2008 11:12 PM
> To: Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] DTN from space - Low Earth 
> Orbiting Satellite
> 
> Yes, this seems quite interesting.  Would you be willing/able 
> to present this at the IETF in Philidelphia?
> 
> 
> - K
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of 
> Scott Burleigh
> Sent: Friday, January 25, 2008 1:48 PM
> To: Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] DTN from space - Low Earth 
> Orbiting Satellite
> 
> Ivancic, William D. (GRC-RCN0) wrote:
> > The following a status of some recent tests - very recent.
> >
> > We have learned quite a lot in the past month and in 
> particular during 
> > the past two days regarding operations of a global DTN network.  We
> will
> > be getting our lessons learned documented and send those out.
> Congratulations, Will.  This is a great first step; I'll be 
> very interested to read your lessons learned.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Fri, 25 Jan 2008 20:11:46 -0800
From: "Fall, Kevin" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] DTN from space - Low Earth Orbiting Satellite
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Yes, this seems quite interesting.  Would you be willing/able to present
this at the IETF in Philidelphia?

- K

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: Friday, January 25, 2008 1:48 PM
To: Delay Tolerant Networking Interest List
Subject: Re: [dtn-interest] DTN from space - Low Earth Orbiting
Satellite

Ivancic, William D. (GRC-RCN0) wrote:
> The following a status of some recent tests - very recent.
>
> We have learned quite a lot in the past month and in particular during
> the past two days regarding operations of a global DTN network.  We
will
> be getting our lessons learned documented and send those out.
Congratulations, Will.  This is a great first step; I'll be very 
interested to read your lessons learned.

Scott

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 25 Jan 2008 13:48:07 -0800
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN from space - Low Earth Orbiting Satellite
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Ivancic, William D. (GRC-RCN0) wrote:
> The following a status of some recent tests - very recent.
>
> We have learned quite a lot in the past month and in particular during
> the past two days regarding operations of a global DTN network.  We will
> be getting our lessons learned documented and send those out.
Congratulations, Will.  This is a great first step; I'll be very 
interested to read your lessons learned.

Scott

Content-class: urn:content-classes:message
Date: Fri, 25 Jan 2008 15:09:52 -0600
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN from space - Low Earth Orbiting Satellite
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

The following a status of some recent tests - very recent.

We have learned quite a lot in the past month and in particular during
the past two days regarding operations of a global DTN network.  We will
be getting our lessons learned documented and send those out.  Items
such as time synchronization and better ways to ensure bundle don't live
forever are just a few of the items we will address. 

Three SSTL UK-DMC Satellite passes were taken on 25 January 2008 to test
the latest NASA/Cisco/SSTL build of Saratoga/DTN bundling. 
The passes occurred as follows:
07:54 - 08:07 UTC   28 deg elev
09:31 - 09:45 UTC   45 deg elev
11:12 - 11:21 UTC    5 deg elev

Information on the SSTL disaster monitoring satellites is here:
http://www.sstl.co.uk/index.php?loc=120

And the UK-DMC with the Cisco Router is here: 
Note, the router was not used for these tests.  The code is written
directly to RTEMS on the Solid State Data Recorder Stack.  Only those
portions necessary to create bundles were written into RTEMS.  The
smarts where placed on the ground.  All of this will eventually be
documented in a formal report and papers.  This is most definitely work
in progress.

http://www.sstl.co.uk/index.php?loc=113
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/
ftp://ftp-eng.cisco.com/lwood/cleo/README.html

============================================
DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
1)	Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
Station
2)	Demonstrate that DTN code and general SSTL code can coexist
without effecting normal SSTL Operations

Configuration
*	UK-DMC acquired a150 Mbyte image over the Gulf of Khambhat,
India at ~04:35 UTC on 25 January 2008. 
*	DTN bundling code default set to 80 Mbytes for proactive
fragmentation
Tests
1)	Basic file download using existing technique (Saratoga)
2)	Same file downloaded but treated as single bundle (DTN)
3)	Same file download but using DTN proactive fragmentation with 80
Mbytes preconfigured fragments.
=============================================

Executive Summary:

The passes where successful in the fact that we learned a lot and
identified some bugs.  On the surface, these bugs appear to be minor and
relatively easy to correct.  Thus, for a first try, we should all be
please.

For the most part, DTN bundling and forwarding worked but we appear to
have a bug in the GRC implementation of Saratoga regarding filling holes
in missed data.  In addition, there may be a bug in the DTN-2 code
implementation on the SSTL bundling agent as on bundle got stuck in a
temporary file and was never transferred from SSTL to GRC.

It appears that on the first pass, tests 1 and 2 were successful
regarding operation of DTN and the ability to either use either Saratoga
for straight file transfers or Saratoga with bundling to transfer DTN
bundles between the UK-DMC solid state data recorder and the ground.
Also the DTN-2 forwarding agent, Bundling-SSTL was able to automatically
forward the DTN bundles to a DTN-2 bundling agent at Glenn Research
Center, Bundling-GRC1.  Furthermore, we could then extract the image
file from the DTN bundle.

============================================== 
 
Detailed Analysis:

The image files for 25 January 2008 tests are available at the following
URL:
(Link Removed)

Investigation of these show each image file has "holes" in different
portions of the file.

The simplified test configuration is show in the figure below.

                   UK-DMC
                 (Bundling Only)
             +------+,-.+------+
             |      |   |      |
             +------+`-'+------+
                    .'
                  .'
                .' Saratoga Transport
              .'        Over UDP
       |    .'
        '..'
       .\ `..
     .i__i.
   +----------+                           +----------+
   | Bundling | __________________________| Bundling |
   |  SSTL    |'       TCP Transport      |  GRC1    |
   +----------+                           +----------+
    DTN-2-Based                            DTN-2-Based
    Modifications
    - Large files
    - DTN Client to pull bundles
      From UK-DMC (smarts on the ground)

Pass 1, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL.

Pass 1, Test 2:
The DTN file and associated metadata for the full bundle was received by
Bundling-SSTL and then forwarded as a full bundle to Bundinging-GRC1

The file was then extracted from the bundle and saved as
"bundling-file".

We  performed a "diff" between "saratoga-file" and "bundling-file" and
the result showed mismatch, but no detail on what was mismatched.  
Post analysis showed "holes" in both the files brought down using
Saratoga for file transfer and Saratoga for bundle transfer.  We suspect
a problem with the GRC implementation of Saratoga.  We suspect  a
problem in the perl code.  This is the first place GRC will investigate
as that code is related to the hole filling.  We did not really stress
the testing of that (hole filing) in the lab as we were running
error-free links.  The pattern of holes in different places of each
image transfer leads us to suspect the "holes to fill" portion of the
code. That probably explains the main difference regarding file mismatch
between the first and second passes from the standpoint of that part of
the experiment.  That would also explain why the Saratoga-only transfer
doesn't match the DTN one.  

Pass 1, Test 3 - Proactive Fragmentation:

While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file.  The directory showed creation of the 1st fragmentation
metadata file, but not the second.  We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1.

Upon investigation of the syslog, it appears that the 2nd metadata
proactive fragmentation metadata file was created, but the file could
not be written.  Upon discussion with SSTL and investigation, it appears
the 2nd metadata file length was to be 33 characters and 32 characters
is the current limit.  

*	One possible way is to fix this is to recompile RTEMS such that
longer file names are allowed.  Since this only effects the DTN
proactive fragmentation this may be acceptable.  
*	Another possible solution is to have the default file name less
than 10 characters.  However, this changes SSTL's default naming system.
*	A third way is to rethink how the proactive fragmentation files
are named.  The long length is caused by the naming convention used
where the fragmentation metadata files and associated bundles are name
as "filename.startoffset-endoffset.dtn".  Here, the start offset is the
location in memory where Saratoga should begin capturing data and the
end offset is the location where Saratoga should stop capturing data.
We will discuss possible solutions with SSTL. 

Example file names:

SSTL full image = DU000c76pm
Fragment 1 (80 Mbytes) = DU000c76pm.0-79999999.dtn  (25 characters)
Fragment 2 (70 Mbytes) = DU000c76pm.79999999-153700328.dtn  (33
characters)

Pass 2, Test 1:
The Image file DU00076pm was received using Saratoga at the
Bundling-SSTL, the DTN bundle agent at SSTL.  However, post processing
showed holes in the image file (long strings of zeros).

Pass 2, Test 2:
The DTN metadata file for the full bundle was received as was the DTN
file.  However, this data was written to a temporary file and never pass
on to the DTN bundle forwarding portion of the code.  Thus, the bundle
was never transferred from Bundling-SSTL to Bundinging-GRC1.

After the fact, we manually retrieved the bundle from the temporary
storage location and extracted the file.  Thus, the bundle was moved
from the UK-DMC to SSTL bundling agent at the ground and then got stuck
in memory.  This may take some time to troubleshoot.

Pass 2, Test 3 - Proactive Fragmentation:

While running Saratoga on Bundling-SSTL we retrieved the directory and
the syslog file.  The directory showed creation of the 1st fragmentation
metadata file, but not the second.  We retrieved the 1st proactive
fragmented bundle from the UK-DMC and it was automatically transferred
using DTN-2 between Bundling-SSTL to Bundling-GRC1.  Thus, results were
identical to Pass1, Test 3.

Pass 3:

During the third pass of the day, GRC personnel went home to sleep and
SSTL personnel transferred the image using SSTL's version of Saratoga.
The image transferred in tact with no holes.  

========================================

Next Steps to fix technical problems:

1)  	Induce errors into the space-to-ground and ground-to-space links
of the engineering test system and troubleshoot the "hole filling"
problem.  The capability currently exists and just has to be turned on.

2)  	Fix the fragmentation problem associated with the long naming.
This should be relatively easy, but which approach needs to be discussed
with SSTL.

3)  	Analyze and investigate why the DTN bundle got trapped in
temporary storage locations on the SSTL bundle forwarding agent.  This
may take some time.  Our files were quite large - 150 Mbytes.  This
large size may have something to do with the problem.

Date: Wed, 23 Jan 2008 16:58:36 -0500
From: "Gaurav Saxena" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Compile errors on "make" in Cygwin
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

------=_Part_20634_6151328.1201125516569
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,

I am trying to install DTN2 on Cygwin (latest version: 1.5.27-7). I got
success when I ran:-

./configure -C --disable-ecl --disable-edp;

However after executing above instruction I did 'make': - I get the
following error-

/io/FileUtils.cc: line 133:error:   'struct dirent' has no member named
'd_type'
/io/FileUtils.cc: line 133: error:  'DT_DIR' undeclared <first use this
function>

compilation stops in 'io' directory of parent 'oasys' directory.

Please help me in resolving the above error.

Thanks in advance.

Gaurav

------=_Part_20634_6151328.1201125516569
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi All,</div>
<div>&nbsp;</div>
<div>I am trying to install DTN2 on Cygwin (latest version: 1.5.27-7). I got success when I ran:-</div>
<div>&nbsp;</div>
<div>./configure -C --disable-ecl --disable-edp;</div>
<div>&nbsp;</div>
<div>However after executing above instruction I did &#39;make&#39;: - I get the following error-</div>
<div>&nbsp;</div>
<div>/io/FileUtils.cc: line 133:error:&nbsp;&nbsp; &#39;struct dirent&#39; has no member named &#39;d_type&#39;</div>
<div>/io/FileUtils.cc: line 133: error:&nbsp; &#39;DT_DIR&#39; undeclared &lt;first use&nbsp;this function&gt;</div>
<div>&nbsp;</div>
<div>compilation stops in &#39;io&#39; directory of parent &#39;oasys&#39; directory.</div>
<div>&nbsp;</div>
<div>Please help me in resolving the above error.</div>
<div>&nbsp;</div>
<div>Thanks in advance.</div>
<div>&nbsp;</div>
<div>Gaurav</div>

------=_Part_20634_6151328.1201125516569--

Date: Wed, 23 Jan 2008 16:36:48 +0100
From: Chiara Boldrini <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [IEEE AOC 2008 - WoWMoM Workshop]: Call for Papers - Deadline approaching
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

We apologize in advance if you receive multiple copies of this CFP.

---------------------------------------------------------------------
      ***** PAPER SUBMISSION DEADLINE IS FAST APPROACHING *****
                   ***   JUST 2 WEEKS LEFT  ***
                         FEBRUARY 11, 2008
---------------------------------------------------------------------

                          CALL FOR PAPERS

                 Second IEEE WoWMoM Workshop on
          Autonomic and Opportunistic Communications  (AOC 2008)
                June 23, 2008 - Newport Beach (CA), USA
                     http://cnd.iit.cnr.it/aoc2008/

                             organized by
                       ANA and HAGGLE projects
             funded by the FET-IST Programme in the area
              Situated and Autonomic Communications (SAC)

      Fast Track on Pervasive and Mobile Computing (PMC) Journal
                   http://www.elsevier.com/locate/pmc

          **** Submission Deadline --- February 11, 2008 ****

---------------------------------------------------------------------

The goal of this workshop is to provide a forum between the autonomic
and opportunistic communication communities to exchange ideas,
discuss solutions, and share experiences among researchers,
professionals, and application developers both from industry and
academia. Original papers addressing both theoretical and practical
aspects of autonomic and opportunistic communications and are
solicited. Papers describing prototype implementations and
deployments are welcome.

Topics of interest include but are not limited to:

* Architecture and models for autonomic and opportunistic
   communications
* Tools and techniques for designing, analyzing and building autonomic
   and opportunistic networks
* Adaptive security for self protection of networks
* Economic, biological and social models used for autonomic and
   opportunistic communications
* Mobility models for opportunistic networking
* Novel management techniques for autonomic and opportunistic
   communications
* Sensing, monitoring and measurements for self-managing networks
* Advanced technologies for enabling autonomic and opportunistic
   communications
* Autonomic and opportunistic communication testbeds and measurements
* Algorithmic aspects associated with autonomic communications
   environments and problems

PAPER SUBMISSION AND PUBLICATION
--------------------------------
Papers should neither have been published elsewhere nor currently
under review by another conference or journal. Guidelines on paper
submission and formatting are available at
http://cnd.iit.cnr.it/aoc2008/.
Accepted papers will appear in the symposium proceedings published
by IEEE. Extended versions of workshop selected papers will be
considered for possible fast track publication on the Pervasive and
Mobile Computing Journal (Elsevier).

IMPORTANT DATES
---------------
Full papers due:      February 11, 2008
Notification:            March 15, 2007

ORGANIZING COMMITTEE
--------------------

WORKSHOP Chairs
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair
  Chiara Boldrini, IIT-CNR, Italy

PROGRAM COMMITTEE
--------------------------------

Mostafa Ammar, Georgia Institute of Technology, USA
Edoardo Biagioni, University of Hawaii, USA
Vania Conan, Thales, France
Falko Dressler, University of Erlangen-Nuremberg, Germany
Stephen Farrell, Trinity College Dublin, Ireland
Per Gunningberg, Uppsala University, Sweden
Hannes Hartenstein, Karlsruhe, Germany
Jean-Yves Le Boudec, EPFL, Switzerland
Vincent Lenders, Princeton University, USA
Cecilia Mascolo, UCL, UK
Martin May, ETH, Switzerland
Daniele Miorandi, Create-net, Italy
Refik Molva, EurÃ©com, France
Konstantinos Oikonomou, Ionian University, Greece
Joerg Ott, HUT, Finland
Antonios Panagakis, University of Athens, Greece
Symeon Papavassiliou, NTUA, Greece
Andrea Passarella, IIT-CNR, Italy
Giovanni Pau, UCLA, USA
Calicrates Policroniades, Telenor, Norway
George Polyzos, AUEB, Greece
Konstantinos Psounis, University of Southern California, USA
Christian Rohner, Uppsala University, Sweden
Fabrizio Sestini, FET, European Commission
Thrasyvoulos Spyropoulos, ETH Zurich, Switzerland
John Strassner, Motorola, USA
Violet Syrotiuk, Arizona State University, USA
Pablo Vidales, Deutsche Telekom Laboratories, Germany
Hongyi Wu, University of Louisiana, USA
Eiko Yoneki, University of Cambridge, UK
Franco Zambonelli, University of Modena-Reggio, Italy

====================================================
Chiara Boldrini - Ph.D. Student
AOC 2008 Publicity Chair

     Institute for Informatics and Telematics (IIT)
     Italian National Research Council (CNR)
     Via G. Moruzzi, 1 - 56124 Pisa, Italy

     phone: + 39 050 315 3504 (direct)
     email: [email-masked]
====================================================

Content-class: urn:content-classes:message
Date: Wed, 16 Jan 2008 13:44:29 -0500
From: "Garriott, Gary" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: [dtn-interest] off the beaten path--legacy project anyone?
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8586F.D44AAA90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello to all,

I am a lurker on this list as the idea of different approaches to
internet communication such as asynchronous still has application in
many areas of the developing world.

One of the earliest projects in this regard was a store-and-forward
email project via low orbiting satellite on which I worked for many
years (from about 1984-2002). While we did fascinating pilots in various
parts of the world, it didn't go all the way to commercial success
because of some bad management decisions at the time. However, a group
of volunteers maintained interest in developing a lowcost groundstation
(called the Portable Ground Station, PGS) at the board level and came
very close to finishing (all that was needed was to finish the TNC
[terminal node controller] piece as transmitter and receiver were
working fine), see one of the last emails below.

I was wondering if this would be of interest to anyone on this list.
There are still satellites in orbit manufactured by Surrey Satellite
Technology in the UK that could be used for further experimentation and
'piggy-backing' for new trials in developing countries.

Further info attached (file).

Best,

Gary Garriott
Innovation Program Officer
Digital Futures for Development Program
Winrock International
Voice: +703 525 9430, ext. 614
www.winrock.org

+++++++++++++++++++++
(mid-2006)
=20

After 8 years (1998 - 2006) of work on the PGS it is a shame that there
is no completion to the project.

We have built approx. 40 of the original PGS units and deployed them all
over Africa.   Three Hybrid units were built that were very successful
until the satellites died.  The hybrid had everything purpose built with
the exception of the TNC.  The latest and very small design is almost
complete except for testing the new TNC software.

I have lost so much income in the last 8 years having to remortgage
several times that I must work hard now so that I can retire at 65.
Even if we had a new satellite and enough money to continue I am worried
that at my age it may become difficult to find another job after a short
contract to complete the work.

I'm open to suggestions and would consider passing the baton on.  The
documentation is limited and the prototype a little fragile but a
serious party could take it over.  It would be a steep learning curve
for someone and would require some significant funding.  I would be
happy to consult on the project, or even fly over if someone can raise
funds.

I am really happy that you are trying to find a solution.  I only wish I
could still be involved.  As you say there doesn't seem to be a solution
at the time.  I trust you will find one.

God bless - Dave

Dave Palmer PhD MIET
14 Garibaldi Road
REDHILL
Surrey
RHI 6PB
UK

Tel: 01737 772391

------_=_NextPart_001_01C8586F.D44AAA90
Content-Type: application/msword;
	name="GARECissue3.doc"
Content-Transfer-Encoding: base64
Content-Description: GARECissue3.doc
Content-Disposition: attachment;
	filename="GARECissue3.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAUAEAAAAAAAAA
EAAAUgEAAAEAAAD+////AAAAAE0BAABOAQAATwEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C8586F.D44AAA90--

Date: Tue, 15 Jan 2008 10:10:24 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN simulator
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

You can also take a look at ONE.

http://www.netlab.hut.fi/~jo/dtn/index.html#one

Joerg

> I was wondering if there is a DTN simulator around.. My understanding is that
> the DTN reference implementation instantiates a single node on a computer. Is
> that assumption correct?
> 
> Durga
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Michael Demmer <[email-masked]>
Date: Mon, 14 Jan 2008 14:30:53 -0800
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN simulator
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

The DTN2 reference implemementation includes a simulator that can  
model multiple nodes in a single-threaded unix process.

Email me off-list if you have any questions about this simulator.

-mike

On Jan 14, 2008, at 1:28 PM, [email-masked] wrote:

> I was wondering if there is a DTN simulator around.. My  
> understanding is that
> the DTN reference implementation instantiates a single node on a  
> computer. Is
> that assumption correct?
>
> Durga
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 14 Jan 2008 16:28:25 -0500
From: [email-masked]
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] DTN simulator
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I was wondering if there is a DTN simulator around.. My understanding is that
the DTN reference implementation instantiates a single node on a computer. Is
that assumption correct?

Durga

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: 14 Jan 2008 14:57:06 -0000
From: "laveen vikram sundararaj" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] Meeting at next IETF
Reply-To: laveen vikram sundararaj <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>

 This is a multipart mime message

--Next_1200322626---0-59.160.240.225-24983
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Respected Sir,=0AI am currently in US and will be there till july. It will =
be good to meet you and the DTNRG folks again. Hence if you can let me know=
 the exact slot when the DTNRG is gonna be there at PA, I can plan to come =
over that day only.=0Aregards,=0ALaveen. =A0=0A=0A=0AOn Wed, 02 Jan 2008 St=
ephen Farrell wrote :=0A>=0A>Folks,=0A>=0A>I've just requested a slot for u=
s to meet at the next=0A>IETF meeting, March 9-14 [1].=0A>=0A>I'll send a c=
all for agenda items closer to the date.=0A>=0A>There was some talk about d=
oing another interop then.=0A>If you'd like to take part in that please say=
 so and=0A>we can start to get organised.=0A>=0A>Stephen.=0A>=0A>[1] http:/=
/www.ietf.org/meetings/71-IETF.html=0A>=0A>=0A>____________________________=
___________________=0A>dtn-interest mailing list=0A>[email-masked]=
nrg.org=0A>http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t=0A
--Next_1200322626---0-59.160.240.225-24983
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0ARespected Sir,<BR>=0AI am currently in US and will be there till july=
. It will be good to meet you and the DTNRG folks again. Hence if you can l=
et me know the exact slot when the DTNRG is gonna be there at PA, I can pla=
n to come over that day only.<BR>=0Aregards,<BR>=0ALaveen.&nbsp; <BR>=0A<BR=
>=0A<BR>=0AOn Wed, 02 Jan 2008 Stephen Farrell wrote :<BR>=0A&gt;<BR>=0A&gt=
;Folks,<BR>=0A&gt;<BR>=0A&gt;I've just requested a slot for us to meet at t=
he next<BR>=0A&gt;IETF meeting, March 9-14 [1].<BR>=0A&gt;<BR>=0A&gt;I'll s=
end a call for agenda items closer to the date.<BR>=0A&gt;<BR>=0A&gt;There =
was some talk about doing another interop then.<BR>=0A&gt;If you'd like to =
take part in that please say so and<BR>=0A&gt;we can start to get organised=
.<BR>=0A&gt;<BR>=0A&gt;Stephen.<BR>=0A&gt;<BR>=0A&gt;[1] http://www.ietf.or=
g/meetings/71-IETF.html<BR>=0A&gt;<BR>=0A&gt;<BR>=0A&gt;___________________=
____________________________<BR>=0A&gt;dtn-interest mailing list<BR>=0A&gt;=
[email-masked]<BR>=0A&gt;http://maillists.intel-research.ne=
t/mailman/listinfo/dtn-interest<BR>=0A=0A</P>=0A<br><br>=0A<Table border=3D=
0 Width=3D644 Height=3D57 cellspacing=3D0 cellpadding=3D0 style=3D'font-fam=
ily:Verdana;font-size:11px;line-height:15px;'><TR><td><img src =3D'http://i=
madworks.rediff.com/cgi-bin/AdWorks/adimage.cgi/2030158_2022951/creative_20=
30003.gif'  alt=3D'Blank Default Campaign'  border=3D0></td></TR></Table>
--Next_1200322626---0-59.160.240.225-24983--

From: Michael Demmer <[email-masked]>
Date: Tue, 8 Jan 2008 17:08:27 -0800
To: dtn-interest <[email-masked]>, dtn-users <[email-masked]>
Subject: [dtn-interest] DTN2 version control switch
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Over the past several months, I and a few other people have been  
using mercurial [1] as a version control system for the DTN2  
reference implementation to replace CVS. Based on those experiences,  
we've decided to adopt it as the "official" version control system  
for the development of the DTN2 reference implementation going forward.

Mercurial has a number of advantages over CVS, and I won't try to  
list them all here, but there are a number of good online resources  
available off of the main mercurial web site that explain how  
mercurial is different (and IMO better) than CVS or even newer  
centralized VC systems like subversion.

Despite the fact that Mercurial can be used in a decentralized  
manner, we will continue to host an "official" repository for DTN2  
and its supporting libraries (oasys, etc) on code.dtnrg.org. The  
dtnrg wiki has been updated with information [2] on how to access the  
new mercurial repositories.

We did an initial repository conversion from CVS in October 2007 to  
preserve the old revision history and source file attributions. This  
included all changes up and including to the 2.5.0 release of DTN2.  
Since that time, there have been some relatively significant source  
code reorganization and modifications, as can be seen in the  
mercurial revision history, but the current tip of the mercurial tree  
is stable.

Hopefully this will make it easier for people to use the DTN source  
tree (and will help keep my life as the main source maintainer a  
little easier). Our initial experiences have been positive and we  
hope that will continue going forward.

-m

[1] http://www.selenic.com/mercurial
[2] http://www.dtnrg.org/wiki/UsingMercurial

Date: Mon, 07 Jan 2008 09:31:55 -0800
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Meeting at next IETF
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Stephen Farrell wrote:
> Folks,
>
> I've just requested a slot for us to meet at the next
> IETF meeting, March 9-14 [1].
>
> I'll send a call for agenda items closer to the date.
>
> There was some talk about doing another interop then.
> If you'd like to take part in that please say so and
> we can start to get organised.
>   
I think that would be worthwhile, especially now that RFC 5050 is out 
and we've got a fixed point of reference for a while.  And I'd like to 
try inserting the ION implementation of LTP into an LTP interop as well.

Scott

Date: Sun, 06 Jan 2008 16:36:59 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN bundle protocol reference implementation: requirements and goals
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

>>I am not sure that there is a need for _the_ reference
>>implementation (and so I am wondering why we should have a
>>list of "requirements").  I do not see the implementation
>>activities as a contest to be won by someone and lost by
>>others.
> 
> I think that if there is an implementation that is recognized by the 
> community as _the_ reference implementation, it holds special status 
> with the community. It is the one that people go to as a starting place 
> when learning about the technology; it is used as an interoperability 
> benchmark; it is a deployable implementation that can be easily and 
> widely deployed. If it meets these requirements, it can accelerate 
> adoption of a technology. 

Not necessarily if the requirements are set such that a true
reference implementation (meeting them) has a hard time to emerge.
As I pointed out in the larger part of my mail (and as also Craig
pointed to), some of these 'requirements' may easily be at odds
with each other.  It may be worthwhile to define an 'ideal' target
(then, why did you not include the major mobile operating systems?),
but it should not create unrealistic expectations on what the
community can offer.

> Examples that come to mind are the Berkeley TCP stack and the K&R C 
> compiler. Both implemented a documented standard, both were adopted by 
> their communities as reference implementations, both really helped 
> catalyze the adoption of the technology.

Yes.  And this is good.  Yet, we have a bit more diversity today.
In my opinion, the key points here are that we have a
well-defined and stable API to the application and adherence
to the protocol spec.  Except for educactional purposes, the internals
are not of that much interest to the many users wanting to deploy
this technology in different projects, nor to those people
developing their own code who want to see whether they can
interoperate.

Maybe, the requirements should be grouped to different targets
to be able to have something for everyone and provide some
guidance like: "for embedded devices, use X", "for cellphones,
use Y", "for playing around with extensions under linux in the
lab, use Z".  I have a hard time believing in one-size-fits-all
approaches.

> I agree that there will be multiple implementations -- that's good. But 
> it's also good for a nascent technology to have a reference 
> implementation to rally people, projects, and effort around.

Agreed, again.

> DTN2 has done a great job of that. But it was started before we had a 
> spec for the bundle protocol, and it has grown organically to meet the 
> needs of its developers. This is a good time to step back and think 
> consciously about the goals and requirements of an RI to best support 
> the growth and adoption of DTN. As I said before, it might be that DTN2 
> is the answer, or DTN2.1, or maybe it's a clean-slate DTN3.

Taking a step back is surely a good thing to do.  But we clearly do
not want to end up with the 'second (well: third :-) system syndrome'
and never complete anything.  What the community needs most to ensure
use and spreading of this technology, is an API on top of which
application can be written and ported to different system environments.
And the community members should never need to be told 'to wait for the
big thing to come'.  So, my guess would be that our path should be
somehow evolutionary concerning the API, although I agree that there
is room for improvement (e.g., the security functions are not available
in the API).

There are quite many projects out there doing DTN research who are
not using the reference implementation or the DTNRG work at all.
They can probably give some insights on what they are missing.

Joerg

Date: Sat, 05 Jan 2008 19:44:57 +0100
From: Damien Sauveron <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [WISTP2008] Second Call for Papers
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

*******************************************************************
We apologize in advance if you receive multiple copies of this CFP.
Please disseminate it to your colleagues that could be interested.
*******************************************************************

Workshop in Information Security Theory and Practices 2008: Smart
Devices, Convergence and Next Generation Networks

May 13-16, 2008, Sevilla, Spain

Workshop URL: http://wistp2008.xlim.fr/

*******************************************************
WISTP2008 is:
- Co-Sponsored by IFIP WG 11.2 Small System Security
- Technical sponsorship of the IEEE Systems, Man & Cybernetics Society
Technical Committee on Systems Safety and Security
- Technical sponsorship of the IEEE Systems, Man & Cybernetics Society
Technical Committee on Information Assurance & Intelligent
Multimedia-Mobile Communications
- Technical sponsorship of the IEEE Region 8
- Technical sponsorship of the IEEE Spain Section, Computer Society
Chapter and the Signal Processing Society + ComSoc Joint Chapter
- Technical sponsorship of the IEEE UKRI Section Systems,
Man & Cybernetics Society Chapter
- In cooperation with the ACM SIGBED
- Supported by the Institute for Systems and Technologies of
Information, Control and Communication (INSTICC)
- Supported by the European Workshop on Industrial Computer Systems,
Technical Committee 7, Safety, Reliability and Security

*******************************************************
WISTP2008 Background and Goals:
With the rapid technological development of information technologies and
with the transition from the common to the next generation networks,
computer systems and especially embedded systems are becoming more
mobile and ubiquitous, increasingly interfacing with the physical world.
Ensuring the security of these complex and yet, resource constraint
systems has emerged as one of the most pressing challenges. Another
important challenge is related to the convergence of these new
technologies.
The aim of this second workshop is to bring together researchers and
practitioners in related areas and to encourage interchange and
cooperation between the research community and the industrial/consumer
community.
The workshop will consist of technical paper presentations, one special
session for student papers and six invited talks.

*******************************************************
Topics of interest include, but are not limited to:

A. Smart Devices
* Biometrics, National ID cards
* Embedded Systems Security and TPMs
* Interplay of TPMs and Smart Cards
* Mobile Codes Security
* Mobile Devices Security
* New Applications for Secure RFID Systems
* RFID Systems Security
* Smart Card Security
* Smart Devices Applications
* Wireless Sensor Node Security

B. Convergence: Security Architectures, Protocols, Policies and
Management for Mobility
* Critical Infrastructure (e.g. for Medical or Military Applications)
Security
* Digital Rights Management (DRM)
* Distributed Systems and Grid Computing Security
* Industrial and Multimedia Applications
* Information Assurance and Trust Management
* Intrusion Detection and Information Filtering
* Localization Systems Security (Tracking of People and Goods)
* M2M (Machine to Machine), H2M (Human to Machine) and M2H (Machine to
Human) Security
* Mobile Commerce Security
* Public Administration and Governmental Services
* Privacy Enhancing Technologies
* Security Models and Architecture
* Security Policies (Human-Computer Interaction and Human Behavior
Impact)
* Security Protocols (for Identification and Authentication,
Confidentiality and Privacy, and Integrity)
* Security Measurements

C. Next Generation Networks
* Ad Hoc Networks Security
* Delay-Tolerant Network Security
* Domestic Network Security
* Peer-to-Peer Networks Security
* Security Issues in Mobile and Ubiquitous Networks
* Security of GSM/GPRS/UMTS Systems
* Sensor Networks Security
* Vehicular Network Security
* Wireless Communication Security: Bluetooth, NFC, WiFi, WiMAX, WiMedia,
others

*******************************************************
Submission Details:
Authors are invited to submit original papers (written in english) not
previously published nor submitted in parallel for publication to any
other conference, workshop or journal. All submissions will be subjected
to thorough blind review by at least three reviewers (if the paper
involved a Program Committee member, the paper will be reviewed at least
by five reviewers). All submitted papers should be anonymous with no
author(s) names, affiliations, acknowledgements, nor obvious references.
Each paper should begin with a title, a short abstract, and a list of
keywords, following the template indicated by Springer at:
http://www.springer.de/comp/lncs/authors.html
The papers will be in .pdf format, at most 10 pages long excluding
bibliography and well-marked appendices, and at most 14 pages long in
total, using at least 11-point fonts with reasonable margins. As the
reader should not be required to read any appendices, the paper should
be intelligible even without them.
20 papers will be accepted for presentation at the workshop (they will
be included in the proceedings) and 12 additional papers will be
selected to be presented as A1 poster at the workshop (they will NOT be
included in the proceedings).
If a submitted paper is mainly the result of the work of a student
author, this paper could have the chance to be selected as "Best student
paper" (even if the paper has been written with senior co-authors).
To participate to this selection process, please add the word "STUDENT"
in the affiliation field in the submission form.
At least one author of each accepted paper is required to register with
the Conference and present the paper. For authors presenting multiple
papers, one normal registration is valid for up to two papers.
For electronic paper submission please use the following URL:
http://wistp2008.xlim.fr/wistp2008/iChair/
The secure version is not yet available
https://wistp2008.xlim.fr/wistp2008/iChair/
For further inquiries, please contact the secretariat at
[email-masked]

Workshop Proceedings:
Like for the first edition, accepted papers will be included in the
workshop proceedings, that should be published by Springer in their LNCS
series. Camera-ready versions of the papers should not exceed 10 pages
excluding bibliography and well-marked appendices (14 pages in total)
and must comply with the "Authors Instructions" that can be found at:
http://www.springer.de/comp/lncs/authors.html
We plan to index the proceedings to the DBLP, ISI Proceedings and
Inspec.

*******************************************************
Awards:
  * Best student paper: 800€
  * Best workshop paper: 800€ + the Handbook of Computer Networks
  * Best innovative technology: 800€
  * Each speaker of a selected papers will receive a kit containing a
smart card reader, a card and several software

*******************************************************
Important Dates:
- Intention of submission: ASAP. Send a mail to [email-masked]
- Intention of attendance: ASAP. Send a mail to [email-masked]
- Paper submission:     January 20th, 2008 (23h59 UTC)
- Notification:         February 20th, 2008
- Author Registration:  March 3rd, 2008
- Camera-ready papers:  March 5th, 2008

*******************************************************
WISTP2008 Committees and Chairs:

##### General chairs #####
* Jose Onieva. Computer Science Department, University of Malaga, Spain
* Damien Sauveron. XLIM, University of Limoges, France

- Local organisers:
* Diego Lopez. Red.es - RedIRIS, Spain
* Javier Lopez. Computer Science Department, University of Malaga, Spain

##### Workshop/panel/tutorial chair #####
* Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK

##### Publicity chairs #####
* Claudio Ardagna. Department of Information Technologies, University of
Milan, Italy
* Samia Bouzefrane. CEDRIC, CNAM, France
* Joonsang Baek. Cryptography and Security Department of Institute for
Infocomm Research (I2R), Singapore

##### Program chairs #####
* Serge Chaumette. LaBRI, University Bordeaux 1, France
* Dieter Gollmann. Security in Distributed Applications, Institutes of
the TU Hamburg-Harburg, Germany

##### Program Committee #####
* Rafael Accorsi. IIG, University of Freiburg, Germany
* Manfred Aigner. IAIK, Technical University Graz, Austria
* François Arnault. XLIM, University of Limoges, France
* Ioannis G. Askoxylakis. FORTH-ICS, Greece
* Christophe Bidan. SSIR, Supélec, France
* Pierre-François Bonnefoi. XLIM, University of Limoges, France
* Stefano Campadello. Nokia Research Center, Finland
* Sajal K. Das. CReWMaN, The University of Texas at Arlington, USA
* Mads Dam. KTH - Royal Institute of Technology, Sweden
* Estíbaliz Delgado, European Software Institute (ESI), Spain
* Tassos Dimitriou. Athens Information Technology, Greece
* Boris Dragovic. CREATE-NET, Italy
* Pierre Dusart. XLIM, University of Limoges, France
* Eduardo Fernández-Medina Patõn. Alarcos Research Group, University of
Castilla-La Mancha, Spain
* Theodoulos Garefalakis. Department of Mathematics, University of
Crete, Greece
* Stefanos Gritzalis. Info-Sec-Lab, University of the Aegean, Greece
* Olivier Heen. Security Laboratory, Thomson R&D, France
* Jaap-Henk Hoepman. TNO and Radboud University Nijmegen, Netherlands
* Sotiris Ioannidis. FORTH-ICS & University of Crete, Greece
* Sokratis Katsikas. Dept. of Technology Education & Digital Systems,
University of Piraeus, Greece
* Evangelos Kranakis. Carleton University, Canada
* Jean-Louis Lanet. XLIM, University of Limoges, France
* Christian Laforest. IBISC, University of Evry, France
* Deok-Gyu Lee. Information Security Technoogy Division, Electronics and
Telecommunications Research Institute, Korea
* Javier Lopez. Computer Science Department, University of Malaga, Spain
* Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
* Fabio Martinelli. Information Security Group, IIT-CNR, Italy
* Keith Mayes. ISG-SCC, Royal Holloway University of London, UK
* Jan de Meer. smartspacelab.eu, Brandenburg Technical University (BTU),
Germany
* Sjouke Mauw. SATOSS of Computer Science and Communications, University
of Luxembourg, Luxembourg
* Rolf Oppliger. eSECURITY Technologies, Switzerland
* Pierre Paradinas. INRIA/CEDRIC, CNAM, France
* Jong Hyuk Park. Department of Computer Science and Engineering,
Kyungnam University, Korea
* Erik Poll. SOS (Security of Systems) group of the Radboud University
Nijmegen, Netherlands
* Joachim Posegga. Security in Distributed Systems, University of
Hamburg, Germany
* Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
* Kai Rannenberg. Chair of Mobile Commerce and Multilateral Security,
Goethe University Frankfurt, Germany
* Konstantinos Rantos. GSPAEG at the Hellenic Ministry of Interior,
Public Administration and Decentralisation, Greece
* Pierangela Samarati. Department of Information Technologies,
University of Milan, Italy
* Damien Sauveron. XLIM, University of Limoges, France
* Willy Susilo. CCISR, University of Wollongong, Australia
* Michael Tunstall. Department of Electrical and Electronic Engineering,
University College Cork, Ireland
* Paulo Jorge Esteves Veríssimo. University of Lisboa, Portugal

##### Steering committee #####
* Angelos Bilas. FORTH-ICS & University of Crete, Greece
* Konstantinos Markantonakis. ISG-SCC, Royal Holloway University of
London, UK
* Jean-Jacques Quisquater. DICE, Catholic University of Louvain, Belgium
* Damien Sauveron. XLIM, University of Limoges, France

*******************************************************
Keynote Speakers:
- TBA

*******************************************************
Opportunities for students:
To help the students looking for a PhD thesis or a postdoctoral
position, we will propose them to add a colorized sticker on their
badge. In the same way, we will propose to persons offering these
positions to add a sticker with a different color. We hope this
mechanism will help to support the exchanges between young and senior
researchers.

*******************************************************
Thanks to our main sponsors:
Elopsys
Limousin Expansion
Nokia
SCM Microsystems
WILEY

*******************************************************
We hope you will be interested by this event.
For further inquiries, please contact the secretariat at
[email-masked]

-- 
Damien Sauveron

Date: Fri, 04 Jan 2008 17:09:49 -0500
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN bundle protocol reference implementation: requirements and goals
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Joerg Ott wrote:
> Christopher,
>
> I am not sure that there is a need for _the_ reference
> implementation (and so I am wondering why we should have a
> list of "requirements").  I do not see the implementation
> activities as a contest to be won by someone and lost by
> others.
>   

I think that if there is an implementation that is recognized by the 
community as _the_ reference implementation, it holds special status 
with the community. It is the one that people go to as a starting place 
when learning about the technology; it is used as an interoperability 
benchmark; it is a deployable implementation that can be easily and 
widely deployed. If it meets these requirements, it can accelerate 
adoption of a technology. 

Examples that come to mind are the Berkeley TCP stack and the K&R C 
compiler. Both implemented a documented standard, both were adopted by 
their communities as reference implementations, both really helped 
catalyze the adoption of the technology.

I agree that there will be multiple implementations -- that's good. But 
it's also good for a nascent technology to have a reference 
implementation to rally people, projects, and effort around.

DTN2 has done a great job of that. But it was started before we had a 
spec for the bundle protocol, and it has grown organically to meet the 
needs of its developers. This is a good time to step back and think 
consciously about the goals and requirements of an RI to best support 
the growth and adoption of DTN. As I said before, it might be that DTN2 
is the answer, or DTN2.1, or maybe it's a clean-slate DTN3.

- 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

Date: Fri, 04 Jan 2008 20:33:15 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] DTN bundle protocol reference implementation: requirements and goals
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Christopher,

I am not sure that there is a need for _the_ reference
implementation (and so I am wondering why we should have a
list of "requirements").  I do not see the implementation
activities as a contest to be won by someone and lost by
others.

If there are two or three implementations I can download and
test against, better than having just one.  Diversity of peers
usually helps implementation robustness (for people's own
implementation) and provides the -- necessary -- choice to match
different environments.

Some specific comments on your lists (since you asked :-)

In my opinion, your goal G3 may, in practice, easily be at odds
with G4 and G2.  Also, R8 does not go well together with the
experimentation idea either.  Same for G9.  Emphasizing portability
creates many abstractions that may hinder efficiency, extensibility,
or suitability as an experimentation platform.

 From your requirements list below, a reference implementation would
either be trivial and advance only slowly or would never be done.

 From my personal experience, however, what I would like to have is
indeed defined feature sets and stability.  And extensibility
with some reasonable choice of the extension mechanisms and protocols.

So, generally, I welcome some discussion on this with the purpose to
find out what to offer to the community as a platform that is usable
in research and deployable in practice.  This is key to the DTNRG
work finding broader adoption.  These "desirables" (rather than
requirements -- who would be the judge anyway?) should be a
rather short list and they may differ for those who want to use
the implementations and those who want to extend them.

This list could be some kind of guidance what to think about and a
list of priorities for documentation.  (We should not forget that,
in research, you don't get much credit for code and documentation,
so helping to focus could be useful.)

 From a community perspective, what I am missing in your list below
is a well-defined way to contribute.  This works for the reference
implementation as Mike puts effort into it, but should be generalized
as we move to multiple implementations.

My 2 cents,

Joerg

Christopher Small wrote:
> I'd like to have a discussion, starting here on the list and continuing 
> face-to-face at the upcoming IETF, on the future of the DTN bundle 
> protocol reference implementation. The goal would be to work out what 
> we, as a community, have as requirements and goals for the reference 
> implementation.
> 
> (Note that this is not meant to be a discussion of DTN2, the current 
> reference implementation, but rather what we would like to have from a 
> reference implementation. We might find that these requirements and 
> goals are realized by DTN2 today; could easily be met by extending DTN2; 
> or might motivate the development of a new reference implementation.)
> 
> My thought is that we could discuss requirements and goals here; I would 
> summarize the discussion, and organize a discussion in Philadelphia in 
> March. (And to support good turnout and lively discussion, I'll provide 
> the beer.)
> 
> As a start, here is a list of mine.
> 
> (Note that I'm speaking for myself here, not my employer. Also note that 
> some of these may be contradictory or not possible with a single 
> implementation.)
> 
> Goals:
> 
> G1. The RI should function as a benchmark standard for BPA behavior and 
> interoperability.
> G2. The RI implementation architecture should help people understand the 
> protocol (by reading the code).
> G3. The RI should be a ready-to-deploy BPA that meets at least one 
> common DTN deployment performance profile. (No implementation will be 
> appropriate for all DTN deployments, from lightly-loaded small-footprint 
> handhelds to heavily-loaded DTN routers -- but the RI should be 
> appropriate for one or more applications.)
> G4. The RI should be a good platform for doing research on DTN -- 
> supporting new routing algorithms, new convergence layers, testing 
> modifications and extensions to the protocol.
> 
> Requirements:
> 
> R1. The RI meets the BP spec
> R2. ... supports the external plugin interface
> R3. ... has a well-specified architecture
> R4. ... has a well-defined (preferably simple) data and message flow
> R5. ... has a well-defined synchronization model
> R6. ... has a clear definition of what features of the BP spec are 
> implemented and aren't.
> R7. ... implementation is simple and clear; can be used to learn how to 
> build BPAs
> R8. ... stability and simplicity as a goal over functionality and 
> overall performance
> R9. ... runs on POSIX, WinAPI, WinCE (the logical deployment platforms 
> for DTN)
> R10. ... degrades gracefully under load
> 
> What should be added? What should be removed?
> 
> - Chris
> 

To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Fri, 04 Jan 2008 12:58:54 -0500
From: Craig Partridge <[email-masked]>
Subject: Re: [dtn-interest] DTN bundle protocol reference implementation: requirements and goals
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

In message <[email-masked]>, Christopher Small writes:

>Requirements:
>
>R1. The RI meets the BP spec
>R2. ... supports the external plugin interface
>R3. ... has a well-specified architecture
>R4. ... has a well-defined (preferably simple) data and message flow
>R5. ... has a well-defined synchronization model
>R6. ... has a clear definition of what features of the BP spec are 
>implemented and aren't.
>R7. ... implementation is simple and clear; can be used to learn how to 
>build BPAs
>R8. ... stability and simplicity as a goal over functionality and 
>overall performance
>R9. ... runs on POSIX, WinAPI, WinCE (the logical deployment platforms 
>for DTN)
>R10. ... degrades gracefully under load

Hi Chris:

Just my $0.02 (or less).

There's a good chance that R7/R8 are in opposition to R10.  In my experience,
graceful degradation under load often means code that is non-obvious.  (Which
is not to say it is not understandable -- simply that you often have to go
at the problem from a perspective that requires lots of education to
understand).

Also, my version of R10 would be "runs more efficiently (per unit of
delivered work) as load increases" -- which I think is what you meant but
puts the challenge a bit more firmly.

Craig

Date: Fri, 4 Jan 2008 12:36:27 -0500
From: "Mirco Musolesi" <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [dtn-interest] CfP: ACM SIGMOBILE MobilityModels'08 at MobiHoc'08
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

All,

Please find attached the CfP of a workshop on mobility models
(MobilityModels'08) that we are organizing at MobiHoc'08.

We are interested in receiving submissions from the DTN community
about mobility models for DTN protocols and systems evaluation,
connectivity models, human mobility characterization, etc.

Mirco

---------------------------

Our apologies if you receive multiple copies of this CfP.
---------------------------------------------------------

                       MobilityModels'08

         First ACM SIGMOBILE International Workshop on
             Mobility Models for Networking Research

             Colocated with ACM SIGMOBILE MobiHoc'08

                          Hong Kong
                      26 or 30 May 2008
	
  http://www.cl.cam.ac.uk/research/srg/netos/mobilitymodels08/

*Scope of the Workshop*

One of the key issues in the evaluation of algorithms, protocols and
systems for mobile networks is modeling node mobility. Different types
of models have been proposed in the last decade, from those founded on
purely synthetic movements, such as the ones based on purely random
movements of the nodes to the ones based aiming at reproducing the
mobility patterns inside specific places like campuses or cities. In
addition, efforts to collect real traces of people movement have been
made and traces have been made available and used in simulators.
Despite these efforts, the problem of understanding and modeling
mobility, and, more specifically, human mobility remains of great
interest for the mobile ad hoc networks community, as many questions
are still unanswered and evaluation methodologies still
unsatisfactory. New insights and more refined and realistic models are
still needed, bringing together real world measurements and
mathematical characterization of node mobility. These problems are of
interest to anyone working on mobile networking, as these models are
often at the basis of the performance evaluation, comparison, and
validation of new approaches and solutions. We solicit the papers on
mobility models for various wireless networks including MANETs, DTNs
and vehicular networks.  Papers on mobility characterizations based on
real traces are also welcomed.

The goal of this workshop is to bring together researchers working or
interested in mobility modeling and characterizations. We wish to
build a lively forum to propose and discuss recent advances in
mobility modeling both from theoretical and practical point of views.
The workshop will be opened to contributions from researchers tackling
the research problems in this area from different perspectives, with
the aim of discussing the many open issues in movement modeling trying
to identify novel solutions to be investigated also by means of
collaborations among the participants of the workshop. We will welcome
especially highly innovative and/or controversial contributions,
debunking existing results or confirming existing models by means of
new experimental results. Papers providing key mathematical insights
on open mobility modeling issues will also be highly appreciated. We
invite to submit papers in the following areas:

* Design, implementation and evaluation of synthetic and trace-based
mobility models
* Validation of synthetic models using real world traces
* Mathematical characterization of human mobility
* Analysis and characterization of dynamic network topologies
* Mobility and connectivity modeling
* Influence of mobility on radio characterization
* Complex networks models for mobility modeling
* Human mobility and social networks
* Impact of mobility modeling on algorithms, protocols and systems performance
* Network measurements and mobility characterization
* Simulation tools and testbed for mobility simulation
* Systems testing based on real world mobility traces
* Mobility traces collection and data archive, including privacy issues
* Mobility characterizations of real traces

*Submission Format*

Paper submissions is limited to 8 pages (10pt ACM format). Submission
instructions will be available soon on the workshop Website
(http://www.cl.cam.ac.uk/research/srg/netos/mobilitymodels08/). The
proceedings will be published by ACM and will be available in the ACM
Digital Library.

*Important dates*

Submission deadline: 18 February 2008
Notification to the authors: 18 March 2008
Camera ready version deadline: 28 March 2008
Workshop date: 26 or 30 May 2008

*Organization*

Workshop Program Chairs

Minkyong Kim (IBM Watson, USA)
Cecilia Mascolo (University of Cambridge, UK)
Mirco Musolesi (Dartmouth College, USA)

Workshop Program Committee

Marcelo Dias de Amorim (LIP6/University Pierre et Marie Curie, France)
Elizabeth M. Belding (University of California Santa Barbara, USA)
Rainer Baumann (ETHZ, Switzerland)
Augustin Chaintreau (Thomson Research Paris, France)
Jon Crowcroft (University of Cambridge, UK)
Nathan Eagle (MIT, USA)
Mario Gerla (University of California Los Angeles, USA)
Tristan Henderson (University of St. Andrews, UK)
David Kotz (Dartmouth College, USA)
Mehul Motani (National University of Singapore, Singapore)
Brian Noble (University of Michigan, USA)
Paolo Santi (IIT CNR, Italy)
Giovanni Resta (IIT CNR, Italy)
Thrasyvoulos Spyropoulos (ETHZ, Switzerland)
Milan Vojnovic (Microsoft Research Cambridge, UK)

-- 
Mirco Musolesi
Dept. of Computer Science, Dartmouth College
6211 Sudikoff Laboratory Hanover NH 03755 USA
Web: http://www.cs.dartmouth.edu/~musolesi

Date: Fri, 04 Jan 2008 11:35:05 -0500
From: Christopher Small <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN bundle protocol reference implementation: requirements and goals
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I'd like to have a discussion, starting here on the list and continuing 
face-to-face at the upcoming IETF, on the future of the DTN bundle 
protocol reference implementation. The goal would be to work out what 
we, as a community, have as requirements and goals for the reference 
implementation.

(Note that this is not meant to be a discussion of DTN2, the current 
reference implementation, but rather what we would like to have from a 
reference implementation. We might find that these requirements and 
goals are realized by DTN2 today; could easily be met by extending DTN2; 
or might motivate the development of a new reference implementation.)

My thought is that we could discuss requirements and goals here; I would 
summarize the discussion, and organize a discussion in Philadelphia in 
March. (And to support good turnout and lively discussion, I'll provide 
the beer.)

As a start, here is a list of mine.

(Note that I'm speaking for myself here, not my employer. Also note that 
some of these may be contradictory or not possible with a single 
implementation.)

Goals:

G1. The RI should function as a benchmark standard for BPA behavior and 
interoperability.
G2. The RI implementation architecture should help people understand the 
protocol (by reading the code).
G3. The RI should be a ready-to-deploy BPA that meets at least one 
common DTN deployment performance profile. (No implementation will be 
appropriate for all DTN deployments, from lightly-loaded small-footprint 
handhelds to heavily-loaded DTN routers -- but the RI should be 
appropriate for one or more applications.)
G4. The RI should be a good platform for doing research on DTN -- 
supporting new routing algorithms, new convergence layers, testing 
modifications and extensions to the protocol.

Requirements:

R1. The RI meets the BP spec
R2. ... supports the external plugin interface
R3. ... has a well-specified architecture
R4. ... has a well-defined (preferably simple) data and message flow
R5. ... has a well-defined synchronization model
R6. ... has a clear definition of what features of the BP spec are 
implemented and aren't.
R7. ... implementation is simple and clear; can be used to learn how to 
build BPAs
R8. ... stability and simplicity as a goal over functionality and 
overall performance
R9. ... runs on POSIX, WinAPI, WinCE (the logical deployment platforms 
for DTN)
R10. ... degrades gracefully under load

What should be added? What should be removed?

- 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

Date: Wed, 02 Jan 2008 15:46:30 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Meeting at next IETF
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Folks,

I've just requested a slot for us to meet at the next
IETF meeting, March 9-14 [1].

I'll send a call for agenda items closer to the date.

There was some talk about doing another interop then.
If you'd like to take part in that please say so and
we can start to get organised.

Stephen.

[1] http://www.ietf.org/meetings/71-IETF.html