Subject: [dtn-interest] FW: ID Checklist Reminder
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Date: Fri, 31 Mar 2006 11:44:47 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Fyi -- K

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 30, 2006 9:00 PM
> To: Working Group Chairs
> Subject: ID Checklist Reminder
> 
> 
> Dear Working Group Chairs:
> 
> In the course of your efforts, you will likely be submitting
> Internet-Drafts to the IESG for consideration as RFCs.  Please note
> that all Internet-Drafts offered for publication as RFCs must conform
> to the requirements specified in the ID-Checklist
> (http://www.ietf.org/ID-Checklist.html), or they will be returned to
> the author(s) for revision.  Therefore, the IETF Secretariat strongly
> recommends that you address all of the issues raised in this document
> before submitting a request to publish an Internet-Draft to the IESG.
> The content issues should be addressed early on in the work since they
> are integral to the technical makeup of the Internet-Draft.
> 
> Thank you in advance for your cooperation.
> 
> The IETF Secretariat

Date: Tue, 28 Mar 2006 23:06:22 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] last week's slides etc. all now complete
Sender: [email-masked]

Thanks to everyone who presented and attended.

I even added some very modest minutes:-)

Goto [1] and scroll down to DTRNG (near the end),
Cheers,
Stephen.

[1] https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65

Date: Sun, 26 Mar 2006 18:21:32 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked], [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
Subject: [dtn-interest] DTN reference implementation version 2.2.0 release
Sender: [email-masked]

This is an announcement of the 2.2.0 release of the DTN reference
implementation. The source and documentation are available at
http://www.dtnrg.org/wiki/Code.

The major changes since the last version are:

- Various changes for conformance with version 4 of the bundle
  protocol as specified in the Bundle Protocol Internet Draft, as
  released on November 2005.

- Initial implementation of custody transfer, including
  flexible per-route timing specifications for retransmissions.

- Initial implementation of a Bluetooth convergence layer from Jeff
  Wilson <[email-masked]>.

- Added support for the ARM architecture, gcc 4.0, and BerkeleyDB 4.4.

- Added support for a file system based persistent storage
  implementation as an alternative to Berkeley DB.

- Many minor changes to improve stability and robustness of the code,
  largely due to an improved testing infrastructure including several
  tcl based system tests.

- Miscellaneous other improvements including: a persistent
  ForwardingLog for each bundle to maintain the history of where (and
  when) the bundle was sent to peers, restored support for reactive
  fragmentation, a NullConvergenceLayer and other testing hooks, and
  some scalability improvements.

In addition, this release is also available as a binary debian package
for the stable debian release (sarge) on x86, as well as in source
form through the apt package management system. Add the following
lines to /etc/apt/sources.list:

   deb     http://www.dtnrg.org/debian stable contrib
   deb-src http://www.dtnrg.org/debian stable contrib

The package is called 'dtn'.

Enjoy!

-mike

Reply-To: <[email-masked]>
From: "Eiko Yoneki" <[email-masked]>
To: <[email-masked]>
Date: Fri, 24 Mar 2006 08:58:55 -0000
Importance: Normal
Subject: [dtn-interest] [CFP RDDS 2006] Workshop on Reliability in Decentralized Distributed Systems
Sender: [email-masked]

(Apologies if you receive multiple copies of this message)  
--------------------------------------------------------------------------

International Workshop on Reliability in Decentralized Distributed Systems
(RDDS 2006) 
http://www.cs.rmit.edu.au/fedconf/index.html?page=rdds2006cfp

In conjunction with ON THE MOVE FEDERATED CONFERENCES 2006
(OTM'06-ODBASE/DOA/CoopIS/GADA) http://www.cs.rmit.edu.au/fedconf 

Montpellier, France, Oct 29 - Nov 3, 2006
Proceedings will be published by Springer Verlag

**** Submission Deadline  June 30, 2006 ****

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

WORKSHOP THEME 

Middleware has become a popular technology for building distributed systems
from tiny sensor networks to large scale peer-to-peer (P2P) networks.
Support such as asynchronous and multipoint communication is well suited for
constructing reactive distributed computing applications over wired and
wireless networks environments. While middleware infrastructures exhibit
attractive features from an application development perspective (e.g.,
portability, interoperability, adaptability etc.), they are often lacking in
robustness and reliability. Distributed systems become increasingly large
and complex, thereby compounding many reliability problems that necessitate
different strategies and solutions.

For example, in the inherently distributed nature of P2P networks, the most
common solution to reliability is to take advantage of redundancy. The same
task can be initially assigned to multiple peers. In file sharing
applications, data can be replicated across many peers. In messaging
applications, messages can be simultaneously sent along multiple paths.
Redundancy may not be appropriate, however, in resource-constrained
environments such as wireless ad hoc networks where more lightweight
alternatives are needed. Some systems even rely on autonomic management
technologies inspired by nature and biological organisms to cope with the
challenges of scale, complexity, heterogeneity and unpredictability. In any
case, the system model (e.g., communication, failures) and application
requirements are key factors in the design of reliably mechanisms.

Among different aspects of reliability issues, this workshop focuses on
reliability in decentralized distributed systems. While decentralized
architectures are gaining adoption is most application domains, there is
still some reluctance in deploying them in systems with high dependability
requirements. This has led, over the past few years, to several academic and
industrial research efforts aimed at correcting this deficiency. For the
most part, these research efforts have been independent of each other, and
have often focused on specific pieces of the dependability puzzle. Our aim,
in this Workshop, is to bring researchers and practitioners together, to
further our insights on reliable decentralized architectures and to
investigate collectively the challenges that remain.

GOAL

The purpose of the RDDS 2006 workshop on Reliability in Distributed
Decentralized Systems is to bring together researchers from diverse
communities who are interested in building dependable reliable distributed
systems in decentralized form, to explore ways of making today's middleware
technologies more robust, and to discuss and exchange experimental or
theoretical results, novel design, work-in-progress, experience, case study,
and trend-setting ideas. We seek contributions from researchers of all
backgrounds, in particular peer-to-peer systems, messaging, ad hoc
communication, middleware and distributed systems, and autonomic management
systems.

TOPICS OF INTEREST 

The Workshop solicits contributions on topics related to, but not limited
to, the following: 

-  Reliable communication, architectures and algorithms 
-  Lessons learned in building/using dependable middleware: what works, what
doesn't? 
-  Integrating dependable embedded and enterprise middleware systems 
-  Trade-offs in adding other "-ilities" (survivability, adaptability,
scalability, availability, mobility, security, real-time, etc.) to reliable
middleware infrastructures 
-  Integration of dependability into formal distributed object models 
-  Shaping/enhancing standards for reliable middleware 
-  Evaluating dependability for middleware applications 
-  Limitations of existing fault tolerance technologies in the context of
middleware applications 
-  Metrics, benchmarks and performance studies in evaluating reliability for
middleware applications 
-  Combining different dependability strategies, e.g., replication with
transactions 
-  Self-healing, self-protecting systems 
-  Autonomic system management 
-  Reliability measurement, modelling and evaluation 
-  Tools for design and evaluation of reliable systems 
-  Application-specific reliable system (e.g.embedded systems, Web,
databases) 
-  Enabling technologies for self-managing systems and networks 
-  Economic, biological and social models used for autonomic communications 
-  Timeliness and availability in support of reliability 
-  QoS for reliable systems

IMPORTANT DATES

Deadline for paper submission June 30th, 2006
Notification of acceptance August 10th, 2006
Deadline for camera-ready papers August 20th, 2006

SUBMISSION GUIDELINES

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, and clarity of expression. All
submissions must be in English. Submissions should be in PDF format and must
not exceed 10 pages in the final camera-ready format for regular papers and
4 pages for position papers. 

Authors instructions can be found at: 
http://www.springer.de/comp/lncs/authors.html 

The paper submission site is located at: 
http://www.cs.rmit.edu.au/fedconf/rdds/2006/papers 

Accepted workshop contributions will be published by Springer-Verlag as LNCS
(Lecture Notes in Computer Science) as a part of the workshop proceedings of
the 2006 International On The Move Federated Conferences (OTM). Registering
to the OTM conference and RDDS workshop is a prerequisite for the paper to
be published. 

CONTACT PEOPLE:

Eiko Yoneki
Computer Laboratory
University of Cambridge 
United Kingdom
Email: [email-masked]

Pascal Felber
Dependable and Distributed Computing Group
Université de Neuchâtel 
Institut d'informatique
Switzerland
Email: [email-masked]

PROGRAM COMMITTEE

- Licia Capra (University College London, UK) 
- Mariano Cilia (Darmstadt University of Technology, Germany) 
- Vittorio Cortellessa (Universita' de L'Aquila, Italy) 
- Simon Courtenage (University of Westminster, UK) 
- Patrick Eugster (Purdue University, USA) 
- Ludger Fiege (Siemens Research, Germany) 
- Maria Gradinariu (IRISA/INRIA-CNRS, France)
- Eli Katsiri (Imperial College London, UK) 
- Michael Kounavis (Intel Research, USA) 
- Marco Mamei (Università di Modena, Italy) 
- Jon Munson (IBM T J Watson Research Center, USA) 
- Maziar Nekovee (BT Research, UK) 
- Andrea Passarella (CNR, Italy) 
- Peter Pietzuch (Harvard University, USA) 
- Matthieu Roy (LAAS-CNRS, France)
- François Taïani (Lancaster University, UK) 
- Niki Trigoni (Birkbeck University London, UK) 
- Einar Vollset (Cornell University, USA) 

Content-class: urn:content-classes:message
Date: Wed, 22 Mar 2006 17:37:59 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTNRG meetings during IETF (reminder)
Sender: [email-masked]

Stephen already sent this out, but here is a reminder.  DTNRG is meeting
at the Embassy Suites on Thursday, and at the Sheraton (fri morning) and
then in its official slot (Hilton, fri afternoon):

http://www3.ietf.org/proceedings/06mar/agenda/DTNRG.html

- Kevin

Date: Wed, 22 Mar 2006 17:12:08 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Slides please...
Sender: [email-masked]

Folks,

If you are presenting at the DTNRG could you get me your slides
today sometime please so that we can post them on the meeting
materials site [1] and also avoid loads of laptop swapping during
the meeting. PDFs seem to be better since they're smaller btw.

I'm not sure about connectivity during the meeting, (given
that we're meeting out of the IETF hotel and during the network
teardown on Friday), so again getting all the stuff on one
laptop today would be good.

And, yes I've yet to put my own PPT up there, so I'm just as
bad as any of you:-) Except Susan and Scott who've already
sent me theirs.

Stephen.

[1] https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65

Date: Tue, 21 Mar 2006 13:57:26 -0800
To: "DTN Interest" <[email-masked]>
From: "Melissa Ho" <[email-masked]>
Subject: [dtn-interest] dtnrg.org docs updates
Sender: [email-masked]

Hi all,

The dtnrg.org docs page has been updated. I also put up a link to the ietf  
page so people can get the updated list of drafts from there.

http://www.dtnrg.org/wiki/Docs

The following Internet Drafts habe been updated:
* V. Cerf et. al., "Delay Tolerant Network Architecture",  
draft-irtf-dtnrg-arch-05.txt, September 2006
* K. Scott, S. Burleigh, "Bundle Protocol Specification",  
draft-irtf-dtnrg-bundle-spec-04.txt, May 2006
* S. Farrell, S. Symington, and H. Weiss, "Delay Tolerant Networking  
Security Overview", draft-irtf-dtnrg-sec-overview-01.txt, September 2006
* S. Symington, S. Farrell, and H. Weiss, "Bundle Security Protocol  
Specification", draft-irtf-dtnrg-bundle-security-01.txt, September 2006
* S. Symington, R. Durst, K. Scott, "Non-Custodial (Best-Effort)  
Multicasting Support in DTN",  
draft-symington-bundle-multicast-noncustodial-00.txt, August 2006
* S. Symington, R. Durst, "Bundle Protocol Extensions to Support  
Multicasting", draft-irtf-dtnrg-bundle-multicast-00.txt, October 2005  
(expired)
* S. Burleigh et al, "Licklider Transmission Protocol"
   - Motivation Document: draft-irtf-dtnrg-ltp-motivation-02.txt, September  
