Subject: [dtn-interest] Query regarding space links
From: gtmbht <[email-masked]>
To: [email-masked]
Date: Sun, 29 May 2005 14:46:01 -0600
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Hello,

I have a query regarding deep space communication. Are the errors on space 
links bursty in nature or are they distributed? Also is there any measure on 
how long the bursts last on average?

Thank You

Gautam

To: [email-masked]
From: [email-masked]
Date: Fri, 27 May 2005 09:33:18 -0400
Subject: [dtn-interest] Re: DARPA BAA04-13: Disruption Tolerant Networking (DTN)
Sender: [email-masked]

This is a multipart message in MIME format.
--=_related 004A76528525700E_=
Content-Type: multipart/alternative; boundary="=_alternative 004A76528525700E_="

--=_alternative 004A76528525700E_=
Content-Type: text/plain; charset="US-ASCII"

Anyone know the status of the DARPA DTN BAA? The response data was 
yesterday.  Was this cancelled/delayed?

Matthew Ashoff
Systems Engineer II
727.302.2908
727.302.4220 fax
[email-masked] 

>The DARPA DTN BAA has finally come out!  Full proposals are due to DARPA
>by noon on 9-July-2004.
>
>Here is a link, for those interested:
>
>                
http://www.eps.gov/spg/ODA/DARPA/CMO/BAA04%2D13/Attachments.html
>
>- Kevin
--=_alternative 004A76528525700E_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Anyone know the status of the DARPA
DTN BAA? The response data was yesterday. &nbsp;Was this cancelled/delayed?</font>
<br>
<table width=100%>
<tr>
<td bgcolor=white>
<td width=100% bgcolor=white><img src=cid:_1_0268B2B40268AECC004A76528525700E alt=Raytheon>
<tr valign=top>
<td bgcolor=white><img src=cid:_1_0268B8740268B4B8004A76528525700E>
<td bgcolor=white><font size=2 color=#666666 face="Arial"><b>Matthew Ashoff</b></font><font size=1 color=#666666 face="Arial"><br>
Systems Engineer II<br>
727.302.2908<br>
727.302.4220 fax<u><br>
</u></font><a href=mailto:[email-masked]><font size=1 color=#666666 face="Arial"><u>[email-masked]</u></font></a><font size=1 color=#666666 face="Arial">
</font></table>
<br>
<br>
<br><font size=2 face="Arial">&gt;The DARPA DTN BAA has finally come out!
&nbsp;Full proposals are due to DARPA<br>
&gt;by noon on 9-July-2004.<br>
&gt;<br>
&gt;Here is a link, for those interested:<br>
&gt;<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
</font><a href=http://www.eps.gov/spg/ODA/DARPA/CMO/BAA04%2D13/Attachments.html><font size=2 color=blue face="Arial"><u>http://www.eps.gov/spg/ODA/DARPA/CMO/BAA04%2D13/Attachments.html</u></font></a><font size=2 face="Arial"><br>
&gt;<br>
&gt;- Kevin</font>
--=_alternative 004A76528525700E_=--
--=_related 004A76528525700E_=
Content-Type: image/gif
Content-ID: <_1_0268B2B40268AECC004A76528525700E>
Content-Transfer-Encoding: base64

--=_related 004A76528525700E_=
Content-Type: image/gif
Content-ID: <_1_0268B8740268B4B8004A76528525700E>
Content-Transfer-Encoding: base64

R0lGODlhFAAaAJECAP////8zAP///wAAACH5BAEAAAIALAAAAAAUABoAAAI3hI8oy+nHWJi01ris
pljs3X1aKF5YaUYod64BucKoXNKi/eFgG/OzXwPehDniTuXSjYxLZC9SAAA7
--=_related 004A76528525700E_=--

Date: Thu, 26 May 2005 12:02:31 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] A/V Applications and LTP w/o bundling?
Sender: [email-masked]

[email-masked] wrote:

