Subject: [dtn-interest] FW: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
From: "Henderson, Thomas R" <[email-masked]>
To: <[email-masked]>
Date: Tue, 31 Oct 2006 02:48:43 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

FYI, I provided the below comments in the review process of this
document.

Tom

-----Original Message-----
From: Henderson, Thomas R 
Sent: Monday, October 30, 2006 1:20 PM
To: 'Aaron Falk'; Internet Steering Group
Subject: RE: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct

Aaron, this is my first careful review of this document.  I would lean
towards 'not-ready-to-publish' until some more clarity in the
architecture and terminology is introduced:

I did not find the terminology to be well defined.  In particular, the
architecture introduces custom terminology (bundles, blocks, bundle
fragments, custodians and custodial transfer) that take the place of
more conventional networking terminology.  I recommend at the least that
there is a terminology section up front that defines these things in
relation to more conventional terms, or adoption of the more
conventional terms.  

Also, I found the use of the term endpoint identifier (EID) to be
non-standard; it seems like what you are really talking about are
addresses, or maybe they are serving both functions, in which case it
should be so stated.  The EID seems most equivalent to an IP address, or
perhaps an i3 trigger since it is late binding.  I would suggest not to
overload the term EID with this concept.  Also, is routing and
forwarding done on EIDs?  Does each bundle (and bundle fragment) carry
the EID?

It is not clear whether ADUs or bundles are passed to the DTN stack
across the service access point (SAP).  In 3.1 and 3.3.1, it says that
applications send ADUs, but in other places, it describes bundles being
the unit of data passed.  But it says in 3.1 that ADUs may be fragmented
into bundles; who does this fragmentation?  

Section 2, it seems like an additional guiding principle for
applications is that they should communicate data lifetimes to the
network when possible.

In section 3.4, the sentence "Group join operations are initiated at
receivers" seems out of place in this section talking about naming of
groups.

The reference to section 3.11 within Section 3.7 should refer instead to
3.12.

In section 3.8, second paragraph, s/We assume C(t) and B(t)/We assume
C(t) and D(t)/

It's not really clear how fragmentation works; is the protocol control
information copied into the fragments?

In the acknowledgements, s/Andrea/Andrei

-Tom

Date: Tue, 31 Oct 2006 09:30:31 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Michael Welzl <[email-masked]>
Subject: Re: [dtn-interest] [Fwd: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct]
Sender: [email-masked]

Just to explain. The new scheme for IRTF RFC publication
requires a poll of the IRSG (the set of RG chairs plus a
few others). If there're negative polls then those comments
should be discussed and hopefully resolved. (If not resolved
then in the end the IRTF chair makes a call I think.)

For those familiar with current IETF WG practice this is
sort of like a combined IESG review and IETF last call.

So the thing to do here is for one of the authors of the
arch draft to respond to Michael's comments. (Please make
sure to cc' both the list and Michael.)

Stephen.

FYI: there's another comment to come from Tom Henderson.