2006
   - Main Spec: draft-irtf-dtnrg-ltp-04.txt, September 2006
   - Extensions Document: draft-irtf-dtnrg-ltp-extensions-03.txt, September  
2006
* A. Lindgren and A. Doria, "Probabilistic Routing Protocol for  
Intermittently Connected Networks", draft-lindgren-dtnrg-prophet-02.txt,  
August 2006

I have also added the following publications to the list:

Khaled Harras and Kevin Almeroth. Inter-Regional Messenger Scheduling in
Delay Tolerant Mobile Networks. IEEE World of Wireless, Mobile and
Multimedia Networks. Niagara-Falls, Buffalo-NY, June 2006.
link: http://www.cs.ucsb.edu/~kharras/docs/scheduling.pdf

Khaled Harras and Kevin Almeroth. Transport Layer Issues in Delay
Tolerant Mobile Networks. IFIP Networking. Coimbra, Portugal, May 2006.
link: http://www.cs.ucsb.edu/~kharras/docs/transport.pdf

Eric Brewer, Michael Demmer, Bowei Du, Kevin Fall, Melissa Ho, Matthew  
Kam, Sergiu Nedevschi, Joyojeet Pal, Rabin Patra, and Sonesh Surana. The  
Case for Technology for Developing Regions. /IEEE Computer/. Volume 38,  
Number 6, pp. 25-38, June 2

Melissa

Date: Tue, 21 Mar 2006 10:08:55 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Basic doubts on DTN(IPN) working
Sender: [email-masked]

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

Mayur Maheshwari wrote:

> Hi Scott
>
>     Mayur Maheshwari wrote:
>
>>     3) What happens when a router having the persistent storage is
>>     linked with both the nodes simulaneously(the backward node "from
>>     where it is getting the message" and the forward node "to which
>>     it will send the message"). Still, there will be persistent
>>     storage in the middle node and then transmission to the forward
>>     node?
>>     I guess that in this situation the middle node should exercise a
>>     dual nature i.e. act as a normal internet router(a bridge between
>>     the two nodes) and a DTN router(save the message in it's
>>     persistent storage simultaneously). Had it been working like a
>>     DTN router solely then it would have first stored the message and
>>     then transmitted(after breaking the link with the previous
>>     backward). Again, we have to look at the energy issues and
>>     whether we are able to save time by doing such a thing.
>
>     I would say that using non-volatile storage for your forwarding
>     and retransmission buffers will probably always be slower than
>     using DRAM.  You'd do it to reduce the risk of loss, not to save time.
>
>
> The middle node will be storing the data simultaneously in it's 
> persistent storage in addition to sending it to the forward node. The 
> acknowledgement from the forward node(once the data is received, 
> verified and accepted in the custody) can be sent to the backward node 
> for the deletion from it's persistent storage, and also from the 
> storage of the middle node.
>
> In total, the middle node will be storing the data in both, it's 
> volatile(for immediate forwarding), and non-volatile storage(in case 
> there occurred any loss). But, once the forward node has taken the 
> custody of the data, even the middle node can delete it.
>
> I guess there will not be too much benefit from this scheme if there 
> are only 3 nodes linked at the same time, but if more number of nodes 
> get linked(for the possible passage of data) then the scheme could 
> just be propagated with every "encountered node" storing the data in 
> it's volatile and non-volatile storage. I guess this situation will 
> not occur very often with IPN but may be in some other case of the DTN 
> where nodes get linked ad hoc.
>
> Do you think that still we can save time by this scheme, without too 
> much overload on the node? Well, we are not losing any data, since it 
> also being stored in the persistent storage. Just that the immediate 
> forwarding is being given the preference.

I think these are useful implementation options to experiment with.  For 
what it's worth, the JPL implementation of the bundle protocol stores 
bundles in just one place, in what is nominally non-volatile storage in 
an "SDR" database; we forward and retransmit from the same buffer.  (SDR 
is an embedded object persistence system developed at JPL for spacecraft 
flight software.)  But one feature of the SDR design is that the "heap" 
segment of the database is mirrored in DRAM for rapid retrieval, so in 
reality the bundle does indeed live in both volatile and non-volatile 
space concurrently.  We get pretty good performance from this design, 
but -- even so -- not quite as good as if you never put the bundle in 
any sort of non-volatile storage at all.  It's all a matter of what you 
want to optimize.

Scott

--------------090005060906000104080503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mayur Maheshwari wrote:
<blockquote
 cite="[email-masked]"
 type="cite">Hi Scott<br>
  <br>
  <div><span class="gmail_quote"></span>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div style="direction: ltr;"><span class="q">
    <div style="direction: ltr;"><span> Mayur Maheshwari wrote:</span></div>
    </span></div>
  </blockquote>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div style="direction: ltr;"><span class="q">
    <div style="direction: ltr;"><span>
    <blockquote
 cite="http://[email-masked]"
 type="cite">3) What happens when a router having the persistent
storage is linked
with both the nodes simulaneously(the backward node "from where it is
getting the message" and the forward node "to which it will send the
message"). Still, there will be persistent storage in the middle node
and then transmission to the forward node? <br>
I
guess that in this situation the middle node should exercise a dual
nature i.e. act as a normal internet router(a bridge between the two
nodes) and a DTN router(save the message in it's persistent storage
simultaneously). Had it been working like a DTN router solely then it
would have first stored the message and then transmitted(after breaking
the link with the previous backward). Again, we have to look at the
energy issues and whether we are able to save time by doing such a
thing.</blockquote>
    </span></div>
    </span></div>
    <div style="direction: ltr;">
    <div style="direction: ltr;">I would say that using non-volatile
storage for your forwarding and
retransmission buffers will probably always be slower than using DRAM.&nbsp;
You'd do it to reduce the risk of loss, not to save time.</div>
    </div>
  </blockquote>
  <div><br>
The middle node will be storing the data simultaneously in it's
persistent storage in addition to sending it to the forward node. The
acknowledgement from the forward node(once the data is received,
verified and accepted in the custody) can be sent to the backward node
for the deletion from it's persistent storage, and also from the
storage of the middle node.<br>
  <br>
In total, the middle node will be storing the data in both, it's
volatile(for immediate forwarding), and non-volatile storage(in case
there occurred any loss). But, once the forward node has taken the
custody of the data, even the middle node can delete it.<br>
  <br>
I guess there will not be too much benefit from this scheme if there
are only 3 nodes linked at the same time, but if more number of nodes
get linked(for the possible passage of data) then the scheme could just
be propagated with every "encountered node" storing the data in it's
volatile and non-volatile storage. I guess this situation will not
occur very often with IPN but may be in some other case of the DTN
where nodes get linked ad hoc.<br>
  <br>
Do you think that still we can save time by this scheme, without too
much overload on the node? Well, we are not losing any data, since it
also being stored in the persistent storage. Just that the immediate
forwarding is being given the preference.<br>
  </div>
  </div>
</blockquote>
I think these are useful implementation options to experiment with.&nbsp;
For what it's worth, the JPL implementation of the bundle protocol
stores bundles in just one place, in what is nominally non-volatile
storage in an "SDR" database; we forward and retransmit from the same
buffer.&nbsp; (SDR is an embedded object persistence system developed at JPL
for spacecraft flight software.)&nbsp; But one feature of the SDR design is
that the "heap" segment of the database is mirrored in DRAM for rapid
retrieval, so in reality the bundle does indeed live in both volatile
and non-volatile space concurrently.&nbsp; We get pretty good performance
from this design, but -- even so -- not quite as good as if you never
put the bundle in any sort of non-volatile storage at all.&nbsp; It's all a
matter of what you want to optimize.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------090005060906000104080503--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Basic doubts on DTN(IPN) working
Date: Tue, 21 Mar 2006 12:35:01 -0500
From: "Krupiarz, Christopher" <[email-masked]>
To: "Mayur Maheshwari" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Mayur,
=20
I think the scenario you describe would be dependent upon the the
forward link bandwidth as well as the ratio between rates on the forward
and backward links.  If it's downlink rate is low, the extra overhead
and loss of speed due to storing the bundles in non-volatile memory may
not matter.  However, if you have a very high downlink rate from the
intermediate node onward, you may waste bandwidth using non-volatile
storage and may want to use volatile memory in parallel or some other
scheme to ensure full use of the downlink pipe.  I wouldn't discount the
case of only 3 nodes.  Deep space bandwidth is a valuable commodity.
=20
Chris

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mayur
Maheshwari
	Sent: Tuesday, March 21, 2006 11:56 AM
	To: [email-masked]
	Subject: Re: [dtn-interest] Basic doubts on DTN(IPN) working
=09
=09
	Hi Scott
=09
=09
=09

	=09
		Mayur Maheshwari wrote:=20

			Hi all,
		=09
			We got introduced to the DTN project by an
article in IEEE Spectrum Magazine and would like to participate in the
project. We have read the publicly available tutorials on DTN and it
appears to be an extremely interesting project to solve a rather
fundamental problem within heterogenous networks.
		=09
			About us - we are a team of undergraduate
students pursuing various degrees at Punjab Engineering College with a
shared interest in networking. We as individuals and a team have worked
on projects on manet(energy aware clustering, dynamic address management
in MANETs). Previously we have used ns2 and are comfortable with C and
Java
		=09
			We have some questions over the basic working of
the DTN(especially IPN):
		=09
			1) Can we say that the IPN nodes link in ad hoc
fashion, or they make the link as expected?=20
			Can we solve the uncertainty in time--i.e. the
time at which the nodes make a link--with the help of machine learning
technique? May be we can train the nodes on when to expect the
connection.
		=09

		In general, IPN links over long distances (e.g., between
Mars and Earth) will be quite carefully scheduled rather than ad hoc.
The actual establishment of the link is only a small part of what has to
happen: the spacecraft's high-gain antenna must be re-pointed at Earth
(which may involve moving a scan platform or changing the attitude of
the spacecraft itself), power must be applied to the radio system, other
spacecraft activities that need the power that's being  redirected to
the radio system must be discontinued, etc.  I doubt that machine
learning will be either necessary or sufficient in this process in the
foreseeable future.
	=09
		IPN links over short distances (e.g., between the
Martian surface and a Mars communications relay orbiter) are another
story: ad hoc links initiated by some sort of hailing protocol may well
make sense, because the round-trip times involved in the dialogue would
be brief enough to assure that you wouldn't reach the end of the contact
opportunity before the link negotiation was complete.  But again I doubt
that machine learning would offer much help.

	ok..
=09

	=09
	=09

			2) Do all the routers contain the persistent
storage, or it is at our discretion to install the persistent storage in
them depending upon their connectivity(like the nodes--of the same
region--which do not suffer from intermittent connectivity should not
carry this storage, as the flow across them is continuous)?
		=09

		I'd say this is a matter of risk versus benefit.  A
router that's handling a lot of continuous traffic might nominally be
connected all the time, but if you had an anomalous disconnection it
still might be nice to have everything in persistent storage so that
after recovery you could pick up where you left off.  And anomalous
events are not unknown in deep space robotic exploration.

	ok..=20

	=09
	=09

			3) What happens when a router having the
persistent storage is linked with both the nodes simulaneously(the
backward node "from where it is getting the message" and the forward
node "to which it will send the message"). Still, there will be
persistent storage in the middle node and then transmission to the
forward node?=20
			I guess that in this situation the middle node