>
> Got two questions on my mind:
>
> 1) Does DTN address audio/video transmission concerns specifically? 
>  Obviously, real-time is not feasible, but certainly streaming A/V are 
> going to be desired.  Does DTN handle issues that are specific to 
> streaming (such as a minimum bandwidth, jitter control, etc.)? For 
> these purposes, assume that we're smart enough to send the stream when 
> an end-to-end path is available (and S+F will be only be used as a 
> pseudo-buffer).
>
> 2) Is LTP designed to work without bundling? I know that it was 
> developed to "split up" the CCSDS CFDP and add enhancements, but could 
> it work without CFDP running over it? (Say I'm developing a CFDP-like 
> application and I want to run a transport protocol underneath that 
> would support it.)

LTP was designed to have the DTN Bundle protocol running over it, and 
potentially to have unacknowledged CFDP running on top of that.  But in 
fact Stephen Farrell's LTP implementation was built to run on its own 
from the start, and I know of one or two other people who are 
contemplating the use of LTP without an overlying Bundle layer.  So 
sure, you can run it stand-alone in the sort of application you're 
thinking about; there are no built-in dependencies on DTN, CFDP, or 
anything else.

Scott

To: [email-masked]
From: [email-masked]
Date: Thu, 26 May 2005 14:39:14 -0400
Subject: [dtn-interest] A/V Applications and LTP w/o bundling?
Sender: [email-masked]

This is a multipart message in MIME format.
--=_related 006678BE8525700D_=
Content-Type: multipart/alternative; boundary="=_alternative 006678C08525700D_="

--=_alternative 006678C08525700D_=
Content-Type: text/plain; charset="US-ASCII"

Got two questions on my mind:

1) Does DTN address audio/video transmission concerns specifically? 
Obviously, real-time is not feasible, but certainly streaming A/V are 
going to be desired.  Does DTN handle issues that are specific to 
streaming (such as a minimum bandwidth, jitter control, etc.)? For these 
purposes, assume that we're smart enough to send the stream when an 
end-to-end path is available (and S+F will be only be used as a 
pseudo-buffer).

2) Is LTP designed to work without bundling? I know that it was developed 
to "split up" the CCSDS CFDP and add enhancements, but could it work 
without CFDP running over it? (Say I'm developing a CFDP-like application 
and I want to run a transport protocol underneath that would support it.)

Thanks for any clarification anyone!

Matthew Ashoff
Systems Engineer II
727.302.2908
727.302.4220 fax
[email-masked] 

--=_alternative 006678C08525700D_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Got two questions on my mind:</font>
<br>
<br><font size=2 face="sans-serif">1) Does DTN address audio/video transmission
concerns specifically? &nbsp;Obviously, real-time is not feasible, but
certainly streaming A/V are going to be desired. &nbsp;Does DTN handle
issues that are specific to streaming (such as a minimum bandwidth, jitter
control, etc.)? For these purposes, assume that we're smart enough to send
the stream when an end-to-end path is available (and S+F will be only be
used as a pseudo-buffer).</font>
<br>
<br><font size=2 face="sans-serif">2) Is LTP designed to work without bundling?
I know that it was developed to &quot;split up&quot; the CCSDS CFDP and
add enhancements, but could it work without CFDP running over it? (Say
I'm developing a CFDP-like application and I want to run a transport protocol
underneath that would support it.)</font>
<br>
<br><font size=2 face="sans-serif">Thanks for any clarification anyone!<br>
</font>
<table width=100%>
<tr>
<td bgcolor=white>
<td width=100% bgcolor=white><img src=cid:_1_041D7FF8041D7C10006678BE8525700D alt=Raytheon>
<tr valign=top>
<td bgcolor=white><img src=cid:_1_041D85B8041D81FC006678BE8525700D>
<td bgcolor=white><font size=2 color=#666666 face="Arial"><b>Matthew Ashoff</b></font><font size=1 color=#666666 face="Arial"><br>
Systems Engineer II<br>
727.302.2908<br>
727.302.4220 fax<u><br>
</u></font><a href=mailto:[email-masked]><font size=1 color=#666666 face="Arial"><u>[email-masked]</u></font></a><font size=1 color=#666666 face="Arial">
</font></table>
<br>
--=_alternative 006678C08525700D_=--
--=_related 006678BE8525700D_=
Content-Type: image/gif
Content-ID: <_1_041D7FF8041D7C10006678BE8525700D>
Content-Transfer-Encoding: base64

