Subject: [dtn-interest] CFP: IEEE Workshop on Delay Tolerant Mobile Networks (DTMN'06)
From: "Dr. Hongyi Wu" <[email-masked]>
To: [email-masked], <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 22 Nov 2005 22:28:51 -0600 (CST)
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

========================================================================
     IEEE Workshop on Delay Tolerant Mobile Networks (DTMN'06)
            in conjunction with IEEE IWCMC 2006
                 (IEEE Sponsorship Pending)
========================================================================

Objective: Mobile communication has experienced an explosive growth during
the last few years. Various researches have been carried out for
mesh-based mobile networks, where an end-to-end path from the source to
the destination always exists. In many application scenarios, however, the
connectivity between the mobile stations is poor, and thus it is difficult
to form a well-connected mesh network for transmitting data through
end-to-end connections. In this workshop we aim to explore novel designs
for such delay tolerant mobile networks and bring together
state-of-the-art contributions in this emerging area.

Topic of Interests: Topics of interest include, but are not limited to the
following:

* New architecture of delay tolerant mobile networks
* New design of protocol stack for delay tolerant mobile networks
* Delay and fault tolerance in mobile peer-to-peer and sensor networks
* Mobility management and modeling
* Security and privacy
* Localization and synchronization
* System modeling and performance evaluation
* Testbed implementation and experimental results

Submission deadline and guideline: see details at IEEE IWCMC website
http://www.iwcmc2006.cs.wmich.edu/.

Workshop Co-Chairs:

Hongyi Wu
Center for Advanced Computer Studies
University of Louisiana at Lafayette
Email: [email-masked]

Dipak Ghosal
Department of Computer Science
University of California, Davis
E-mail: [email-masked]

Program Committee: TBD.

--Hongyi
========================================================================
Dr. Hongyi Wu,  Assistant Professor
The Center for Advanced Computer Studies (CACS)
University of Louisiana (UL) at Lafayette
P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A.
Tel: 337-482-5779, Fax: 337-482-5791
E-mail: [email-masked]
http://www.cacs.louisiana.edu/~wu
========================================================================

Date: Tue, 22 Nov 2005 06:05:56 -0500
From: "S. Keshav" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] FW: end2end-interest Digest, Vol 21, Issue 15
Sender: [email-masked]

------ Forwarded Message
> From: <[email-masked]>
> Reply-To: <[email-masked]>
> Date: Sat, 19 Nov 2005 12:00:01 -0800
> To: <[email-masked]>
> Subject: end2end-interest Digest, Vol 21, Issue 15
> 
> Message: 1
> Date: Fri, 18 Nov 2005 19:13:45 -0800
> From: John Wroclawski <[email-masked]>
> Subject: [e2e] NSF NETS Future Internet Design Informational Meeting
> To: [email-masked]
> Message-ID: <p06230913bfa448581a73@[192.168.1.101]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> (Forwarded for "NSF NETS FIND Info Meeting <[email-masked]>"
>   Please see the website or reply directly to that address for more info)
> 
> 
> Dear Colleague,
> 
> This email is to invite you to an informational meeting about the
> upcoming NSF NETS Program's Future Internet Network Design (FIND)
> research initiative. The meeting will be held Monday, December 5,
> 2005, 9:00AM - 4:30PM, at the Hilton Washington Dulles Airport.
> 
> The goals, structure, and emphasis of the FIND initiative differ
> somewhat from current NETS programs. For this reason, researchers
> interested in these topics are particularly encouraged to attend
> this informational meeting.
> 
> Further information about the informational meeting is available below
> and at the meeting website, http://find.isi.edu.
> 
> 
> The FIND Program
> 
> FIND (Future Internet Network Design) is a major new long-term
> initiative of the NSF NETS research program. FIND asks two broad
> questions:
> 
> * What are the requirements for the global network of 15 years from
> now - what should that network look like and do?
> 
> and
> 
> * How would we re-conceive tomorrow's global network today, if we
> could design it from scratch?
> 
> The FIND program will solicit "clean slate process" research
> proposals in the broad area of network architecture, principles,
> and design, aimed at answering these questions. The philosophy of
> the program is to help conceive the future by momentarily letting
> go of the present - freeing our collective minds from the
> constraints of the current.
> 
> The intellectual scope of the FIND program is wide. As examples, FIND
> research might address questions such as:
> 
> * What will the edge of the network look like in 15 years? How
>    might the network architecture of 15 years hence best
>    accommodate sensors, embedded systems, and the like?
> 
> * How might the network of 15 years from now support what users
>    really do (and care about)? How might such functions as
>    information access, location management or identity management
>    best fit into a new overall network architecture?
> 
> * What will the core of the network look like in 15 years? How
>    might the changing economics of optical systems affect the
>    overall design of the larger network?
> 
> 
> The Informational Meeting
> 
> The informational meeting will include a discussion of the scope,
> purpose, and intellectual underpinnings of the FIND program, guidance
> for potential proposers about the program's structure and review
> process, and community discussion and feedback about this exciting new
> initiative in networking research.
> 
> The meeting will take place on Monday, December 5, 2005, at the
> Hilton Washington Dulles Airport. Further details about the meeting
> and hotel are available at http://find.isi.edu. A full agenda for the
> meeting will be posted shortly.
> 
> Due to the short deadline, please register as soon as possible at
> http://find.isi.edu. There is no fee to register for the meeting.
> 
> A block of rooms at the meeting hotel has been held at a preferential rate
> for the night of Sunday, December 4th. You must reserve your room by
> *Monday, November 28* to obtain this rate. Information needed to reserve
> rooms from this block is available at the meeting website. Please make
> your hotel reservations as soon as possible to ensure that the hotel
> is able to accommodate all attendees.
> 
> Thanks for your interest in the FIND Program!
> 

------ End of Forwarded Message

Date: Mon, 21 Nov 2005 11:13:17 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] The problem of Compiling DTN2
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