should exercise a dual nature i.e. act as a normal internet router(a
bridge between the two nodes) and a DTN router(save the message in it's
persistent storage simultaneously). Had it been working like a DTN
router solely then it would have first stored the message and then
transmitted(after breaking the link with the previous backward). Again,
we have to look at the energy issues and whether we are able to save
time by doing such a thing.

		I would say that using non-volatile storage for your
forwarding and retransmission buffers will probably always be slower
than using DRAM.  You'd do it to reduce the risk of loss, not to save
time.

	The middle node will be storing the data simultaneously in it's
persistent storage in addition to sending it to the forward node. The
acknowledgement from the forward node(once the data is received,
verified and accepted in the custody) can be sent to the backward node
for the deletion from it's persistent storage, and also from the storage
of the middle node.
=09
	In total, the middle node will be storing the data in both, it's
volatile(for immediate forwarding), and non-volatile storage(in case
there occurred any loss). But, once the forward node has taken the
custody of the data, even the middle node can delete it.
=09
	I guess there will not be too much benefit from this scheme if
there are only 3 nodes linked at the same time, but if more number of
nodes get linked(for the possible passage of data) then the scheme could
just be propagated with every "encountered node" storing the data in
it's volatile and non-volatile storage. I guess this situation will not
occur very often with IPN but may be in some other case of the DTN where
nodes get linked ad hoc.
=09
	Do you think that still we can save time by this scheme, without
too much overload on the node? Well, we are not losing any data, since
it also being stored in the persistent storage. Just that the immediate
forwarding is being given the preference.
=09

	=09
	=09

			We are going through the documentation of the
simulator which we have configured.=20
		=09
			Given the mammoth scope of the project, we were
wondering if we could get some guidance on how to get started on the
project.=20
		=09
			Any suggestions on the current fields of
investigation, the current challenges and mini-projects that we could
take up, would be much appreciated.

		Well, there's always routing.  That certainly appears
not to be a wholly solved problem yet, at least not in dense terrestrial
environments.
	=09
	=09
		Scott
	=09

	Thanks=20
	Mayur Maheshwari([email-masked])
=09
	"Karmanye Vadhikaraste Ma Phaleshu Kadachana,
	Ma Karma Phala Hetur Bhurmatey Sangostva Akarmani"=20

------_=_NextPart_001_01C64D0D.C850AAA4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D360432017-21032006><FONT face=3DArial color=3D#0000ff =

size=3D2>Mayur,</FONT></SPAN></DIV>
<DIV><SPAN class=3D360432017-21032006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D360432017-21032006><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think the scenario you describe would be dependent upon the the forward =
link=20
bandwidth as well as the ratio between rates on the forward and backward =

links.&nbsp; If it's downlink rate is low, the extra overhead and loss =
of speed=20
due to storing the bundles in non-volatile memory may not matter.&nbsp; =
However,=20
if you have a very high downlink rate from the intermediate node onward, =
you may=20
waste bandwidth using non-volatile storage and may want to use volatile =
memory=20
in parallel or some other scheme to ensure full use of the downlink =
pipe.&nbsp;=20
I wouldn't discount the case of only 3 nodes.&nbsp; Deep space bandwidth =
is a=20
valuable commodity.</FONT></SPAN></DIV>
<DIV><SPAN class=3D360432017-21032006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D360432017-21032006><FONT face=3DArial color=3D#0000ff =

size=3D2>Chris</FONT></SPAN></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Mayur=20
  Maheshwari<BR><B>Sent:</B> Tuesday, March 21, 2006 11:56 =
AM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: [dtn-interest] =
Basic=20
  doubts on DTN(IPN) working<BR><BR></FONT></DIV>Hi Scott<BR><BR>
  <DIV><SPAN class=3Dgmail_quote></SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV style=3D"DIRECTION: ltr"><SPAN class=3Dq>
    <DIV style=3D"DIRECTION: ltr"><SPAN>Mayur Maheshwari wrote:=20
    <BLOCKQUOTE=20
    =
cite=3Dhttp://[email-masked].=
com=20
    type=3D"cite"><SPAN>Hi all,<BR><BR>We got introduced to the DTN =
project by=20
      an article in IEEE<SPAN style=3D"COLOR: rgb(255,0,0)"> <SPAN=20
      style=3D"COLOR: rgb(0,0,0)">Spectrum Magazine </SPAN></SPAN>and =
would like=20
      to participate in the project. </SPAN>We have read the publicly =
available=20
      tutorials on DTN and it appears to be an extremely interesting =
project to=20
      solve a rather fundamental problem <SPAN=20
      style=3D"COLOR: rgb(255,0,0)"></SPAN>within heterogenous=20
      networks.<BR><BR>About us - we are a team of undergraduate =
students=20
      pursuing various degrees at Punjab Engineering College with a =
shared=20
      interest in networking. We as individuals and a team have worked =
on=20
      projects on manet(energy aware clustering, dynamic address =
management in=20
      MANETs). <SPAN style=3D"COLOR: rgb(255,0,0)"></SPAN>Previously we =
have used=20
      ns2 and are comfortable with C and Java<BR><BR>We have some =
questions over=20
      the basic working of the DTN(especially IPN):<BR><BR>1) Can we say =
that=20
      the IPN nodes link in ad hoc fashion, or they make the link as =
expected?=20
      <BR>Can we solve the uncertainty in time--i.e. the time at which =
the nodes=20
      make a link--with the help of machine learning technique? May be =
we can=20
      train the nodes on when to expect the=20
    connection.<BR></BLOCKQUOTE></SPAN></DIV></SPAN></DIV>
    <DIV style=3D"DIRECTION: ltr">
    <DIV style=3D"DIRECTION: ltr">In general, IPN links over long =
distances (e.g.,=20
    between Mars and Earth) will be quite carefully scheduled rather =
than ad=20
    hoc.&nbsp; The actual establishment of the link is only a small part =
of what=20
    has to happen: the spacecraft's high-gain antenna must be re-pointed =
at=20
    Earth (which may involve moving a scan platform or changing the =
attitude of=20
    the spacecraft itself), power must be applied to the radio system, =
other=20
    spacecraft activities that need the power that's being&nbsp; =
redirected to=20
    the radio system must be discontinued, etc.&nbsp; I doubt that =
machine=20
    learning will be either necessary or sufficient in this process in =
the=20
    foreseeable future.<BR><BR>IPN links over short distances (e.g., =
between the=20
    Martian surface and a Mars communications relay orbiter) are another =
story:=20
    ad hoc links initiated by some sort of hailing protocol may well =
make sense,=20
    because the round-trip times involved in the dialogue would be brief =
enough=20
    to assure that you wouldn't reach the end of the contact opportunity =
before=20
    the link negotiation was complete.&nbsp; But again I doubt that =
machine=20
    learning would offer much help.</DIV></DIV></BLOCKQUOTE>
  <DIV><BR>ok..<BR></DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV style=3D"DIRECTION: ltr"><SPAN class=3Dq>
    <DIV style=3D"DIRECTION: ltr"><SPAN>
    <BLOCKQUOTE=20
    =
cite=3Dhttp://[email-masked].=
com=20
    type=3D"cite">2) Do all the routers contain the persistent storage, =
or it is=20
      at our discretion to install the persistent storage in them =
depending upon=20
      their connectivity(like the nodes--of the same region--which do =
not suffer=20
      from intermittent connectivity should not carry this storage, as =
the flow=20
      across them is =
continuous)?<BR></BLOCKQUOTE></SPAN></DIV></SPAN></DIV>
    <DIV style=3D"DIRECTION: ltr">
    <DIV style=3D"DIRECTION: ltr">I'd say this is a matter of risk =
versus=20
    benefit.&nbsp; A router that's handling a lot of continuous traffic =
might=20
    nominally be connected all the time, but if you had an anomalous=20
    disconnection it still might be nice to have everything in =
persistent=20
    storage so that after recovery you could pick up where you left =
off.&nbsp;=20
    And anomalous events are not unknown in deep space robotic=20
    exploration.</DIV></DIV></BLOCKQUOTE>
  <DIV><BR>ok..&nbsp;</DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV style=3D"DIRECTION: ltr"><SPAN class=3Dq>
    <DIV style=3D"DIRECTION: ltr"><SPAN>
    <BLOCKQUOTE=20
    =
cite=3Dhttp://[email-masked].=
com=20
    type=3D"cite">3) What happens when a router having the persistent =
storage is=20
      linked with both the nodes simulaneously(the backward node "from =
where it=20
      is getting the message" and the forward node "to which it will =
send the=20
      message"). Still, there will be persistent storage in the middle =
node and=20
      then transmission to the forward node? <BR>I guess that in this =
situation=20
      the middle node should exercise a dual nature i.e. act as a normal =

      internet router(a bridge between the two nodes) and a DTN =
router(save the=20
      message in it's persistent storage simultaneously). Had it been =
working=20
      like a DTN router solely then it would have first stored the =
message and=20
      then transmitted(after breaking the link with the previous =
backward).=20
      Again, we have to look at the energy issues and whether we are =
able to=20
      save time by doing such a =
thing.</BLOCKQUOTE></SPAN></DIV></SPAN></DIV>
    <DIV style=3D"DIRECTION: ltr">
    <DIV style=3D"DIRECTION: ltr">I would say that using non-volatile =
storage for=20
    your forwarding and retransmission buffers will probably always be =
slower=20
    than using DRAM.&nbsp; You'd do it to reduce the risk of loss, not =
to save=20
    time.</DIV></DIV></BLOCKQUOTE>
  <DIV><BR>The middle node will be storing the data simultaneously in =
it's=20
  persistent storage in addition to sending it to the forward node. The=20
  acknowledgement from the forward node(once the data is received, =
verified and=20
  accepted in the custody) can be sent to the backward node for the =
deletion=20
  from it's persistent storage, and also from the storage of the middle=20
  node.<BR><BR>In total, the middle node will be storing the data in =
both, it's=20
  volatile(for immediate forwarding), and non-volatile storage(in case =
there=20
  occurred any loss). But, once the forward node has taken the custody =
of the=20
  data, even the middle node can delete it.<BR><BR>I guess there will =
not be too=20
  much benefit from this scheme if there are only 3 nodes linked at the =
same=20
  time, but if more number of nodes get linked(for the possible passage =
of data)=20
  then the scheme could just be propagated with every "encountered node" =
storing=20
  the data in it's volatile and non-volatile storage. I guess this =
situation=20
  will not occur very often with IPN but may be in some other case of =
the DTN=20
  where nodes get linked ad hoc.<BR><BR>Do you think that still we can =
save time=20
  by this scheme, without too much overload on the node? Well, we are =
not losing=20
  any data, since it also being stored in the persistent storage. Just =
that the=20
  immediate forwarding is being given the preference.<BR></DIV><BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV style=3D"DIRECTION: ltr"><SPAN class=3Dq>
    <DIV style=3D"DIRECTION: ltr"><SPAN>
    <BLOCKQUOTE=20
    =
cite=3Dhttp://[email-masked].=
com=20
    type=3D"cite">We are going through the documentation of the =
simulator which=20
      we have configured. <BR><BR>Given the mammoth scope of the =
project, we=20
      were wondering if we could get some guidance on how to get started =
on the=20
      project. <BR><BR>Any suggestions on the current fields of =
investigation,=20
      the current challenges and mini-projects that we could take up, =
would be=20
      much appreciated.</BLOCKQUOTE></SPAN></DIV></SPAN></DIV>
    <DIV style=3D"DIRECTION: ltr">
    <DIV style=3D"DIRECTION: ltr">Well, there's always routing.&nbsp; =
That=20
    certainly appears not to be a wholly solved problem yet, at least =
not in=20
    dense terrestrial environments.<BR></DIV>
    <DIV=20
  style=3D"DIRECTION: =
ltr"><SPAN><BR>Scott<BR></SPAN></DIV></DIV></BLOCKQUOTE></DIV><BR>Thanks =

  <BR>Mayur Maheshwari(<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A>)<=
BR><BR>"Karmanye=20
  Vadhikaraste Ma Phaleshu Kadachana,<BR>Ma Karma Phala Hetur Bhurmatey=20
  Sangostva Akarmani" </BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C64D0D.C850AAA4--

Date: Tue, 21 Mar 2006 22:25:56 +0530
From: "Mayur Maheshwari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Basic doubts on DTN(IPN) working
Sender: [email-masked]

------=_Part_529_5852277.1142960156324
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Scott

Mayur Maheshwari wrote:
>
> Hi all,
>
> We got introduced to the DTN project by an article in IEEE Spectrum
> Magazine and would like to participate in the project. We have read the
> publicly available tutorials on DTN and it appears to be an extremely
> interesting project to solve a rather fundamental problem within
> heterogenous networks.
>
> About us - we are a team of undergraduate students pursuing various
> degrees at Punjab Engineering College with a shared interest in networkin=
g.
> We as individuals and a team have worked on projects on manet(energy awar=
e
> clustering, dynamic address management in MANETs). Previously we have use=
d
> ns2 and are comfortable with C and Java
>
> We have some questions over the basic working of the DTN(especially IPN):
>
> 1) Can we say that the IPN nodes link in ad hoc fashion, or they make the
> link as expected?
> Can we solve the uncertainty in time--i.e. the time at which the nodes
> make a link--with the help of machine learning technique? May be we can
> train the nodes on when to expect the connection.
>
> In general, IPN links over long distances (e.g., between Mars and Earth)
> will be quite carefully scheduled rather than ad hoc.  The actual
> establishment of the link is only a small part of what has to happen: the
> spacecraft's high-gain antenna must be re-pointed at Earth (which may
> involve moving a scan platform or changing the attitude of the spacecraft
> itself), power must be applied to the radio system, other spacecraft
> activities that need the power that's being  redirected to the radio syst=
em
> must be discontinued, etc.  I doubt that machine learning will be either
> necessary or sufficient in this process in the foreseeable future.
>
> IPN links over short distances (e.g., between the Martian surface and a
> Mars communications relay orbiter) are another story: ad hoc links initia=
ted
> by some sort of hailing protocol may well make sense, because the round-t=
rip
> times involved in the dialogue would be brief enough to assure that you
> wouldn't reach the end of the contact opportunity before the link
> negotiation was complete.  But again I doubt that machine learning would
> offer much help.
>