--=_related 006678BE8525700D_=
Content-Type: image/gif
Content-ID: <_1_041D85B8041D81FC006678BE8525700D>
Content-Transfer-Encoding: base64

R0lGODlhFAAaAJECAP////8zAP///wAAACH5BAEAAAIALAAAAAAUABoAAAI3hI8oy+nHWJi01ris
pljs3X1aKF5YaUYod64BucKoXNKi/eFgG/OzXwPehDniTuXSjYxLZC9SAAA7
--=_related 006678BE8525700D_=--

Date: Thu, 26 May 2005 19:21:08 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: Chris Rigano <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] Special Session on Disruption Tolerant Networks and Applications held in conjunction with ICWN'05.
Sender: [email-masked]

Chris,

Since they did not get enough submissions, the DTN session was cancelled.

Regards,

/Anders

On Thu, 26 May 2005, Chris Rigano wrote:

>
> Greetings,
>
> When is this to be held (the DTN session) is there a web page?
>
> Thanks and regards,
>
> Chris (R)
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

From: "Chris Rigano" <[email-masked]>
To: <[email-masked]>
Date: Thu, 26 May 2005 13:12:31 -0400
Subject: [dtn-interest] Special Session on Disruption Tolerant Networks and Applications held in conjunction with ICWN'05.
Sender: [email-masked]

Greetings,

When is this to be held (the DTN session) is there a web page?

Thanks and regards,

Chris (R)

Date: Thu, 26 May 2005 08:29:04 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Error models
Sender: [email-masked]

Hi,

Can someone please direct me to some papers which have error models for 
interplanetary internet(DTNs)? Also could someone tell me what the blackout 
durations are on the IPN internet? I would really appreciate the help.

Thank You

Gautam Bhatia

Date: Mon, 23 May 2005 13:43:09 -0700
From: Michael Demmer <[email-masked]>
To: Matthew Robert Seligman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Custody Transfer description & node selection
Mail-Followup-To: Matthew Robert Seligman <[email-masked]>, [email-masked]
Sender: [email-masked]

> Is there any documentation that describes the details of custody 
> transfer and how it is implemented in DTN2?  I've been unable to find 
> much in the DTN2 tarball.

It's not (yet) implemented -- hence why you don't see anything in
there...

> Has custody node selection been addressed?  The concept of determining 
> which nodes are currently able to be custodians and the ability to 
> modify the list of currently available custodians based available 
> routes, available storage, and other parameters effecting a node's 
> ability to be a custodian.

As per above, there's no logic in there currently. My plan was to
first get the basic mechanism in place, then let people play around
with parameters for selection.

-m

Date: Mon, 23 May 2005 15:55:40 -0400 (EDT)
From: Matthew Robert Seligman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] Custody Transfer description & node selection
Sender: [email-masked]

Is there any documentation that describes the details of custody 
transfer and how it is implemented in DTN2?  I've been unable to find 
much in the DTN2 tarball.

Has custody node selection been addressed?  The concept of determining 
which nodes are currently able to be custodians and the ability to 
modify the list of currently available custodians based available 
routes, available storage, and other parameters effecting a node's 
ability to be a custodian.

Thank you, in advance, for any feedback.
- Matt

Date: Wed, 18 May 2005 07:36:16 -0400
From: Srinivasan Keshav <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] On naming and addressing
Sender: [email-masked]

Folk,
    In preparation for the DTN meeting, I read through the email exchanged