Michael Welzl wrote:
> -----Forwarded Message-----
> 
>> From: Aaron Falk <[email-masked]>
>> To: Michael Welzl <[email-masked]>
>> Cc: Kevin Fall <[email-masked]>, Stephen Farrell <[email-masked]>
>> Subject: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
>> Date: 30 Oct 2006 08:41:11 -0800
>>
>> Michael-
>>
>> Please forward your review to the RG mailing list as per draft-irtf- 
>> rfcs.  Stephen Farrell is the draft shepherd and will coordinate  
>> resolution of your comments.
>>
>> --aaron
>>
>> On Oct 30, 2006, at 2:38 AM, Michael Welzl wrote:
>>
>>> o  'not ready to publish' -- requires a thorough read, reasonably
>>>    detailed review, and actionable comments.
>>>
>>> See my review below - and sorry that it took me so long!
>>>
>>> Cheers,
>>> Michael
>>>
>>> ---
>>>
>>> I am not an expert on DTN (but this probably makes me a good guinea
>>> pig for a document such as this one), and therefore don't know all
>>> the reasons that led to design decisions in this document; such
>>> specifications are not necessarily the right place for justifying
>>> design decisions, and there may be conference or journal papers
>>> where such justification is found, and which I may not know about.
>>> Thus, if there are such documents, it would be all right in my
>>> opinion to simply point to them, as an aid to readers who would
>>> like to understand a bit more about the design.
>>>
>>> If there isn't any justification in any such documents regarding
>>> the points I'm raising about delivery options and bundle status
>>> reports, I would however regard this as critical.
>>>
>>>
>>> pages 12/13: what is the rationale behind delivery options such as  
>>> these:
>>>
>>>    - Report When Bundle Forwarded - requests a Bundle Forwarding  
>>> Status
>>>       Report be generated when the subject bundle departs a DTN node
>>>       that has forwarded it.
>>>
>>>    - Report When Bundle Deleted - requests a Bundle Deletion Status
>>>       Report be generated when the subject bundle is deleted at a DTN
>>>       node.
>>>
>>> If I would propose something like these reports for the general  
>>> Internet,
>>> it would immediately be rejected for obvious reasons ("how would  
>>> this scale?
>>> why do you need this?" etc.) - why would this then be acceptable  
>>> for a DTN?
>>> Deletion could be done because of congestion, so you require a message
>>> to be generated during times of congestion - which smells like  
>>> source quench.
>>> I don't have a problem with end-to-end ACKs like "Report When Bundle
>>> Acknowledged by Application", but these reports of intermediary nodes
>>> seem strange to me.
>>>
>>> The same comments obviously apply to the Bundle Status Reports that go
>>> with these options, e.g. "Bundle Deletion" on page 14.
>>>
>>> I could imagine that such intermediate reports would be useful for
>>> per-hop retransmissions as foreseen by the custody transfer, but they
>>> reports do not appear to be designed (solely) for such use, as there
>>> is a specific signal dedicated to custody transfer, and the report-to
>>> EID *may* differ from the source's EID. On page 13, it is stated that
>>> Bundle Status Reports correspond approximately to ICMP - thus,
>>> "Bundle Deletion" should not be regarded as a per-hop NACK (which
>>> I could accept as a necessary message, if it is sent to no other
>>> node than the custodian) but rather as an  ICMP-style "packet dropped"
>>> or "packet received" message. Having such a feature strikes me as
>>> bad design in no matter what network, as it is not cumulative in
>>> nature and therefore implicitly assumes up to 50% of the bundles
>>> in the network to be signaling messages of a "report" nature (i.e.
>>> not a necessary element of a specific scheme such as per-hop or
>>> end-to-end retransmission).
>>>
>>> Combined with the ability of arbitrary nodes to register for
>>> reception of data for a particular EID (multicast support),
>>> I imagine that these per-hop, per-bundle reports would open
>>> the door for interesting DoS attacks.
>>>
>>> It also seems to me that the problem which is described in the last
>>> paragraph on page 19 indicates that something is wrong with this
>>> design. If the only ACK to the source would be of an end-to-end
>>> nature, the problem would not occur, and why would a source need
>>> earlier loss notifications when it can request custody transfer?
>>> If the delay is too large for end-to-end retransmissions to be
>>> useful, the source is probably not the node that should retransmit
>>> anyway.
>>>
>>>
>>>
>>> page 15:
>>>> The payload block indicates information about the contained payload
>>>> (e.g. its length) and, somewhat unusually, includes the payload
>>>> itself.  In addition to the fields found in the primary and payload
>>> I suggest to remove "somewhat unusually" here. It caused me
>>> to wonder why this is so unusual, while it doesn't really
>>> matter anyway whether this is unusual or not.
>>>
>>> page 17, reactive fragmentation:
>>>> the previous-hop sender may learn that only a portion of the bundle
>>>> was delivered to the next hop, ..
>>> How? No such report is defined.
>>>
>>> The description of Reactive Fragmentation should probably
>>> be more detailed, perhaps using an example to explain the process.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

From: Michael Welzl <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Organization: University of Innsbruck
Date: 31 Oct 2006 08:04:34 +0100
Subject: [dtn-interest] [Fwd: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct]
Sender: [email-masked]

-----Forwarded Message-----

> From: Aaron Falk <[email-masked]>
> To: Michael Welzl <[email-masked]>
> Cc: Kevin Fall <[email-masked]>, Stephen Farrell <[email-masked]>
> Subject: Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
> Date: 30 Oct 2006 08:41:11 -0800
> 
> Michael-
> 
> Please forward your review to the RG mailing list as per draft-irtf- 
> rfcs.  Stephen Farrell is the draft shepherd and will coordinate  
> resolution of your comments.
> 
> --aaron
> 
> On Oct 30, 2006, at 2:38 AM, Michael Welzl wrote:
> 
> > o  'not ready to publish' -- requires a thorough read, reasonably
> >    detailed review, and actionable comments.
> >
> > See my review below - and sorry that it took me so long!
> >
> > Cheers,
> > Michael
> >
> > ---
> >
> > I am not an expert on DTN (but this probably makes me a good guinea
> > pig for a document such as this one), and therefore don't know all
> > the reasons that led to design decisions in this document; such
> > specifications are not necessarily the right place for justifying
> > design decisions, and there may be conference or journal papers
> > where such justification is found, and which I may not know about.
> > Thus, if there are such documents, it would be all right in my
> > opinion to simply point to them, as an aid to readers who would
> > like to understand a bit more about the design.
> >
> > If there isn't any justification in any such documents regarding
> > the points I'm raising about delivery options and bundle status
> > reports, I would however regard this as critical.
> >
> >
> > pages 12/13: what is the rationale behind delivery options such as  
> > these:
> >
> >    - Report When Bundle Forwarded - requests a Bundle Forwarding  
> > Status
> >       Report be generated when the subject bundle departs a DTN node
> >       that has forwarded it.
> >
> >    - Report When Bundle Deleted - requests a Bundle Deletion Status
> >       Report be generated when the subject bundle is deleted at a DTN
> >       node.
> >
> > If I would propose something like these reports for the general  
> > Internet,
> > it would immediately be rejected for obvious reasons ("how would  
> > this scale?
> > why do you need this?" etc.) - why would this then be acceptable  
> > for a DTN?
> > Deletion could be done because of congestion, so you require a message
> > to be generated during times of congestion - which smells like  
> > source quench.
> > I don't have a problem with end-to-end ACKs like "Report When Bundle
> > Acknowledged by Application", but these reports of intermediary nodes
> > seem strange to me.
> >
> > The same comments obviously apply to the Bundle Status Reports that go
> > with these options, e.g. "Bundle Deletion" on page 14.
> >
> > I could imagine that such intermediate reports would be useful for
> > per-hop retransmissions as foreseen by the custody transfer, but they
> > reports do not appear to be designed (solely) for such use, as there
> > is a specific signal dedicated to custody transfer, and the report-to
> > EID *may* differ from the source's EID. On page 13, it is stated that
> > Bundle Status Reports correspond approximately to ICMP - thus,
> > "Bundle Deletion" should not be regarded as a per-hop NACK (which
> > I could accept as a necessary message, if it is sent to no other
> > node than the custodian) but rather as an  ICMP-style "packet dropped"
> > or "packet received" message. Having such a feature strikes me as
> > bad design in no matter what network, as it is not cumulative in
> > nature and therefore implicitly assumes up to 50% of the bundles
> > in the network to be signaling messages of a "report" nature (i.e.
> > not a necessary element of a specific scheme such as per-hop or
> > end-to-end retransmission).
> >
> > Combined with the ability of arbitrary nodes to register for
> > reception of data for a particular EID (multicast support),
> > I imagine that these per-hop, per-bundle reports would open
> > the door for interesting DoS attacks.
> >
> > It also seems to me that the problem which is described in the last
> > paragraph on page 19 indicates that something is wrong with this
> > design. If the only ACK to the source would be of an end-to-end
> > nature, the problem would not occur, and why would a source need
> > earlier loss notifications when it can request custody transfer?
> > If the delay is too large for end-to-end retransmissions to be
> > useful, the source is probably not the node that should retransmit
> > anyway.
> >
> >
> >
> > page 15:
> >> The payload block indicates information about the contained payload
> >> (e.g. its length) and, somewhat unusually, includes the payload
> >> itself.  In addition to the fields found in the primary and payload
> >
> > I suggest to remove "somewhat unusually" here. It caused me
> > to wonder why this is so unusual, while it doesn't really
> > matter anyway whether this is unusual or not.
> >
> > page 17, reactive fragmentation:
> >> the previous-hop sender may learn that only a portion of the bundle
> >> was delivered to the next hop, ..
> >
> > How? No such report is defined.
> >
> > The description of Reactive Fragmentation should probably
> > be more detailed, perhaps using an example to explain the process.
> 

Date: Fri, 27 Oct 2006 20:32:34 +0300
From: Joerg Ott <[email-masked]>
To: DTN <[email-masked]>, DTN dev <[email-masked]>
CC: Stephen Farrell <[email-masked]>, Michael Demmer <[email-masked]>
Subject: [dtn-interest] DTN Interop @ IETF 67: Device information
Sender: [email-masked]

Hi,

we are currently preparing the setup of the interop
during the IETF meeting.

To allow everyone to configure their systems as much as
possible ahead of time and also to be able to dimension
the equipment needed accordingly, we are collecting data
on the devices you will bring.

Please drop me a short note on how many devices you will
have so that we can count the number of switch ports and
power sockets we will need.  Please also make sure
to bring your own Ethernet cable to connect and maybe
even an extension cord.  If you need special equipment
to connect, you will most likely need to bring it yourself.

Please also let me know which DTN URIs your applications
will use (we assume that we will just use the DTN URI
space dtn://<your-id>.

We will send around a list of statically assigned IP
addresses and publish all the DTN URIs among the
participants so that static configuration can be done
before, at least for the peerwise tests.

Further logistics to follow.

Thanks,
Joerg

To: DTN <[email-masked]>
From: Jon Olson <[email-masked]>
Date: Wed, 25 Oct 2006 14:49:09 -0400
Subject: [dtn-interest] Georgia Tech DTN Implementation Release
Sender: [email-masked]

Hello all,

For those who are interested, a release of Georgia Tech's DTN  
implementation can be downloaded at: http://www.cc.gatech.edu/~jon/ 
gtdtn-rev231.zip

Release notes are in the root of the source tree. Windows binaries  
are also supplied. These should work under mono as well. This release  
is a bit rough, but it should be stable and functional enough to try  
some testing. We hope to have another stable release packaged out  
from our unstable development branch by IETF.

-- Jon

Date: Tue, 24 Oct 2006 18:18:41 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Agenda for IETF-67
Sender: [email-masked]

Folks,

I've updated the draft agenda for our meeting in San Diego [1].

Let me know if a slot is missing, wrongly described, too long
or too short or whatever...

And if you have slides already then send them to me and I can
post them too.

Cheers,
Stephen.

[1] http://www.ietf.org/proceedings/06nov/agenda/DTNRG.html

Date: Wed, 18 Oct 2006 12:13:51 +0200 (CEST)
From: "Adriano Galati" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] dtnsim2
Sender: [email-masked]

Hi everybody,

I get stuck to make simulation with dtnsim2.
I haven't clear which are the steps to make simulation, how to create
sim.fl, sim.file, inp_graph_file.gr and how to use it.
Please, could you send me some examples and instructions?

Thank you very much,

regards,

Adriano

=======================================================
Adriano Galati

MSc Student
Department of Information and Computer Sciences
Utrecht University
The Netherlands

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

Date: Tue, 17 Oct 2006 18:49:58 +0200 (CEST)
From: "Adriano Galati" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] Compiling dtnsim2
Sender: [email-masked]

Hi Ladies and Gentlemen,

Well, as you know I have had some problems with compiling dtnsim2
I solved (I think) all my problems (also thanks to you) so I resume here
the changes I made to fix these.
I wish this help

====================================================================
 In simulator.h , uncomment this line and check the installation

 gsl_rng                 *rand_gen;

Add this line into your simulator.h file

int                                init(int routing_type,int max_t);

below
int                                init(int break_point_type,int
routing_type,int lptype,time_type_t
max_t);

Go into the file "constants.h" and I uncommented

#include <gsl/gsl_randist>
#include <gsl/gsl_rng.h>

In the Makefile uncomment this line

LDFLAGS= -lgsl -lgslcblas

and add "break.o lpent.o" in "dtsim"

dtsim:  break.o lpent.o topology.o netent.o network.o  pktent.o ctrlent.o
node.o link.o sched.o sim.o
        ${CCMALLOC} g++  -o dtsim       break.o lpent.o topology.o
netent.o pktent.o ctrlent.o network.o  node.o link.o sched.o sim.o
${LDFLAGS}

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

Best rregards,

Adriano

=======================================================
Adriano Galati

MSc Student
Department of Information and Computer Sciences
Utrecht University
The Netherlands

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

Content-class: urn:content-classes:message
Date: Tue, 17 Oct 2006 12:26:45 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Updated (01 version) DTN Custodial Multicast Extensions I-D
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6F209.0A6D9552
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C6F209.0A6D9552"

------_=_NextPart_002_01C6F209.0A6D9552
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,=20
=20
Attached is an updated (01 version) of the DTN Custodial Multicast
Extensions I-D, which incorporates feedback that I received on the 00
version from Mike and others. I plan to discuss this draft at the San
Diego meeting.
=20
Abstract

   This document defines optional extensions to the Bundle Protocol [2]
   for supporting the custodial multicast delivery of bundles within a
   Delay-Tolerant Network (DTN).  The protocol extensions described
   herein may be used to support custody transfer and custody-based
   reforwarding during the transmission of a bundle from a single
source
   node to multiple destination nodes.

=20
Below are my notes on the major enhancements that were made to the 00
version I-D to yield the attached 01 version I-D:=20

1.=09
	Mention the assumption that in order for custody signals to be
received at  custodians, there has to be connectivity back from the
node generating the custody signal to the custodian. If this
connectivity doesn't exist, the protocol will still work, but the
custodian may continue to resend the bundles (thinking they weren't
received), so it  won't be as efficient. This is true for both unicast
and multicast custody transfer. In the multicast case, the node
generating the custody signal must have connectivity back to the
previous  proxy custodian (if there was one) and this proxy custodian
must have connectivity back to its previous proxy custodian (if there
was one) and so forth until there is connectivity to the real
custodian.=20
2.	Mention that when bundles are resent, we want proxy custodians
to only reforward the resent bundles on those downstream branches of
the distribution  tree from which successful custody signals have not
been received. In order to be able to do this, the proxy custodian must
maintain state. The question arises as to how long this state
information should be maintained. A node could run out of room if it
tries to keep this state information until the bundles expire. If it
runs out of room though, then the bundle will just be resent to all
downstream branches.  This is not incorrect, just inefficient. Should
have a default algorithm for defining how long state information must
be maintained, and if a node runs out of room for state information,
which state information gets deleted and which gets saved.=20
3.=09
	Strictly speaking, there is not a requirement that individual
copies of multicast bundles be identified when they are forwarded. This
is an optimization for reducing the number of retransmissions. (Yes, it
is an optimization, but it is a pretty vital one.)  Still, I changed
the spec to say that individual copies SHOULD be identified, rather
than MUST be. Retransmitted bundles could always be resent on every
branch.
4.=09
	Enable non-custodial branching points to aggregate Failed
custody signals received. This change was effected by enabling more
than one Proxy EID extension block (which identifies the source of a
"Failed" custody signal) to be inserted into a "Failed" custody signal
bundle. Each Proxy EID header identifies a different "Failed" signal
that was generated at a downstream node. Also, the nodes need to start
a timer when they receive a Failed signal and then when the timer times
out (or when custody signals for every branch have been received,
whichever comes first) the Failed signals received can be aggregated
and sent upstream as one failed signal. =20
5.	Added a section regarding interaction of custodial multicast
with use of the optional Retransmission Block. It explains that if a
custodial multicast bundle with a Retransmission Block is received at a
non-custodial branching node, then that node, which is a proxy
custodian for that bundle,  must not only put its own EID in the
custodian field; it must also put  its own EID in the Retransmission
Block. (To state this more exactly, the proxy custodian's EID must be
placed in the dictionary, and the offsets in the custodian Scheme and
SSP fields and the offsets in the RB scheme and SSP fields must be
changed to point to the proxy custodian's EID rather than to the
custodian's EID.)
6.	Updated references.

 -susan

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

------_=_NextPart_002_01C6F209.0A6D9552
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.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D387375915-17102006>All,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D387375915-17102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D387375915-17102006>Attached is an=20
updated (01 version) of the DTN Custodial Multicast Extensions I-D, =
which=20
incorporates feedback that I received on the 00 version from Mike and =
others. I=20
plan to discuss this draft at the San Diego meeting.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D387375915-17102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D387375915-17102006>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Courier New">Abstract<BR><BR><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>This document defines optional extensions to the Bundle Protocol=20
[2]<BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>for =
supporting the=20
custodial multicast delivery of bundles within a<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Delay-Tolerant Network =
(DTN).<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>The protocol extensions=20
described<BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>herein may be=20
used to support custody transfer and custody-based<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>reforwarding during the=20
transmission of a bundle from a single source<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>node to multiple =
destination=20
nodes.</FONT><BR></P></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D387375915-17102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D387375915-17102006>Below =
are my notes=20
on the major&nbsp;enhancements that were made to the 00 version I-D to =
yield the=20
attached 01 version&nbsp;I-D:&nbsp;</SPAN></FONT></DIV><FONT =
face=3DArial=20
size=3D2><SPAN class=3D387375915-17102006>
<OL>
  <LI>
  <DIV class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Mention the assumption that in order =
for custody=20
  signals to be received at<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN>custodians, there has to be connectivity back from the node =
generating=20
  the custody signal to the custodian. If this connectivity doesn't =
exist, the=20
  protocol will still work, but the custodian may continue to resend the =
bundles=20
  (thinking they weren't received), so it<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>won't be as efficient. This is true for both unicast and =
multicast=20
  custody transfer. In the multicast case, the node generating the =
custody=20
  signal must have connectivity back to the previous<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>proxy custodian (if there =
was one) and=20
  this proxy custodian must have connectivity back to its previous proxy =

  custodian (if there was one) and so forth until there is connectivity =
to the=20
  real custodian.&nbsp;</FONT></DIV></LI>
  <LI><FONT face=3D"Times New Roman" size=3D3>Mention that when bundles =
are resent,=20
  we want proxy custodians to only reforward the resent bundles on those =

  downstream branches of the distribution<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>tree from which successful custody signals have not been =
received. In=20
  order to be able to do this, the proxy custodian must maintain state. =
The=20
  question arises as to how long this state information should be =
maintained. A=20
  node could run out of room if it tries to keep this state information =
until=20
  the bundles expire. If it runs out of room though, then the bundle =
will just=20
  be resent to all downstream branches.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>This is not incorrect, just inefficient. Should have a default=20
  algorithm for defining how long state information must be maintained, =
and if a=20
  node runs out of room for state information, which state information =
gets=20
  deleted and which gets saved.</FONT><?xml:namespace prefix =3D o ns =
=3D=20
  "urn:schemas-microsoft-com:office:office" /><o:p><FONT face=3D"Times =
New Roman"=20
  size=3D3>&nbsp;</FONT></o:p></LI>
  <LI><o:p><FONT face=3D"Times New Roman" size=3D3>
  <DIV class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman"><FONT size=3D3><SPAN =
class=3D387375915-17102006>Strictly=20
  speaking, there is not </SPAN>a requirement that individual copies of =
m<SPAN=20
  class=3D387375915-17102006>ulti</SPAN>cast bundles be identified when =
they are=20
  forwarded. This is an optimization for reducing the number of =
retransmissions.=20
  (Yes, it is an optimization, but it is a pretty vital one.)<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Still, I changed the spec to =
say that=20
  individual copies SHOULD be identified, rather than MUST be. =
Retransmitted=20
  bundles could always be resent on every branch<SPAN=20
  =
class=3D387375915-17102006>.</SPAN></FONT></FONT></DIV></FONT></o:p></LI>=

  <LI>
  <DIV class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo1; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman"><FONT size=3D3><SPAN =
class=3D387375915-17102006>Enable=20
  </SPAN>non-custodial branching points&nbsp;<SPAN =
class=3D387375915-17102006>to=20
  </SPAN>aggregate Failed custody signals received. This change was =
effected by=20
  enabling more than one Proxy EID extension block (which identifies the =
source=20
  of a &#8220;Failed&#8221; custody signal) to be inserted into a =
&#8220;Failed&#8221; custody signal=20
  bundle. Each Proxy EID header identifies a different =
&#8220;Failed&#8221; signal that was=20
  generated at a downstream node. Also, the nodes need to start a timer =
when=20
  they receive a Failed signal and then when the timer times out (or =
when=20
  custody signals for every branch have been received, whichever comes =
first)=20
  the Failed signals received can be aggregated and sent upstream as one =
failed=20
  signal.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN></FONT></FONT></DIV></LI>
  <LI class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
face=3D"Times New Roman"=20
  size=3D3>Added a section regarding interaction of custodial multicast =
with use=20
  of the optional Retransmission Block. It explains that if a custodial=20
  multicast bundle with a Retransmission Block is received at a =
non-custodial=20
  branching node, then that node, which is a proxy custodian for that=20
  bundle,<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>must not only =
put its own=20
  EID in the custodian field; it must also put<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>its own EID in the =
Retransmission=20
  Block. (To state this more exactly, the proxy custodian&#8217;s EID =
must be placed=20
  in the dictionary, and the offsets in the custodian Scheme and SSP =
fields and=20
  the offsets in the RB scheme and SSP fields must be changed to point =
to the=20
  proxy custodian's EID rather than to the custodian's EID.)</FONT></LI>
  <LI class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
  class=3D387375915-17102006><FONT face=3D"Times New Roman" =
size=3D3>Updated=20
  references.</FONT></SPAN></LI></OL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;<SPAN class=3D387375915-17102006><FONT face=3DArial=20
size=3D2>-susan</FONT></SPAN></FONT></o:p></P></SPAN></FONT>
<DIV>&nbsp;</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><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C6F209.0A6D9552--

------_=_NextPart_001_01C6F209.0A6D9552
Content-Type: text/plain;
	name="draft-symington-dtnrg-bundle-multicast-custodial-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-symington-dtnrg-bundle-multicast-custodial-01.txt
Content-Disposition: attachment;
	filename="draft-symington-dtnrg-bundle-multicast-custodial-01.txt"

------_=_NextPart_001_01C6F209.0A6D9552--

Date: Tue, 17 Oct 2006 16:52:39 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IETF-67 draft agenda
Sender: [email-masked]

Folks,

I've posted the current draft agenda for San Diego [1].

Let me know of additions/corrections and once you have slides
if you can send them to me that'd be good.

Cheers,
Stephen.

[1] http://www.ietf.org/proceedings/06nov/agenda/DTNRG.html

Date: Tue, 17 Oct 2006 15:31:47 +0200
From: David MENTRE <[email-masked]>
Organization: Mitsubishi Electric ITE TCL
To: Adriano Galati <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] make dtsim
Sender: [email-masked]

Hello,

Adriano Galati a écrit :
> I have the gsl installed in /usr/local/include . I don't know if it could
> be a problem but I have a gcc 3.4.6
> Maybe I have to change something in the Makefile in the directory
> /dtnsim2/dtlp/src/

Yes, you should probably add an option '-L /usr/local/path-to-gsl' to
CFLAGS. And maybe uncomment 'LDFLAGS= -lgsl -lgslcblas'.

Or the issue is elsewhere (having files with suffix .c for C++ code
seems strange to me, but I'm not a C++ programmer). You'd better find a
person having some knowledge in compiling Unix programs.

Best wishes,
d.
-- 
David MENTRE <[email-masked]> - Research engineer
Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab
Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59
http://www.mitsubishi-electric-itce.fr

Date: Tue, 17 Oct 2006 06:09:34 -0700 (PDT)
From: Kevin C Almeroth <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP:  WCMC Special Issue on Disruption Tolerant Networking
Sender: [email-masked]

*Wireless Communications & Mobile Computing*

*Special Issue Announcement*

*Disruption Tolerant Networking for Mobile or Sensor Networks*

* *

*Guest Editors:*
    Professor M. Chuah, Lehigh University, [email-masked]
    Professor Kevin Almeroth, UC-Santa Barbara, [email-masked]
    Dr Mark-Oliver Stehr, SRI, [email-masked]

Traditional network architecture that works well for Internet may not work
in many challenging environments e.g. sparsely connected ad hoc networks,
mobile sensor networks, interplanetary or battlefield communications. In
such environments, end-to-end paths may not exist or the path between a
source and destination pair may be constantly disrupted or largely delayed.

This special issue will provide a forum for academic researchers and
industry professionals to present their latest research results on
architectural and protocol designs that allow nodes in such environments to
communicate. The submitted papers should focus on the state-of-the-art
research in various important aspects of this exciting research area. Topics
of interests include but are not limited to:

-  new architecture for delay/disruption tolerant networks
-  protocol design and evaluation for message delivery in
    delay/disruption tolerant networks
-  Delay & Fault tolerance design for mobile or sensor networks
-  Modeling and analysis of delay/disruption tolerant networks
-  characterization of traffic and mobility patterns in
    delay/disruption tolerant networks
-  Security, privacy issues in delay/disruption tolerant networks
-  Declarative approaches to networking
-  Name management for disruption tolerant networks
-  Resource management and policy control for disruption tolerant networks
-  Machine learning techniques for disruption tolerant networks
-  Routing or topology formation algorithms for disruption tolerant networks

Submission: Manuscripts in PDF or zipped postscript format should be sent
directly by email to one of the Guest Editors. Please also submit a separate
cover letter via email, which contains the paper title, authors' names and
affiliations, and an abstract.

Please refer to this URL for the manuscript style:
    http://www3.interscience.wiley.com/cgi-bin/jabout/76507157/ForAuthors.html

*Schedule:*
    Submission deadline: 15th, Nov, 2006
    Notification of acceptance: 30th, Dec, 2006
    Camera-ready paper deadline: 15th, Jan, 2006
    Schedule Publication Date: Feb , 2007

Date: Tue, 17 Oct 2006 10:24:38 +0200
From: David MENTRE <[email-masked]>
Organization: Mitsubishi Electric ITE TCL
To: Adriano Galati <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] make dtsim
Sender: [email-masked]

Hello Adriano,

Adriano Galati a écrit :
> sim.c:37: error: `gsl_rng_taus' was not declared in this scope
[...]
> Does anybody have an idea about what is missing?

At least the GSL (GNU Scientific Library).

BTW, I found that with the first hit of a simple Google search!
 http://www.google.fr/search?q=gsl_rng_taus

Please do some basic research before asking on mailing lists.

Sincerely yours,
david
-- 
David MENTRE <[email-masked]> - Research engineer
Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab
Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59
http://www.mitsubishi-electric-itce.fr

Date: Mon, 16 Oct 2006 20:38:29 +0200 (CEST)
From: "Adriano Galati" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] make dtsim
Sender: [email-masked]

Hi,

I am a PhD student at the first year, I would like to use the dtn
simulator dtnsim but when I try to run "make dtsim" in the directory
"dtnsim2/dtlp/src" I get the following message:

[agalati@erm src]$ make dtsim
g++ -D INDOWS -D OUTE_DEBUG_ -D STATIC -D TEST -D DEBUG -g -Wunused
-Wno-deprecated   -c -o sim.o sim.c
sim.c: In constructor `Simulator::Simulator(char*)':
sim.c:37: error: `rand_gen' was not declared in this scope
sim.c:37: error: `gsl_rng_taus' was not declared in this scope
sim.c:37: error: `gsl_rng_alloc' was not declared in this scope
sim.c:38: error: `gsl_rng_set' was not declared in this scope
sim.c:37: warning: unused variable 'gsl_rng_taus'
sim.c:37: warning: unused variable 'gsl_rng_alloc'
sim.c:38: warning: unused variable 'gsl_rng_set'
sim.c: In destructor `Simulator::~Simulator()':
sim.c:48: error: `rand_gen' was not declared in this scope
sim.c:48: error: `gsl_rng_free' was not declared in this scope
sim.c:48: warning: unused variable 'rand_gen'
sim.c:48: warning: unused variable 'gsl_rng_free'
sim.c: At global scope:
sim.c:58: error: prototype for `int Simulator::init(int, int)' does not
match any in class `Simulator'simulator.h:34: error: candidate is: int
Simulator::init(int, int, int, time_type_t)
make: *** [sim.o] Error 1

Does anybody have an idea about what is missing?
I thank you in advance,

regards,

Adriano Galati

=======================================================
Adriano Galati

MSc Student
Department of Information and Computer Sciences
Utrecht University
The Netherlands

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

Date: Mon, 16 Oct 2006 14:13:39 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: 67th IETF Agenda]
Sender: [email-masked]

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

FYI. We're on Thursday at 9am-11:30am.

--------------050103020402000900020701
Content-Type: message/rfc822;
 name="67th IETF Agenda"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="67th IETF Agenda"

To: Working Group Chairs <[email-masked]>
From: IETF Secretariat <[email-masked]>
Date: Mon, 16 Oct 2006 04:15:11 -0400
Cc: [email-masked], [email-masked]
Subject: 67th IETF Agenda 

The final agenda can be found at:

http://www3.ietf.org/meetings/agenda_67.txt

Most, but not all, requests for changes have been made.

Marcia

--------------050103020402000900020701--

Content-class: urn:content-classes:message
Date: Fri, 13 Oct 2006 10:34:56 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN Retransmission Block I-D
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6EED4.C1752536
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C6EED4.C1752536"

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

All,
=20
Attached is a document for which I just received public release. I hope
we can discuss it at an upcoming teleconference or meeting.
=20
Abstract:
=20
   This document defines an optional extension block, called a
   Retransmission Block, that may be used with the Bundle Protocol [2]
   within the context of a Delay-Tolerant Network architecture [4].
The
   Retransmission Block (RB) is designed to be inserted by a custodian
   when re-forwarding a bundle, so as to mark the bundle as a
legitimate
   custody-based retransmission rather than an unauthorized bundle
   duplicate.  By providing a way for nodes that receive the re-
   forwarded bundle to distinguish it from an unauthorized duplicate,
   the RB enables those nodes whose local security policies do not
   permit them to forward replayed bundles to detect and delete
   unauthorized bundle replays but forward authorized custody-based
   bundle retransmissions.  This document defines the format and
   processing of this new Retransmission Block.

-susan

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

------_=_NextPart_002_01C6EED4.C1752536
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.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D234562814-13102006>All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D234562814-13102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D234562814-13102006>Attached is a=20
document for which I just received public release. I hope we can discuss =
it at=20
an upcoming teleconference or meeting.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D234562814-13102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D234562814-13102006>Abstract:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D234562814-13102006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D234562814-13102006>
<P class=3DMsoPlainText style=3D"MARGIN: 0in 0in 0pt"><FONT =
size=3D2><FONT=20
face=3D"Courier New"><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>This=20
document defines an optional extension block, called a<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Retransmission Block, =
that may be=20
used with the Bundle Protocol [2]<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>within the context of a=20
Delay-Tolerant Network architecture [4].<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>The<BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>Retransmission=20
Block (RB) is designed to be inserted by a custodian<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>when re-forwarding a =
bundle, so as=20
to mark the bundle as a legitimate<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>custody-based =
retransmission=20
rather than an unauthorized bundle<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>duplicate.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>By providing a way for nodes =
that=20
receive the re-<BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; =
</SPAN>forwarded=20
bundle to distinguish it from an unauthorized duplicate,<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>the RB enables those =
nodes whose=20
local security policies do not<BR><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>permit them to forward replayed bundles to detect and =
delete<BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>unauthorized bundle =
replays but=20
forward authorized custody-based<BR><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>bundle retransmissions.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>This=20
document defines the format and<BR><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>processing of this new Retransmission Block.</FONT><BR><BR><SPAN=20
class=3D234562814-13102006>-susan</SPAN></FONT></P></SPAN></FONT></DIV>
<DIV>&nbsp;</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><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C6EED4.C1752536--

------_=_NextPart_001_01C6EED4.C1752536
Content-Type: text/plain;
	name="draft-symington-dtnrg-bundle-retrans-block-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-symington-dtnrg-bundle-retrans-block-00.txt
Content-Disposition: attachment;
	filename="draft-symington-dtnrg-bundle-retrans-block-00.txt"

------_=_NextPart_001_01C6EED4.C1752536--

Date: Fri, 13 Oct 2006 15:20:19 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Interop in San Diego...
Sender: [email-masked]

Thanks all,

I've updated the interop page [1], let me know if I missed stuff or
if there's more to add.

Jon - please send a URL when you have one for that code (after the 15th
I guess)

Stephen.

[1] http://www.dtnrg.org/wiki/IETF67Interop

To: [email-masked]
Reply-To: "=?GB2312?B?1964tMPx?=" <[email-masked]>
From: "=?GB2312?B?1964tMPx?=" <[email-masked]>
Date:  Fri, 13 Oct 2006 21:18:45 +0800 (CST) 
Cc: [email-masked]
Subject: [dtn-interest] Does DTN can't work with normal TCP/IP application together, or it's a BUG?
Sender: [email-masked]

Hi,

DTN router can deliver the remain bundles to their destination as normal. I tested it as the following steps:
1. shutdown the AP -> dtnsend one message -> open the AP
after some seconds, DTN delivered the bundle to its destination OK.
2. shutdown the AP -> dtnsend one message -> open the AP -> ping the destination
I find that DTN did not deliver the bundle to its destination. I look for it with "bundle list" command and I find that it has lost.

Does DTN can't work with normal TCP/IP application together, or it's a BUG? Who can give me some advice? Thanks very much!

Regards.

Fumin

To: [email-masked]
Reply-To: "=?GB2312?B?1964tMPx?=" <[email-masked]>
From: "=?GB2312?B?1964tMPx?=" <[email-masked]>
Date:  Fri, 13 Oct 2006 20:59:41 +0800 (CST) 
Subject: [dtn-interest] it can't work to forward the DTN traffic to UDP
Sender: [email-masked]

Hi,

Sorry, I want to implement the dtntunnel, not the moteproxy between DTN and normal TCP/IP network.
I found that it work well to forward the UDP traffic to DTN Router. But it can't work to forward the DTN traffic to UDP.
I implemented as below:
dtntunnel -r s -p dtn://xxx.dtn -s 7000
it work well to forward the UDP traffic from port 7000 to dtn://xxx.dtn.
dtntunnel -r r -p dtn://yyy.dtn -d 192.168.50.153:7001
it can't work to forward the DTN traffic to 192.168.50.153:7001.
Who can give me some advice? Thanks very much!

Regards.

Fumin

To: [email-masked]
Reply-To: "=?GB2312?B?1964tMPx?=" <[email-masked]>
From: "=?GB2312?B?1964tMPx?=" <[email-masked]>
Date:  Fri, 13 Oct 2006 12:30:35 +0800 (CST) 
Subject: [dtn-interest] Pls help me to implement the dtnmoteproxy
Sender: [email-masked]

Hi,

I want to implement a dtnmoteproxy between the DTN and normal TCP network. But I can't get the manual for implementing the dtnmoteproxy. Could you please tell me how to deploy it? Thanks very much!

Regards.

Fumin

To: [email-masked]
Reply-To: "=?GB2312?B?1964tMPx?=" <[email-masked]>
From: "=?GB2312?B?1964tMPx?=" <[email-masked]>
Date:  Fri, 13 Oct 2006 12:30:26 +0800 (CST) 
Subject: [dtn-interest] Pls help me to implement the dtnmoteproxy
Sender: [email-masked]

Hi,

I want to implement a dtnmoteproxy between the DTN and normal TCP network. But I can't get the manual for implementing the dtnmoteproxy. Could you please tell me how to deploy it? Thanks very much!

Regards.

Fumin

Date: Thu, 12 Oct 2006 20:56:16 -0700 (PDT)
From: Hadi <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] the simulation code
Sender: [email-masked]

--0-404252989-1160711776=:9282
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Respected All.
   
  I need the NS2 simulation code for the Unicast,DTBR,OS-Multicast and CAMR.
  for the copmaritive analysis.
  If anyone have access to that code plz mail me that.
  waiting for a kind reply....
  thanks.
  Hadi.

---------------------------------
Stay in the know. Pulse on the new Yahoo.com.  Check it out. 
--0-404252989-1160711776=:9282
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div>Respected All.</div>  <div>&nbsp;</div>  <div>I need the NS2 simulation code for the Unicast,DTBR,OS-Multicast and CAMR.</div>  <div>for the copmaritive analysis.</div>  <div>If anyone have access to that code plz mail me that.</div>  <div>waiting for a kind reply....</div>  <div>thanks.</div>  <div>Hadi.</div><p>&#32;
		<hr size=1>Stay in the know. Pulse on the new Yahoo.com. <a href="http://us.rd.yahoo.com/evt=42974/*http://www.yahoo.com/preview"> Check it out.</a> 

--0-404252989-1160711776=:9282--

Cc: DTN <[email-masked]>
From: Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] Interop in San Diego...
Date: Thu, 12 Oct 2006 15:49:53 -0400
To: Scott Burleigh <[email-masked]>
Sender: [email-masked]

--Apple-Mail-3--160716401
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Indeed.  I would recommend using delay/error emulators only if  
everything else is already working.

On Oct 12, 2006, at 3:37 PM, Scott Burleigh wrote:

> Zegura, Ellen Witte wrote:
>> Delay is fun, but my guess is that interoperability even without  
>> delays
>> is likely to occupy a good part of the week.
>>
> I so totally agree.
>
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-3--160716401
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Indeed.=A0 I would recommend =
using delay/error emulators only if everything else is already =
working.<DIV><BR><DIV><DIV>On Oct 12, 2006, at 3:37 PM, Scott Burleigh =
wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Zegura, Ellen Witte wrote:</DIV> =
<BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">Delay is fun, but my guess =
is that interoperability even without delays</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">is likely to occupy a good part of the week.</DIV><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN =
class=3D"Apple-converted-space">=A0=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></P> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I so totally agree.</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Scott</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mai=
lman.dtnrg.org/mailman/listinfo/dtn-interest</A></DIV> =
</BLOCKQUOTE></DIV><BR><DIV> <SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> =
</DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-3--160716401--

Date: Thu, 12 Oct 2006 12:37:02 -0700
From: Scott Burleigh <[email-masked]>
CC: DTN <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Interop in San Diego...
Sender: [email-masked]

Zegura, Ellen Witte wrote:
> Delay is fun, but my guess is that interoperability even without delays
> is likely to occupy a good part of the week.
>   
I so totally agree.

Scott

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Interop in San Diego...
Date: Thu, 12 Oct 2006 15:25:39 -0400
From: "Zegura, Ellen Witte" <[email-masked]>
To: "Leigh Torgerson" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Delay is fun, but my guess is that interoperability even without delays
is likely to occupy a good part of the week.

Ellen

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Leigh
Torgerson
Sent: Thursday, October 12, 2006 2:25 PM
To: Stephen Farrell; DTN
Cc: [email-masked]
Subject: Re: [dtn-interest] Interop in San Diego...

Hi -

Just wanted to throw out another possibility - we have some computers 
with our deep space delay simulators (selectable delay milliseconds 
to an hour; with frame-error-rate noise addition possible) that we 
can ssh into from outside our firewall - we could set up a simulated 
space link possibly over ssh tunnels - haven't tried it before but 
might be something to try out in the next couple of weeks since the 
delay simulators are already available.. contact Josh if you're 
interested in trying this out!

Leigh

At 6:02 PM +0100 10/12/06, Stephen Farrell wrote:
>Folks,
>
>We've discussed doing some interop at the forthcoming IETF
>meeting in San Diego [1].
>
>Some of us have started to make those plans more concrete
>so we've started a wiki page for this [2]. Comments to Me,
>Kevin, Mike Demmer, Joerg Ott, and/or the list I guess.
>
>If you'd like to take part, you're more than welcome, just
>let us know. If you can help out somehow, that'd be great
>(e.g. if you've some cute way to delay packets that we
>can use). If you've experience of this kind of thing and
>see us making a mistake we'd like to hear about that too!
>
>Regards,
>Stephen.
>
>PS: Melissa's also updating the docs page [3] so if you've
>anything to go there you may want to point that out now.
>The I-D links there should be up to date in the next while.
>
>[1] http://www3.ietf.org/meetings/67-IETF.html
>[2] http://www.dtnrg.org/wiki/IETF67Interop
>[3] http://www.dtnrg.org/wiki/Docs
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
-------------------------------------------------------------------
J. Leigh Torgerson                          [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec.332
DARPA DTN / DSMS Advanced Protocol Implementation Work Area Manager
(818) 393-0695                                   (818) 393-4643 fax
-------------------------------------------------------------------
_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 12 Oct 2006 11:24:46 -0700
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] Interop in San Diego...
Cc: [email-masked]
Sender: [email-masked]

Hi -

Just wanted to throw out another possibility - we have some computers 
with our deep space delay simulators (selectable delay milliseconds 
to an hour; with frame-error-rate noise addition possible) that we 
can ssh into from outside our firewall - we could set up a simulated 
space link possibly over ssh tunnels - haven't tried it before but 
might be something to try out in the next couple of weeks since the 
delay simulators are already available.. contact Josh if you're 
interested in trying this out!

Leigh

At 6:02 PM +0100 10/12/06, Stephen Farrell wrote:
>Folks,
>
>We've discussed doing some interop at the forthcoming IETF
>meeting in San Diego [1].
>
>Some of us have started to make those plans more concrete
>so we've started a wiki page for this [2]. Comments to Me,
>Kevin, Mike Demmer, Joerg Ott, and/or the list I guess.
>
>If you'd like to take part, you're more than welcome, just
>let us know. If you can help out somehow, that'd be great
>(e.g. if you've some cute way to delay packets that we
>can use). If you've experience of this kind of thing and
>see us making a mistake we'd like to hear about that too!
>
>Regards,
>Stephen.
>
>PS: Melissa's also updating the docs page [3] so if you've
>anything to go there you may want to point that out now.
>The I-D links there should be up to date in the next while.
>
>[1] http://www3.ietf.org/meetings/67-IETF.html
>[2] http://www.dtnrg.org/wiki/IETF67Interop
>[3] http://www.dtnrg.org/wiki/Docs
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
-------------------------------------------------------------------
J. Leigh Torgerson                          [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec.332
DARPA DTN / DSMS Advanced Protocol Implementation Work Area Manager
(818) 393-0695                                   (818) 393-4643 fax
-------------------------------------------------------------------

Cc: DTN <[email-masked]>, [email-masked]
From: Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] Interop in San Diego...
Date: Thu, 12 Oct 2006 14:00:25 -0400
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

--Apple-Mail-2--167284790
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Great job Stephen!  I'll comment once I have a few cycles to digest  
the plan.

I will try to get a couple of delay generators up at OU if I have  
time.  That would mean having to bounce traffic out of and then back  
into the IETF site, so you may only want to do that for portions of  
the tests.   On the other hand, doing something like that would give  
us some data points for the dtnbone.

On Oct 12, 2006, at 1:02 PM, Stephen Farrell wrote:

>
> Folks,
>
> We've discussed doing some interop at the forthcoming IETF
> meeting in San Diego [1].
>
> Some of us have started to make those plans more concrete
> so we've started a wiki page for this [2]. Comments to Me,
> Kevin, Mike Demmer, Joerg Ott, and/or the list I guess.
>
> If you'd like to take part, you're more than welcome, just
> let us know. If you can help out somehow, that'd be great
> (e.g. if you've some cute way to delay packets that we
> can use). If you've experience of this kind of thing and
> see us making a mistake we'd like to hear about that too!
>
> Regards,
> Stephen.
>
> PS: Melissa's also updating the docs page [3] so if you've
> anything to go there you may want to point that out now.
> The I-D links there should be up to date in the next while.
>
> [1] http://www3.ietf.org/meetings/67-IETF.html
> [2] http://www.dtnrg.org/wiki/IETF67Interop
> [3] http://www.dtnrg.org/wiki/Docs
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-2--167284790
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Great job Stephen!=A0 I'll =
comment once I have a few cycles to digest the plan.<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I will try to get a couple =
of delay generators up at OU if I have time.=A0 That would mean having =
to bounce traffic out of and then back into the IETF site, so you may =
only want to do that for portions of the tests.=A0 =A0On the other hand, =
doing something like that would give us some data points for the =
dtnbone.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"><DIV><DIV><DIV>On Oct 12, 2006, at =
1:02 PM, Stephen Farrell wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Folks,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">We've discussed doing some interop at the =
forthcoming IETF</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">meeting in San Diego =
[1].</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Some of us have started to make those plans more =
concrete</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">so we've started a wiki page for =
this [2]. Comments to Me,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Kevin, Mike =
Demmer, Joerg Ott, and/or the list I guess.</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">If you'd like =
to take part, you're more than welcome, just</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">let us know. If you can help out somehow, that'd be =
great</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">(e.g. if you've some cute way to =
delay packets that we</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">can use). If you've =
experience of this kind of thing and</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">see us making =
a mistake we'd like to hear about that too!</DIV><DIV style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Regards,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Stephen.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">PS: =
Melissa's also updating the docs page [3] so if you've</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">anything to go there you may want to point that out =
now.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">The I-D links there should be up =
to date in the next while.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">[1] <A =
href=3D"http://www3.ietf.org/meetings/67-IETF.html">http://www3.ietf.org/m=
eetings/67-IETF.html</A></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">[2] <A =
href=3D"http://www.dtnrg.org/wiki/IETF67Interop">http://www.dtnrg.org/wiki=
/IETF67Interop</A></DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">[3] <A =
href=3D"http://www.dtnrg.org/wiki/Docs">http://www.dtnrg.org/wiki/Docs</A>=
</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mai=
lman.dtnrg.org/mailman/listinfo/dtn-interest</A></DIV> =
</BLOCKQUOTE></DIV><BR><DIV> <SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> =
</DIV><BR></DIV></DIV></BODY></HTML>=

--Apple-Mail-2--167284790--

Date: Thu, 12 Oct 2006 18:02:45 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Interop in San Diego...
Sender: [email-masked]

Folks,

We've discussed doing some interop at the forthcoming IETF
meeting in San Diego [1].

Some of us have started to make those plans more concrete
so we've started a wiki page for this [2]. Comments to Me,
Kevin, Mike Demmer, Joerg Ott, and/or the list I guess.

If you'd like to take part, you're more than welcome, just
let us know. If you can help out somehow, that'd be great
(e.g. if you've some cute way to delay packets that we
can use). If you've experience of this kind of thing and
see us making a mistake we'd like to hear about that too!

Regards,
Stephen.

PS: Melissa's also updating the docs page [3] so if you've
anything to go there you may want to point that out now.
The I-D links there should be up to date in the next while.

[1] http://www3.ietf.org/meetings/67-IETF.html
[2] http://www.dtnrg.org/wiki/IETF67Interop
[3] http://www.dtnrg.org/wiki/Docs

Date: Wed, 11 Oct 2006 15:31:09 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>, Ted Hardie <[email-masked]>
Subject: [dtn-interest] A late comment on the DTN arch
Sender: [email-masked]

Hi all,

During the IRSG review of the DTN arch. I-D we got a comment from Ted
Hardie that the authors wanted to address. His comment's below, and
the resolution proposed is to clarify section 3.3.2 is below that again.

If, as I hope, this is non-controversial, it should be ok to make
the change during AUTH-48. (Leigh may however issue a -07 with this
change if he has time.)

But do say if you've a problem with this that really has to be fixed.

(You can just send mail to Leigh if you've some wordsmithing
suggestions.)

Thanks,
Stephen.

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

Ted's comment:

...I've done a quick review of the document,
and I am somewhat concerned by the discussion of URIs/EIDs. ...

In practice, URIs are split into two broad classes.  The first class
is used solely as identifiers, with no expectation that they need to
be dereferenced to function as identifiers.  URNs are a sub-class
of this class, and they provide specific properties for their namespaces
(e.g. that that they persistent).  Other URIs are, however, used in
similar ways (XML namespace declarations, for example, may be any URI
scheme, and there is no general expectation that there be any data at
the URI).

The other usage invokes protocol processing.  While schemes like
http, ftp, or snmp: may be used as pure identifiers, they may (and in
the usual case do) invoke a set of protocol handlers that retrieve,
post, or otherwise engage in protocol-specific processing.  For those
that fall into this class, the design of a scheme has to carefully match
the actual protocol semantics which are to be exposed.

Reading through the description EIDs, it was not clear to me which
of these properties DTN would be counting on.  At one level, you appear
to want simply to be able to construct identifiers with a known but
flexible format. But this text, among others, seems to indicate that you
are looking to design schemes that invoke specific protocol processors:

    It is the responsibility of a scheme designer to define how to
    interpret the SSP of an EID so as to determine whether it refers to a
    unicast, multicast or anycast set of nodes

I am not aware of any URI scheme which currently distinguishes
between unicast and anycast service, and this might be a significant
challenge, since the "shared unicast" nature of anycast is (in the
Internet environment) opaque to the end node.  There are
application-layer schemes which distinguish between specific transport
protocols (e.g. soap.beep vs. soap.beeps), but others, including HTTP,
do not presume the underlying transport and do not change the
identifiers with the transport (see the work on upgrading to TLS within
HTTP in 2817).

Part of my confusion may arise in the discussion of late binding.
The late binding discussion seems to indicate that the EID/URIs are
passed around as identifiers within bundles, but that at some late stage
shift roles to protocol invocation.    So the "registration" uses URIs
as identifiers, if I understood the document correctly, but at late
binding moment, the scheme is used to invoke a specific protocol for
processing.  Is that substantially correct?

I understand, of course, that the details of the URI/EID mechanisms
are not likely to be in this document.  But I believe some additional
text might be added to clarify the basic connection, and to indicate the
extent to which schemes designed for use in this environment will be
specific to its binding and resolution mechanisms.
...

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

New proposed text for 3.3.2:

Late Binding

Binding means interpreting the SSP of an EID for the purpose of carrying 
an associated message towards a destination.  For example, binding might 
require mapping an EID to a next hop EID or to a lower-layer address for 
transmission.  "Late binding" means that the binding of a message 
destination to a partiular destination Node does not necessarily happen 
at the source.  Because the destination EID is potentially re-bound at 
each hop, the binding between a destination EID and a particular 
destination node may occur at the source, during transit, or only at the 
destination node itself.  This contrasts with the name-to-address 
binding of Internet communications where a DNS lookup at the source 
fixes the IP address of the destination node before data is sent.  Such 
a circumstance would be considered "early binding" because the 
name-to-address translation is performed prior to data being sent into 
the network.

In a frequently-disconnected network, late binding may be advantageous 
because the transit time of a message may exceed the validity time of a 
binding, making binding at the source impossible. Furthermore, use of 
name-based routing with late binding may reduce the amount of 
administrative (mapping) information that must propagate through the 
network, and may also limit the scope of mapping synchronization 
requirements to a local topological neighborhood of its origin.

Date: Thu, 05 Oct 2006 16:08:01 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] updated security drafts
Sender: [email-masked]

Just FYI. Since they'd expired I refreshed the bundle security
drafts [1,2] with no substantive changes at all.

S.

[1] 
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-security-02.txt
[2] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sec-overview-02.txt

Date: Thu, 05 Oct 2006 09:18:07 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] A bundle protocol RFC
Sender: [email-masked]

Keith, Scott,

(Acting on my own call for comments:-)

I believe that the -06 version of the bundle spec is very
much ready to go for IRSG review.

I've one possibly substantive comment, that is, however,
procedural, rather than technical:

- Someone could reasonably argue that the security protocol
   has to be a normative reference, which would be ok except
   it might have the effect of probably holding up the BP
   spec in the RFC editor queue until the security protocol
   catches up. A few months ago I'd have seen that as a bit
   of a problem, but now that people are coding up the
   security stuff, I think its less of an issue. I guess the
   counterargument is that the security stuff is optional to
   implement - so maybe just making that clearer in the
   security considerations section would be ok.

Some nits that can be fixed along the way (i.e. during or
after the IRSG review)

- The TOC is broken
- Some of the ascii art spacing is wrong (e.g. figure 2)
- Some headings are odd (e.g. 4.8, 4.10.1)
- Pagination @ p32/33 is odd and ascii art broken too
- Section 8 - the iana registration exists now & should
   be referenced (maybe even copy in the registration
   info - others do that)
- Different reference formats for normative and informative
   is odd, e.g "[
- RFC 2119 (MUSTSHOULD) can't be informative can it?
- I-D references could be updated

Regards,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-06.txt

Date: Wed, 04 Oct 2006 22:15:01 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] A bundle protocol RFC
Sender: [email-masked]

Folks,

The DTN architecture draft is now well on its way to being an
RFC and we think that its about time for the bundle protocol
to follow.

So, can you please take some time to re-read the bundle
protocol draft [1] and say whether you think it is, or is
not, ready to become an experimental RFC.

Please try to do that by Friday week, October 13th. (The
short duration for this is because this is the 2nd time
we've done this - 1st was back in February [2].)

BTW, its quite ok to say "its ready and here are a few nits
and typos to fix along the way..."

Thanks,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-06.txt
[2] 
http://mailman.dtnrg.org/pipermail/dtn-interest/2006-February/002101.html

Date: Tue, 03 Oct 2006 22:44:45 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] [Fwd: 67th IETF - Hotels]
Sender: [email-masked]

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

FYI for those heading to San Diego.

Not being in the main hotels is a bit of a pain at this venue.

S.

--------------050407030104010001030204
Content-Type: message/rfc822;
 name="67th IETF - Hotels"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="67th IETF - Hotels"

To: IETF Announcement list <[email-masked]>
From: IETF Secretariat <[email-masked]>
Date: Tue, 03 Oct 2006 15:50:59 -0400
Cc: [email-masked], [email-masked]
Subject: 67th IETF - Hotels 

San Diego is approaching fast!

One problem with the upcoming event in San Diego is that the city will be
under siege of a citywide convention.  This means hotel rooms are very
scarce and immediate action should be taken:

It is strongly suggested that you book your rooms now.  Here are some
suggestions to help you with your accommodations:

1.  Keep checking with the main hotels (Sheraton and Hilton).  While
the IETF block is technically full, the hotels may still be taking
reservations.  Also it is typical for some rooms to be cancelled resulting
in additional openings.  Given the island setting of this venue, it would
be best to be on the island.

2.  Overflow hotels have been arranged and are within five miles (15
minutes by cab).  All have agreed to favorable rates especially given the
high demand for the rooms.  Information on two additional hotels has been
added to the IETF website: http://www.ietf.org/meetings/67-hotels.html. We
will continue to update the site as more hotel rooms are secured.

3.  Travelocity, Expedia and Orbits all show rooms that are available.

Please act now, as rooms will become harder to get and a lot more
expensive as we approach the meeting.  Also for those of you who have not
attended this event in San Diego in the past, our main venue is on an
island so the longer you wait the farther away you will be.

REMINDER: Early-Bird registration cut-off is Friday, October 27, 2006. 
You can register for the IETF Meeting at:
http://www.ietf.org/meetings/67-IETF.html

--------------050407030104010001030204--

Reply-To: <[email-masked]>
From: "Kevin Fall" <[email-masked]>
To: "DTN" <[email-masked]>
Date: Mon, 2 Oct 2006 09:35:51 -0700
Organization: Intel Research Berkeley
Subject: [dtn-interest] IETF schedule - DTNRG on thursday Nov 9
Sender: [email-masked]

See draft agenda here:

http://www.ietf.org/meetings/67-agenda.txt