ok..

2) Do all the routers contain the persistent storage, or it is at our
> discretion to install the persistent storage in them depending upon their
> connectivity(like the nodes--of the same region--which do not suffer from
> intermittent connectivity should not carry this storage, as the flow acro=
ss
> them is continuous)?
>
> I'd say this is a matter of risk versus benefit.  A router that's handlin=
g
> a lot of continuous traffic might nominally be connected all the time, bu=
t
> if you had an anomalous disconnection it still might be nice to have
> everything in persistent storage so that after recovery you could pick up
> where you left off.  And anomalous events are not unknown in deep space
> robotic exploration.
>

ok..

3) What happens when a router having the persistent storage is linked with
> both the nodes simulaneously(the backward node "from where it is getting =
the
> message" and the forward node "to which it will send the message"). Still=
,
> there will be persistent storage in the middle node and then transmission=
 to
> the forward node?
> I guess that in this situation the middle node should exercise a dual
> nature i.e. act as a normal internet router(a bridge between the two
> nodes) and a DTN router(save the message in it's persistent storage
> simultaneously). Had it been working like a DTN router solely then it wou=
ld
> have first stored the message and then transmitted(after breaking the lin=
k
> with the previous backward). Again, we have to look at the energy issues =
and
> whether we are able to save time by doing such a thing.
>
> I would say that using non-volatile storage for your forwarding and
> retransmission buffers will probably always be slower than using DRAM.
> You'd do it to reduce the risk of loss, not to save time.
>

The middle node will be storing the data simultaneously in it's persistent
storage in addition to sending it to the forward node. The acknowledgement
from the forward node(once the data is received, verified and accepted in
the custody) can be sent to the backward node for the deletion from it's
persistent storage, and also from the storage of the middle node.

In total, the middle node will be storing the data in both, it's
volatile(for immediate forwarding), and non-volatile storage(in case there
occurred any loss). But, once the forward node has taken the custody of the
data, even the middle node can delete it.

I guess there will not be too much benefit from this scheme if there are
only 3 nodes linked at the same time, but if more number of nodes get
linked(for the possible passage of data) then the scheme could just be
propagated with every "encountered node" storing the data in it's volatile
and non-volatile storage. I guess this situation will not occur very often
with IPN but may be in some other case of the DTN where nodes get linked ad
hoc.

Do you think that still we can save time by this scheme, without too much
overload on the node? Well, we are not losing any data, since it also being
stored in the persistent storage. Just that the immediate forwarding is
being given the preference.

We are going through the documentation of the simulator which we have
> configured.
>
> Given the mammoth scope of the project, we were wondering if we could get
> some guidance on how to get started on the project.
>
> Any suggestions on the current fields of investigation, the current
> challenges and mini-projects that we could take up, would be much
> appreciated.
>
> Well, there's always routing.  That certainly appears not to be a wholly
> solved problem yet, at least not in dense terrestrial environments.
>
> Scott
>

Thanks
Mayur Maheshwari([email-masked])

"Karmanye Vadhikaraste Ma Phaleshu Kadachana,
Ma Karma Phala Hetur Bhurmatey Sangostva Akarmani"

------=_Part_529_5852277.1142960156324
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Scott<br><br><div><span class=3D"gmail_quote"></span><blockquote class=
=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin=
: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=3D"direction: ltr;"><sp=
an class=3D"q">
<div style=3D"direction: ltr;"><span>

 =20

Mayur Maheshwari wrote:
<blockquote cite=3D"http://midb78dc8040603201340x70661ff5j91889beaaabe733b@=
mail.gmail.com" type=3D"cite"><span>Hi all,<br>
  <br>
We got introduced to the DTN project by an article in IEEE<span style=3D"co=
lor: rgb(255, 0, 0);"> <span style=3D"color: rgb(0, 0, 0);">Spectrum
Magazine </span></span>and would like to participate in the project. </span=
>We
have read the publicly available tutorials on DTN and it appears to be
an extremely interesting project to solve a rather fundamental problem <spa=
n style=3D"color: rgb(255, 0, 0);"></span>within heterogenous networks.<br>
  <br>
About
us - we are a team of undergraduate students pursuing various degrees
at Punjab Engineering College with a shared interest in networking. We
as individuals and a team have worked on projects on manet(energy aware
clustering, dynamic address management in MANETs). <span style=3D"color: rg=
b(255, 0, 0);"></span>Previously we have used ns2 and
are comfortable with C and Java<br>
  <br>
We have some questions over the basic working of the DTN(especially
IPN):<br>
  <br>
1) Can we say that the IPN nodes link in ad hoc fashion, or they make
the link as expected? <br>
Can we solve
the uncertainty in time--i.e. the time at which the nodes make a
link--with the help of
machine learning technique? May be we can train the nodes on when to
expect the connection.<br>
</blockquote></span></div></span></div><div style=3D"direction: ltr;"><div =
style=3D"direction: ltr;">
In general, IPN links over long distances (e.g., between Mars and
Earth) will be quite carefully scheduled rather than ad hoc.&nbsp; The
actual establishment of the link is only a small part of what has to
happen: the spacecraft's high-gain antenna must be re-pointed at Earth
(which may involve moving a scan platform or changing the attitude of
the spacecraft itself), power must be applied to the radio system,
other spacecraft activities that need the power that's being&nbsp;
redirected to the radio system must be discontinued, etc.&nbsp; I doubt tha=
t
machine learning will be either necessary or sufficient in this process
in the foreseeable future.<br>
<br>
IPN links over short distances (e.g., between the Martian surface and a
Mars communications relay orbiter) are another story: ad hoc links
initiated by some sort of hailing protocol may well make sense, because
the round-trip times involved in the dialogue would be brief enough to
assure that you wouldn't reach the end of the contact opportunity
before the link negotiation was complete.&nbsp; But again I doubt that
machine learning would offer much help.</div></div></blockquote><div><br>
ok..<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div st=
yle=3D"direction: ltr;"><span class=3D"q"><div style=3D"direction: ltr;"><s=
pan><blockquote cite=3D"http://midb78dc8040603201340x70661ff5j91889beaaabe7=
[email-masked]" type=3D"cite">
2) Do all the routers contain the persistent storage, or
it is at our
discretion to install the persistent storage in them depending upon
their connectivity(like the nodes--of the same region--which do not
suffer from intermittent connectivity should not carry this storage, as
the flow across them is continuous)?<br>
</blockquote></span></div></span></div><div style=3D"direction: ltr;"><div =
style=3D"direction: ltr;">
I'd say this is a matter of risk versus benefit.&nbsp; A router that's
handling a lot of continuous traffic might nominally be connected all
the time, but if you had an anomalous disconnection it still might be
nice to have everything in persistent storage so that after recovery
you could pick up where you left off.&nbsp; And anomalous events are not
unknown in deep space robotic exploration.</div></div></blockquote><div><br=
>
ok..&nbsp;</div><br><blockquote class=3D"gmail_quote" style=3D"border-left:=
 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex=
;"><div style=3D"direction: ltr;"><span class=3D"q"><div style=3D"direction=
: ltr;"><span>
<blockquote cite=3D"http://midb78dc8040603201340x70661ff5j91889beaaabe733b@=
mail.gmail.com" type=3D"cite">3) What happens when a router having the pers=
istent
storage is linked
with both the nodes simulaneously(the backward node &quot;from where it is
getting the message&quot; and the forward node &quot;to which it will send =
the
message&quot;). Still, there will be persistent storage in the middle node
and then transmission to the forward node? <br>
I
guess that in this situation the middle node should exercise a dual
nature i.e. act as a normal internet router(a bridge between the two
nodes) and a DTN router(save the message in it's persistent storage
simultaneously). Had it been working like a DTN router solely then it
would have first stored the message and then transmitted(after breaking
the link with the previous backward). Again, we have to look at the
energy issues and whether we are able to save time by doing such a
thing.</blockquote></span></div></span></div><div style=3D"direction: ltr;"=
><div style=3D"direction: ltr;">
I would say that using non-volatile storage for your forwarding and
retransmission buffers will probably always be slower than using DRAM.&nbsp=
;
You'd do it to reduce the risk of loss, not to save time.</div></div></bloc=
kquote><div><br>
The middle node will be storing the data simultaneously in it's
persistent storage in addition to sending it to the forward node. The
acknowledgement from the forward node(once the data is received,
verified and accepted in the custody) can be sent to the backward node
for the deletion from it's persistent storage, and also from the
storage of the middle node.<br>
<br>
In total, the middle node will be storing the data in both, it's
volatile(for immediate forwarding), and non-volatile storage(in case
there occurred any loss). But, once the forward node has taken the
custody of the data, even the middle node can delete it.<br>
<br>
I guess there will not be too much benefit from this scheme if there
are only 3 nodes linked at the same time, but if more number of nodes
get linked(for the possible passage of data) then the scheme could just
be propagated with every &quot;encountered node&quot; storing the data in i=
t's
volatile and non-volatile storage. I guess this situation will not
occur very often with IPN but may be in some other case of the DTN
where nodes get linked ad hoc.<br>
<br>
Do you think that still we can save time by this scheme, without too
much overload on the node? Well, we are not losing any data, since it
also being stored in the persistent storage. Just that the immediate
forwarding is being given the preference.<br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
 rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div st=
yle=3D"direction: ltr;"><span class=3D"q"><div style=3D"direction: ltr;"><s=
pan><blockquote cite=3D"http://midb78dc8040603201340x70661ff5j91889beaaabe7=
[email-masked]" type=3D"cite">
We are going through the documentation of the simulator
which we have configured. <br>
  <br>