last month on naming and addressing. I thought that I would share with you
some ideas on this that I have been writing up. This is an extract from a
longer paper on this topic that I am still working on. However, I think that
the ideas may help introduce some clarity into our discussions. I'm sorry
for the last-minute introduction, but I hope that it is readable enough that
you can get the ideas without too much effort.
    Specific recommendations on DTN naming/addressing/routing are at the end
of the document

thanks

keshav
---

Introduction

The concepts of naming, address, forwarding, and routing have always been
hotly debated. The classical definition is that the address of an entity
locates it, and its name identifies it, usually in a human-understandable
fashion. Forwarding is the process by which a switch or router, on receiving
data, uses a routing table to decide where to forward the data, then
actually forwards it. Thus, forwarding is in the data plane. In contrast,
routing is the process by which routing tables are constructed, and this is
in the control plane.

On the surface, this seems perfectly clear. However, as one starts taking a
deeper look, names and addresses start to look very like each other, and it
is sometimes hard to distinguish between forwarding and routing. Here, I
present a simple framework to understand these concepts and their
relationship to each other.

The Postal Network

The usual way to explain naming and addressing is by recourse to the postal
network, where your name is your given name, your address is where you live,
and the forwarding process is what the postal service does. In the postal
system, neither routing nor routing tables are needed because the entire
process is strictly hierarchical. Thus, at every decision point, there is a
unique  choice of what to do; consequently the forwarding process needs no
help from routing. 

This is worth examining in a little more detail. Consider a letter sent from
1, Main Street, Fromtown, Fromstate to 1, Main Street, Totown, Tostate. When
the mail is picked up, it arrives at the Fromtown post office. Here, the
destination address is matched with the local town name. If the destination
town is Fromtown, then the address is 'known' and local routing is used to
deliver it. If is not known, it is forwarded on the default path to the main
post office for Fromstate. At this main post office, similarly, the only
decision is whether to send it to the Totown post office (if Totown is in
Fromstate) or to the main post office for Fromstate. In the destination
state, the path is uniquely determined by the address, and in fact, no
forwarding decisions are necessary, because each 'output link' is associated
with a unique set of destination addresses. Thus the observation that in a
strict hierarchy, no routing (in the sense of a distributed algorithm that
creates routing tables) is necessary; default routes suffice.
Even in the postal world, some things are not so straightforward. Several
people live in the same house, so the mapping from addresses to names is not
unique. Moreover, some people have more than one address (an office and a
home address), so the name to address mapping is not unique. Nevertheless,
since every address has a unique physical location, forwarding mail to that
address follows a strict hierarchy, and is, therefore, trivial. In other
words, names and addresses need not be one-one mapped for strict
hierarchical routing.

Telephone networks

The telephone network, in the earliest days, followed the postal model. A
call's destination phone number (its E.164 address) was matched with the
local 'exchange number' or 'area code' of a phone exchange to route calls in
a strict hierarchy. Indeed, in the early days, every central exchange in
every area code had a one-hop path to every other area's central exchange,
precisely so that the forwarding decision involved little electromechanical
switching logic. Note that in the early phone network, the telephone number,
or address, was a physical location corresponding to an actual phone
instrument.

With the advent of electronic switching and computer-controlled phone
switches, the forwarding logic could be made more complex with little added
expense. This led to the immensely-profitable business of toll free numbers.
A toll-free number, such as 1 800 555 1212 looks like a phone number.
However, when it is dialed, the local exchange forwards it to the '800 area'
phone exchange, which then looks up a table to determine where the call is
supposed to go to. In other words, the 800 area is really a way to request
an additional level of indirection. Indeed, the indirection table could be
changed with the time of day, day of year, or in more complex ways, for
instance, to forward calls to one of a set of destination numbers in round
robin fashion at a call center. Introducing this indirection is conceptually
problematic. The 800 number looks like a phone number, i.e. like an E.164
address. But it really isn't an address at all. In fact, it has no location
significance. In this sense, it is a name. However, paradoxically, this
number can be used for routing (up to a point) just like an address. That
is, a local exchange, on receiving a toll free number, can forward it to the
800 area exchange just like a 'regular' number. In this sense, the 800
number, or name, by masquerading as a regular E.164 address is able to
co-opt existing routing to its own ends! In other words, if we can
masquerade names as addresses, we can introduce complex forwarding decisions
in a manner compatible with legacy systems. This is a useful trick, as we
will see shortly.