First of all, this topic is better-suited for the dtn-users mailing
list, so I've cross-posted this response there.

To answer your question, the current CVS head supports gcc4, as will
an upcoming release. I'll try to package up a newer release soon, but
until then, try pulling the CVS snapshot.

-mike

> Why can't gcc(verson 4.0.3) be used to compile the DTN2?
> 
> There is an error when excecuting the bash configure.
> checking for the version of the gcc compiler... 4.0.3
> error: unsupported compiler version 4.0.3
> 
> My OS is Debian.
> 
> Help!
> 
> Thanks!
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: [email-masked]
To: [email-masked]
Date: Tue, 22 Nov 2005 02:54:36 +0800
Reply-To: [email-masked]
Subject: [dtn-interest] The problem of Compiling DTN2
Sender: [email-masked]

Why can't gcc(verson 4.0.3) be used to compile the DTN2?

There is an error when excecuting the bash configure.
checking for the version of the gcc compiler... 4.0.3
error: unsupported compiler version 4.0.3

My OS is Debian.

Help!

Thanks!

From: Navid Yazdani <[email-masked]>
To: [email-masked]
Date: Sat, 19 Nov 2005 16:03:10 -0500
Subject: [dtn-interest] Navid Yazdani is way out of the office.
Sender: [email-masked]

I will be out of the office starting  11/14/2005 and will not return until
01/23/2006.

To: [email-masked]
From: Manikantan Ramadas <[email-masked]>
Date: Fri, 18 Nov 2005 16:14:45 -0500
Subject: [dtn-interest] Soliciting feedback on the LTP drafts
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2--577537330
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi folks,

	We are planning on requesting the movement of the LTP internet- 
drafts  (the Motivation document and the Specification document  
specifically) in their path towards getting published as RFCs. We  
invite you to review them and give us your feedback. The LTP  
extensions document (primarily comprising security extensions right  
now) is in the works, and we would also welcome your feedback on it.

	You may fetch those documents here: http://irg.cs.ohiou.edu/ltp

Thanks,
Mani.
--
"The quieter you become, the more you can hear." - Baba Ram Dass.
____________________________________________________________________

* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________

--Apple-Mail-2--577537330
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-2--577537330--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] paper on authentication of fragments
Date: Thu, 10 Nov 2005 13:19:30 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Craig Partridge" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Craig,

I read your paper and it is a nice explanation of the general problem
of authenticating fragments. I had to laugh when I saw that the "toilet
paper" approach was now being cited. It figures that that phrase would
be one of the first to make it into the literature! 

Since you have obviously been thinking about this problem a lot, and it
is important to us in DTN, I thought it might be worth pointing out a
few items that make the problem a little unique when looked at within
the DTN context, so you can have our particular problems in mind as you
work on the issues of fragment authentication:

1. In DTN, we make the assumption that we won't be able to rely in
being able to distribute keys arbitrarily far and wide across the
network. So, we don't have a situation in which a source (the
originator of the data) breaks a bundle into fragments, authenticates
them, and then these authenticated fragments and their authenticator
pass from one node in the DTN to the next, unchanged, being verified as
authentic at each hop along the way. We don't rely on a node that is
several hops away from the source as having the keys needed to verify
an authenticator that the source has computed. Instead, we make the
assumption that a node will share keys with its adjacent nodes, and
authenticators are verified and then re-calculated at every hop in the
network. So, when a bundle is passed from node A to node B to node C,
for example, node A authenticates it, and sends it to B; node B
verifies the authenticator that A computed, and then computes a new
authenticator, which it transmits to C with the bundle. Node C verifies
the authenticity of the authenticator that B computed. I thought this
might be worth pointing out because:

A) With this in mind, the "Cumulative Authentication" idea that you
discuss in section 5.1 is not so unreasonable, because all fragments
(in the toilet paper approach) will necessarily follow the same path
from sender to recipient (the path over the single hop). 

B) Because we make the assumption that each node shares the keys it
needs to with its adjacent nodes, we don't constrain our cryptography
to being public key. Private key cryptography can be used too. 

2. Because each hop in the network calculates its own authenticator
before forwarding the bundle, any node is free to fragment a bundle
into any sizes it wishes, package up these fragments as bundles, and
authenticate them individually. This is what we sometimes refer to as
"proactive fragmentation", and it does not cause any problems in terms
of authentication.

3. The authentication problem that does creep in is caused by what we
call "reactive fragmentation", which may occur if a link on which a
bundle is being transferred goes down before the entire bundle has been
received. Ideally, we would like the receiving node to be able to take
the part of the bundle that was received, package it up as a bundle,
and forward it. However, a node that receives only a partial bundle has
no way of authenticating this partial bundle. The toilet paper approach
was proposed to enable a node that receives only a partial bundle to
take that portion of the bundle that was received with an authenticator
and package it up as a bundle for forwarding.  Any part of the
toilet-paper payload that was received after the "perforation" of the
authentication boundary would have to be discarded. In other words, the
toilet paper approach is, in your terminology, a way of forcing the
"authentication boundary" to be consistent with the "fragmentation
boundary". 

4. There may be some merit in computing "toilet paper" (or some
alternative that you suggest) authenticators at the source of the data
and then checking these at the final destination. This would be useful,
for example, in cases in which the whole original application data unit
did not reach the destination, but the data is such that even partial
data might be useful. By performing "toilet paper" authentication at
the source, the destination node (assuming it had the keys to do so)
could have the security of having authenticated the partially received
data end-to-end. 

5. Good luck finding a function with a small representation. I hope you
are right that they can be found and I hope you find one!  

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Craig Partridge
>Sent: Wednesday, November 09, 2005 9:18 AM
>To: [email-masked]
>Subject: [dtn-interest] paper on authentication of fragments
>
>
>Hi folks:
>
>Given the interest in fragment authentication in DTN, I though some 
>readers might find my upcoming
>HOTNETS paper on authenticating fragments of interest.
>
> From my perspective, the fun and merit of the paper is that it tries 
>to present the problem without
>any shortcuts (e.g. no fair assuming all fragments follow the same 
>path) and points out that the
>major issue in any solution without shortcuts is the amount of data 
>required to authenticate and
>protect the authentication information on a per-fragment basis. 
>(There are also subtle issues in
>sizing the fragments).  I also sketch a possible path towards less 
>space intensive solutions.
>
>The public review (HOTNETS publishes a review with each paper) 
>suggests the reviewers found
>the problem explication fun but weren't too impressed with my path to 
>a solution.
>
>The paper is short, so you can read and see what you think:
>
>              
>http://www.acm.org/sigs/sigcomm/HotNets-IV/papers/partridge.pdf
>
>Thanks!
>
>Craig
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Wed, 9 Nov 2005 09:18:07 -0500
To: [email-masked]
From: Craig Partridge <[email-masked]>
Subject: [dtn-interest] paper on authentication of fragments
Sender: [email-masked]

Hi folks:

Given the interest in fragment authentication in DTN, I though some 
readers might find my upcoming
HOTNETS paper on authenticating fragments of interest.

 From my perspective, the fun and merit of the paper is that it tries 
to present the problem without
any shortcuts (e.g. no fair assuming all fragments follow the same 
path) and points out that the
major issue in any solution without shortcuts is the amount of data 
required to authenticate and
protect the authentication information on a per-fragment basis. 
(There are also subtle issues in
sizing the fragments).  I also sketch a possible path towards less 
space intensive solutions.

The public review (HOTNETS publishes a review with each paper) 
suggests the reviewers found
the problem explication fun but weren't too impressed with my path to 
a solution.

The paper is short, so you can read and see what you think:

              http://www.acm.org/sigs/sigcomm/HotNets-IV/papers/partridge.pdf

Thanks!

Craig

Date: Tue, 8 Nov 2005 16:20:46 -0600 (CST)
From: "Dr. Hongyi Wu" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Delay/Fault-Tolerant Mobile Sensor Networks
Sender: [email-masked]