Given the mammoth scope of the project, we were wondering if we could
get some guidance on how to get started on the project. <br>
  <br>
Any
suggestions on the current fields of investigation, the current
challenges and mini-projects that we could take up, would be much
appreciated.</blockquote></span></div></span></div><div style=3D"direction:=
 ltr;"><div style=3D"direction: ltr;">
Well, there's always routing.&nbsp; That certainly appears not to be a
wholly solved problem yet, at least not in dense terrestrial
environments.<br></div><div style=3D"direction: ltr;"><span>
<br>
Scott<br>

</span></div>

</div></blockquote></div><br>Thanks <br>Mayur Maheshwari(<a href=3D"mailto:=
[email-masked]">[email-masked]</a>)<br><br>&quot;Karm=
anye Vadhikaraste Ma Phaleshu Kadachana,<br>Ma Karma Phala Hetur Bhurmatey =
Sangostva Akarmani&quot;

------=_Part_529_5852277.1142960156324--

Date: Mon, 20 Mar 2006 15:11:23 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Basic doubts on DTN(IPN) working
Sender: [email-masked]

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

Mayur Maheshwari wrote:

> Hi all,
>
> We got introduced to the DTN project by an article in IEEE Spectrum 
> Magazine and would like to participate in the project. We have read 
> the publicly available tutorials on DTN and it appears to be an 
> extremely interesting project to solve a rather fundamental problem 
> within heterogenous networks.
>
> About us - we are a team of undergraduate students pursuing various 
> degrees at Punjab Engineering College with a shared interest in 
> networking. We as individuals and a team have worked on projects on 
> manet(energy aware clustering, dynamic address management in MANETs). 
> Previously we have used ns2 and are comfortable with C and Java
>
> We have some questions over the basic working of the DTN(especially IPN):
>
> 1) Can we say that the IPN nodes link in ad hoc fashion, or they make 
> the link as expected?
> Can we solve the uncertainty in time--i.e. the time at which the nodes 
> make a link--with the help of machine learning technique? May be we 
> can train the nodes on when to expect the connection.

In general, IPN links over long distances (e.g., between Mars and Earth) 
will be quite carefully scheduled rather than ad hoc.  The actual 
establishment of the link is only a small part of what has to happen: 
the spacecraft's high-gain antenna must be re-pointed at Earth (which 
may involve moving a scan platform or changing the attitude of the 
spacecraft itself), power must be applied to the radio system, other 
spacecraft activities that need the power that's being  redirected to 
the radio system must be discontinued, etc.  I doubt that machine 
learning will be either necessary or sufficient in this process in the 
foreseeable future.

IPN links over short distances (e.g., between the Martian surface and a 
Mars communications relay orbiter) are another story: ad hoc links 
initiated by some sort of hailing protocol may well make sense, because 
the round-trip times involved in the dialogue would be brief enough to 
assure that you wouldn't reach the end of the contact opportunity before 
the link negotiation was complete.  But again I doubt that machine 
learning would offer much help.

> 2) Do all the routers contain the persistent storage, or it is at our 
> discretion to install the persistent storage in them depending upon 
> their connectivity(like the nodes--of the same region--which do not 
> suffer from intermittent connectivity should not carry this storage, 
> as the flow across them is continuous)?

I'd say this is a matter of risk versus benefit.  A router that's 
handling a lot of continuous traffic might nominally be connected all 
the time, but if you had an anomalous disconnection it still might be 
nice to have everything in persistent storage so that after recovery you 
could pick up where you left off.  And anomalous events are not unknown 
in deep space robotic exploration.

> 3) What happens when a router having the persistent storage is linked 
> with both the nodes simulaneously(the backward node "from where it is 
> getting the message" and the forward node "to which it will send the 
> message"). Still, there will be persistent storage in the middle node 
> and then transmission to the forward node?
> I guess that in this situation the middle node should exercise a dual 
> nature i.e. act as a normal internet router(a bridge between the two 
> nodes) and a DTN router(save the message in it's persistent storage 
> simultaneously). Had it been working like a DTN router solely then it 
> would have first stored the message and then transmitted(after 
> breaking the link with the previous backward). Again, we have to look 
> at the energy issues and whether we are able to save time by doing 
> such a thing.

I would say that using non-volatile storage for your forwarding and 
retransmission buffers will probably always be slower than using DRAM.  
You'd do it to reduce the risk of loss, not to save time.

> We are going through the documentation of the simulator which we have 
> configured.
>
> Given the mammoth scope of the project, we were wondering if we could 
> get some guidance on how to get started on the project.
>
> Any suggestions on the current fields of investigation, the current 
> challenges and mini-projects that we could take up, would be much 
> appreciated.

Well, there's always routing.  That certainly appears not to be a wholly 
solved problem yet, at least not in dense terrestrial environments.

Scott

--------------070803050304020305060804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mayur Maheshwari wrote:
<blockquote
 cite="[email-masked]"
 type="cite"><span>Hi all,<br>
  <br>
We got introduced to the DTN project by an article in IEEE<span
 style="color: rgb(255, 0, 0);"> <span style="color: rgb(0, 0, 0);">Spectrum
Magazine </span></span>and would like to participate in the project. </span>We
have read the publicly available tutorials on DTN and it appears to be
an extremely interesting project to solve a rather fundamental problem <span
 style="color: rgb(255, 0, 0);"></span>within heterogenous networks.<br>
  <br>
About
us - we are a team of undergraduate students pursuing various degrees
at Punjab Engineering College with a shared interest in networking. We
as individuals and a team have worked on projects on manet(energy aware
clustering, dynamic address management in MANETs). <span
 style="color: rgb(255, 0, 0);"></span>Previously we have used ns2 and
are comfortable with C and Java<br>
  <br>
We have some questions over the basic working of the DTN(especially
IPN):<br>
  <br>
1) Can we say that the IPN nodes link in ad hoc fashion, or they make
the link as expected? <br>
Can we solve
the uncertainty in time--i.e. the time at which the nodes make a
link--with the help of
machine learning technique? May be we can train the nodes on when to
expect the connection.<br>
</blockquote>
In general, IPN links over long distances (e.g., between Mars and
Earth) will be quite carefully scheduled rather than ad hoc.&nbsp; The
actual establishment of the link is only a small part of what has to
happen: the spacecraft's high-gain antenna must be re-pointed at Earth
(which may involve moving a scan platform or changing the attitude of
the spacecraft itself), power must be applied to the radio system,
other spacecraft activities that need the power that's being&nbsp;
redirected to the radio system must be discontinued, etc.&nbsp; I doubt that
machine learning will be either necessary or sufficient in this process
in the foreseeable future.<br>
<br>
IPN links over short distances (e.g., between the Martian surface and a
Mars communications relay orbiter) are another story: ad hoc links
initiated by some sort of hailing protocol may well make sense, because
the round-trip times involved in the dialogue would be brief enough to
assure that you wouldn't reach the end of the contact opportunity
before the link negotiation was complete.&nbsp; But again I doubt that
machine learning would offer much help.<br>
<blockquote
 cite="[email-masked]"
 type="cite">2) Do all the routers contain the persistent storage, or
it is at our
discretion to install the persistent storage in them depending upon
their connectivity(like the nodes--of the same region--which do not
suffer from intermittent connectivity should not carry this storage, as
the flow across them is continuous)?<br>
</blockquote>
I'd say this is a matter of risk versus benefit.&nbsp; A router that's
handling a lot of continuous traffic might nominally be connected all
the time, but if you had an anomalous disconnection it still might be
nice to have everything in persistent storage so that after recovery
you could pick up where you left off.&nbsp; And anomalous events are not
unknown in deep space robotic exploration.<br>
<blockquote
 cite="[email-masked]"
 type="cite">3) What happens when a router having the persistent
storage is linked
with both the nodes simulaneously(the backward node "from where it is
getting the message" and the forward node "to which it will send the
message"). Still, there will be persistent storage in the middle node
and then transmission to the forward node? <br>
I
guess that in this situation the middle node should exercise a dual
nature i.e. act as a normal internet router(a bridge between the two
nodes) and a DTN router(save the message in it's persistent storage
simultaneously). Had it been working like a DTN router solely then it
would have first stored the message and then transmitted(after breaking
the link with the previous backward). Again, we have to look at the
energy issues and whether we are able to save time by doing such a
thing.</blockquote>
I would say that using non-volatile storage for your forwarding and
retransmission buffers will probably always be slower than using DRAM.&nbsp;
You'd do it to reduce the risk of loss, not to save time.<br>
<blockquote
 cite="[email-masked]"
 type="cite">We are going through the documentation of the simulator
which we have configured. <br>
  <br>
Given the mammoth scope of the project, we were wondering if we could
get some guidance on how to get started on the project. <br>
  <br>
Any
suggestions on the current fields of investigation, the current
challenges and mini-projects that we could take up, would be much
appreciated.</blockquote>
Well, there's always routing.&nbsp; That certainly appears not to be a
wholly solved problem yet, at least not in dense terrestrial
environments.<br>
<br>
Scott<br>
</body>
</html>

--------------070803050304020305060804--

Date: Tue, 21 Mar 2006 03:10:26 +0530
From: "Mayur Maheshwari" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Basic doubts on DTN(IPN) working
Sender: [email-masked]

------=_Part_5753_17732062.1142890826736
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,

We got introduced to the DTN project by an article in IEEE Spectrum Magazin=
e
and would like to participate in the project. We have read the publicly
available tutorials on DTN and it appears to be an extremely interesting
project to solve a rather fundamental problem within heterogenous networks.

About us - we are a team of undergraduate students pursuing various degrees
at Punjab Engineering College with a shared interest in networking. We as
individuals and a team have worked on projects on manet(energy aware
clustering, dynamic address management in MANETs). Previously we have used
ns2 and are comfortable with C and Java

We have some questions over the basic working of the DTN(especially IPN):

1) Can we say that the IPN nodes link in ad hoc fashion, or they make the
link as expected?
Can we solve the uncertainty in time--i.e. the time at which the nodes make
a link--with the help of machine learning technique? May be we can train th=
e
nodes on when to expect the connection.

2) Do all the routers contain the persistent storage, or it is at our
discretion to install the persistent storage in them depending upon their
connectivity(like the nodes--of the same region--which do not suffer from
intermittent connectivity should not carry this storage, as the flow across
them is continuous)?

3) What happens when a router having the persistent storage is linked with
both the nodes simulaneously(the backward node "from where it is getting th=
e
message" and the forward node "to which it will send the message"). Still,
there will be persistent storage in the middle node and then transmission t=
o
the forward node?
I guess that in this situation the middle node should exercise a dual natur=
e
i.e. act as a normal internet router(a bridge between the two nodes) and a
DTN router(save the message in it's persistent storage simultaneously). Had
it been working like a DTN router solely then it would have first stored th=
e
message and then transmitted(after breaking the link with the previous
backward). Again, we have to look at the energy issues and whether we are
able to save time by doing such a thing.

We are going through the documentation of the simulator which we have
configured.

Given the mammoth scope of the project, we were wondering if we could get
some guidance on how to get started on the project.

Any suggestions on the current fields of investigation, the current
challenges and mini-projects that we could take up, would be much
appreciated.

Thanks in advance,

Mayur Maheshari
Shagandeep Kaur
Robin Dhawan

--
Mayur Maheshwari([email-masked])

------=_Part_5753_17732062.1142890826736
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<span>Hi all,<br><br>We got introduced to the DTN project by an article in =
IEEE<span style=3D"color: rgb(255, 0, 0);"> <span style=3D"color: rgb(0, 0,=
 0);">Spectrum Magazine </span></span>and would like to participate in the =
project.=20
</span>We
have read the publicly available tutorials on DTN and it appears to be
an extremely interesting project to solve a rather fundamental problem <spa=
n style=3D"color: rgb(255, 0, 0);"></span>within heterogenous networks.<br>
<br>
About
us - we are a team of undergraduate students pursuing various degrees
at Punjab Engineering College with a shared interest in networking. We
as individuals and a team have worked on projects on manet(energy aware clu=
stering, dynamic address management in MANETs).=20
<span style=3D"color: rgb(255, 0, 0);"></span>Previously we have used ns2 a=
nd are comfortable with C and Java<br>
<br>
We have some questions over the basic working of the DTN(especially IPN):<b=
r>
<br>1) Can we say that the IPN nodes link in ad hoc fashion, or they make
the link as expected? <br>
Can we solve
the uncertainty in time--i.e. the time at which the nodes make a link--with=
 the help of