The Internet 

In the early Internet, like the phone network, things were simple. Every
interface had an IP address, and the network used routing algorithms to set
up forwarding tables, which allowed a router or gateway to determine the
output interface corresponding to an IP address. IP addresses therefore were
associated with specific locations.

With Mobile IP, however, things have changed. What looks like an IP address
is in fact translated by the home address agent to another IP address, which
is (hopefully!) the actual physical address. This is essentially the same as
what is done for toll free numbers.

Location Specific and Location Independent Identifiers

This brings up a fundamental semantic issue. The 800 number (or Mobile IP
address) looks like a regular E.164 (or IP) address, but it has no location
significance, so can we call it an address at all? I argue that much
confusion arises from names masquerading as addresses. In order to clarify
the situation and distinguish them, I will call them two different things. I
will call a handle or character string that is associated with a physical
location a Location Specific Identifier or LSI. I will call a handle or
character string that is looked up in a table as a Location Independent
Identifier or LII. These are similar in intent to Universal Resource
Locators (URLs) and Universal Resoure Names (URNs). I have chosen to use
other tags because URLs today contain DNS names, which are really not
location specific. 

Using these terms, we can call a 'regular' phone number or a 'regular' IP
address as LSIs, and an 800 number or a Mobile IP address as LIIs. In the
same way, your physical postal address is an LSI, and your name is an LII.
Of course, some LSIs, such as 800 numbers, look syntactically the same as
LIIs, but we must not let that confuse us. Note additionally that, even in a
strict hierarchical network we can have both LSI and LIIs -- an LII
masquerades as an LSI and is delivered to some destination, which can simply
look up some part of the delivered data as another LSI, and send it there.
This is another way to describe what is commonly known as IP tunneling.
Because LIIs can masquerade as LSIs, they permit a form of information
hiding. One part of the network may contract with the other to agree to
deliver packets addressed by addresses that appear ostensibly as LSIs. In
fact, these addresses may actually be treated as LIIs, and may be resolved
to an LSI. For instance, one could imagine that the toll free service is
provided by a third party. This third party tells the phone company that it
has a geographical area that it covers, that happens to be assigned the area
code 800. Calls with the 800 E.164 address, should therefore be sent to this
area. From the perspective of the rest of the phone network, the 800 area
looks like a regular area, and 800 numbers look like regular numbers, i.e.
LSIs. In fact they are LIIs. Because of this information hiding, every
handoff between service providers can potentially result in an ostensible
LSI turning out to be an LII. The actual data delivery, therefore, may
require multiple translations from an LII to a series of one or more
masqueraded LIIs finally to an LSI.

LII to LSI Translation

Lets look at this process more carefully. By definition, LIIs are not
location specific, so it is not possible to deliver data addressed by an
LII. In order actually deliver data, is is necessary to translate from an
LII to a LSI. This requires a lookup in a translation table. Where is the
translation table? Its location can be specified in one of three different
ways.

1. First, the sender can explicitly specify the translation table
corresponding to the LII using  an LSI or an LII. The destination tag
therefore has two components: the LII string, and a way to get to the
translation table, which is either an LSI or an LII string. We now have a
problem of recursion. If the translation table's location  is specified by
an LII, then we need yet another translation table to get the LSI
corresponding to it. Therefore, at some point, the translation must be
accomplished using one of the two methods described next.