Additionally, we also have implemented our proposed approach on Crossbow
sensors. We are interested in sharing the codes as well.

Regards,
Hongyi

On Tue, 8 Nov 2005, Dr. Hongyi Wu wrote:

>
> Dear All,
>
> We would like to share with you our research on Delay/Fault-Tolerant
> Mobile Sensor Networks. This work is based on the basic concepts of DTN.
> Here is a paper to appear in IEEE Infocom'06. We appreciate if you can
> provide your valuable comments on it.
>
> Yu Wang and Hongyi Wu, "DFT-MSN: The Delay/Fault-Tolerant Mobile Sensor
> Network for Pervasive Information Gathering", to appear in IEEE
> INFOCOM'06, Barcelona, Spain, April 23-29, 2006.
>
> The paper draft is available at
> http://www.cacs.louisiana.edu/~wu/paper/DFT-MSN.pdf.
>
> In addition, can it be included in DTNRG document web so that broader
> readers can share and comment on it?
>
> Many thanks.
> --Hongyi
> ========================================================================
> Dr. Hongyi Wu,  Assistant Professor
> The Center for Advanced Computer Studies (CACS)
> University of Louisiana (UL) at Lafayette
> P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A.
> Tel: 337-482-5779, Fax: 337-482-5791
> E-mail: [email-masked]
> http://www.cacs.louisiana.edu/~wu
> ========================================================================
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 8 Nov 2005 16:06:55 -0600 (CST)
From: "Dr. Hongyi Wu" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Delay/Fault-Tolerant Mobile Sensor Networks
Sender: [email-masked]

Dear All,

We would like to share with you our research on Delay/Fault-Tolerant
Mobile Sensor Networks. This work is based on the basic concepts of DTN.
Here is a paper to appear in IEEE Infocom'06. We appreciate if you can
provide your valuable comments on it.

Yu Wang and Hongyi Wu, "DFT-MSN: The Delay/Fault-Tolerant Mobile Sensor
Network for Pervasive Information Gathering", to appear in IEEE
INFOCOM'06, Barcelona, Spain, April 23-29, 2006.

The paper draft is available at
http://www.cacs.louisiana.edu/~wu/paper/DFT-MSN.pdf.

In addition, can it be included in DTNRG document web so that broader
readers can share and comment on it?

Many thanks.
--Hongyi
========================================================================
Dr. Hongyi Wu,  Assistant Professor
The Center for Advanced Computer Studies (CACS)
University of Louisiana (UL) at Lafayette
P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A.
Tel: 337-482-5779, Fax: 337-482-5791
E-mail: [email-masked]
http://www.cacs.louisiana.edu/~wu
========================================================================

From: <[email-masked]>
To: [email-masked]
Date: Mon, 7 Nov 2005 15:31:47 -0600
Subject: [dtn-interest] Tom Vogl is out of the office.
Sender: [email-masked]

I will be out of the office starting  11/06/2005 and will not return until
11/10/2005.

Date: Mon, 07 Nov 2005 13:26:43 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] next (final?) Internet Draft of the bundle protocol spec
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060509080104080503090505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi.  Attached is the latest incarnation of the bundle protocol spec,
reflecting a number of modifications that we've agreed on over the past
few weeks.

The service specifications (both for BP and for the convergence layer)
have been removed, and significant stuff that was in those sections has
been migrated either to the Definitions (section 2.1) or to three new
paragraphs at the end of major section 4.

Every node now has to be a member of at least one "singleton" endpoint; 
"singleton" is a new term meaning an endpoint that never has more than 
one member.

Language has been inserted to make it clear that the custody transfer
operations defined in this spec apply only when the destination endpoint
is a singleton ("unicast").  One of the formerly unused bundle
processing flags now indicates whether the bundle's destination is a
singleton, so that not all nodes along the end-to-end path have to be
able to determine this by inspection of the destination endpoint ID.

Flags in the primary header and in the administrative records have been
reorganized in a more rational way.

A new section 2.2 describes four example implementation architectures,
to illustrate the range of architectures that should be able to conform
to the abstract protocol specification.

And the notion that a single node might have multiple concurrent 
registrations within the same endpoint has been expunged, since we can 
no longer think of any good reason for it.

Comments?

Scott

--------------060509080104080503090505
Content-Type: application/msword;
 name="draft-irtf-dtnrg-bundle-spec-04.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-irtf-dtnrg-bundle-spec-04.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAGAAAA8gIAAAAA
AAAAEAAA9AIAAAEAAAD+////AAAAAOwCAADtAgAA7gIAAO8CAADwAgAA8QIAAP//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------060509080104080503090505--