machine learning technique? May be we can train the nodes on when to
expect the connection.<br>
<br>
2) Do all the routers contain the persistent storage, or it is at our
discretion to install the persistent storage in them depending upon
their connectivity(like the nodes--of the same region--which do not
suffer from intermittent connectivity should not carry this storage, as
the flow across them is continuous)?<br>
<br>
3) What happens when a router having the persistent storage is linked
with both the nodes simulaneously(the backward node &quot;from where it is
getting the message&quot; and the forward node &quot;to which it will send =
the
message&quot;). Still, there will be persistent storage in the middle node
and then transmission to the forward node? <br>I
guess that in this situation the middle node should exercise a dual
nature i.e. act as a normal internet router(a bridge between the two
nodes) and a DTN router(save the message in it's persistent storage
simultaneously). Had it been working like a DTN router solely then it
would have first stored the message and then transmitted(after breaking
the link with the previous backward). Again, we have to look at the
energy issues and whether we are able to save time by doing such a
thing. <br>
&nbsp;<br>We are going through the documentation of the simulator which we =
have configured.=20
<br>
<br>
Given the mammoth scope of the project, we were wondering if we could get s=
ome guidance on how to get started on the project. <br>
<br>
Any
suggestions on the current fields of investigation, the current
challenges and mini-projects that we could take up, would be much
appreciated.
<br>
<br>
Thanks in advance,<br>
<br>
<div>Mayur Maheshari<br>Shagandeep Kaur<br>Robin Dhawan</div>
<br clear=3D"all"><br>-- <br>Mayur Maheshwari(<a href=3D"mailto:mayur.mahes=
[email-masked]" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(wind=
ow,event,this)">[email-masked]</a>)<br>

------=_Part_5753_17732062.1142890826736--

Date: Sat, 18 Mar 2006 14:48:55 -0500
From: "Jessy Cowan-Sharp" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [dtn-interest] hi
Sender: [email-masked]

------=_Part_2491_30386489.1142711335294
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

also, the US Defense Advanced Research Projects Agency (DARPA) is working o=
n
a program called XNAV which is exploring the feasability of using Xray
pulsars as the timing and positioning mechanism for interplanetary and
orbital communications. the project is focused more on technology
demonstration rather than on the protocols side. i believe that johns
hopkins university's applied physics lab was recently awarded a contract to
implement some of this.

here are a couple of links which may provide some more details:

XNAV program:
http://www.darpa.mil/dso/thrust/matdev/xnav.htm

Johns Hopkins Applied Physics Laboratory * to Apply Space Research
Expertise to Develop Deep Space Navigation Network*:
http://www.jhuapl.edu/newscenter/pressreleases/2005/051024.asp

jessy

On 3/17/06, Adrian J. Hooke <[email-masked]> wrote:
>
> At 11:17 AM 3/17/2006, Rishab Mahajan wrote:
>
>  We are currently pursuing civil engineering from Punjab Engineering
> College. We have worked on space colonies with a scientist affiated  with
> nasa. We  are mainly into space structural dynamics and *orbital mechanic=
s
> *.We found this poject to be mainly concerned with computer science. Is
> there anything we can contribute to the project.
>
>
> Rishab, Nitin, Ankur: you might want to take a look at Dave Mills' work
> on  "Timekeeping in the Interplanetary Internet"
> http://www.cis.udel.edu/~mills/ipin.html<http://www.cis.udel.edu/%7Emills=
/ipin.html>to see if you have any interest in the orbital mechanics problem=
s of
> synchronizing clocks across interplanetary distances?
>
> Best regards
> Adrian Hooke
>
>

--
Jessy Cowan-Sharp
Graduate Student,
University of Maryland
202-360-3967

------=_Part_2491_30386489.1142711335294
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

also, the US Defense Advanced Research Projects Agency (DARPA) is
working on a program called XNAV which is exploring the feasability of
using Xray pulsars as the timing and positioning mechanism for
interplanetary and orbital communications. the project is focused more
on technology demonstration rather than on the protocols side. i
believe that johns hopkins university's applied physics lab was
recently awarded a contract to implement some of this. <br><br>here are a c=
ouple of links which may provide some more details:<br><br>XNAV program: <b=
r><a href=3D"http://www.darpa.mil/dso/thrust/matdev/xnav.htm" target=3D"_bl=
ank" onclick=3D"return top.js.OpenExtLink(window,event,this)">
http://www.darpa.mil/dso/thrust/matdev/xnav.htm</a><br><br><span>
Johns Hopkins Applied Physics Laboratory=20
          <strong style=3D"font-weight: normal;"> to Apply Space Research <=
br>
          Expertise to Develop Deep Space Navigation
          Networ<span style=3D"font-weight: bold;"></span>k</strong></span>=
:<br><a href=3D"http://www.jhuapl.edu/newscenter/pressreleases/2005/051024.=
asp" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,event,th=
is)">
http://www.jhuapl.edu/newscenter/pressreleases/2005/051024.asp</a><br>
<br><div><span class=3D"gmail_quote">jessy</span></div><br><br><div><span c=
lass=3D"gmail_quote">On 3/17/06, <b class=3D"gmail_sendername">Adrian J. Ho=
oke</b> &lt;<a href=3D"mailto:[email-masked]">adrian.j.hooke@j=
pl.nasa.gov
</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;"><div style=3D"direction: ltr;"><span class=3D"q">

<font color=3D"#0000ff">At 11:17 AM 3/17/2006, Rishab Mahajan wrote:<br>
<blockquote type=3D"cite" cite=3D"http://">&nbsp;We are currently pursuing
civil engineering from Punjab Engineering College. We have worked on
space colonies with a scientist affiated&nbsp; with nasa. We&nbsp; are
mainly into space structural dynamics and <b>orbital mechanics</b>.We
found this poject to be mainly concerned with computer science. Is there
anything we can contribute to the project.</blockquote></font><br></span></=
div><div style=3D"direction: ltr;">
Rishab, Nitin, Ankur: you might want to take a look at Dave Mills' work
on&nbsp; &quot;Timekeeping in the Interplanetary Internet&quot;
<a href=3D"http://www.cis.udel.edu/%7Emills/ipin.html" target=3D"_blank" on=
click=3D"return top.js.OpenExtLink(window,event,this)">
http://www.cis.udel.edu/~mills/ipin.html</a> to see if you have any
interest in the orbital mechanics problems of synchronizing clocks across
interplanetary distances?<br><br>
Best regards<br></div><div style=3D"direction: ltr;"><span class=3D"sg">
Adrian Hooke<br>

<br>

</span></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Jessy Cowa=
n-Sharp<br>Graduate Student, <br>University of Maryland<br>202-360-3967

------=_Part_2491_30386489.1142711335294--

Date: Sat, 18 Mar 2006 00:02:06 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] IETF-65 meeting - DTNRG agenda
Sender: [email-masked]

And now I've made it official, so its at:

http://www3.ietf.org/proceedings/06mar/agenda/DTNRG.html

Forget everything you've ever seen before about this:-)

S.

Date: Fri, 17 Mar 2006 12:06:04 -0800
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] hi
Sender: [email-masked]

--=====================_199103535==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:17 AM 3/17/2006, Rishab Mahajan wrote:
>  We are currently pursuing civil engineering from Punjab Engineering 
> College. We have worked on space colonies with a scientist affiated  with 
> nasa. We  are mainly into space structural dynamics and orbital 
> mechanics.We found this poject to be mainly concerned with computer 
> science. Is there anything we can contribute to the project.

Rishab, Nitin, Ankur: you might want to take a look at Dave Mills' work 
on  "Timekeeping in the Interplanetary Internet" 
http://www.cis.udel.edu/~mills/ipin.html to see if you have any interest in 
the orbital mechanics problems of synchronizing clocks across 
interplanetary distances?

Best regards
Adrian Hooke

--=====================_199103535==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font color="#0000FF">At 11:17 AM 3/17/2006, Rishab Mahajan wrote:<br>
<blockquote type=cite class=cite cite="">&nbsp;We are currently pursuing
civil engineering from Punjab Engineering College. We have worked on
space colonies with a scientist affiated&nbsp; with nasa. We&nbsp; are
mainly into space structural dynamics and <b>orbital mechanics</b>.We
found this poject to be mainly concerned with computer science. Is there
anything we can contribute to the project.</font></blockquote><br>
Rishab, Nitin, Ankur: you might want to take a look at Dave Mills' work
on&nbsp; &quot;Timekeeping in the Interplanetary Internet&quot;
<a href="http://www.cis.udel.edu/~mills/ipin.html" eudora="autourl">
http://www.cis.udel.edu/~mills/ipin.html</a> to see if you have any
interest in the orbital mechanics problems of synchronizing clocks across
interplanetary distances?<br><br>
Best regards<br>
Adrian Hooke<br>
</body>
<br>
</html>

--=====================_199103535==.ALT--

Date: Fri, 17 Mar 2006 12:00:49 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] hi
Sender: [email-masked]

Rishab Mahajan wrote:

> hi all
>  We are currently pursuing civil engineering from Punjab Engineering 
> College. We have worked on space colonies with a scientist affiated  
> with nasa. We  are mainly into space structural dynamics and orbital 
> mechanics.We found this poject to be mainly concerned with computer 
> science. Is there anything we can contribute to the project.

I'd like to say there is, but until we're a little closer to getting DTN 
on a spacecraft I unfortunately don't know what it would be.  For now, 
all the DTN work is protocol definition, simulation, implementation, 
testing in simulated environments, and application to terrestrial 
networking problems -- all of which, as you say, is mainly software 
work.  Anybody else have a perspective I'm missing?

Scott

Date: Sat, 18 Mar 2006 00:47:10 +0530
From: "Rishab Mahajan" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] hi
Sender: [email-masked]

------=_Part_5688_13081282.1142623030480
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi all
 We are currently pursuing civil engineering from Punjab Engineering
College. We have worked on space colonies with a scientist affiated  with
nasa. We  are mainly into space structural dynamics and orbital
mechanics.Wefound this poject to be mainly concerned with computer
science. Is there
anything we can contribute to the project.

Regards
Rishab Mahajan
Nitin Arora
Ankur Bajoria

------=_Part_5688_13081282.1142623030480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

hi all<br>
&nbsp;We are currently pursuing civil engineering from Punjab
Engineering College. We have worked on space colonies with a scientist
affiated&nbsp; with nasa. We&nbsp; are mainly into space structural
dynamics and orbital mechanics.We found this poject to be mainly
concerned with computer science. Is there anything we can contribute to
the project.<br>
<br>
Regards<br>
Rishab Mahajan <br>
Nitin Arora<br>
Ankur Bajoria<br>

------=_Part_5688_13081282.1142623030480--

Date: Fri, 17 Mar 2006 16:50:11 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] IETF-65 meeting - DTNRG agenda
Sender: [email-masked]

Stephen Farrell wrote:

> I'll find a URL to post this at where we can put
> slides etc and send that to the list in a bit.

I've put the version of the agenda I'll maintain
at [1].

If you've a speaking slot, can you send me your
slides sometime before Wednesday evening so that
I can post them there. Its fine to send a draft
version that you update later on.