2. The second technique to translate an LII to an LSI is to implicitly
determine the location of the translation table. This can be done by
convention. For instance, when you type a URL in a browser, the browser
implicitly knows that this LII should be resolved to an LSI (an IP address)
using the Domain Name System. The location of the DNS table is found by
configuring its LSI on the local host: this LSI is given to the host at the
time of IP address assignment using DHCP, or hand-configured in the local
file system. Armed with this LSI, the browser can translate the LII to an
LSI (which may itself require several indirections). We now make two
observations about this process.

    (a) the resolution of the LII may result in an LII  masquerading as a
LSI, such as a mobile IP address. In this case, the translation from the
masquerading LSI to actual LSI is also done implicitly, using the
translation table located at the location indicated by the masquerading LII.
For instance, one could translate from DNS name (LII) to a mobile IP address
(LII masquerading as LSI). When the data gets to the destination specified
by the masquerading LII, it is translated to an actual LSI. This translation
may also be delegated to an in-line middlebox that promises to deliver data
to the LSI, but actually does a translation mid-stream, so to speak, and
generates another LSI. Indeed, this is the way toll free numbers work: there
is no need for the call to actually be given to an end system -- the
middlebox that intercepts the LII implicitly performs the translation.

    (b) another way to implicitly define a translation table is to use an
address schema tag. For instance, a.b.c.d is immediately recognized as a
FQDN, and sent to the DNS for resolution. In the same way, the LII
nat:10.1.1.3/1232 may correspond to a process by which the resolver can
contact the local nat middlebox to obtain an LSI corresponding to it.

3. The third and final way to translate an LII to an LSI is to use default
routing. Essentially, the resolver gives up, and simply passes on the LII to
someone else, who, presumably, is better informed. This is best understood
by a simple example. Consider a letter written by a speaker of Hindi from
the US to her hometown in India, addressed entirely in Hindi. The local post
office has no way to resolve this address, but all it needs to know is that
it is almost surely not a local address, and that it can delegate the
letter, i.e. forward it, to the city post office. this continues on up the
line until it comes to the international post office for the entire US.
Here, the letter can be dispatched in one of two ways. It can be broadcast
to all international post offices, worldwide, in an attempt to see if anyone
understands it. For instance, the post offices could be arranged in an
LSI-based ring, and the letter could be tunneled from one LSI to another in
this fashion, until it came to India. Alternatively, the post office would
have to hire one speaker of every international language, who would all be
asked to resolve any unresolved names. The letter is default routed to each
of these speakers, one by one, until someone matches it, in which case it
reaches the main post office in India, where it can make its way to its
destination unhindered.

A variant of default routing is to broadcast the LII and the appropriate
note replies with the LSI. This is how the IP to MAC resolution works in a
LAN; the MAC address is the LSI, and the IP address LII is translated to
this LSI using ARP.Note that we have an intersting situation here, in that
an IP address is an LSI that can be used for forwarding outside of its own
subnet, but within it, while still identifying a physical interface, cannot
actually be used for forwarding data! A MAC address is also an LSI, but it
cannot be used for routing (at least scalably) outside of a subnet. The
lesson is that LSIs are not always useful for forwarding.

To sum up, therefore, there are three ways to translate an LII to an LSI
 - by explicit specification of the LSI or LII of a translation table
 - by implicit invocation of a resolution process associated with that LII,
perhaps using a schema-specific resolution process, if the LII has a schema
tag 
 -using default routing of the LII-addressed data entity to someone who
knows better.

Note that schema-based names, by themselves are not sufficient for
resolution. There has to be either a binding from a schema name to a
resolution process resulting in an LSI, or the system has to be configured
to do default routing on names from that scheme to the LSI of another node
that hopefully knows better.

DTN Schemas and routing

The proposed DTN addressing scheme is schema:mark (to use Scott's
terminology). Based on the discussion above, every approved schema should
belong to one of three classes:

Class 1 schema: resolution of the schema is done using a translation table,
whose location is specified by another LII or LSI address

Class 2 schema: every DTN router knows the implicit resolution process for
that schema 

Class 3 schema: (a variant of the Class 2) : the DTN router knows only the
LSI of someone else who can perform the resolution

