Subject: [dtn-interest] Re: underwater networking
From: Lloyd Wood <[email-masked]>
To: <[email-masked]>
Date: Sat, 29 Apr 2006 22:13:15 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

At Saturday 2006-04-29 08:17 -0700, Fall, Kevin wrote:
 > Ok, the conference you have all been waiting for---
 >
 > http://wuwnet.engr.uconn.edu/

Cool. Any papers describing work with NEEMO, including the recent 
tele-robotic underwater surgery:
ftp://ftp-eng.cisco.com/lwood/neemo/README.html  (requires passive 
ftp on in IE)
would be of particular interest.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood><[email-masked]> 

Content-class: urn:content-classes:message
Date: Sat, 29 Apr 2006 08:17:32 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] underwater networking
Sender: [email-masked]

Ok, the conference you have all been waiting for---

http://wuwnet.engr.uconn.edu/

- Kevin

Content-class: urn:content-classes:message
Date: Fri, 28 Apr 2006 22:07:21 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Berkeley DTNRG meeting May 16/17
Sender: [email-masked]

DTNRG Meeting
Intel Berkeley Lab
May 16-17, 2006
9am - 5pm each day

Address:

2150 Shattuck Ave., #1300
Berkeley CA 94704
Admin: +1 (510) 495-3056	Amrita Lokre
				([email-masked])

Nearest airport: OAK
Next nearest: SFO (you can ride BART directly from this airport to our
front door in about 1:15 time).

We are located on the top floor of the "Powerbar" building right at the
downtown Berkeley BART station {so-labeled due to the big sign outside
on the face of the building}.  Take the elevator to the "PH" floor.
See http://www.intel-research.net/berkeley/index.asp for more.
We do not have a selection of good hotels nearby our facility.  The best
options are likely to be the UC Berkeley faculty club or the DoubleTree
in the Berkeley marina (about 15 minute drive, but I think they have
govt rates).  Hotel Durant is another possibility (about a 20 min walk
or
6 min drive).

I am planning to arrange for dinner on the 16th at a local restaurant
(the same one as before for those of you who have visited previously).
Please let me know if you are planning on attending.

The format for this meeting is not going to be a series of talk so much
as an open forum of discussion.  The topics are listed below, so if you
would like to change them, please let me know.

Topics for discussion:

Multicast

	please see Susan Symington's note to dtn-interest from 2/28/2006
	as well as her ID for background
	
http://www.ietf.org/internet-drafts/draft-symington-bundle-multicast-non
custodial-00.txt

	one of the issues here is what is required in terms of a
	'previous hop' indicator
	in bundles, and if such a thing constructed would it be
	in the bundle spec, be optional, or what

	another unresolved issue is whether support for multicast
	forwarding is a required feature (even if not turned on or
	even if a dtn router doesn't have a multicast routing
	protocol running)

	an issue potentially overlapping both multicast and application
	API is just how an application expresses its desire to join a
	group, and when

Router API

	this will be a review (lead by MITRE) regarding their
	work on the router API.  That is, an API on the "side" of a
	dtn agent that supports routing plug-ins.  This is currently
	being pursued via an IPC mechanism in order to support
	routing decision processes that
	are not necessarily in the same address space as the forwarding
agent

Application API

	this relates to the current state of the DTN API primarily
	as supported in the reference implementation.  The particular
	feature that allows for an application to 'confirm success'
(causing the underlying system to create a special associated status
report)
	is not presently implemented

"Custody request" operation vs routing updates

	a recent discussion has revealed some issues around
	the question as to what happens when a node
	(possibly custodian) wishes to move its message to somebody
	else temporarily and possibly retrieve it later.
	Currently the custody transfer
	capability is sender (push) based with no support for
	"pull based" operations.
	Such pull based operations might be implemented either at the
	DTN layer (new signal) or maybe by 'adjusting' the underlying
	routing to entice another node to wish to transfer messages
	(and thus custody) to the node providing the update.  The
	best way to do all of this remains unresolved and barely
discussed.

thanks,
- Kevin

Date: Thu, 27 Apr 2006 16:37:48 -0400 (Eastern Daylight Time)
From: Sandra Murphy <[email-masked]>
To: "Bush, Jeff" <[email-masked]>
cc: [email-masked]
Subject: RE: [dtn-interest] save the date: May 16/17 in Berkeley
Sender: [email-masked]

Sorry for responding to my own message.  But I thought to check other 
working groups and found one that seems to have the same problem, so it is 
more likely an IETF staff issue.  I'll report it.

--Sandy

On Thu, 27 Apr 2006, Sandra Murphy wrote:

> Ah, thanks.  I did not connect the dots.  Sorry.
>
> Incidentally, I don't know if this is a dtnrg issue or an IETF staff issue, 
> but the presentations in the proceedings (that I've checked) have a link to 
> the ppt version that does not work.  The link ends in a lower case file name 
> and the directory has an upper case file name.  I.e.,
>
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-17/dtnrg-17.ppt (fail)
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-17/DTNRG-17.ppt (work)
>
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-5/dtnrg-5.ppt (fail)
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-5/DTNRG-5.ppt (work)
>
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-7/dtnrg-7.ppt (fail)
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-7/DTNRG-7.ppt (work)
>
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-16/dtnrg-16.ppt (fail)
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-16/DTNRG-16.ppt (work)
>
> --Sandy
>
> On Thu, 27 Apr 2006, Bush, Jeff wrote:
>
>> The "router API" relates to the DTN2 RI interface architecture
>> presented at the last DTNRG meeting in Dallas.  A presentation is
>> available here:
>> 
>> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-4/sld1.htm
>> 
>> Benefits:
>> 
>> - Plug-in modules can be written in any language capable of processing
>> XML messages
>> - No need for algorithms employed in plug-in modules to be divulged
>> - DTN2 RI can be enhanced while the "core" bundle forwarder remains
>> stable
>> - Addition and removal of DTN capabilities (e.g. routers, convergence
>> layers, etc.) on a running bundle forwarder is possible
>> - Testing of new capabilities is simplified
>> 
>> An implementation of the router interface will be available shortly.
>> The plan is to have a draft router interface specification ready by the
>> Berkeley meeting.
>> 
>> Jeff
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Sandra
>> Murphy
>> Sent: Thursday, April 27, 2006 12:10 PM
>> To: Fall, Kevin
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley
>> 
>> Can you say anything about the "router API" or point me to any
>> documents?
>> I'm not certain if you mean an API by which an intermediate node
>> serving
>> as a *router* might be queried (maybe something like "do you have a
>> route
>> to site X / a direct connection to site X" or "how heavily loaded are
>> you") or an API with which the *routing* could be
>> requested/signalled/etc
>> ("the measure of the route to site X through neighbor Q just changed to
>> 
>> N", "dear neighbor: I just lost my connection to site X").
>> 
>> --Sandy
>> 
>> On Tue, 18 Apr 2006, Fall, Kevin wrote:
>> 
>>> There will be a face to face DTN meeting at the Intel Berkeley lab
>> May
>>> 16 and 17.  Major topics: multicast, application API, router API.
>> More
>>> to come...
>>> 
>>> - K
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>> 
>

Date: Thu, 27 Apr 2006 16:28:57 -0400 (Eastern Daylight Time)
From: Sandra Murphy <[email-masked]>
To: "Bush, Jeff" <[email-masked]>
cc: [email-masked]
Subject: RE: [dtn-interest] save the date: May 16/17 in Berkeley
Sender: [email-masked]

Ah, thanks.  I did not connect the dots.  Sorry.

Incidentally, I don't know if this is a dtnrg issue or an IETF staff 
issue, but the presentations in the proceedings (that I've checked) have a 
link to the ppt version that does not work.  The link ends in a lower case 
file name and the directory has an upper case file name.  I.e.,

http://www3.ietf.org/proceedings/06mar/slides/DTNRG-17/dtnrg-17.ppt (fail)
http://www3.ietf.org/proceedings/06mar/slides/DTNRG-17/DTNRG-17.ppt (work)

http://www3.ietf.org/proceedings/06mar/slides/DTNRG-5/dtnrg-5.ppt (fail)
http://www3.ietf.org/proceedings/06mar/slides/DTNRG-5/DTNRG-5.ppt (work)

http://www3.ietf.org/proceedings/06mar/slides/DTNRG-7/dtnrg-7.ppt (fail)
http://www3.ietf.org/proceedings/06mar/slides/DTNRG-7/DTNRG-7.ppt (work)

http://www3.ietf.org/proceedings/06mar/slides/DTNRG-16/dtnrg-16.ppt (fail)
http://www3.ietf.org/proceedings/06mar/slides/DTNRG-16/DTNRG-16.ppt (work)

--Sandy

On Thu, 27 Apr 2006, Bush, Jeff wrote:

> The "router API" relates to the DTN2 RI interface architecture
> presented at the last DTNRG meeting in Dallas.  A presentation is
> available here:
>
> http://www3.ietf.org/proceedings/06mar/slides/DTNRG-4/sld1.htm
>
> Benefits:
>
> - Plug-in modules can be written in any language capable of processing
> XML messages
> - No need for algorithms employed in plug-in modules to be divulged
> - DTN2 RI can be enhanced while the "core" bundle forwarder remains
> stable
> - Addition and removal of DTN capabilities (e.g. routers, convergence
> layers, etc.) on a running bundle forwarder is possible
> - Testing of new capabilities is simplified
>
> An implementation of the router interface will be available shortly.
> The plan is to have a draft router interface specification ready by the
> Berkeley meeting.
>
> Jeff
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sandra
> Murphy
> Sent: Thursday, April 27, 2006 12:10 PM
> To: Fall, Kevin
> Cc: [email-masked]
> Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley
>
> Can you say anything about the "router API" or point me to any
> documents?
> I'm not certain if you mean an API by which an intermediate node
> serving
> as a *router* might be queried (maybe something like "do you have a
> route
> to site X / a direct connection to site X" or "how heavily loaded are
> you") or an API with which the *routing* could be
> requested/signalled/etc
> ("the measure of the route to site X through neighbor Q just changed to
>
> N", "dear neighbor: I just lost my connection to site X").
>
> --Sandy
>
> On Tue, 18 Apr 2006, Fall, Kevin wrote:
>
>> There will be a face to face DTN meeting at the Intel Berkeley lab
> May
>> 16 and 17.  Major topics: multicast, application API, router API.
> More
>> to come...
>>
>> - K
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] save the date: May 16/17 in Berkeley
Date: Thu, 27 Apr 2006 13:05:33 -0400
From: "Bush, Jeff" <[email-masked]>
To: "Sandra Murphy" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

The "router API" relates to the DTN2 RI interface architecture
presented at the last DTNRG meeting in Dallas.  A presentation is
available here:

http://www3.ietf.org/proceedings/06mar/slides/DTNRG-4/sld1.htm

Benefits:

- Plug-in modules can be written in any language capable of processing
XML messages
- No need for algorithms employed in plug-in modules to be divulged
- DTN2 RI can be enhanced while the "core" bundle forwarder remains
stable
- Addition and removal of DTN capabilities (e.g. routers, convergence
layers, etc.) on a running bundle forwarder is possible
- Testing of new capabilities is simplified

An implementation of the router interface will be available shortly.
The plan is to have a draft router interface specification ready by the
Berkeley meeting.

Jeff

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sandra
Murphy
Sent: Thursday, April 27, 2006 12:10 PM
To: Fall, Kevin
Cc: [email-masked]
Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley

Can you say anything about the "router API" or point me to any
documents? 
I'm not certain if you mean an API by which an intermediate node
serving 
as a *router* might be queried (maybe something like "do you have a
route 
to site X / a direct connection to site X" or "how heavily loaded are 
you") or an API with which the *routing* could be
requested/signalled/etc 
("the measure of the route to site X through neighbor Q just changed to

N", "dear neighbor: I just lost my connection to site X").

--Sandy

On Tue, 18 Apr 2006, Fall, Kevin wrote:

> There will be a face to face DTN meeting at the Intel Berkeley lab
May
> 16 and 17.  Major topics: multicast, application API, router API.
More
> to come...
>
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 27 Apr 2006 12:10:25 -0400 (Eastern Daylight Time)
From: Sandra Murphy <[email-masked]>
To: "Fall, Kevin" <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley
Sender: [email-masked]

Can you say anything about the "router API" or point me to any documents? 
I'm not certain if you mean an API by which an intermediate node serving 
as a *router* might be queried (maybe something like "do you have a route 
to site X / a direct connection to site X" or "how heavily loaded are 
you") or an API with which the *routing* could be requested/signalled/etc 
("the measure of the route to site X through neighbor Q just changed to 
N", "dear neighbor: I just lost my connection to site X").

--Sandy

On Tue, 18 Apr 2006, Fall, Kevin wrote:

> There will be a face to face DTN meeting at the Intel Berkeley lab May
> 16 and 17.  Major topics: multicast, application API, router API.  More
> to come...
>
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

To: "DTN Interest" <[email-masked]>
From: "Melissa Ho" <[email-masked]>
Date: Thu, 27 Apr 2006 01:09:58 -0700
Subject: [dtn-interest] ICTD2006 Conference Early Registration Deadline 5/10
Sender: [email-masked]

Please join us for the 2006 International Conference on Information
Communications and Development on Thursday, May 25 and Friday May 26,
2006, hosted by the University of California, Berkeley School of
Information.

ICTD2006 is a multi-disciplinary forum for researchers designing
information and communications technologies for developing regions. The
conference presents the state-of-the-art ICTD research by social and
technical scientists with original, peer-reviewed papers, a poster
session, breakout sessions and keynote addresses by leading scholars in
the field.

Conference Program and Registration are available online at:
     http://www.sims.berkeley.edu/ictd2006/

Early Bird Registration ends May 10, and is $200/40/60 for
standard/student/student+banquet.
After this deadline, registration is $300/50/75.

We are recruiting volunteers (fees will be waived). If you are interested,
please send me ([email-masked]) an email.

Keynote Speakers:
     Brij Kothari, Founder, PlanetRead
     Anaya Roy, Associate Dean, International Area Studies and
        Assistant Professor, City and Regional Planning, UC Berkeley
     Zhuwei Xu, Professor and Deputy Directory of the Institute of Computing
        Technology, Chinese Academy of Sciences

When: May 25 and 26, 2006
Where: South Hall and Sibley Auditorium, University of California, Berkeley

Sponsors:
     Microsoft Research India
     Siemens Corporate Technology, China
     UC Berkeley School of Information
     IEEE

Melissa Ho

From: =?iso-8859-1?Q?Jos=E9_Santiago?= <[email-masked]>
To: <[email-masked]>
Date: Wed, 26 Apr 2006 14:06:00 +0100
Importance: Normal
Subject: [dtn-interest] DTN - multicast
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C6693A.8C5AFA30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

ih,

    As a student, I need to simulate a protocol aiming DTN-multicast. I have
chosen the DTN-simulator, by Sushant Jain, to test the protocol. However, I
couldn’t find examples of how to work with it. And I couldn’t get a manual
too. In addition, am not used with Java. Can someone help? Or, is there a
better simulator for this purpose? It would be very kind of you let me know.
Many tanks in advance.

Jsantiago.

------=_NextPart_000_0019_01C6693A.8C5AFA30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-GB style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>ih,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </span>As =
a</span></font></span><span
class=3DEmailStyle15><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;mso=
-ansi-language:
EN-US'> student</span></font></span><span class=3DEmailStyle15><font =
size=3D2
color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;
font-family:Arial'>, I need to simulate a protocol aiming DTN-multicast. =
I have
chosen the DTN-simulator, by Sushant Jain, to test the protocol. =
However, I
couldn&#8217;t find examples of how to work with it. And I =
couldn&#8217;t get a manual too.
In addition, am not used with Java. Can someone help? Or, is there a =
better
simulator for this purpose? It would be very kind of you let me know. =
Many
tanks in advance.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'>Jsantiago.<o:p></o:p></span></font></span></p>

</div>

</body>

</html>

------=_NextPart_000_0019_01C6693A.8C5AFA30--

Date: Tue, 25 Apr 2006 10:46:21 +0200
From: "Gerardo Izquierdo" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

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

Hi Wesley

I've been working a bit more with the code and found why it works even if i=
t
returns the null string.

Problem is that an empty null-terminated string consist in just an 0x00 wic=
h
can be read as an SNDV of value 0.

Perhaps we can have troubles in systems wich encodes the string in a
different way.

In fact, the length of the string encoding a SNDV with it's 7 final bits
equal to 0 will be different in lenguajes using null-terminated strings
(length -1)

That is not a problem itself, but we should be aware in order to avoid
problems when we convert null-terminated strings to non null-terminated
strings.
By example in Borland Pascal lets be Cstring a null-terminated string and
PString a Pascal style string, then if Cstring contains an SNDV you should
code the conversion carefully

Pstring :=3D StrPas(Cstring); {Built-in function to convert between
null-terminated strings and Pascal-style strings}
if ord(Pstring[Length(Pstring)])>127  {if the high-order bit of the last
byte is 1}
   then Pstring :=3D Pstring + chr(0);   {then append a 0x00}

Also, if using null-terminated-strings, when constructing the headers, it's
possible to have problems with an extra byte to 0x00

Please if anyone thinks this subject is too much specific for the list, fee=
l
free in sending me a direct-email.

(And yes, I program mainly in Pascal, and yes, I'm a fossil 8-D )

Gerardo

On 4/24/06, Wesley Eddy <[email-masked]> wrote:
>
> On Mon, Apr 24, 2006 at 05:28:43PM +0200, Gerardo Izquierdo wrote:
> > I think the python Source Code about SNDV is  a bit incorrect
>
> You're right, thanks.  I think maybe the draft should state that the code
> is just for demonstration purposes, and that (for example) the C++ SDNV
> code in the DTN2 implementation should more similar to what people
> actually
> use in production.  That said, it is also important the the code be
> correct
> in this document.
>
> > sdnv_encode does not encode well the value 0 (0x00), it returns an empt=
y
> > string
> >
> > I haven't never programmed in python, but I think we should add a line
> just
> > before the
> > return r
> >
> >
> > if type(n) =3D=3D type(1) and n =3D 0:
> >    r =3D chr (0x00)
> >
>
> Instead of doing this, I changed the looping construct to always execute
> at least once:
>    done =3D False
>    while not done:
>      # encode lowest 7 bits from n
>      newbits =3D n & 0x7F
>      n =3D n>>7
>      r =3D chr(newbits + flag) + r
>      if flag =3D=3D 0:
>        flag =3D 0x80
>      if n =3D=3D 0:
>        done =3D True
>
>
> > also, there is no reference to the optional parameter slen in
> sdnv_decode
> > but in the parameter declaration.
>
> The line:
>    elif i =3D=3D len(s)-1:
> should be:
>    elif i =3D=3D len(s)-1 or i > slen:
>
> These will be fixed in the next update.  Thanks.
>
> -Wes
>
> --
> Wesley M. Eddy
> Verizon Federal Network Systems
>
>
>

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

<div>Hi Wesley</div>
<div>&nbsp;</div>
<div>I've been working a bit more with the code and found why it works even=
 if it returns the null string.</div>
<div>&nbsp;</div>
<div>Problem is that an empty null-terminated string consist in just an 0x0=
0 wich can be read as an SNDV of value 0.</div>
<div>&nbsp;</div>
<div>Perhaps we can have troubles in systems wich encodes the string in a d=
ifferent way.</div>
<div>&nbsp;</div>
<div>In fact, the length of the string encoding a SNDV with it's 7 final bi=
ts equal to 0 will be different in lenguajes using null-terminated strings =
(length -1)</div>
<div>&nbsp;</div>
<div>That is not a problem itself, but we should be&nbsp;aware in order to =
avoid problems when we convert null-terminated strings to non null-terminat=
ed strings. </div>
<div>By example in Borland Pascal lets be Cstring a null-terminated string =
and PString a Pascal style string, then if Cstring contains an SNDV you sho=
uld code the conversion carefully</div>
<div>&nbsp;</div>
<div>Pstring :=3D StrPas(Cstring); {Built-in function to convert between nu=
ll-terminated strings and Pascal-style strings}</div>
<div>if ord(Pstring[Length(Pstring)])&gt;127&nbsp; {if the high-order bit o=
f the last byte is 1}</div>
<div>&nbsp;&nbsp; then Pstring :=3D Pstring + chr(0);&nbsp;&nbsp; {then app=
end a 0x00}<br>&nbsp;</div>
<div>Also, if using null-terminated-strings, when constructing the headers,=
 it's possible to have problems with an extra byte to 0x00</div>
<div>&nbsp;</div>
<div>Please if anyone thinks this subject is too much specific for the list=
, feel free in sending me a direct-email.</div>
<div>&nbsp;</div>
<div>(And yes, I program mainly in Pascal, and yes, I'm a fossil 8-D )</div=
>
<div>&nbsp;</div>
<div>Gerardo<br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 4/24/06, <b class=3D"gmail_sendername">=
Wesley Eddy</b> &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
v</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Mon, Apr 24, 2006 at 05:28:43=
PM +0200, Gerardo Izquierdo wrote:<br>&gt; I think the python Source Code a=
bout SNDV is&nbsp;&nbsp;a bit incorrect
<br><br>You're right, thanks.&nbsp;&nbsp;I think maybe the draft should sta=
te that the code<br>is just for demonstration purposes, and that (for examp=
le) the C++ SDNV<br>code in the DTN2 implementation should more similar to =
what people actually
<br>use in production.&nbsp;&nbsp;That said, it is also important the the c=
ode be correct<br>in this document.<br><br>&gt; sdnv_encode does not encode=
 well the value 0 (0x00), it returns an empty<br>&gt; string<br>&gt;<br>&gt=
; I haven't never programmed in python, but I think we should add a line ju=
st
<br>&gt; before the<br>&gt; return r<br>&gt;<br>&gt;<br>&gt; if type(n) =3D=
=3D type(1) and n =3D 0:<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;r =3D chr (0x00)<br=
>&gt;<br><br>Instead of doing this, I changed the looping construct to alwa=
ys execute<br>at least once:
<br>&nbsp;&nbsp; done =3D False<br>&nbsp;&nbsp; while not done:<br>&nbsp;&n=
bsp;&nbsp;&nbsp; # encode lowest 7 bits from n<br>&nbsp;&nbsp;&nbsp;&nbsp; =
newbits =3D n &amp; 0x7F<br>&nbsp;&nbsp;&nbsp;&nbsp; n =3D n&gt;&gt;7<br>&n=
bsp;&nbsp;&nbsp;&nbsp; r =3D chr(newbits + flag) + r<br>&nbsp;&nbsp;&nbsp;&=
nbsp; if flag =3D=3D 0:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; flag =3D 0x=
80<br>&nbsp;&nbsp;&nbsp;&nbsp; if n =3D=3D 0:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; done =3D True<br><br><br>&gt; also=
, there is no reference to the optional parameter slen in sdnv_decode<br>&g=
t; but in the parameter declaration.<br><br>The line:<br>&nbsp;&nbsp; elif =
i =3D=3D len(s)-1:<br>should be:<br>&nbsp;&nbsp; elif i =3D=3D len(s)-1 or =
i &gt; slen:
<br><br>These will be fixed in the next update.&nbsp;&nbsp;Thanks.<br><br>-=
Wes<br><br>--<br>Wesley M. Eddy<br>Verizon Federal Network Systems<br><br><=
br></blockquote></div><br>

------=_Part_30255_8221008.1145954781606--

Date: Mon, 24 Apr 2006 11:57:11 -0400
From: Wesley Eddy <[email-masked]>
To: Gerardo Izquierdo <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Reply-To: [email-masked]
Sender: [email-masked]

--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 24, 2006 at 05:28:43PM +0200, Gerardo Izquierdo wrote:
> I think the python Source Code about SNDV is  a bit incorrect

You're right, thanks.  I think maybe the draft should state that the code
is just for demonstration purposes, and that (for example) the C++ SDNV
code in the DTN2 implementation should more similar to what people actually
use in production.  That said, it is also important the the code be correct
in this document.
=20
> sdnv_encode does not encode well the value 0 (0x00), it returns an empty
> string
>=20
> I haven't never programmed in python, but I think we should add a line ju=
st
> before the
> return r
>=20
>=20
> if type(n) =3D=3D type(1) and n =3D 0:
>    r =3D chr (0x00)
>

Instead of doing this, I changed the looping construct to always execute
at least once:
    done =3D False
    while not done:
      # encode lowest 7 bits from n
      newbits =3D n & 0x7F
      n =3D n>>7
      r =3D chr(newbits + flag) + r
      if flag =3D=3D 0:
        flag =3D 0x80
      if n =3D=3D 0:
        done =3D True

> also, there is no reference to the optional parameter slen in sdnv_decode
> but in the parameter declaration.

The line:
    elif i =3D=3D len(s)-1:
should be:
    elif i =3D=3D len(s)-1 or i > slen:

These will be fixed in the next update.  Thanks.

-Wes

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--G4iJoqBmSsgzjUCe
Content-Type: application/pgp-signature
Content-Disposition: inline

--G4iJoqBmSsgzjUCe--

Date: Mon, 24 Apr 2006 17:28:43 +0200
From: "Gerardo Izquierdo" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

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

Hi people.

I think the python Source Code about SNDV is  a bit incorrect

sdnv_encode does not encode well the value 0 (0x00), it returns an empty
string

I haven't never programmed in python, but I think we should add a line just
before the
return r

if type(n) =3D=3D type(1) and n =3D 0:
   r =3D chr (0x00)

also, there is no reference to the optional parameter slen in sdnv_decode
but in the parameter declaration.

On 4/21/06, Wesley Eddy <[email-masked]> wrote:
>
> A new internet-draft on SDNVs has been published:
> http://roland.grc.nasa.gov/~weddy/shared/dtn/draft-eddy-dtn-sdnv-00a.txt
>
> This might be interesting to a few participants in the RG.
>
> Abstract:
>   Self-Delimiting Numeric Values (SDNVs) have recently been introduced
>   as fields used in proposed Delay-Tolerant Networking protocols.  The
>   basic goal of an SDNV is to hold a positive integer value of
>   arbitrary magnitude, without consuming much more space than
>   necessary.  This can be desirable in allowing protocol header fields
>   to evolve as appropriate for a given use, without making difficult
>   and potentially erroneous engineering decisions that may have to be
>   hacked around in the future.  This document describes formats and
>   algorithms for SDNV encoding and decoding, and discusses several
>   other aspects of SDNVs.
>
> --
> Wesley M. Eddy
> Verizon Federal Network Systems
>
>
>

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

<div>Hi people.</div>
<div>&nbsp;</div>
<div>I think the python Source Code about SNDV is&nbsp; a bit incorrect</di=
v>
<div>&nbsp;</div>
<div>sdnv_encode does not encode well the value 0 (0x00), it returns an emp=
ty string</div>
<div>&nbsp;</div>
<div>I haven't never programmed in python, but I think we should add a line=
 just before the</div>
<div>return r</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>if type(n) =3D=3D type(1) and n =3D 0:</div>
<div>&nbsp;&nbsp; r =3D chr (0x00)</div>
<div>&nbsp;</div>
<div>also, there is no reference to the optional parameter slen in sdnv_dec=
ode but in the parameter declaration. <br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 4/21/06, <b class=3D"gmail_sendername">=
Wesley Eddy</b> &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
v</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">A new internet-draft on SDNVs ha=
s been published:<br><a href=3D"http://roland.grc.nasa.gov/~weddy/shared/dt=
n/draft-eddy-dtn-sdnv-00a.txt">
http://roland.grc.nasa.gov/~weddy/shared/dtn/draft-eddy-dtn-sdnv-00a.txt</a=
><br><br>This might be interesting to a few participants in the RG.<br><br>=
Abstract:<br>&nbsp;&nbsp;Self-Delimiting Numeric Values (SDNVs) have recent=
ly been introduced
<br>&nbsp;&nbsp;as fields used in proposed Delay-Tolerant Networking protoc=
ols.&nbsp;&nbsp;The<br>&nbsp;&nbsp;basic goal of an SDNV is to hold a posit=
ive integer value of<br>&nbsp;&nbsp;arbitrary magnitude, without consuming =
much more space than<br>&nbsp;&nbsp;necessary.&nbsp;&nbsp;This can be desir=
able in allowing protocol header fields
<br>&nbsp;&nbsp;to evolve as appropriate for a given use, without making di=
fficult<br>&nbsp;&nbsp;and potentially erroneous engineering decisions that=
 may have to be<br>&nbsp;&nbsp;hacked around in the future.&nbsp;&nbsp;This=
 document describes formats and<br>&nbsp;&nbsp;algorithms for SDNV encoding=
 and decoding, and discusses several
<br>&nbsp;&nbsp;other aspects of SDNVs.<br><br>--<br>Wesley M. Eddy<br>Veri=
zon Federal Network Systems<br><br><br></blockquote></div><br>

------=_Part_18061_19577987.1145892523486--

Date: Fri, 21 Apr 2006 14:15:38 -0400
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Reply-To: [email-masked]
Sender: [email-masked]

--Cgrdyab2wu3Akvjd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 21, 2006 at 11:03:16AM -0700, Scott Burleigh wrote:
> Maybe the SDNV I-D should state more explicitly that the purpose of this=
=20
> representation is to economize on storage space (and/or transmission=20
> time) while not precluding the use of large numbers.  That point may not=
=20
> come across clearly enough.
>=20

Agree, this can be fixed in an update.  FWIW, the text in the BP and LTP
specs is fairly clear on this:
"""
   The design of the bundle protocol attempts to reconcile minimal=20
   consumption of transmission bandwidth with:=20
      o extensibility to address requirements not yet identified, and=20
      o scalability across a wide range of network scales and payload=20
        sizes.=20
"""

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--Cgrdyab2wu3Akvjd
Content-Type: application/pgp-signature
Content-Disposition: inline

--Cgrdyab2wu3Akvjd--

Date: Fri, 21 Apr 2006 11:03:16 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

Lloyd Wood wrote:

> At Friday 2006-04-21 08:59 -0700, Scott Burleigh wrote:
>
>> Wesley Eddy wrote:
>>
>>> On Fri, Apr 21, 2006 at 04:05:26PM +0100, Lloyd Wood wrote:
>>>
>>>> I'm stunned by the complexity of this draft. what's wrong with a byte
>>>> saying how many bytes store the number, and then the number?
>>>
>> Mainly, I think, that for numeric values less than 128 you'd spend 
>> more bits on expressing the length of the number than on expressing 
>> its value.
>>
>> For numeric values that can be expressed in fewer than 50 bits, a 
>> representation that uses one bit of meta-number per seven bits of 
>> numeric value can impose significantly less overhead than the 
>> alternative you're suggesting.
>
> For numeric values that can be expressed in fewer than 50 bits, we 
> have a whole host of other alternatives. 64-bit long longs are not 
> unheard of.

Certainly we do, some of which are even more expensive than your 
original proposal.  For example, if we use a 64-bit long long instead of 
an SDNV then we express the number 16383 as

00000000 00000000 00000000 00000000 00000000 00000000 00111111 11111111

instead of

11111111 01111111

Maybe the SDNV I-D should state more explicitly that the purpose of this 
representation is to economize on storage space (and/or transmission 
time) while not precluding the use of large numbers.  That point may not 
come across clearly enough.

Scott

Date: Fri, 21 Apr 2006 17:16:34 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

Scott Burleigh wrote:
> Stephen Farrell wrote:
> 
>> Hi Wes,
>>
>> That's great - seeing all that list discussion reduced to something
>> sensible and with code too!
>>
>> Two comments:-
>>
>> 1. I'm not sure whether it'd be wise to reference this from the
>> current documents or not. Possibly its a bit late in the game to
>> do so, but I'm not sure how others feel.
> 
> It might simplify the documents a bit, but I think it will need to wait 
> until the next round.  We've got documents going in as proposed 
> experimental RFCs, and I'm pretty sure you're not supposed to reference 
> an Internet draft from an RFC.

Yep. I tend to agree.

Stephen.

Date: Fri, 21 Apr 2006 08:59:21 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

Wesley Eddy wrote:

>On Fri, Apr 21, 2006 at 04:05:26PM +0100, Lloyd Wood wrote: 
>  
>
>>I'm stunned by the complexity of this draft. what's wrong with a byte
>>saying how many bytes store the number, and then the number?
>>
Mainly, I think, that for numeric values less than 128 you'd spend more 
bits on expressing the length of the number than on expressing its value.

For numeric values that can be expressed in fewer than 50 bits, a 
representation that uses one bit of meta-number per seven bits of 
numeric value can impose significantly less overhead than the 
alternative you're suggesting.  For example, 16383 can be encoded into 
two bytes:

11111111 01111111

instead of three:

00000010 00111111 11111111

For numeric values that can't be expressed in fewer than 57 bits, your 
approach imposes less overhead.  But the numbers that SDNVs are used for 
in the LTP and BP specs typically won't be that large.

And the code for dealing with these things doesn't have to be too 
difficult.  It's really more work explaining them than using them.

Scott

>>In eight
>>bytes that also gives you 2^56-1.  > What's wrong with the decimal
>>additions to IEEE 754r?
>>    
>>

Date: Fri, 21 Apr 2006 11:22:46 -0400
From: Wesley Eddy <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Reply-To: [email-masked]
Sender: [email-masked]

--Q0rSlbzrZN6k9QnT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 21, 2006 at 04:05:26PM +0100, Lloyd Wood wrote:
>=20
> So you can't store zero? (note positive !=3D non-negative, which the=20
> draft also mentions)
>

Non-negative is more correct, since and SDNV can hold 0.  That ambiguity
should be cleared up in a next revision.
=20
> I'm stunned by the complexity of this draft. what's wrong with a byte
> saying how many bytes store the number, and then the number? In eight
> bytes that also gives you 2^56-1.  > What's wrong with the decimal
> additions to IEEE 754r?

There have been several discussions on this mailing list regarding the
SDNV format, and it has been defined in the BP and LTP drafts for some
time.  Do you think the RG needs to reopen the topic and hold up on the
publication of the BP and LTP specs, even though the group seemed to
have consensus long ago?

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--Q0rSlbzrZN6k9QnT
Content-Type: application/pgp-signature
Content-Disposition: inline

--Q0rSlbzrZN6k9QnT--

Date: Fri, 21 Apr 2006 07:49:24 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

Stephen Farrell wrote:

> Hi Wes,
>
> That's great - seeing all that list discussion reduced to something
> sensible and with code too!
>
> Two comments:-
>
> 1. I'm not sure whether it'd be wise to reference this from the
> current documents or not. Possibly its a bit late in the game to
> do so, but I'm not sure how others feel.

It might simplify the documents a bit, but I think it will need to wait 
until the next round.  We've got documents going in as proposed 
experimental RFCs, and I'm pretty sure you're not supposed to reference 
an Internet draft from an RFC.

Scott

Date: Fri, 21 Apr 2006 09:58:31 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Reply-To: [email-masked]
Sender: [email-masked]

--4SFOXa2GPu3tIq4H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 21, 2006 at 02:39:03PM +0100, Stephen Farrell wrote:
>=20
> 2. There's one other thing that might be worth mentioning. In the
> earliest definitions SDNVs also allowed negative integers. The reason
> to change to positive-only was a security consideration - it meant
> that integer underflow attacks on the decoder were no longer a
> concern. (Many TLV implementations map the 'L' to an int and are
> potentially vulnerable in this way. A good SDNV decoder shouldn't
> have to worry.)
>=20

Thanks, I was not aware of this.  I will add a couple of sentences to
explain the reasoning against negative values in the next update.

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--4SFOXa2GPu3tIq4H
Content-Type: application/pgp-signature
Content-Disposition: inline

--4SFOXa2GPu3tIq4H--

Date: Fri, 21 Apr 2006 14:39:03 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

Hi Wes,

That's great - seeing all that list discussion reduced to something
sensible and with code too!

Two comments:-

1. I'm not sure whether it'd be wise to reference this from the
current documents or not. Possibly its a bit late in the game to
do so, but I'm not sure how others feel.

2. There's one other thing that might be worth mentioning. In the
earliest definitions SDNVs also allowed negative integers. The reason
to change to positive-only was a security consideration - it meant
that integer underflow attacks on the decoder were no longer a
concern. (Many TLV implementations map the 'L' to an int and are
potentially vulnerable in this way. A good SDNV decoder shouldn't
have to worry.)

Cheers,
Stephen.

Wesley Eddy wrote:
> A new internet-draft on SDNVs has been published:
> http://roland.grc.nasa.gov/~weddy/shared/dtn/draft-eddy-dtn-sdnv-00a.txt
> 
> This might be interesting to a few participants in the RG.
> 
> Abstract:
>    Self-Delimiting Numeric Values (SDNVs) have recently been introduced
>    as fields used in proposed Delay-Tolerant Networking protocols.  The
>    basic goal of an SDNV is to hold a positive integer value of
>    arbitrary magnitude, without consuming much more space than
>    necessary.  This can be desirable in allowing protocol header fields
>    to evolve as appropriate for a given use, without making difficult
>    and potentially erroneous engineering decisions that may have to be
>    hacked around in the future.  This document describes formats and
>    algorithms for SDNV encoding and decoding, and discusses several
>    other aspects of SDNVs.
> 

Date: Fri, 21 Apr 2006 09:27:44 -0400
From: Wesley Eddy <[email-masked]>
To: "Scott, Keith L." <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] new i-d on sdnvs
Reply-To: [email-masked]
Sender: [email-masked]

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 21, 2006 at 09:23:33AM -0400, Scott, Keith L. wrote:
> Isn't the example for encoding of 128 incorrect:

Yes :).  Thanks.=20
=20
> And a formatting suggestion, in the bit sequences it might help to
> group the bits into groups of eight and separate groups by spaces.

Agreed.  I will work in both of these comments.

--
Wesley M. Eddy
Verizon Federal Network Systems

--jRHKVT23PllUwdXP
Content-Type: application/pgp-signature
Content-Disposition: inline

--jRHKVT23PllUwdXP--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] new i-d on sdnvs
Date: Fri, 21 Apr 2006 09:23:33 -0400
From: "Scott, Keith L." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Isn't the example for encoding of 128 incorrect:

	For example:
	
	   o  1 (decimal) is represented by the bitstring "0000001" and
encoded
	      as the single byte 0x01 (in hexadecimal)
	
	   o  128 is represented by the bitstring "00000010000000" and
encoded
	      as the bytes 0x01 followed by 0x00.
	
	   o  Other values can be found in the test vectors of the
source code
	      in Appendix A
	
I would think that 128 would have to encode with a 1 in the high-order
bit of the high-order byte (to signify that it is not the last byte of
the encoded value).  Thus I would think 128 would encode as:

	0x81 0x00

And a formatting suggestion, in the bit sequences it might help to
group the bits into groups of eight and separate groups by spaces.

		--keith

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Wesley Eddy
>Sent: Friday, April 21, 2006 9:03 AM
>To: [email-masked]
>Subject: [dtn-interest] new i-d on sdnvs
>
>A new internet-draft on SDNVs has been published:
>http://roland.grc.nasa.gov/~weddy/shared/dtn/draft-eddy-dtn-sdn
>v-00a.txt
>
>This might be interesting to a few participants in the RG.
>
>Abstract:
>   Self-Delimiting Numeric Values (SDNVs) have recently been
introduced
>   as fields used in proposed Delay-Tolerant Networking protocols.
The
>   basic goal of an SDNV is to hold a positive integer value of
>   arbitrary magnitude, without consuming much more space than
>   necessary.  This can be desirable in allowing protocol header
fields
>   to evolve as appropriate for a given use, without making difficult
>   and potentially erroneous engineering decisions that may have to be
>   hacked around in the future.  This document describes formats and
>   algorithms for SDNV encoding and decoding, and discusses several
>   other aspects of SDNVs.
>
>--
>Wesley M. Eddy
>Verizon Federal Network Systems
> 

Date: Fri, 21 Apr 2006 09:02:51 -0400
From: Wesley Eddy <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] new i-d on sdnvs
Sender: [email-masked]

--7ZAtKRhVyVSsbBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

A new internet-draft on SDNVs has been published:
http://roland.grc.nasa.gov/~weddy/shared/dtn/draft-eddy-dtn-sdnv-00a.txt

This might be interesting to a few participants in the RG.

Abstract:
   Self-Delimiting Numeric Values (SDNVs) have recently been introduced
   as fields used in proposed Delay-Tolerant Networking protocols.  The
   basic goal of an SDNV is to hold a positive integer value of
   arbitrary magnitude, without consuming much more space than
   necessary.  This can be desirable in allowing protocol header fields
   to evolve as appropriate for a given use, without making difficult
   and potentially erroneous engineering decisions that may have to be
   hacked around in the future.  This document describes formats and
   algorithms for SDNV encoding and decoding, and discusses several
   other aspects of SDNVs.

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--7ZAtKRhVyVSsbBD2
Content-Type: application/pgp-signature
Content-Disposition: inline

--7ZAtKRhVyVSsbBD2--

Date: Wed, 19 Apr 2006 14:41:14 +0100
From: Stephen Farrell <[email-masked]>
To: "Fall, Kevin" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley
Sender: [email-masked]

Ooh - gotta think about budget. Will get back later.

S.

Fall, Kevin wrote:
> There will be a face to face DTN meeting at the Intel Berkeley lab May
> 16 and 17.  Major topics: multicast, application API, router API.  More
> to come...
> 
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Wed, 19 Apr 2006 09:26:05 -0400
From: "Scott, Keith L." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: I-D ACTION:draft-irtf-dtnrg-bundle-spec-05.txt
Sender: [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, April 18, 2006 6:50 PM
>To: [email-masked]
>Subject: I-D ACTION:draft-irtf-dtnrg-bundle-spec-05.txt 
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>
>
>	Title		: Bundle Protocol Specification
>	Author(s)	: K. Scott, S. Burleigh
>	Filename	: draft-irtf-dtnrg-bundle-spec-05.txt
>	Pages		: 40
>	Date		: 2006-4-18
>	
>This document describes the end-to-end protocol, header formats, and 
>abstract service description for the exchange of messages (bundles) 
>in Delay Tolerant Networking (DTN).
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-05.tx
t
>
>To remove yourself from the I-D Announcement list, send a message to 
>[email-masked] with the word unsubscribe in the 
>body of the message.  
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login 
>with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-irtf-dtnrg-bundle-spec-05.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[email-masked].
>In the body type:
>	"FILE /internet-drafts/draft-irtf-dtnrg-bundle-spec-05.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant 
>mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation
on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>

Cc: <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: [dtn-interest] save the date: May 16/17 in Berkeley
Date: Tue, 18 Apr 2006 23:18:51 -0400
To: "Fall, Kevin" <[email-masked]>
Sender: [email-masked]

Hello;

An address would be useful. Also, do you want people to RSVP ?

Regards
Marshall Eubanks

On Apr 18, 2006, at 6:49 PM, Fall, Kevin wrote:

> There will be a face to face DTN meeting at the Intel Berkeley lab May
> 16 and 17.  Major topics: multicast, application API, router API.   
> More
> to come...
>
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Tue, 18 Apr 2006 15:49:10 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] save the date: May 16/17 in Berkeley
Sender: [email-masked]

There will be a face to face DTN meeting at the Intel Berkeley lab May
16 and 17.  Major topics: multicast, application API, router API.  More
to come...

- K

To: [email-masked]
Date: Sun, 09 Apr 2006 13:05:39 +0100
From: Milena V Radenkovic <[email-masked]>
Subject: [dtn-interest] DTN PhD Position Open
Sender: [email-masked]

Dear all,

There is a new project on "Providing Communication in Infrastructureless
  Environments: Disruption Tolerant Networking" starting in Nottingham,
UK and we are seeking for candidate to fill in one position of
three-year, full-time studentship fully-funded by The Engineering and
Physical Sciences Research Council (EPSRC). The successful candidate
will work on 'A Novel Routing Protocol for Large Scale Disconnected
Environments'.

The start date is 1 Sep 2006.
For informal queries contact Dr. Milena Radenkovic ([email-masked]).

If you are interested please visit:

http://cs.nott.ac.uk/~mvr/PhDAdvert.html

Best,

Milena

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Cc: [email-masked]
From: Marshall Eubanks <[email-masked]>
Subject: Re: [dtn-interest] Re:
Date: Sat, 8 Apr 2006 14:23:01 -0400
To: Vamsi Maram Reddy <[email-masked]>
Sender: [email-masked]

If you mean, what's the worst case ?, it depends on the weather.

If there is heavy rain / thunderstorms at a DSN site, bit error rates  
can be quite high. I remember
one encounter when I was at JPL (Voyager Saturn ?) where some data  
was lost irretrievably due to weather
(at Canberra IIRC).

And of course, there was the story from the 1960's about when the  
Moon caused a total loss of signal by inconveniently getting in front  
of the spacecraft, causing mass consternation until the shift change  
came in and asked why the dish was pointing at the Moon.

Otherwise, the noise is pretty much all thermal and you should be  
able to calculate it from first
principles to 10 - 20% or better if you know the transmit power,  
system temperatures, antenna sizes, etc.

Regards
Marshall Eubanks

On Apr 8, 2006, at 1:49 PM, Vamsi Maram Reddy wrote:

> Hello,
>
> Can anyone let me know what bit error rates do deep space satellite  
> networks generally have? I am working on satellite networks taking  
> bit error rates and would like to know the range of link bit error  
> rates.
>
> Thanks,
> Vamsi
>
> How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone  
> call rates.

Date: Sat, 8 Apr 2006 10:49:55 -0700 (PDT)
From: Vamsi Maram Reddy <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Re:
Sender: [email-masked]

--0-572372286-1144518595=:33149
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello,
   
  Can anyone let me know what bit error rates do deep space satellite networks generally have? I am working on satellite networks taking bit error rates and would like to know the range of link bit error rates. 
   
  Thanks,
  Vamsi 

---------------------------------
How low will we go? Check out Yahoo! Messenger’s low  PC-to-Phone call rates.
--0-572372286-1144518595=:33149
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<div>Hello,</div>  <div>&nbsp;</div>  <div>Can anyone let me know what bit error rates do deep space satellite networks generally have? I am working on satellite networks&nbsp;taking bit error rates and would like to know the range of link bit error rates. </div>  <div>&nbsp;</div>  <div>Thanks,</div>  <div>Vamsi&nbsp;</div><p>
		<hr size=1>How low will we go? Check out Yahoo! Messenger’s low <a href="http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com"> PC-to-Phone call rates.
--0-572372286-1144518595=:33149--

Date: Sat, 8 Apr 2006 00:19:45 +0200 (CEST)
From: "Magnus Kindgren" <[email-masked]>
To: "dtn-interest" <[email-masked]>
Importance: Normal
Subject: [dtn-interest] return receipt in dtncp
Sender: [email-masked]

Hi,

When a bundle is sent with dtncp, the return receipt is not successfully
received.
As I understand the source code, this if statement incorrect:

    if ((ret = dtn_recv(handle, &reply_spec,
                        DTN_PAYLOAD_MEM, &reply_payload, -1)) < 0)

The application waits here, but no return receipt is retrieved.

Can someone help me please.

Regards,
Magnus Kindgren

Master student, KTH, Sweden
Sámi Network Connectivity

Content-class: urn:content-classes:message
Date: Tue, 4 Apr 2006 16:03:08 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] (no subject)
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65822.CB8C23FE
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C65822.CB8C23FE"

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

All,

=20

Here is my proposed agenda for the non-custodial multicast discussion
we need to have.

=20

Objective: Conclude our discussion with an agreement on how
non-custodial multicast should be specified in DTN.

=20

Summary of the four identified additional mechanisms that are needed to
support non-custodial DTN multicast:

1.	A way to identify the EID of the node that forwarded a received
bundle.=20
2.	An assurance that the EID used to identify this previous hop is
the same EID that the receiving node uses to identify the forwarding
node (and not some other alias EID of the forwarding node)
3.	A way to eliminate or sufficiently mitigate potential implosion
at the report-to endpoint from a multicast bundle that requests status
report generation
4.	If support for multicast is optional rather than mandatory, a
way to encapsulate multicast bundles inside of unicast bundles.

Summary of the proposals made at the Dallas DTNRG meeting to address
the need for the above mechanisms:

1.	Define an optional Previous Hop EID extension header (in a
separate, stand-alone specification) that a forwarding node inserts
into a bundle to identify itself to the receiving node.
2.	Require that each node that is capable of supporting multicast
delivery must have a unique, designated singleton EID that is the only
EID for that node that:

	a.	Other nodes use to identify that node when making
forwarding decisions, and
	b.	That node will ever put in a Previous Hop EID header
that it creates.

3.	Require that local policy must be capable of overriding all
requests for status reporting so as to mitigate the risk of status
report implosion at report-to endpoints.
4.	Assuming that support for multicast is optional rather than
mandatory, require multicast-capable nodes to implement
bundle-in-bundle encapsulation (defined in a separate specification)=20

Specifically we want to answer the following questions which have
arisen in previous discussion:=20

1.      Should support for non-custodial multicast be mandatory (in the
base bundle protocol) or optional?  By making support mandatory, we
mean that every node would be required to be capable of generating and
processing previous-hop EID headers, though not required to actually
use these headers. (Implementation would be mandatory; use would remain
optional)

2.      How should the problem of potential implosion at the report-to
endpoint of a multicast bundle be mitigated? Some ideas that were
floated include:

a.       Turn off generation of all status reports if the destination
endpoint is not a singleton endpoint?=20

b.      Turn off generation of only the "each-hop" status reports if
destination endpoint is not a singleton endpoint (turn off only Request
reporting of bundle reception and Request reporting of bundle
forwarding; leave on Request reporting of bundle delivery, Request
reporting of bundle deletion, and Request acknowledgement by
application ) (For large groups this could still be a problem.)

c.       Say that at any node implementing the Bundle Protocol, local
policy may override status report request flags and not send reports
for multicast bundles. (Question here is how any given node has
knowledge necessary to know whether to override or not.)

3.      What exactly should be the wording of the requirement that each
node have some sort of "designated" EID that denotes it and that it and
other nodes use in specific situations.  (A mechanism for identifying
the previous hop endpoint of a bundle seems to be required for
multicast support. Regardless of how it is implemented, for the
previous-hop EID to be meaningful, there must be a requirement that the
endpoint ID that a node uses to identify itself to others in the
previous hop EID header/field is the same endpoint ID that it's
neighbor nodes use to identify it for the purpose of making forwarding
decisions. Right now there is nothing in the specifications that ensure
that every node has or uses a "designated" EID. Is this a more general
requirement that will be needed to support DTN routing in general or is
it multicast-specific?)

=20

Lastly, I am attaching three normative drafts that I put together based
on my presentation at the Dallas meeting. Please look them over and
provide me with comments. They are:

=20

1.	Previous Hop Extension Header draft
2.	Bundle-in-Bundle Encapsulation draft
3.	Non-Custodial Multicast Extensions draft

 The multicast extensions draft assumes that multicast remains
optional, so it would have to be modified slightly if we end up
deciding that multicast is mandatory, but the basic ideas would remain
the same.=20

=20

Thanks.

=20

-Susan

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
class=3D893065919-04042006>All,</SPAN></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
class=3D893065919-04042006></SPAN></FONT></FONT>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT><SPAN=20
class=3D893065919-04042006></SPAN><FONT face=3D"Times New Roman"><FONT =
size=3D3><SPAN=20
class=3D893065919-04042006>Here is my proposed a</SPAN>genda =
for&nbsp;<SPAN=20
class=3D893065919-04042006>the non-custodial </SPAN>multicast=20
discussion&nbsp;<SPAN class=3D893065919-04042006>we need to=20
have.</SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><?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></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Objective: Conclude our discussion with an agreement on how =
non-custodial=20
multicast should be specified in DTN.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Summary of the four identified additional mechanisms that are =
needed to=20
support non-custodial DTN multicast:</FONT></P>
<OL style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>A way to identify the EID of the =
node that=20
  forwarded a received bundle. </FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>An assurance that the EID used to =
identify this=20
  previous hop is the same EID that the receiving node uses to identify =
the=20
  forwarding node (and not some other alias EID of the forwarding=20
  node)</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>A way to eliminate or sufficiently =
mitigate=20
  potential implosion at the report-to endpoint from a multicast bundle =
that=20
  requests status report generation</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l3 level1 lfo2; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>If support for multicast is optional =
rather than=20
  mandatory, a way to encapsulate multicast bundles inside of unicast=20
  bundles.</FONT></LI></OL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Summary of the proposals made at the Dallas DTNRG meeting to =
address the=20
need for the above mechanisms:</FONT></P>
<OL style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Define an optional Previous Hop EID =
extension=20
  header (in a separate, stand-alone specification) that a forwarding =
node=20
  inserts into a bundle to identify itself to the receiving =
node.</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Require that each node that is =
capable of=20
  supporting multicast delivery must have a unique, designated singleton =
EID=20
  that is the only EID for that node that:</FONT></LI>
  <OL style=3D"MARGIN-TOP: 0in" type=3Da>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman" size=3D3>Other nodes use to identify that =
node when=20
    making forwarding decisions, and</FONT></LI>
    <LI class=3DMsoNormal=20
    style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level2 lfo3; tab-stops: =
list 1.0in"><FONT=20
    face=3D"Times New Roman" size=3D3>That node will ever put in a =
Previous Hop EID=20
    header that it creates.</FONT></LI></OL>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Require that local policy must be =
capable of=20
  overriding all requests for status reporting so as to mitigate the =
risk of=20
  status report implosion at report-to endpoints.</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l0 level1 lfo3; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Assuming that support for multicast =
is optional=20
  rather than mandatory, require multicast-capable nodes to implement=20
  bundle-in-bundle encapsulation (defined in a separate specification)=20
  </FONT></LI></OL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>Specifically we want to answer =
the following=20
questions<SPAN class=3D893065919-04042006> which have arisen in previous =

discussion</SPAN>:<o:p>&nbsp;</o:p></FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>Should support for non-custodial multicast =
be=20
mandatory (in the base bundle protocol) or optional?<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>By making support mandatory, =
we mean=20
that every node would be required to be capable of generating and =
processing=20
previous-hop EID headers, though not required to actually use these =
headers.=20
(Implementation would be mandatory; use would remain =
optional)</FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>How should the problem of potential =
implosion at the=20
report-to endpoint of a multicast bundle be mitigated? Some ideas that =
were=20
floated include:</FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>a.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>Turn off generation of all status reports =
if the=20
destination endpoint is not a singleton endpoint? </FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>b.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>Turn off generation of only the =
&#8220;each-hop&#8221; status=20
reports if destination endpoint is not a singleton endpoint (turn off =
only=20
Request reporting of bundle reception and Request reporting of bundle=20
forwarding; leave on Request reporting of bundle delivery, Request =
reporting of=20
bundle deletion, and Request acknowledgement by application ) (For large =
groups=20
this could still be a problem.)</FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 75pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level2 lfo1; tab-stops: list 75.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>c.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>Say that at any node implementing the =
Bundle=20
Protocol, local policy may override status report request flags and not =
send=20
reports for multicast bundles. (Question here is how any given node has=20
knowledge necessary to know whether to override or =
not.)</FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 39pt; TEXT-INDENT: -0.25in; mso-list: l2 =
level1 lfo1; tab-stops: list 39.0pt"><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-list: Ignore"><FONT=20
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><FONT size=3D3>What exactly should be the wording of the =
requirement=20
that each node have some sort of &#8220;designated&#8221; EID that =
denotes it and that it=20
and other nodes use in specific situations.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>(A mechanism for identifying =
the=20
previous hop endpoint of a bundle seems to be required for multicast =
support.=20
Regardless of how it is implemented, for the previous-hop EID to be =
meaningful,=20
there must be a requirement that the endpoint ID that a node uses to =
identify=20
itself to others in the previous hop EID header/field is the same =
endpoint ID=20
that it&#8217;s neighbor nodes use to identify it for the purpose of =
making forwarding=20
decisions. Right now there is nothing in the specifications that ensure =
that=20
every node has or uses a &#8220;designated&#8221; EID. Is this a more =
general requirement=20
that will be needed to support DTN routing in general or is it=20
multicast-specific?)</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Lastly, I am attaching three normative drafts that I put =
together based=20
on my presentation at the <?xml:namespace prefix =3D st1 ns =3D=20
"urn:schemas-microsoft-com:office:smarttags" /><st1:City =
w:st=3D"on"><st1:place=20
w:st=3D"on">Dallas</st1:place></st1:City> meeting. Please look them over =
and=20
provide me with comments. They are:</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<OL style=3D"MARGIN-TOP: 0in" type=3D1>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Previous Hop Extension Header =
draft</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Bundle-in-Bundle Encapsulation =
draft</FONT></LI>
  <LI class=3DMsoNormal=20
  style=3D"MARGIN: 0in 0in 0pt; mso-list: l1 level1 lfo4; tab-stops: =
list .5in"><FONT=20
  face=3D"Times New Roman" size=3D3>Non-Custodial Multicast Extensions=20
  draft</FONT></LI></OL>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><SPAN style=3D"mso-spacerun: =
yes">&nbsp;</SPAN>The=20
multicast extensions draft assumes that multicast remains optional, so =
it would=20
have to be modified slightly if we end up deciding that multicast is =
mandatory,=20
but the basic ideas would remain the same. </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Thanks.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>-Susan</FONT></P></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>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C65822.CB8C23FE--

------_=_NextPart_001_01C65822.CB8C23FE
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-encapsulation-04-04-2006.txt"

ICAgICAgICAgICAgICAgIFtQYWdlIDldCgwK

------_=_NextPart_001_01C65822.CB8C23FE
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-previous-hop-extension-header-04-04-2006.txt"

------_=_NextPart_001_01C65822.CB8C23FE
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-multicast-noncustodial-protocol-extensions-04-04-2006.txt"

------_=_NextPart_001_01C65822.CB8C23FE--

Date: Tue, 4 Apr 2006 11:36:43 -0700
From: "Steve King" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fw: IEEE Comm. Surveys & Tut., 1st Qu. 2006 issue
Sender: [email-masked]

FYI

Forwarded Message [ Download File | Save to Yahoo! Briefcase ]

From: "Martin Reisslein" <[email-masked]>
To: [email-masked]
Date: Mon, 03 Apr 2006 14:03:31 -0700
Subject: [Tccc] IEEE Comm. Surveys & Tut., 1st Qu. 2006 issue

Dear Colleagues,

The First Quarter 2006 issue of the IEEE Communications Surveys and
Tutorials has been posted at

http://www.comsoc.org/livepubs/surveys/public/2006/jan

Please find the table of contents enclosed and note that the articles
are available free of charge from the IEEE ComSoc Digital Library
(non-IEEE members can access them by setting up a free guest account)
and that publication in IEEE Xplore is forthcoming.

Martin

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

IEEE Communications Surveys and Tutorials

Volume 8, Number 1, First Quarter 2006

Marcus Roberts, Michael Temple, Robert Mills, and Richard Raines.

Evolution of the Air Interface of Cellular Communications Systems
Toward
4G Realization,

pages 2-23,

http://www.comsoc.org/livepubs/surveys/public/2006/jan/pdf/roberts.pdf

Zhensheng Zhang.

Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay
Tolerant Networks: Overview and Challenges,

pages 24-37,

http://www.comsoc.org/livepubs/surveys/public/2006/jan/pdf/zhang.pdf

Deguang Le, Xiaoming Fu, and Dieter Hogrefe.

A Review of Mobility Support Paradigms for the Internet,

pages 38-51,

http://www.comsoc.org/livepubs/surveys/public/2006/jan/pdf/fu.pdf

Content-class: urn:content-classes:message
Date: Tue, 4 Apr 2006 11:19:28 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: Last Call: 'The Tao of IETF - A Novice's Guide to the Internet   Engineering Task Force' to Informational RFC
Sender: [email-masked]

For any of you who may have been to IETF for the first time (or those of
you who have been there more than once) that are interested in whether
IETF is capturing its own vibe correctly...

- K

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 9:41 AM
> To: [email-masked]
> Subject: Fwd: Last Call: 'The Tao of IETF - A Novice's Guide to the
> Internet Engineering Task Force' to Informational RFC
> 
> Greetings again. The revision of the Tao of the IETF is last call. It
> would be great for WG chairs (who are supposed to know most of this
> stuff) to read it through and point out any errors and/or propose
> changes. Thanks!
> 
> >The IESG has received a request from an individual submitter to
consider
> the
> >following document:
> >
> >- 'The Tao of IETF - A Novice's Guide to the Internet Engineering
Task
> Force '
> >    <draft-hoffman-taobis-06.txt> as an Informational RFC
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action.  Please send any comments to the
> >[email-masked] or [email-masked] mailing lists by 2006-05-02.
> >
> >The file can be obtained via
> >http://www.ietf.org/internet-drafts/draft-hoffman-taobis-06.txt