Cheers,
S.

[1] http://down.dsg.cs.tcd.ie/misc/dtnrg/dallas-agenda.html

Date: Fri, 17 Mar 2006 15:48:06 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IETF-65 meeting - DTNRG agenda
Sender: [email-masked]

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

Folks,

Please find a draft agenda attached for next week.

Let me know if there are any changes needed.

I'll find a URL to post this at where we can put
slides etc and send that to the list in a bit.

Regards,
Stephen.

--------------080608030403020504000900
Content-Type: text/plain;
 name="dallas-agenda-04.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="dallas-agenda-04.txt"

IRTF DTNRG Draft agenda for IETF-65 meeting

DTNRG site: http://www.dtnrg.org/

Chairs:
	Kevin Fall ([email-masked])
	Stephen Farrell ([email-masked])

Thursday Morning
Embassy Suites  08:00-11:30					
			5	Jim Snyder	Welcome		
			20	Stephen Farrell - TCD	Bundle Security update/issues		
			20	Walter Scheirer  - LeHigh	DTN2 security		
			20	?? - GaTech/Umass	DieselNet/routing		
			15	break			
			20	Mostafa Ammar - GaTech	Throwboxes and routing		
			20	JJ (Garcia-Lunes-Aceves) - UCSC 	content-based networking		
			20	Mirco Musolesi - UCL	Content based routing		
			15	break			
			20	Bob Durst - Mitre	DTN for CONDOR		
			25	Kevin Fall - Intel	DTNRG Status/Open Mike/Discuss		

Friday morning
Sheraton        09:00-11:00			
			5	Kevin Fall - Intel	Agenda bashing
			25	Bob Durst - Mitre	Interface Architecture
			25	Darcy Kroeker - Waterloo	Tetherless Comp. Arch.
			25	Rajesh Krishnan - BBN	BBN work on DARPA DTN
			25	?? - GaTech/Umass	Java DTN implementation
			10	Joerg Ott - HUT	TCP conv. Layer issues

Friday afternoon
Hilton Anatole  12:30-14:00			
			15	Kevin Fall - Intel	General DTNRG update
			15	Scott Burleigh - JPL	"DTN for space, JPL impl."
			15	"Joe Rice, NRL"	Seaweb update
			15	Susan Symington - Mitre	Multicast
			10	Anders Lindgren - Luth	Prophet update
			20	Kevin Fall - Intel	Open Mike

Logistics:

Thanks are due to the DARPA DTN folks for arranging the meeting rooms for
Thursday and Friday morning. 

Thursday morning:

	Note: there is limited space (~30 seats) in the Thursday session so please
	contact one of the chairs if you plan to attend so we can manage that 
	space.

	Embassy Suites Dallas Market Center, Salon B
	2727 Stemmons Fwy, Dallas
	(214) 630-5332

Friday morning:

	Sheraton Suites Market Center Dallas, Red Oak/Live Oak Room
	2101 Stemmons Fwy, Dallas
	(214) 747-3000

Friday afternoon:

	Hilton Anatole (IETF meeting hotel)
	Metropolitan Ballroom

--------------080608030403020504000900--

Date: Thu, 16 Mar 2006 08:22:26 +0100 (MET)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Posting of draft-lindgren-dtnrg-prophet-02.txt  (fwd)
Sender: [email-masked]

All,

A new version of our draft "Probabilistic Routing Protocol for
Intermittently Connected Networks" is available from
http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-02.txt

There's been some changes to details in the protocol operation (mainly
based on implementation experience), and parts of the draft have been
rewritten and restructured to be easier to read and use as reference for
an implementor.
I'll give a short presentation about the updated draft in Dallas, and I'll
go through the most important changes there.

As always, comments are welcome,

/Anders

---------- Forwarded message ----------
Date: Mon, 06 Mar 2006 15:50:02 -0500
From: IETF Secretariat <[email-masked]>
To: [email-masked]
Cc: Avri Doria <[email-masked]>
Subject: Posting of draft-lindgren-dtnrg-prophet-02.txt

As you requested, draft-lindgren-dtnrg-prophet-02.txt, an updated version of an
expired Internet-Drafts, has been posted.  The draft will expire on September 7,
2006 unless it is replaced by an updated version, or it is under official review
by the IESG (i.e., a request has been submitted to publish it as an RFC).

The IETF Secretariat.

Content-class: urn:content-classes:message
Date: Mon, 13 Mar 2006 09:44:15 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] snapshot of our current I-D's
Sender: [email-masked]

Here's a list of active DTN I-D's, based on searching for the keyword
"dtn" with the ID tracker.  Susan't isn't here because I don't think
"dtn" is in the title.

- K

    draft-irtf-dtnrg-arch (None)  05 Not Assigned Yet   
    draft-irtf-dtnrg-bundle-security (None) 01 Not Assigned Yet   
    draft-irtf-dtnrg-bundle-spec (None) 04 Not Assigned Yet   
    draft-irtf-dtnrg-ltp (None) 04 Not Assigned Yet   
    draft-irtf-dtnrg-ltp-extensions (None) 03 Not Assigned Yet   
    draft-irtf-dtnrg-ltp-motivation (None) 02 Not Assigned Yet   
    draft-irtf-dtnrg-sec-overview (None) 01 Not Assigned Yet   
    draft-lindgren-dtnrg-prophet (None) 02 Not Assigned Yet

Content-class: urn:content-classes:message
Date: Mon, 6 Mar 2006 10:14:54 -0500
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: [dtn-interest] Two DTN security drafts updated
Sender: [email-masked]

This is a multi-part message in MIME format.

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

FYI:
=20
Updates of the two DTN security drafts have been posted and are
available from the on-line Internet-Drafts directories.
=20
DTN Security Overview
This document provides an overview of the security requirements and
mechanisms considered for delay tolerant networking security. It
discusses the options for protecting such networks and describes
reasons why specific security mechanisms were (or were not) chosen for
the relevant protocols. The entire document is informative, given it's
purpose is mainly to document design decisions.=20
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sec-overview-01.tx
t
=20
Bundle Security Protocol
This document defines the bundle security protocol, which provides data
integrity and confidentiality services. We also describe various bundle
security considerations including policy options.=20
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-security-01
.txt
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_001_01C64130.BA5156C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D278460615-06032006><FONT face=3DArial=20
size=3D2>FYI:</FONT></SPAN></DIV>
<DIV><SPAN class=3D278460615-06032006></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D278460615-06032006><FONT face=3DArial =
size=3D2>Updates of the two=20
DTN security drafts have been posted and are available from the <FONT=20
size=3D2>on-line Internet-Drafts directories.</FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D278460615-06032006><FONT face=3DArial size=3D2>DTN =
Security=20
Overview</FONT></SPAN></DIV>
<DIV>This document provides an overview of the security requirements and =

mechanisms considered for delay tolerant networking security. It =
discusses the=20
options for protecting such networks and describes reasons why specific =
security=20
mechanisms were (or were not) chosen for the relevant protocols. The =
entire=20
document is informative, given it's purpose is mainly to document design =

decisions. </DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sec-overview=
-01.txt">http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sec-overvie=
w-01.txt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D278460615-06032006><FONT face=3DArial size=3D2>Bundle =
Security=20
Protocol</FONT></SPAN></DIV>
<DIV>This document defines the bundle security protocol, which provides =
data=20
integrity and confidentiality services. We also describe various bundle =
security=20
considerations including policy options. </DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-secur=
ity-01.txt">http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-s=
ecurity-01.txt</A></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C64130.BA5156C0--

Date: Sat, 4 Mar 2006 16:09:38 -0800
From: Michael Demmer <[email-masked]>
To: Magnus Kindgren <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] File convergence layer
Mail-Followup-To: Magnus Kindgren <[email-masked]>, dtn-interest <[email-masked]>
Sender: [email-masked]

Hi,

Unfortunately, there is no functional file-based convergence layer in
the current reference implementation, though it's been something
that's been on my to-do list for a long time now. 

If you're interested in working on an implementation of one, e-mail me
off this list and we can talk about the details of the implementation
and how you could get started on this.

-mike

> Hi,
> 
> I would like to get some guidelines on how to implement/configure DTN2 
> using the file convergence layer. I've searched the archive, but failed 
> to find any information.
> 
> Regards,
> Magnus Kindgren
> 
> Master student, KTH, Sweden
> S?mi Network Connectivity
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Sun, 05 Mar 2006 00:45:17 +0100
From: Magnus Kindgren <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] File convergence layer
Sender: [email-masked]

Hi,

I would like to get some guidelines on how to implement/configure DTN2 
using the file convergence layer. I've searched the archive, but failed 
to find any information.

Regards,
Magnus Kindgren

Master student, KTH, Sweden
Sámi Network Connectivity

Date: Sat, 04 Mar 2006 11:18:29 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] New ltp drafts posted...
Sender: [email-masked]

No real differences, they'd just expired. Still would like to
get more review since they seem done otherwise!

S.

http://tools.ietf.org/id/draft-irtf-dtnrg-ltp-04.txt
http://tools.ietf.org/id/draft-irtf-dtnrg-ltp-extensions-03.txt
http://tools.ietf.org/id/draft-irtf-dtnrg-ltp-motivation-02.txt

Content-class: urn:content-classes:message
Date: Fri, 3 Mar 2006 22:43:21 -0500
From: "Durst, Robert C." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: I-D ACTION:draft-symington-bundle-multicast-noncustodial-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.

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

FYI.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Monday, February 27, 2006 6:50 PM
To: [email-masked]
Subject: I-D
ACTION:draft-symington-bundle-multicast-noncustodial-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Non-Custodial (Best-Effort) Multicasting=20
                          Support in DTN
	Author(s)	: S. Symington, et al.
	Filename	:
draft-symington-bundle-multicast-noncustodial-00.txt
	Pages		: 30
	Date		: 2006-2-27
=09
   This document defines the requirements and constraints that must be
   imposed when using the Bundle Protocol [2] in order to support the
   best-effort multicast delivery of bundles within a Delay-Tolerant
   Network (DTN).  The capabilities described herein enable a source
   node to transmit a bundle to multiple destination nodes without
   having to originate a separate bundle for each destination node.
   These capabilities do not support custody transfer of bundles that
   are being delivered via multicast.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-symington-bundle-multicast-no
ncustodial-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-symington-bundle-multicast-noncustodial-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-symington-bundle-multicast-noncustodial-00.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation
on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C63F3D.C905FB8F
Content-Type: application/octet-stream;
	name="ATT2673075.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT2673075.TXT
Content-Disposition: attachment;
	filename="ATT2673075.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl
cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNi0yLTI3MTUwMTAwLkktREBpZXRmLm9yZz4NCg0KRU5D
T0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXN5bWluZ3Rvbi1idW5kbGUt
bXVsdGljYXN0LW5vbmN1c3RvZGlhbC0wMC50eHQNCg==

------_=_NextPart_001_01C63F3D.C905FB8F
Content-Type: application/octet-stream;
	name="draft-symington-bundle-multicast-noncustodial-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-symington-bundle-multicast-noncustodial-00.txt
Content-Disposition: attachment;
	filename="draft-symington-bundle-multicast-noncustodial-00.txt"

RklMRSBERUxFVEVEDQotLS0tLS0tLS0tLS0NCg0KQW50aWdlbiBmb3IgRXhjaGFuZ2UgcmVtb3Zl
ZCBkcmFmdC1zeW1pbmd0b24tYnVuZGxlLW11bHRpY2FzdC1ub25jdXN0b2RpYWwtMDAuVVJMIHNp
bmNlIGl0DQp3YXMgZm91bmQgdG8gbWF0Y2ggdGhlIEZJTEUgRklMVEVSPSAqLnVybCBmaWxlIGZp
bHRlci4NCg==

------_=_NextPart_001_01C63F3D.C905FB8F
Content-Type: text/plain;
	name="ATT2673076.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT2673076.txt