Recommendations

1. Some authority should define the set of schemas that fall in Class 2.
2. We should also define how to set up a config file for Class 3 schemas.
3.  We need a way to recursively resolve Class 1 schemas.

Date: Fri, 13 May 2005 11:43:41 +0200
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] testing dtn
Sender: [email-masked]

Hi, i'm an italian student and i have to perform some test with DTN for my final
discussion.
I have 7 machines running dtn daemon, and i should transfer bundles and
calculate round-trip times and (possibly) data losses.
I'd like to know if there's any software good for this benchmarks with dtn.
Thanks,
   piero

To: [email-masked]
Sensitivity: 
From: [email-masked]
Date: Thu, 12 May 2005 12:53:54 -0400
Subject: [dtn-interest] Question about CCSDS/DTN integration
Sender: [email-masked]

This is a multipart message in MIME format.
--=_related 005CD38585256FFF_=
Content-Type: multipart/alternative; boundary="=_alternative 005CD38585256FFF_="

--=_alternative 005CD38585256FFF_=
Content-Type: text/plain; charset="US-ASCII"

First time posting, so hello all!

I have read most of the papers and presentations from CCSDS and IPN/DTN. 
At first, I thought that the DTN/IPN group was somewhat competing with 
CCSDS to get their architecture into space.  However, now I realize that 
many people in the DTN group are working closely with CCSDS in their 
development of standards.

In general, DTN seems to advocate using existing CCSDS standards (e.g., 
CFDP, AOS, Proximity 1, etc.) along with a DTN structure "on top" of it. 
At the same time, you also seem to advocate keeping the space architecture 
as COTS/IP based as possible to ensure interoperability between the 
terrestrial Internet, as well as for cost reasons.  My question is: How 
exactly do you wish to accomplish this? Are you intending to get CCSDS to 
recommend a bundling intrastructure? Do you intend to get CCSDS to replace 
CFDP with LTP? Are there any plans to try and test the DTN approach by 
it's self on a long-haul link (at JPL, perhaps)?

I love all the work that is being done to try and figure out this problem, 
but I can't quite figure out exactly how it's all going to fit together. 
Maybe that's because it's still up in the air?

Any clarification anyone could provide be greatly appreciated.

Thanks! 

Matthew Ashoff
Systems Engineer II
727.302.2908
727.302.4220 fax
[email-masked] 

--=_alternative 005CD38585256FFF_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">First time posting, so hello all!</font>
<br>
<br><font size=2 face="sans-serif">I have read most of the papers and presentations
from CCSDS and IPN/DTN. &nbsp;At first, I thought that the DTN/IPN group
was somewhat competing with CCSDS to get their architecture into space.
&nbsp;However, now I realize that many people in the DTN group are working
closely with CCSDS in their development of standards.</font>
<br>
<br><font size=2 face="sans-serif">In general, DTN seems to advocate using
existing CCSDS standards (e.g., CFDP, AOS, Proximity 1, etc.) along with
a DTN structure &quot;on top&quot; of it. &nbsp;At the same time, you also
seem to advocate keeping the space architecture as COTS/IP based as possible
to ensure interoperability between the terrestrial Internet, as well as
for cost reasons. &nbsp;My question is: How exactly do you wish to accomplish
this? Are you intending to get CCSDS to recommend a bundling intrastructure?
Do you intend to get CCSDS to replace CFDP with LTP? Are there any plans
to try and test the DTN approach by it's self on a long-haul link (at JPL,
perhaps)?</font>
<br>
<br><font size=2 face="sans-serif">I love all the work that is being done
to try and figure out this problem, but I can't quite figure out exactly
how it's all going to fit together. &nbsp;Maybe that's because it's still
up in the air?</font>
<br>
<br><font size=2 face="sans-serif">Any clarification anyone could provide
be greatly appreciated.</font>
<br>
<br><font size=2 face="sans-serif">Thanks! <br>
</font>
<table width=100%>
<tr>
<td width=2% bgcolor=white>
<td width=97% bgcolor=white><img src=cid:_1_05B2B6AC05B2B484005CD38585256FFF alt=Raytheon>
<tr valign=top>
<td bgcolor=white><img src=cid:_1_05B2BBE805B2B994005CD38585256FFF>
<td bgcolor=white><font size=2 color=#666666 face="Arial"><b>Matthew Ashoff</b></font><font size=1 color=#666666 face="Arial"><br>
Systems Engineer II<br>
727.302.2908<br>
727.302.4220 fax<u><br>
</u></font><a href=mailto:[email-masked]><font size=1 color=#666666 face="Arial"><u>[email-masked]</u></font></a><font size=1 color=#666666 face="Arial">
</font></table>
<br>
--=_alternative 005CD38585256FFF_=--
--=_related 005CD38585256FFF_=
Content-Type: image/gif
Content-ID: <_1_05B2B6AC05B2B484005CD38585256FFF>
Content-Transfer-Encoding: base64

--=_related 005CD38585256FFF_=
Content-Type: image/gif
Content-ID: <_1_05B2BBE805B2B994005CD38585256FFF>
Content-Transfer-Encoding: base64

R0lGODlhFAAaAJECAP////8zAP///wAAACH5BAEAAAIALAAAAAAUABoAAAI3hI8oy+nHWJi01ris
pljs3X1aKF5YaUYod64BucKoXNKi/eFgG/OzXwPehDniTuXSjYxLZC9SAAA7
--=_related 005CD38585256FFF_=--

Date: Mon, 9 May 2005 12:01:06 -0500
From: Jeff Allen <[email-masked]>
Reply-To: [email-masked]
To: Piero Cornice <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Re: general question
Sender: [email-masked]

Also, please note that the Cygwin port has a known bug that makes it
sometimes stop listening to messages from the clients. I have not had
time to get to the bottom of it.

When you are doing your tests, be sure to use dtnping to talk to the
Cygwin version of DTN2, to verify it is still listening. When it stops
listening, sometimes after only one or two requests from local
clients, you need to restart it. Yes, this makes it completely useless
for anything but interactive experiments. It has to be fixed before
the Cygwin port is useful for anything at all.

Read this page for another fix you need in Cygwin to make DTN work
right: http://www.dtnrg.org/wiki/Dtn2KnownBugs

  -jeff

Date: Mon,  9 May 2005 12:44:09 +0200
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] general question
Sender: [email-masked]

Hi, i suggest you to read the post at
http://mailman.dtnrg.org/pipermail/dtn-interest/2005-January/001643.html
and the 2 following replies. It was very useful to me :)
Cheers,
   piero

Scrive Ryutaro Ishimoto <[email-masked]>:

> I've started playing around with DTN and have a few general questions.  I
> installed DTN2 on two nodes, Linux and Windows(Cygwin).  I followed the
> online manual to send and receive bundles within the local machine.  What
> I want to do now is to have one node send bundles to the other.  I've
> played around with different configurations but I haven't been able to
> accomplish this.  Perhaps I'm missing some important steps or
> understanding.  I thought it would work if I added a link to the other
> node in each configuration file, and add an entry to route bundles to that
> link.  If anyone could help, I'd appreciate it.  Thanks in advance.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Date: Mon, 9 May 2005 02:08:09 -0700 (PDT)
From: Ryutaro Ishimoto <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] general question
Sender: [email-masked]

I've started playing around with DTN and have a few general questions.  I
installed DTN2 on two nodes, Linux and Windows(Cygwin).  I followed the
online manual to send and receive bundles within the local machine.  What
I want to do now is to have one node send bundles to the other.  I've
played around with different configurations but I haven't been able to
accomplish this.  Perhaps I'm missing some important steps or
understanding.  I thought it would work if I added a link to the other
node in each configuration file, and add an entry to route bundles to that
link.  If anyone could help, I'd appreciate it.  Thanks in advance.