Content-Disposition: attachment;
	filename="ATT2673076.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C63F3D.C905FB8F--

Content-class: urn:content-classes:message
Date: Fri, 3 Mar 2006 11:54:57 -0800
From: "Fall, Kevin" <[email-masked]>
To: "Aaron Falk" <[email-masked]>
Cc: <[email-masked]>, "Stephen Farrell" <[email-masked]>
Subject: [dtn-interest] please add co-chair for DTNRG
Sender: [email-masked]

Please add Stephen Farrell as a co-chair for DTNRG.  I nominated him
earlier, and received support and no objections from the rest of the RG.

Thanks,
- Kevin

Content-class: urn:content-classes:message
Date: Fri, 3 Mar 2006 11:50:35 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] call for talks at IETF
Sender: [email-masked]

Hello all.

DTNRG will be meeting in the afternoon on Friday, March 24 at IETF.

I would like to solicit talk from those of you who would like to present
them, and would like to especially encourage those of you who are doing
DTN- related work that we have not heard a talk from before.

Please let me know within a week (or before!).

Thanks,
- Kevin

From: "Lavy Libman" <[email-masked]>
To: <[email-masked]>
Date: Fri, 3 Mar 2006 16:40:35 +1100
Organization: NICTA
Subject: [dtn-interest] CFP - Workshop on Networking in Public Transport
Sender: [email-masked]

Dear colleagues,

Please find below the call for papers for the
Workshop on Networking in Public Transport (WNEPT).
Hope this will be of interest to members of this list -
in any case, DTN is one of the topics of interest of the workshop.
We apologize in advance for any cross-postings and duplicates.

=========================================
CALL FOR PAPERS
Workshop on Networking in Public Transport (WNEPT 2006)
    in conjunction with QShine 2006
    Waterloo, Ontario, Canada
    August 10, 2006
    http://www.wnept.org

Public transport (PT) systems, including buses, taxis, trains, ships
and airplanes, are used daily by millions of people worldwide, ranging
from regular commuters in metropolitan areas to long-distance business
and leisure travellers. The ability to communicate and access
information during travel is becoming increasingly crucial to maintain
productivity or provide entertainment for PT passengers. However,
despite phenomenal advances in mobile wireless networking technologies
in recent years, commercial deployments of special networking
solutions to support PT passengers remain scarce (except in
airplanes). For the most part, mobile end users can only communicate
by connecting directly to their individual wireless service providers.
This prevailing situation offers a very limited and often inadequate
support for the wide range of applications and needs of PT passengers,
such as broadcast of multimedia entertainment and travel-related
updates, and interactive multiplayer games. Additionally, networking
support to PT vehicles is necessary to enable other PT-specific
applications that do not directly involve the passengers, such as
real-time surveillance, remote telemetry, and management of
PT-specific road infrastructure (e.g. traffic lights on priority bus
lanes and rail crossings). All of these require the deployment of
integrated on-board network solutions to connect between passengers,
content/application servers and other vehicle-mounted devices,
neighboring vehicles, roadside infrastructure, and the Internet.
Moreover, some inherent features of PT, such as the repetitiveness and
predictability of routes and timetables, can be used to design
specialized network protocols to further improve the quality of
service perceived by PT passengers. 

Authors are invited to submit original full papers on any aspect of
public transport networking. Contributions describing theoretical
research, protocol design, experiments and measurements, commercial
deployments, business models, or position/vision statements are all
encouraged. Descriptions of work in progress, test trials, and future
work plans are highly appreciated.  Topics of interest include, but
are not limited to: 
* Broadband access to trains and airplanes 
* Mobile routers and network mobility 
* Intra-vehicle networks 
* IP and IPv6 mobility support for public transport 
* Multiple access networks in public transport 
* Authorization and authentication in public transport 
* Inter-vehicular communications, VANETs 
* Intermittent-connectivity and delay-tolerant networks 
* Protocol design for predictable mobility 
* Signalling between public transport and roadside infrastructure 
* Content distribution and on-board caching 
* Location privacy for public transport passengers 
* Novel public transport applications and services 
* Billing and charging for public transport networking 
* Experimental results and practical deployments 

Important dates:
Paper Submission Deadline: May 15, 2006
Notification: June 16, 2006
Final Version Due: June 30, 2006

For further information and submission instructions, visit
http://www.wnept.org .

Content-class: urn:content-classes:message
Date: Thu, 2 Mar 2006 09:02:26 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: 65th IETF Agenda
Sender: [email-masked]

Note new agenda has been posted with the dtnrg Friday session starting
after lunch.

- K

> -----Original Message-----
> From: IETF Agenda [mailto:[email-masked]]
> Sent: Thursday, March 02, 2006 6:47 AM
> To: Working Group Chairs
> Subject: 65th IETF Agenda
> 
> The latest agenda has been posted to:
> http://www.ietf.org/meetings/agenda_65.txt
> 
> While most of the requests to resolve conflicts were addressed, not
all of
> them
> were possible.
> 
> The agenda will be go print on Friday, March 3.
> 

Date: Thu, 2 Mar 2006 15:13:45 +0100
From: "Gerardo Izquierdo" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Routing
Sender: [email-masked]

------=_Part_6541_7042461.1141308825742
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all

This is a newbie question, but I havent been able to found any previous
discussion on this topic

As far as I understand, the DTN concept is a "Networks of Internetworks"
some of them being similar to the normal internet, some others not,
(Zebra-Net, Networks of Ad-Hoc Devices, etc.)

It is supposed that in the future we will have some kind of routing at the
DTN level, using bundles as the minor unit.

But, I think, not all nodes in an internet will need to know how to route
bundles outside is own internet, that is, a node in an internet does not
need dinamically how to route a bundle, but instead, there will be
"Gateways".

So I think, my question is:

How a bundle aware node in our actual internet will select a bundle-router
for the destination internet?

Let's suppose I have bundle-aware software in my computer, and it generates
a bundle for InB:dest-node-in-InB how my computer knows what other computer
in internel (say IPv4) needs to send this bundle in order to reach a node i=
n
the internet InB?

See that this is a side question about the routing, that is, I'm not askink=
g
how that supposed border node will know what to do in order to progress the
bundle.

Could it be possible an extension to DNS, by example a DTNX record with
information in the nodes acting as gateways?

similarly to MX records it could be

mars.sol.int. IN DTNX 100 gateway-mars-1.sample.dtn.org.

telling us that in order to reach a node in mars.sol.int. I should forward
my bundle to the system gateway-mars-1.sample.dtn.org in my network.

Gerardo

------=_Part_6541_7042461.1141308825742
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<p>Hi all</p>
<p>This is a newbie question, but I havent been able to found any previous =
discussion on this topic</p>
<p>As far as I understand, the DTN concept is a &quot;Networks of Internetw=
orks&quot; some of them being similar to the normal internet, some others n=
ot, (Zebra-Net, Networks of Ad-Hoc Devices, etc.)</p>
<p>It is supposed that in the future we will have some kind of routing at t=
he DTN level, using bundles as the minor unit.</p>
<p>But, I think, not all nodes in an internet will need to know how to rout=
e bundles outside is own internet, that is, a node in an internet does not =
need dinamically how to route a bundle, but instead, there will be &quot;Ga=
teways&quot;.
</p>
<p>So I think, my question is:</p>
<p>How a bundle aware node in our actual internet will select a bundle-rout=
er for the destination internet?</p>
<p>Let's suppose I have bundle-aware software in my computer, and it genera=
tes a bundle for InB:dest-node-in-InB how my computer knows what other comp=
uter in internel (say IPv4) needs to send this bundle in order to reach a n=
ode in the internet InB?
</p>
<p>See that this is a side question about the routing, that is, I'm not ask=
inkg how that supposed border node will know what to do in order to progres=
s the bundle.</p>
<p>Could it be possible an extension to DNS, by example a DTNX record with =
information in the nodes acting as gateways?</p>
<p>similarly to MX records it could be </p>
<p><a href=3D"http://mars.sol.int">mars.sol.int</a>.&nbsp;IN&nbsp;DTNX&nbsp=
;100&nbsp;<a href=3D"http://gateway-mars-1.sample.dtn.org">gateway-mars-1.s=
ample.dtn.org</a>.</p>
<p>telling us that in order to reach a node in <a href=3D"http://mars.sol.i=
nt">mars.sol.int</a>. I should forward my bundle to the system <a href=3D"h=
ttp://gateway-mars-1.sample.dtn.org">gateway-mars-1.sample.dtn.org</a> in m=
y network.
</p>
<p>Gerardo</p>

------=_Part_6541_7042461.1141308825742--

Cc: [email-masked]
From: Manikantan Ramadas <[email-masked]>
Subject: Re: [dtn-interest] Routing
Date: Wed, 1 Mar 2006 17:41:53 -0500
To: Purvesh Thakker <[email-masked]>
Sender: [email-masked]

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

Purvesh,

    Finally clearing up my mailbox and caught up with this mail that  
I thought would answer if no one else from the DTNRG answered.
>
> How is routing in these delay-tolerant deep space networks currently
> handled?
>
    I think the best answer to this is that it isn't. Most space- 
missions are still operating in a single path topology; there aren't  
any real DTN routers flying around in our Solar System yet. I think  
that the most interesting contemporary topology is the
Earth- Planetary orbiter - Planetary rover
one, with the orbiter serving as a relay shuttling packets. Since the  
current-day orbiter doesn't really route data belonging to another  
mission for example, the interesting-ness comes only in relaying data  
to and from the rover whenever a line-of-sight link becomes  
available. Of course, this is just my understanding of the current  
state of affairs.

- Mani.
--
"Always being cheerful and being happy takes you closer to God than
any prayer."    - Anonymous

____________________________________________________________________

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

--Apple-Mail-7--263043184
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-7--263043184--

Content-class: urn:content-classes:message
Date: Wed, 1 Mar 2006 10:14:28 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] co-chair for DTNRG
Sender: [email-masked]

Greetings all.

As some of you may know by now, at the next IETF meeting I will be
starting as an IAB member.  This has already begun to fill my inbox more
rapidly than just about anything else I've managed to sign up for
recently...

Anyhow, given that new task in combination with the increasing number of
drafts flowing through DTNRG, I have decided it would be good to get
some help.

Stephen Farrell, who I believe many of you know, has helped out in the
past at various IETF meetings, and has been active in the DTN work for
some time now (a quick bio, written by him, is below).  He also has
significant IETF process experience.

So, I would like to nominate him as a co-chair for the group.  I will
continue to be active, but we would share some of the workload.

I will assume that either lack of response or any form of "yes" is an
indicator of support.  If anyone has a substantive objection, please let
me know.

Thanks,
- Kevin

SF's micro-bio:

Stephen Farrell [1], is co-author of a bunch of security related RFCs
[2], has co-chaired the formally successful, worthy, but IPR-unfortunate
IETF SACRED WG [3], and is currently co-chair of the more interesting,
and more controversial DKIM WG [4]. He was also recently co-chair of the
W3C XKMS working group [5].  He more-or-less works in Trinity College
Dublin [6] doing a bit of teaching and supervising in security,
continually putting off a PhD of sorts on DTN things, and running a DTN
related research project that constantly founders on hardware issues
(today:  smart battery not liking solar panels) but that'll ultimately
bite him back since the software (Farrell's supposed contribution) is
always the last thing on the to-do list. Farrell is also co-author of a
few DTN I-Ds.

[1] https://www.cs.tcd.ie/Stephen.Farrell/me/public-resume.html 
[2] 4210, 3767, 3281, 3185, 3157, 2906, 2905, 2904, 2510
[3] http://www.ietf.org/html.charters/OLD/sacred-charter.html 
[4] http://www.ietf.org/html.charters/dkim-charter.html 
[5] http://www.w3.org/2001/XKMS/
[6] http://www.tcd.ie/