Subject: [dtn-interest] DTNRG Discconnectathon and Network Managment Slides
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 31 Jul 2009 03:32:38 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Kevin, Stephen and all:

I put the updated slides here:
http://roland.grc.nasa.gov/~ivancic/DTN/

Please use the updated Disconnectation.  I updated AFTER the DTNRG meeting to include a picture of the DTN Disconnectathon team - 9 node multihop test Thursday night as well as the white board diagram.

All, Sorry for the large file.  I have a machine that does not have pdf conversion and I tried to compress the pictures, but didn't do  a very good job.

-- Will 

Date: Fri, 31 Jul 2009 02:58:02 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] audio for the WG meeting tomorrow?

Ivancic, William D. (GRC-RHN0) wrote:
> I believe there is a audio feed, or are you asking about the disconnectathon.  In that case, you can use the teleconference number I sent to the Disconnectathon mail list.
> 
> I've participated remote before.  I listened to the mp3 feed and then jabbered back.  I believe there is about a 10 second delay.
> 

Sorry for the ambiguity; yes, I meant the working group meeting.

I've found the URL for the audio:

http://www.ietf.org/meeting/75/audio.html

Thanks,
	-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 31 Jul 2009 01:41:34 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] audio for the WG meeting tomorrow?

I believe there is a audio feed, or are you asking about the disconnectathon.  In that case, you can use the teleconference number I sent to the Disconnectathon mail list.

I've participated remote before.  I listened to the mp3 feed and then jabbered back.  I believe there is about a 10 second delay.

-- will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Daniel
>Ellard
>Sent: Thursday, July 30, 2009 5:35 PM
>To: [email-masked]
>Subject: [dtn-interest] audio for the WG meeting tomorrow?
>
>
>Is there going to be an audio feed or dial-in for the meeting tomorrow?
>
>Thanks,
>	-Dan
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 30 Jul 2009 17:35:11 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] audio for the WG meeting tomorrow?

Is there going to be an audio feed or dial-in for the meeting tomorrow?

Thanks,
	-Dan

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Thu, 30 Jul 2009 07:19:20 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Room change

To bad, Cabaret is much better for our type of meetings.

Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Stephen
>Farrell
>Sent: Thursday, July 30, 2009 7:28 AM
>To: DTN
>Subject: [dtn-interest] Room change
>
>
>Hi All,
>
>Just got a note from the secretariat that our room for tomorrow
>has changed from Cabaret to Large Stage.
>
>Stephen.
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 30 Jul 2009 12:28:14 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Room change

Hi All,

Just got a note from the secretariat that our room for tomorrow
has changed from Cabaret to Large Stage.

Stephen.

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Thu, 30 Jul 2009 02:13:07 -0700
Subject: [dtn-interest] copy of slides presented to IAB this morning

Hi all-

This morning we (Stephen and I) presented an "RG Update" to the IAB.   
A copy of the slides are here:

	http://www.ietf.org/proceedings/75/slides/DTNRG-0.pdf

- K

Date: Thu, 30 Jul 2009 09:48:59 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Slides please...

Hi,

If you have an agenda slot at the meeting tomorrow can you
mail your slides to Kevin and I today, before 7pm (local) so
that we can put them up on the meeting materials page. That
way any remote participants can see what's what and they'll
make it into the IETF meeting proceedings for the record.

Thanks,
Stephen.

PS: If you're intending to participate remotely, do also
let Kevin and I know, so that we can make sure folks at the
mic say their names etc.

Date: Thu, 30 Jul 2009 03:48:34 -0400
From: Armando Caro <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible	extensions for the bundle protocol

Marshall,

Sorry, I wasn't clear before. The drift wasn't 5min/day. It took several 
days for the drift to become noticeable (ie, off by ~5min).

Armando

Marshall Eubanks wrote:
>
> Note that this is really a syntonization issue. If the clock was 
> drifting by
> 5 minutes (300 seconds) per day (86400 seconds) that implies a frequency
> stability of ~3 x 10^-3, and / or a static drift of the same 
> magnitude, six orders of magnitude worse than the typical quartz 
> clock. Now, the environment in a place like an elevator can be tough 
> on clocks (highly variable accelerations, magnetic fields, etc.),
> but this is so large that it sounds like a static drift problem to me.
>
> If the elevator door was open for 1-10 seconds, and you were running a 
> DTN like program with an accuracy of 1 to 10 milliseconds, you would 
> be hard pressed to do clock
> syntonization during the door open period to much better than 10^-3 
> (two synchronizations at the millisecond level separated by a few 
> seconds). On  the other hand, it should be trivial to describe a 10^-3 
> clock drift if you could do two
> synchronizations during two separate door openings.
>
> Regards
> Marshall

Date: Thu, 30 Jul 2009 09:43:26 +0200
From: Teemu <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

I have an embedded Linux box with a battery backed clock. It was synced with
my laptop time a few weeks ago, just now I noticed that the clock in the
Linux box has drifted by 9 minutes.

-Teemu

On 30.7.2009 0.41, "Armando Caro" <[email-masked]> wrote:

> For today's testing issues, I don't know the details. I'd have to defer
> to Jeff Ward who noticed the problem today. He fixed the problem by
> simply pointing the machine to an NTP server.
> 
> For the BBN ElevatorNet issues, I don't remember how much the drift was.
> But all/most of our tests used 5-10 min bundle expiration times. Yes,
> the clock was off by THAT much. We never spent the time to look into why
> it was constantly drifting so much -- it just wasn't high enough of a
> priority.
> 
> Armando
> 
> Hans Kruse wrote:
>> Armando,
>> can you try and quantify the drift (maybe based on the bundle life
>> times you were using).  Will is right, we saw some issues this morning,
>> but I am trying to get a handle on the order of magnitude.   I am
>> _not_ trying to delve into the larger engineering debate, just
>> looking into the way the software is set up now.   If I expect
>> delay/disruptions, I would probably set the life time fairly large. Some
>> of the ION apps default to 5 min, Teemu mentioned sending bundles with
>> 1 hour life times.  I am hard pressed to see
>> how a clock skew can do that, even over a fairly large period of time.
>>  So we may have poorly chosen defaults, or
>> more likely a bug somewhere.
>> 
>> On Jul 29, 2009, at 6:01 PM, Armando Caro wrote:
>> 
>>> I have to say that this is exactly what we observed today. We have also
>>> run into time sync issues many times in the past when testing dtn2 in
>>> BBN's ElevatorNet testbed.
>>> 
>>> FYI, the nodes on our elevators have no way to maintain a sync'd clock.
>>> They do not have atomic clocks. They do not have clear view of the sky
>>> for GPS. They are completely disconnected from the Internet and any NTP
>>> server; they only have connectivity to node(s) immediately outside the
>>> elevator for the short period of time that the elevator door is open.
>>> 
>>> One of the elevator nodes (we have 2 elevators) consistently drifts
>>> enough that it becomes quite noticeable after awhile (I don't know how
>>> long "awhile" is).  Eventually we stopped using that node in our dtn2
>>> tests, because we had to periodically sync the clock manually. We only
>>> went through the trouble of doing so when we wanted to involve both
>>> elevator nodes for a dtn2 test/demo.
>>> 
>>> Another set of observations...
>>> 
>>> Armando
>>> 
>>> Ivancic, William D. (GRC-RHN0) wrote:
>>>> When running interoperability test the first thing one does is run
>>>> dtnping or equivalent.  The next step is to extend the bundle
>>>> lifetime because you suspect the clocks aren't synced.
>>>> 
>>>> Just and observation.
>>>> 
>>>> -- will
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:dtn-
>>>>> [email-masked]
>>>>> <mailto:[email-masked]>] On Behalf
>>>>> Of Kevin Fall
>>>>> Sent: Wednesday, July 29, 2009 9:04 AM
>>>>> To: Daniel Ellard
>>>>> Cc: [email-masked]
>>>>> <mailto:[email-masked]>
>>>>> Subject: Re: [dtn-interest] For our discussion Friday: possible
>>>>> extensions for the bundle protocol
>>>>> 
>>>>> 
>>>>> On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>>>>> 
>>>>> 
>>>>>> Kevin Fall wrote:
>>>>>> 
>>>>>>> I have some thoughts...
>>>>>>> 
>>>>>>> I am suspicious of the idea that synchronized clocks are that hard to
>>>>>>> obtain.  I understand that there are certain cases where this can
>>>>>>> happen, but I would like to preserve the notion that not have sync'd
>>>>>>> time is mistake, and not a normal operating condition.  I'm of the
>>>>>>> opinion that in the vast majority of cases, loose sync'd time is
>>>>>>> possible and is to be desired.
>>>>>>> 
>>>>>> I agree that in many cases it is possible and desirable, but
>>>>>> not all.  Synch'd time should be viewed as a convenient
>>>>>> luxury: desirable and useful, but it must NOT be required.
>>>>>> 
>>>>> I sense agreement but a difference in perspective.  It's not a
>>>>> convenient luxury, it is the "normal case".  However, yes, it seems as
>>>>> though it should be possible to operate even in the "abnormal" case.
>>>>> So, for example, we can operate in the Internet even when the DNS
>>>>> isn't quite working correctly.
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> The comments regarding GPS are too limited.  GPS may not be available
>>>>>>> in some cases, but others (including military systems) very often
>>>>>>> still require time and position even if GPS may be denied.
>>>>>>> 
>>>>>> Often, but not always--see previous point.  We don't want a
>>>>>> protocol that usually works (where the value of "usually" is
>>>>>> the matter of some debate); we want a protocol that works on
>>>>>> all the relevant systems where DTN adds value in the field.
>>>>>> We know that this does and will continue to include a large
>>>>>> number of systems with terrible clocks.
>>>>>> 
>>>>>> Why would we want a protocol that makes assumptions we know
>>>>>> don't always hold, when we can have a protocol based on
>>>>>> assumptions that do?
>>>>>> 
>>>>> I'm not sure its worth arguing over "large" and "often".  My point is
>>>>> that most of the world (and much of 'beyond this world') have
>>>>> reasonably sync'd clocks and that if they don't they probably should
>>>>> because its not that hard.  But yes there are some cases where it is
>>>>> hard, so we should find a way of working there too...  But I see no
>>>>> reason to optimize for the worst possible case.  imho...
>>>>> 
>>>>> - K
>>>>> 
>>>>> 
>>>>>> -Dan
>>>>>> 
>>>>>> --
>>>>>> Daniel Ellard, Ph.D.
>>>>>> Senior Scientist, Network Research
>>>>>> BBN Technologies
>>>>>> 10 Moulton Street
>>>>>> Cambridge, MA 02138
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> 
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> <mailto:[email-masked]>
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> <mailto:[email-masked]>
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>> 
>>> 
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> <mailto:[email-masked]>
>>> http://maillists.intel-research.net/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
>> 
>> 
>> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Marshall Eubanks <[email-masked]>
To: Armando Caro <[email-masked]>
Date: Wed, 29 Jul 2009 20:04:30 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible	extensions for the bundle protocol

On Jul 29, 2009, at 6:41 PM, Armando Caro wrote:

> For today's testing issues, I don't know the details. I'd have to  
> defer
> to Jeff Ward who noticed the problem today. He fixed the problem by
> simply pointing the machine to an NTP server.
>
> For the BBN ElevatorNet issues, I don't remember how much the drift  
> was.
> But all/most of our tests used 5-10 min bundle expiration times. Yes,
> the clock was off by THAT much. We never spent the time to look into  
> why
> it was constantly drifting so much -- it just wasn't high enough of a
> priority.

> Armando
>
> Hans Kruse wrote:
>> Armando,
>> can you try and quantify the drift (maybe based on the bundle life
>> times you were using).  Will is right, we saw some issues this  
>> morning,
>> but I am trying to get a handle on the order of magnitude.

Note that this is really a syntonization issue. If the clock was  
drifting by
5 minutes (300 seconds) per day (86400 seconds) that implies a frequency
stability of ~3 x 10^-3, and / or a static drift of the same  
magnitude, six orders of magnitude worse than the typical quartz  
clock. Now, the environment in a place like an elevator can be tough  
on clocks (highly variable accelerations, magnetic fields, etc.),
but this is so large that it sounds like a static drift problem to me.

If the elevator door was open for 1-10 seconds, and you were running a  
DTN like program with an accuracy of 1 to 10 milliseconds, you would  
be hard pressed to do clock
syntonization during the door open period to much better than 10^-3  
(two synchronizations at the millisecond level separated by a few  
seconds). On  the other hand, it should be trivial to describe a 10^-3  
clock drift if you could do two
synchronizations during two separate door openings.

Regards
Marshall

>> I am
>> _not_ trying to delve into the larger engineering debate, just
>> looking into the way the software is set up now.   If I expect
>> delay/disruptions, I would probably set the life time fairly large.  
>> Some
>> of the ION apps default to 5 min, Teemu mentioned sending bundles  
>> with
>> 1 hour life times.  I am hard pressed to see
>> how a clock skew can do that, even over a fairly large period of  
>> time.
>> So we may have poorly chosen defaults, or
>> more likely a bug somewhere.
>>
>> On Jul 29, 2009, at 6:01 PM, Armando Caro wrote:
>>
>>> I have to say that this is exactly what we observed today. We have  
>>> also
>>> run into time sync issues many times in the past when testing dtn2  
>>> in
>>> BBN's ElevatorNet testbed.
>>>
>>> FYI, the nodes on our elevators have no way to maintain a sync'd  
>>> clock.
>>> They do not have atomic clocks. They do not have clear view of the  
>>> sky
>>> for GPS. They are completely disconnected from the Internet and  
>>> any NTP
>>> server; they only have connectivity to node(s) immediately outside  
>>> the
>>> elevator for the short period of time that the elevator door is  
>>> open.
>>>
>>> One of the elevator nodes (we have 2 elevators) consistently drifts
>>> enough that it becomes quite noticeable after awhile (I don't know  
>>> how
>>> long "awhile" is).  Eventually we stopped using that node in our  
>>> dtn2
>>> tests, because we had to periodically sync the clock manually. We  
>>> only
>>> went through the trouble of doing so when we wanted to involve both
>>> elevator nodes for a dtn2 test/demo.
>>>
>>> Another set of observations...
>>>
>>> Armando
>>>
>>> Ivancic, William D. (GRC-RHN0) wrote:
>>>> When running interoperability test the first thing one does is run
>>>> dtnping or equivalent.  The next step is to extend the bundle
>>>> lifetime because you suspect the clocks aren't synced.
>>>>
>>>> Just and observation.
>>>>
>>>> -- will
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:dtn-
>>>>> [email-masked]
>>>>> <mailto:[email-masked]>] On Behalf
>>>>> Of Kevin Fall
>>>>> Sent: Wednesday, July 29, 2009 9:04 AM
>>>>> To: Daniel Ellard
>>>>> Cc: [email-masked]
>>>>> <mailto:[email-masked]>
>>>>> Subject: Re: [dtn-interest] For our discussion Friday: possible
>>>>> extensions for the bundle protocol
>>>>>
>>>>>
>>>>> On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>>>>>
>>>>>
>>>>>> Kevin Fall wrote:
>>>>>>
>>>>>>> I have some thoughts...
>>>>>>>
>>>>>>> I am suspicious of the idea that synchronized clocks are that  
>>>>>>> hard to
>>>>>>> obtain.  I understand that there are certain cases where this  
>>>>>>> can
>>>>>>> happen, but I would like to preserve the notion that not have  
>>>>>>> sync'd
>>>>>>> time is mistake, and not a normal operating condition.  I'm of  
>>>>>>> the
>>>>>>> opinion that in the vast majority of cases, loose sync'd time is
>>>>>>> possible and is to be desired.
>>>>>>>
>>>>>> I agree that in many cases it is possible and desirable, but
>>>>>> not all.  Synch'd time should be viewed as a convenient
>>>>>> luxury: desirable and useful, but it must NOT be required.
>>>>>>
>>>>> I sense agreement but a difference in perspective.  It's not a
>>>>> convenient luxury, it is the "normal case".  However, yes, it  
>>>>> seems as
>>>>> though it should be possible to operate even in the "abnormal"  
>>>>> case.
>>>>> So, for example, we can operate in the Internet even when the DNS
>>>>> isn't quite working correctly.
>>>>>
>>>>>
>>>>>>
>>>>>>> The comments regarding GPS are too limited.  GPS may not be  
>>>>>>> available
>>>>>>> in some cases, but others (including military systems) very  
>>>>>>> often
>>>>>>> still require time and position even if GPS may be denied.
>>>>>>>
>>>>>> Often, but not always--see previous point.  We don't want a
>>>>>> protocol that usually works (where the value of "usually" is
>>>>>> the matter of some debate); we want a protocol that works on
>>>>>> all the relevant systems where DTN adds value in the field.
>>>>>> We know that this does and will continue to include a large
>>>>>> number of systems with terrible clocks.
>>>>>>
>>>>>> Why would we want a protocol that makes assumptions we know
>>>>>> don't always hold, when we can have a protocol based on
>>>>>> assumptions that do?
>>>>>>
>>>>> I'm not sure its worth arguing over "large" and "often".  My  
>>>>> point is
>>>>> that most of the world (and much of 'beyond this world') have
>>>>> reasonably sync'd clocks and that if they don't they probably  
>>>>> should
>>>>> because its not that hard.  But yes there are some cases where  
>>>>> it is
>>>>> hard, so we should find a way of working there too...  But I see  
>>>>> no
>>>>> reason to optimize for the worst possible case.  imho...
>>>>>
>>>>> - K
>>>>>
>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> --
>>>>>> Daniel Ellard, Ph.D.
>>>>>> Senior Scientist, Network Research
>>>>>> BBN Technologies
>>>>>> 10 Moulton Street
>>>>>> Cambridge, MA 02138
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> <mailto:[email-masked]>
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> <mailto:[email-masked]>
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> <mailto:[email-masked]>
>>> http://maillists.intel-research.net/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
>>
>>
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Wed, 29 Jul 2009 18:41:13 -0400
From: Armando Caro <[email-masked]>
To: Hans Kruse <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible	extensions for the bundle protocol

For today's testing issues, I don't know the details. I'd have to defer 
to Jeff Ward who noticed the problem today. He fixed the problem by 
simply pointing the machine to an NTP server.

For the BBN ElevatorNet issues, I don't remember how much the drift was. 
But all/most of our tests used 5-10 min bundle expiration times. Yes, 
the clock was off by THAT much. We never spent the time to look into why 
it was constantly drifting so much -- it just wasn't high enough of a 
priority.

Armando

Hans Kruse wrote:
> Armando,
> can you try and quantify the drift (maybe based on the bundle life 
> times you were using).  Will is right, we saw some issues this morning,
> but I am trying to get a handle on the order of magnitude.   I am 
> _not_ trying to delve into the larger engineering debate, just
> looking into the way the software is set up now.   If I expect 
> delay/disruptions, I would probably set the life time fairly large. Some
> of the ION apps default to 5 min, Teemu mentioned sending bundles with 
> 1 hour life times.  I am hard pressed to see
> how a clock skew can do that, even over a fairly large period of time. 
>  So we may have poorly chosen defaults, or 
> more likely a bug somewhere.
>
> On Jul 29, 2009, at 6:01 PM, Armando Caro wrote:
>
>> I have to say that this is exactly what we observed today. We have also
>> run into time sync issues many times in the past when testing dtn2 in
>> BBN's ElevatorNet testbed.
>>
>> FYI, the nodes on our elevators have no way to maintain a sync'd clock.
>> They do not have atomic clocks. They do not have clear view of the sky
>> for GPS. They are completely disconnected from the Internet and any NTP
>> server; they only have connectivity to node(s) immediately outside the
>> elevator for the short period of time that the elevator door is open.
>>
>> One of the elevator nodes (we have 2 elevators) consistently drifts
>> enough that it becomes quite noticeable after awhile (I don't know how
>> long "awhile" is).  Eventually we stopped using that node in our dtn2
>> tests, because we had to periodically sync the clock manually. We only
>> went through the trouble of doing so when we wanted to involve both
>> elevator nodes for a dtn2 test/demo.
>>
>> Another set of observations...
>>
>> Armando
>>
>> Ivancic, William D. (GRC-RHN0) wrote:
>>> When running interoperability test the first thing one does is run 
>>> dtnping or equivalent.  The next step is to extend the bundle 
>>> lifetime because you suspect the clocks aren't synced.
>>>
>>> Just and observation.
>>>
>>> -- will
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:dtn-
>>>> [email-masked] 
>>>> <mailto:[email-masked]>] On Behalf 
>>>> Of Kevin Fall
>>>> Sent: Wednesday, July 29, 2009 9:04 AM
>>>> To: Daniel Ellard
>>>> Cc: [email-masked] 
>>>> <mailto:[email-masked]>
>>>> Subject: Re: [dtn-interest] For our discussion Friday: possible
>>>> extensions for the bundle protocol
>>>>
>>>>
>>>> On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>>>>
>>>>
>>>>> Kevin Fall wrote:
>>>>>
>>>>>> I have some thoughts...
>>>>>>
>>>>>> I am suspicious of the idea that synchronized clocks are that hard to
>>>>>> obtain.  I understand that there are certain cases where this can
>>>>>> happen, but I would like to preserve the notion that not have sync'd
>>>>>> time is mistake, and not a normal operating condition.  I'm of the
>>>>>> opinion that in the vast majority of cases, loose sync'd time is
>>>>>> possible and is to be desired.
>>>>>>
>>>>> I agree that in many cases it is possible and desirable, but
>>>>> not all.  Synch'd time should be viewed as a convenient
>>>>> luxury: desirable and useful, but it must NOT be required.
>>>>>
>>>> I sense agreement but a difference in perspective.  It's not a
>>>> convenient luxury, it is the "normal case".  However, yes, it seems as
>>>> though it should be possible to operate even in the "abnormal" case.
>>>> So, for example, we can operate in the Internet even when the DNS
>>>> isn't quite working correctly.
>>>>
>>>>
>>>>>
>>>>>> The comments regarding GPS are too limited.  GPS may not be available
>>>>>> in some cases, but others (including military systems) very often
>>>>>> still require time and position even if GPS may be denied.
>>>>>>
>>>>> Often, but not always--see previous point.  We don't want a
>>>>> protocol that usually works (where the value of "usually" is
>>>>> the matter of some debate); we want a protocol that works on
>>>>> all the relevant systems where DTN adds value in the field.
>>>>> We know that this does and will continue to include a large
>>>>> number of systems with terrible clocks.
>>>>>
>>>>> Why would we want a protocol that makes assumptions we know
>>>>> don't always hold, when we can have a protocol based on
>>>>> assumptions that do?
>>>>>
>>>> I'm not sure its worth arguing over "large" and "often".  My point is
>>>> that most of the world (and much of 'beyond this world') have
>>>> reasonably sync'd clocks and that if they don't they probably should
>>>> because its not that hard.  But yes there are some cases where it is
>>>> hard, so we should find a way of working there too...  But I see no
>>>> reason to optimize for the worst possible case.  imho...
>>>>
>>>> - K
>>>>
>>>>
>>>>> -Dan
>>>>>
>>>>> --
>>>>> Daniel Ellard, Ph.D.
>>>>> Senior Scientist, Network Research
>>>>> BBN Technologies
>>>>> 10 Moulton Street
>>>>> Cambridge, MA 02138
>>>>> [email-masked] <mailto:[email-masked]>
>>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked] 
>>>> <mailto:[email-masked]>
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked] 
>>> <mailto:[email-masked]>
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked] 
>> <mailto:[email-masked]>
>> http://maillists.intel-research.net/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
>
>
>

From: Hans Kruse <[email-masked]>
To: Armando Caro <[email-masked]>
Date: Wed, 29 Jul 2009 18:25:54 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible	extensions for the bundle protocol

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

Armando,
can you try and quantify the drift (maybe based on the bundle life  
times you were using).  Will is right, we saw some issues this morning,
but I am trying to get a handle on the order of magnitude.   I am  
_not_ trying to delve into the larger engineering debate, just
looking into the way the software is set up now.   If I expect delay/ 
disruptions, I would probably set the life time fairly large. Some
of the ION apps default to 5 min, Teemu mentioned sending bundles with  
1 hour life times.  I am hard pressed to see
how a clock skew can do that, even over a fairly large period of  
time.  So we may have poorly chosen defaults, or
more likely a bug somewhere.

On Jul 29, 2009, at 6:01 PM, Armando Caro wrote:

> I have to say that this is exactly what we observed today. We have  
> also
> run into time sync issues many times in the past when testing dtn2 in
> BBN's ElevatorNet testbed.
>
> FYI, the nodes on our elevators have no way to maintain a sync'd  
> clock.
> They do not have atomic clocks. They do not have clear view of the sky
> for GPS. They are completely disconnected from the Internet and any  
> NTP
> server; they only have connectivity to node(s) immediately outside the
> elevator for the short period of time that the elevator door is open.
>
> One of the elevator nodes (we have 2 elevators) consistently drifts
> enough that it becomes quite noticeable after awhile (I don't know how
> long "awhile" is).  Eventually we stopped using that node in our dtn2
> tests, because we had to periodically sync the clock manually. We only
> went through the trouble of doing so when we wanted to involve both
> elevator nodes for a dtn2 test/demo.
>
> Another set of observations...
>
> Armando
>
> Ivancic, William D. (GRC-RHN0) wrote:
>> When running interoperability test the first thing one does is run  
>> dtnping or equivalent.  The next step is to extend the bundle  
>> lifetime because you suspect the clocks aren't synced.
>>
>> Just and observation.
>>
>> -- will
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Kevin  
>>> Fall
>>> Sent: Wednesday, July 29, 2009 9:04 AM
>>> To: Daniel Ellard
>>> Cc: [email-masked]
>>> Subject: Re: [dtn-interest] For our discussion Friday: possible
>>> extensions for the bundle protocol
>>>
>>>
>>> On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>>>
>>>
>>>> Kevin Fall wrote:
>>>>
>>>>> I have some thoughts...
>>>>>
>>>>> I am suspicious of the idea that synchronized clocks are that  
>>>>> hard to
>>>>> obtain.  I understand that there are certain cases where this can
>>>>> happen, but I would like to preserve the notion that not have  
>>>>> sync'd
>>>>> time is mistake, and not a normal operating condition.  I'm of the
>>>>> opinion that in the vast majority of cases, loose sync'd time is
>>>>> possible and is to be desired.
>>>>>
>>>> I agree that in many cases it is possible and desirable, but
>>>> not all.  Synch'd time should be viewed as a convenient
>>>> luxury: desirable and useful, but it must NOT be required.
>>>>
>>> I sense agreement but a difference in perspective.  It's not a
>>> convenient luxury, it is the "normal case".  However, yes, it  
>>> seems as
>>> though it should be possible to operate even in the "abnormal" case.
>>> So, for example, we can operate in the Internet even when the DNS
>>> isn't quite working correctly.
>>>
>>>
>>>>
>>>>> The comments regarding GPS are too limited.  GPS may not be  
>>>>> available
>>>>> in some cases, but others (including military systems) very often
>>>>> still require time and position even if GPS may be denied.
>>>>>
>>>> Often, but not always--see previous point.  We don't want a
>>>> protocol that usually works (where the value of "usually" is
>>>> the matter of some debate); we want a protocol that works on
>>>> all the relevant systems where DTN adds value in the field.
>>>> We know that this does and will continue to include a large
>>>> number of systems with terrible clocks.
>>>>
>>>> Why would we want a protocol that makes assumptions we know
>>>> don't always hold, when we can have a protocol based on
>>>> assumptions that do?
>>>>
>>> I'm not sure its worth arguing over "large" and "often".  My point  
>>> is
>>> that most of the world (and much of 'beyond this world') have
>>> reasonably sync'd clocks and that if they don't they probably should
>>> because its not that hard.  But yes there are some cases where it is
>>> hard, so we should find a way of working there too...  But I see no
>>> reason to optimize for the worst possible case.  imho...
>>>
>>> - K
>>>
>>>
>>>> -Dan
>>>>
>>>> --
>>>> Daniel Ellard, Ph.D.
>>>> Senior Scientist, Network Research
>>>> BBN Technologies
>>>> 10 Moulton Street
>>>> Cambridge, MA 02138
>>>> [email-masked]
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/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-11-16214819
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Armando,<div>can you try and =
quantify the drift (maybe based on the bundle life times you were =
using). &nbsp;Will is right, we saw some issues this =
morning,</div><div>but I am trying to get a handle on the order of =
magnitude. &nbsp; I am _not_ trying to delve into the larger engineering =
debate, just</div><div>looking into the way the software is set up now. =
&nbsp; If I expect delay/disruptions, I would probably set the life time =
fairly large. Some</div><div>of the ION apps default to 5 min, Teemu =
mentioned sending bundles with 1 hour life times. &nbsp;I am hard =
pressed to see</div><div>how a clock skew can do that, even over a =
fairly large period of time. &nbsp;So we may have poorly chosen =
defaults, or&nbsp;</div><div>more likely a bug =
somewhere.</div><div><br></div><div><div><div>On Jul 29, 2009, at 6:01 =
PM, Armando Caro wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>I =
have to say that this is exactly what we observed today. We have also =
<br>run into time sync issues many times in the past when testing dtn2 =
in <br>BBN's ElevatorNet testbed.<br><br>FYI, the nodes on our elevators =
have no way to maintain a sync'd clock. <br>They do not have atomic =
clocks. They do not have clear view of the sky <br>for GPS. They are =
completely disconnected from the Internet and any NTP <br>server; they =
only have connectivity to node(s) immediately outside the <br>elevator =
for the short period of time that the elevator door is open.<br><br>One =
of the elevator nodes (we have 2 elevators) consistently drifts =
<br>enough that it becomes quite noticeable after awhile (I don't know =
how <br>long "awhile" is). &nbsp;Eventually we stopped using that node =
in our dtn2 <br>tests, because we had to periodically sync the clock =
manually. We only <br>went through the trouble of doing so when we =
wanted to involve both <br>elevator nodes for a dtn2 =
test/demo.<br><br>Another set of =
observations...<br><br>Armando<br><br>Ivancic, William D. (GRC-RHN0) =
wrote:<br><blockquote type=3D"cite">When running interoperability test =
the first thing one does is run dtnping or equivalent. &nbsp;The next =
step is to extend the bundle lifetime because you suspect the clocks =
aren't synced.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Just and =
observation.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">-- =
will<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">From: =
[email-masked] [<a =
href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of Kevin =
Fall<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">Sent: Wednesday, July 29, 2009 9:04 =
AM<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">To: Daniel Ellard<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Cc: <a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">Subject: Re: [dtn-interest] For =
our discussion Friday: possible<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">extensions for the bundle =
protocol<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">On Jul 29, 2009, at Jul 295:58 =
AMPDT, Daniel Ellard wrote:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Kevin =
Fall wrote:<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">I have some =
thoughts...<br></blockquote></blockquote></blockquote></blockquote><blockq=
uote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">I am suspicious of the idea that =
synchronized clocks are that hard =
to<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">obtain. &nbsp;I understand that =
there are certain cases where this =
can<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">happen, but I would like to =
preserve the notion that not have =
sync'd<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">time is mistake, and not a =
normal operating condition. &nbsp;I'm of =
the<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">opinion that in the vast =
majority of cases, loose sync'd time =
is<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">possible and is to be =
desired.<br></blockquote></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">I agree that in many cases it is possible and desirable, =
but<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">not =
all. &nbsp;Synch'd time should be viewed as a =
convenient<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">luxury: =
desirable and useful, but it must NOT be =
required.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I sense agreement but a =
difference in perspective. &nbsp;It's not =
a<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">convenient luxury, it is the "normal case". &nbsp;However, =
yes, it seems as<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">though it should be possible to =
operate even in the "abnormal" =
case.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">So, for example, we can operate in the Internet even when =
the DNS<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite">isn't quite working =
correctly.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">The comments regarding GPS are =
too limited. &nbsp;GPS may not be =
available<br></blockquote></blockquote></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">in some cases, but others =
(including military systems) very =
often<br></blockquote></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">still require time and position =
even if GPS may be =
denied.<br></blockquote></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote></blockquote><blo=
ckquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Often, but not always--see previous point. &nbsp;We don't =
want a<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">protocol=
 that usually works (where the value of "usually" =
is<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">the =
matter of some debate); we want a protocol that works =
on<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">all =
the relevant systems where DTN adds value in the =
field.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">We =
know that this does and will continue to include a =
large<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">number =
of systems with terrible =
clocks.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Why =
would we want a protocol that makes assumptions we =
know<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">don't =
always hold, when we can have a protocol based =
on<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">assumptions that =
do?<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I'm not sure its worth arguing =
over "large" and "often". &nbsp;My point =
is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">that most of the world (and much of 'beyond this world') =
have<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">reasonably sync'd clocks and that if they don't they =
probably should<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">because its not that hard. =
&nbsp;But yes there are some cases where it =
is<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">hard, so we should find a way of working there too... =
&nbsp;But I see no<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">reason to optimize for the worst =
possible case. &nbsp;imho...<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">- =
K<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-Dan<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">--<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Daniel =
Ellard, Ph.D.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Senior =
Scientist, Network =
Research<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">BBN =
Technologies<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">10 =
Moulton Street<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Cambridge, MA =
02138<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote></bloc=
kquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">dtn-interest mailing =
list<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><blockquote =
type=3D"cite"><br></blockquote><br>_______________________________________=
________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-11-16214819--

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, Will Leland <[email-masked]>,  [email-masked]
Date: Wed, 29 Jul 2009 18:24:39 -0400
Subject: [dtn-interest] Re(2): For our discussion Friday: possible extensions for the bundle protocol

On Wed, Jul 29, 2009, Burleigh, Scott C (313B)
<[email-masked]> wrote:

>> == Requirements:
>>
>>    - If Hops To Live is greater than zero, Hops To Live MUST
>>      be decremented each time a bundle is forwarded.
>>
>>    - Hops To Live SHOULD be a field in the primary bundle block.
>>
>>    - Hops To Live SHOULD NOT impact the BSP specification.
>>
>>    - Hops To Live SHOULD interoperate with nodes conforming to
>>      RFC 5050.
>
>This additional field can't live in the primary block without violating
>the BSP specification, so you've got conflicting requirements.

Hi Scott,

it does violate the mutable canonicalization scheme defined for PI2
ciphersuite but other ciphersuites with different canonicalization can
work OK.

But this the default and breaking the default is less than optimal.

I have suggested for quite some time now that the canonicalization be
changed in order to avoid problems like this. I still think it's a good idea.

Cheers.....Peter

Date: Wed, 29 Jul 2009 18:01:58 -0400
From: Armando Caro <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible	extensions for the bundle protocol

I have to say that this is exactly what we observed today. We have also 
run into time sync issues many times in the past when testing dtn2 in 
BBN's ElevatorNet testbed.

FYI, the nodes on our elevators have no way to maintain a sync'd clock. 
They do not have atomic clocks. They do not have clear view of the sky 
for GPS. They are completely disconnected from the Internet and any NTP 
server; they only have connectivity to node(s) immediately outside the 
elevator for the short period of time that the elevator door is open.

One of the elevator nodes (we have 2 elevators) consistently drifts 
enough that it becomes quite noticeable after awhile (I don't know how 
long "awhile" is).  Eventually we stopped using that node in our dtn2 
tests, because we had to periodically sync the clock manually. We only 
went through the trouble of doing so when we wanted to involve both 
elevator nodes for a dtn2 test/demo.

Another set of observations...

Armando

Ivancic, William D. (GRC-RHN0) wrote:
> When running interoperability test the first thing one does is run dtnping or equivalent.  The next step is to extend the bundle lifetime because you suspect the clocks aren't synced.
>
> Just and observation.
>
> -- will
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Kevin Fall
>> Sent: Wednesday, July 29, 2009 9:04 AM
>> To: Daniel Ellard
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] For our discussion Friday: possible
>> extensions for the bundle protocol
>>
>>
>> On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>>
>>     
>>> Kevin Fall wrote:
>>>       
>>>> I have some thoughts...
>>>>
>>>> I am suspicious of the idea that synchronized clocks are that hard to
>>>> obtain.  I understand that there are certain cases where this can
>>>> happen, but I would like to preserve the notion that not have sync'd
>>>> time is mistake, and not a normal operating condition.  I'm of the
>>>> opinion that in the vast majority of cases, loose sync'd time is
>>>> possible and is to be desired.
>>>>         
>>> I agree that in many cases it is possible and desirable, but
>>> not all.  Synch'd time should be viewed as a convenient
>>> luxury: desirable and useful, but it must NOT be required.
>>>       
>> I sense agreement but a difference in perspective.  It's not a
>> convenient luxury, it is the "normal case".  However, yes, it seems as
>> though it should be possible to operate even in the "abnormal" case.
>> So, for example, we can operate in the Internet even when the DNS
>> isn't quite working correctly.
>>
>>     
>>>       
>>>> The comments regarding GPS are too limited.  GPS may not be available
>>>> in some cases, but others (including military systems) very often
>>>> still require time and position even if GPS may be denied.
>>>>         
>>> Often, but not always--see previous point.  We don't want a
>>> protocol that usually works (where the value of "usually" is
>>> the matter of some debate); we want a protocol that works on
>>> all the relevant systems where DTN adds value in the field.
>>> We know that this does and will continue to include a large
>>> number of systems with terrible clocks.
>>>
>>> Why would we want a protocol that makes assumptions we know
>>> don't always hold, when we can have a protocol based on
>>> assumptions that do?
>>>       
>> I'm not sure its worth arguing over "large" and "often".  My point is
>> that most of the world (and much of 'beyond this world') have
>> reasonably sync'd clocks and that if they don't they probably should
>> because its not that hard.  But yes there are some cases where it is
>> hard, so we should find a way of working there too...  But I see no
>> reason to optimize for the worst possible case.  imho...
>>
>> - K
>>
>>     
>>> -Dan
>>>
>>> --
>>> Daniel Ellard, Ph.D.
>>> Senior Scientist, Network Research
>>> BBN Technologies
>>> 10 Moulton Street
>>> Cambridge, MA 02138
>>> [email-masked]
>>>       
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>     
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Kevin Fall <[email-masked]>, Daniel Ellard <[email-masked]>
Date: Wed, 29 Jul 2009 16:28:58 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions	for the bundle protocol

When running interoperability test the first thing one does is run dtnping or equivalent.  The next step is to extend the bundle lifetime because you suspect the clocks aren't synced.

Just and observation.

-- will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Wednesday, July 29, 2009 9:04 AM
>To: Daniel Ellard
>Cc: [email-masked]
>Subject: Re: [dtn-interest] For our discussion Friday: possible
>extensions for the bundle protocol
>
>
>On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:
>
>> Kevin Fall wrote:
>>> I have some thoughts...
>>>
>>> I am suspicious of the idea that synchronized clocks are that hard to
>>> obtain.  I understand that there are certain cases where this can
>>> happen, but I would like to preserve the notion that not have sync'd
>>> time is mistake, and not a normal operating condition.  I'm of the
>>> opinion that in the vast majority of cases, loose sync'd time is
>>> possible and is to be desired.
>>
>> I agree that in many cases it is possible and desirable, but
>> not all.  Synch'd time should be viewed as a convenient
>> luxury: desirable and useful, but it must NOT be required.
>
>I sense agreement but a difference in perspective.  It's not a
>convenient luxury, it is the "normal case".  However, yes, it seems as
>though it should be possible to operate even in the "abnormal" case.
>So, for example, we can operate in the Internet even when the DNS
>isn't quite working correctly.
>
>>
>>
>>> The comments regarding GPS are too limited.  GPS may not be available
>>> in some cases, but others (including military systems) very often
>>> still require time and position even if GPS may be denied.
>>
>> Often, but not always--see previous point.  We don't want a
>> protocol that usually works (where the value of "usually" is
>> the matter of some debate); we want a protocol that works on
>> all the relevant systems where DTN adds value in the field.
>> We know that this does and will continue to include a large
>> number of systems with terrible clocks.
>>
>> Why would we want a protocol that makes assumptions we know
>> don't always hold, when we can have a protocol based on
>> assumptions that do?
>
>I'm not sure its worth arguing over "large" and "often".  My point is
>that most of the world (and much of 'beyond this world') have
>reasonably sync'd clocks and that if they don't they probably should
>because its not that hard.  But yes there are some cases where it is
>hard, so we should find a way of working there too...  But I see no
>reason to optimize for the worst possible case.  imho...
>
>- K
>
>>
>>
>> -Dan
>>
>> --
>> Daniel Ellard, Ph.D.
>> Senior Scientist, Network Research
>> BBN Technologies
>> 10 Moulton Street
>> Cambridge, MA 02138
>> [email-masked]
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Wed, 29 Jul 2009 10:35:33 -0700
Subject: [dtn-interest] Fwd: 1-day IETF registrations

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

And now a word from our sponsors....

Begin forwarded message:

> From: Aaron Falk
> Date: July 29, 2009 10:26:21 AM PDT
> To: Internet Research Steering Group
> Cc: Russ Housley
> Subject: [IRSG] 1-day IETF registrations
>
> Folks-
>
> The IETF will be trying an experiment at the IETF-76 with one-day
> registrations.  I've been asked about this in the past since the IETF
> registration is fairly expensive for folks who come only to attend  
> an RG
> meeting.  Thought you might find this of interest.
>
> That's the good news.  The bad news, or really a reminder of prior bad
> news, is that Russ made informed that the IETF had some trouble with
> working group meeting scheduling.  He reminded me that the  
> secretariat's
> policy has been that the IETF gets first crack at meeting rooms. IETF
> and IRTF meeting requests will be considered together and if there  
> is a
> conflict the IETF gets precedence.
>
> If this becomes problematic, I can revisit it with him but most people
> are here for the working groups and the constraints on wg scheduling  
> are
> difficult.  So, I ask that you try to be understanding of late agenda
> changes that cause your meeting to move and to set the expectations of
> your RG that this is a real possibility.
>
> thanks,
>
> --aaron

--Apple-Mail-4--1205915
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">And now a word from our =
sponsors....<br><div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>From: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica">Aaron Falk</font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font =
face=3D"Helvetica" size=3D"5" color=3D"#000000" style=3D"font: 18.0px =
Helvetica; color: #000000"><b>Date: </b></font><font face=3D"Helvetica" =
size=3D"5" style=3D"font: 18.0px Helvetica">July 29, 2009 10:26:21 AM =
PDT</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>To: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Internet Research Steering =
Group</font></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font face=3D"Helvetica" =
size=3D"5" color=3D"#000000" style=3D"font: 18.0px Helvetica; color: =
#000000"><b>Cc: </b></font><font face=3D"Helvetica" size=3D"5" =
style=3D"font: 18.0px Helvetica">Russ Housley</font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font face=3D"Helvetica" size=3D"5" color=3D"#000000" =
style=3D"font: 18.0px Helvetica; color: #000000"><b>Subject: =
</b></font><font face=3D"Helvetica" size=3D"5" style=3D"font: 18.0px =
Helvetica"><b>[IRSG] 1-day IETF registrations</b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><br></div> =
</div><div>Folks-<br><br>The IETF will be trying an experiment at the =
IETF-76 with one-day<br>registrations. &nbsp;I've been asked about this =
in the past since the IETF<br>registration is fairly expensive for folks =
who come only to attend an RG<br>meeting. &nbsp;Thought you might find =
this of interest.<br><br>That's the good news. &nbsp;The bad news, or =
really a reminder of prior bad<br>news, is that Russ made informed that =
the IETF had some trouble with<br>working group meeting scheduling. =
&nbsp;He reminded me that the secretariat's<br>policy has been that the =
IETF gets first crack at meeting rooms. IETF<br>and IRTF meeting =
requests will be considered together and if there is a<br>conflict the =
IETF gets precedence. <br><br>If this becomes problematic, I can revisit =
it with him but most people<br>are here for the working groups and the =
constraints on wg scheduling are<br>difficult. &nbsp;So, I ask that you =
try to be understanding of late agenda<br>changes that cause your =
meeting to move and to set the expectations of<br>your RG that this is a =
real =
possibility.<br><br>thanks,<br><br>--aaron<br></div></blockquote></div></b=
ody></html>=

--Apple-Mail-4--1205915--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Armando Caro <[email-masked]>, "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 29 Jul 2009 10:21:23 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions forthe bundle protocol

Sure, you don't have to maintain interoperability with an Experimental spec.  You don't have to maintain interoperability with a Standard, either; U.S. law is quite lenient in this regard.

You only need to conform to an RFC if you want to be interoperable with other implementations that conform to that RFC.  That turns out to be convenient in the case of some Experimental RFCs, such as HIP and NORM.  And I would expect conformance to RFC 5050 -- which was developed mostly on DARPA funding and addresses a variety of DARPA design concerns -- to be important for a DARPA-funded implementation.  But that's entirely up to you.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Armando Caro
> Sent: Wednesday, July 29, 2009 6:17 AM
> To: Eddy, Wesley M. (GRC-MS00)[Verizon]
> Cc: [email-masked]
> Subject: Re: [dtn-interest] For our discussion Friday: possible extensions
> forthe bundle protocol
> 
> Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> >>   - Relative Timestamps SHOULD preserve interoperability with
> >>     DTN implementations conforming to RFC 5050.
> >>
> >> ...
> >>
> >>   - Hops To Live SHOULD interoperate with nodes conforming to
> >>     RFC 5050.
> >>
> >
> > I wouldn't make this a requirement; it's limiting and there's
> > not much need to worry about it that I see.  The spec in 5050
> > is "Experimental", and now that we've all experimented with it,
> > it's a good time to improve it!  Changes to the BA software
> > should be minimal, and given the current early state of
> > (in?)interoperability, there's not much worry about incremental
> > deployment or disturbing the installed base.
> >
> Wesley,
> 
> I agree. I guess we put these "SHOULDs" in to try to minimize deviation
> from 5050 when possible, but you are probably right in that we don't
> have to maintain interoperability with an Experimental spec.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Will Leland <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 29 Jul 2009 10:06:04 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for	the bundle protocol

Will, some comments in-line below.

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Will Leland
> Sent: Wednesday, July 29, 2009 1:23 AM
> To: [email-masked]
> Subject: [dtn-interest] For our discussion Friday: possible extensions for
> the bundle protocol
> 
> We'd appreciate ideas and feedback on the following strawman;
> we'll briefly outline these ideas in Friday's DTNRG meeting as
> well, but are hoping that the bulk of that timeslot will be RG
> discussion.
> 
> Three issues have proven to be important in our main environments
> (such as MANETs): Relative Timestamps, Hops to Live, and more
> bits for the Class of Service field. This note summarizes their
> motivations and requirements, based on our experience:
> 
> RELATIVE TIMESTAMPS
> 
> == Motivation:
> 
>    The use of absolute timestamps, as specified in RFC 5050, requires
>    that nodes within a DTN to have synchronized clocks. However,
>    synchronized clocks is not always attainable in many target
>    operational environments, such as military networks. There are many
>    reasons why it may not be feasible to synchronize clocks across a
>    DTN:
> 
>         - Protocols like Network Time Protocol (NTP) cannot function
>            properly in a disruption prone network.
> 
>         - Nodes may not have GPS, or may not be able to rely on GPS
>           for accurate time. For example, military systems often
>           cannot rely on GPS due to the possibility of jamming.
> 
>        - Nodes may not have accurate clocks. The size and cost of
>           atomic clocks make them impractical for many fielded systems.
>           Systems with low-cost clocks typically incur high and
>           highly variable drift rates in environments that are not
>           themselves well controlled. (Field environments, for
>           example, may expose DTN nodes to temperatures below
>           -50 C or above +50 C.)
> 
>        - Nodes may not have battery backed up clocks. For example,
>          military systems usually do not have any battery backed up
>          clock for issues of storage and maintenance.
> 
> == Requirements:
> 
>    - Relative Timestamps MUST NOT depend on time synchronization
>      between nodes.
> 
>    - Relative Timestamps MUST NOT depend on a node maintaining
>      time across reboots.
> 
>    - Relative Timestamps MUST assure unique timestamp sequence
>      numbers.
> 
>    - Relative Timestamps and supporting fields SHOULD be in the
>      primary bundle block.
> 
>    - Relative Timestamps SHOULD not interfere with BSP's ability to
>      perform end-to-end integrity.
> 
>    - To support Relative Timestamps the BPA MAY accept input/hints
>      from CLAs.
> 
>    - Relative Timestamps SHOULD preserve interoperability with
>      DTN implementations conforming to RFC 5050.

I agree with Kevin that (a) the environments in which loose clock synchronization among nodes is impossible are a small (for some value of "small") minority of environments in which DTN can be useful, but (b) that minority is significant enough to justify developing an optional additional design element in Bundle Protocol.

At this point, though, I don't see any good way to make that design element interoperable with RFC 5050.  Since people are starting to plan some serious investments in DTN deployments based on RFC 5050, I think we need to make some decisions soon.

> HOPS TO LIVE
> 
> == Motivation:
> 
>    Transient routing loops are unavoidable in many networks. Hops To
>    Live provides a heuristic for detecting when a bundle is traversing
>    a loop and a mechanism for discarding those bundles from the
>    network. These capabilities are important for saving resources
>    (bandwidth, battery, and storage) in the case of transient routing
>    loops. In MANETs, the roundtrip time for a routing loop will
>    often be far shorter than the lifetime of the bundle.
> 
> == Requirements:
> 
>    - If Hops To Live is greater than zero, Hops To Live MUST
>      be decremented each time a bundle is forwarded.
> 
>    - Hops To Live SHOULD be a field in the primary bundle block.
> 
>    - Hops To Live SHOULD NOT impact the BSP specification.
> 
>    - Hops To Live SHOULD interoperate with nodes conforming to
>      RFC 5050.

This additional field can't live in the primary block without violating the BSP specification, so you've got conflicting requirements.  What's the argument for requiring the hops-to-live count in every bundle rather than only in bundles traversing routing loops (in an extension block)?

> CLASS OF SERVICE
> 
> == Motivation:
> 
>    The CoS field has fewer bits than the IP ToS field. To directly
>    map IP ToS bits to CoS bits, the CoS field should have at least
>    the same number of bits. This direct mapping is important to
>    some users.
> 
> == Requirements:
> 
>    - The CoS field SHOULD have at least as many bits as the
>      IP ToS field.

Again, what's wrong with having an extension block that contains IP ToS bits, for those bundles that care about IP ToS?  What's the argument for requiring the IP ToS in every bundle, including bundles that never run over IP?

Scott

From: Kevin Fall <[email-masked]>
To: Greg Troxel <[email-masked]>
Date: Wed, 29 Jul 2009 08:29:35 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

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

>
>
> Is anyone working on how to run NTP over BP?  In my view BP should  
> stand
> alone, rather than always assume there is IP underneath it.

Eh?  Who assumes there is IP underneath?

- K
>

--Apple-Mail-3--8763950
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><br>Is anyone working on how to run NTP over BP? &nbsp;In my view BP should stand<br>alone, rather than always assume there is IP underneath it.</div></blockquote><div><br></div><div>Eh? &nbsp;Who assumes there is IP underneath?</div><div><br></div><div>- K</div><blockquote type="cite"><div><br></div></blockquote></div></body></html>
--Apple-Mail-3--8763950--

From: Greg Troxel <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Wed, 29 Jul 2009 11:26:04 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

--=-=-=

Kevin Fall <[email-masked]> writes:

>> Do you have a proposed value to put into the BP spec for clock sync
>> accuracy?  I have trouble coming up with one, because a wide range of
>> bundle lifetimes seem reasonable depending on the situation.
>
> For terrestrial systems (sort of the 'normal Internet' of today), we
> might base such a value on some otherwise-existing standard.  For
> example, FINRA/OATS requires 3 seconds.  See, for example:
>
> http://www.finra.org/Industry/Compliance/MarketTransparency/OATS/FAQ/P085544

Those are high-value systems.  3 seconds sounds sort of reasonable, but
it means that you had to have had GPS or NTP sync within few hours, if
we assume 200 ppm tolerance.  My concern is that 3s excludes systems
that should not be excluded, and that 600s is too long for bundle
lifetimes that ought to be supported.

Is anyone working on how to run NTP over BP?  In my view BP should stand
alone, rather than always assume there is IP underneath it.  NTP over IP
works because IP doesn't require synchronized clocks, and I don't see a
way to bootstrap NTP over BP with only absolute timestamps.

> Now, obviously we are interested in operating DTN in a bunch more
> environments.  Further discussion is warranted in order to determine
> other values.  However, I believe it would also be fine to specify
> that a BP has a configuration variable that allows one to "fuzz" this
> value for operational reasons.

But could we configure that?  In a world-wide system, you'd have to
interoperate with nodes whose configuration details you don't know, and
which aren't part of the same administrative system.  If you want to set
up several independent 10-node networks for testing, sure I can see
configuring the required offset - but I can't see it in a deployed
worldwide network.

>> Why do you want relative timestamps to generate warnings?
>
> because I believe that for most people that might use this technology
> in the future it will be an indicator that something bad has happened
> (i.e. the ability to sync time has somehow failed).

Using relative timestamps is an indication of a system designed not to
require synchronied clocks, not a failure.  I think it's best not to
merge routine system monitoring and protocol operation.  But this is of
course a very minor point.

I think the only really hard cases for operating without synchronized
clocks are:

  nodes w/o battery-backed clocks that store bundles while they are off

  bundle transport by media without CPUs (flash sticks).

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From: Kevin Fall <[email-masked]>
To: Greg Troxel <[email-masked]>
Date: Wed, 29 Jul 2009 07:21:55 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

responses inline.

On Jul 29, 2009, at Jul 296:59 AMPDT, Greg Troxel wrote:

>
> Kevin Fall <[email-masked]> writes:
>
>> I am suspicious of the idea that synchronized clocks are that hard to
>> obtain.  I understand that there are certain cases where this can
>> happen, but I would like to preserve the notion that not have sync'd
>> time is mistake, and not a normal operating condition.  I'm of the
>> opinion that in the vast majority of cases, loose sync'd time is
>> possible and is to be desired.
>
> I agree that at least loose synchronization is desired, but that's not
> really the question on the table.
>
>> The comments regarding GPS are too limited.  GPS may not be available
>> in some cases, but others (including military systems) very often
>> still require time and position even if GPS may be denied.
>
>> Problems in clock oscillating rates should, hopefully, be under a
>> threshold level so that it doesn't become limiting for us.  What I
>> mean is that if you are worrying about nanoseconds you probably don't
>> have 'loose' sync.
>
> Once we talk about 'loose' synchronization, we have to define what  
> that
> means, and what kinds of bundle lifetimes people can use.  Probably to
> have the 'loose synchronization' property, clock errors relative to  
> UTC
> have to be on the order of 10% of bundle lifetimes.  Conversely, if we
> say it's reasonable to use 1 minute bundle lifetimes, then there is a
> requirement for max 6s clock errors.
>
> Do you have a proposed value to put into the BP spec for clock sync
> accuracy?  I have trouble coming up with one, because a wide range of
> bundle lifetimes seem reasonable depending on the situation.

For terrestrial systems (sort of the 'normal Internet' of today), we  
might base such a value on some otherwise-existing standard.  For  
example, FINRA/OATS requires 3 seconds.  See, for example:

http://www.finra.org/Industry/Compliance/MarketTransparency/OATS/FAQ/P085544

Now, obviously we are interested in operating DTN in a bunch more  
environments.  Further discussion is warranted in order to determine  
other values.  However, I believe it would also be fine to specify  
that a BP has a configuration variable that allows one to "fuzz" this  
value for operational reasons.

>
>
>> I don't buy the comment "military systems usually do not have any
>> battery backed up clock".  Maybe the particular systems you are
>> working with are this way, but this statement is too general.
>
> Agreed.  I would say instead "some systems do not have battery-backed
> clocks", which is really the point.  Consider a relay node in a sensor
> network (one that doesn't generate data).

yep

>
>
>> Regarding a notion of relative time stamps, I would prefer that:
>>
>> - if real TSs become available, the system will start using them
>> - use of relative TSs are to be indicated as a warning condition by  
>> BP
>> software
>
> Why do you want relative timestamps to generate warnings?

because I believe that for most people that might use this technology  
in the future it will be an indicator that something bad has happened  
(i.e. the ability to sync time has somehow failed).

>
>
>
> The hard issue is whether clock sync should be a requirement for BP.
> The consequence of having it be a requirement is that BP cannot be  
> used
> in environments where there are machines without synchronized clocks.
> If we look at BP as an internetworking layer for large-scale systems
> instead of as a thing to be played with in the lab, then designs for
> systems where synchronized clocks cannot be assumed should exclude  
> BP as
> a possible solution.  Or alternatively, designs with BP must exclude
> nodes without clock sync.

I've suggested an operating mode where nodes w/out sync'd clocks can  
be accommodated.... I just happen to think that is an anomalous case.

>
>
>> It may be useful to extend the CoS area, but I don't find the
>> reasoning here compelling.  "Fit in the IP bits", without an example
>> use case, just doesn't seem sufficient to me.
>
> In IP, we have tunnel mode IPsec and IP-IP encapsulation, with
> guidelines for mapping TOS bits on encapsulation and ECN processing on
> decapsulation.  At BBN we have code that puts IP packets in bundles,  
> and
> without a BP TOS field that's big enough this sort of processing can't
> be done.
>
> I would argue that the TOS field size should be even bigger than IP,
> because the possibility of disconnection gives rise to more
> opportunitites to behave differently.

I would argue that it should be defined by IP at all.  There are  
definitions for the CoS fields in the bundle protocol, and they are  
different from those in IP.  It may be a good idea to do as you  
suggest, but as I suggested before I don't see the use case spelled  
out...

- K

From: Greg Troxel <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Wed, 29 Jul 2009 09:59:00 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

--=-=-=
Content-Transfer-Encoding: quoted-printable

Kevin Fall <[email-masked]> writes:

> I am suspicious of the idea that synchronized clocks are that hard to=20=
=20
> obtain.  I understand that there are certain cases where this can=20=20
> happen, but I would like to preserve the notion that not have sync'd=20=20
> time is mistake, and not a normal operating condition.  I'm of the=20=20
> opinion that in the vast majority of cases, loose sync'd time is=20=20
> possible and is to be desired.

I agree that at least loose synchronization is desired, but that's not
really the question on the table.

> The comments regarding GPS are too limited.  GPS may not be available=20=
=20
> in some cases, but others (including military systems) very often=20=20
> still require time and position even if GPS may be denied.

> Problems in clock oscillating rates should, hopefully, be under a=20=20
> threshold level so that it doesn't become limiting for us.  What I=20=20
> mean is that if you are worrying about nanoseconds you probably don't=20=
=20
> have 'loose' sync.

Once we talk about 'loose' synchronization, we have to define what that
means, and what kinds of bundle lifetimes people can use.  Probably to
have the 'loose synchronization' property, clock errors relative to UTC
have to be on the order of 10% of bundle lifetimes.  Conversely, if we
say it's reasonable to use 1 minute bundle lifetimes, then there is a
requirement for max 6s clock errors.

Do you have a proposed value to put into the BP spec for clock sync
accuracy?  I have trouble coming up with one, because a wide range of
bundle lifetimes seem reasonable depending on the situation.

> I don't buy the comment "military systems usually do not have any=20=20
> battery backed up clock".  Maybe the particular systems you are=20=20
> working with are this way, but this statement is too general.

Agreed.  I would say instead "some systems do not have battery-backed
clocks", which is really the point.  Consider a relay node in a sensor
network (one that doesn't generate data).

> Regarding a notion of relative time stamps, I would prefer that:
>
> - if real TSs become available, the system will start using them
> - use of relative TSs are to be indicated as a warning condition by BP=20=
=20
> software

Why do you want relative timestamps to generate warnings?

The hard issue is whether clock sync should be a requirement for BP.
The consequence of having it be a requirement is that BP cannot be used
in environments where there are machines without synchronized clocks.
If we look at BP as an internetworking layer for large-scale systems
instead of as a thing to be played with in the lab, then designs for
systems where synchronized clocks cannot be assumed should exclude BP as
a possible solution.  Or alternatively, designs with BP must exclude
nodes without clock sync.

> It may be useful to extend the CoS area, but I don't find the=20=20
> reasoning here compelling.  "Fit in the IP bits", without an example=20=20
> use case, just doesn't seem sufficient to me.

In IP, we have tunnel mode IPsec and IP-IP encapsulation, with
guidelines for mapping TOS bits on encapsulation and ECN processing on
decapsulation.  At BBN we have code that puts IP packets in bundles, and
without a BP TOS field that's big enough this sort of processing can't
be done.

I would argue that the TOS field size should be even bigger than IP,
because the possibility of disconnection gives rise to more
opportunitites to behave differently.

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

Date: Wed, 29 Jul 2009 09:17:11 -0400
From: Armando Caro <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions forthe bundle protocol

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>>   - Relative Timestamps SHOULD preserve interoperability with
>>     DTN implementations conforming to RFC 5050.
>>
>> ...
>>
>>   - Hops To Live SHOULD interoperate with nodes conforming to
>>     RFC 5050.
>>     
>
> I wouldn't make this a requirement; it's limiting and there's
> not much need to worry about it that I see.  The spec in 5050
> is "Experimental", and now that we've all experimented with it,
> it's a good time to improve it!  Changes to the BA software
> should be minimal, and given the current early state of
> (in?)interoperability, there's not much worry about incremental
> deployment or disturbing the installed base.
>   
Wesley,

I agree. I guess we put these "SHOULDs" in to try to minimize deviation 
from 5050 when possible, but you are probably right in that we don't 
have to maintain interoperability with an Experimental spec.

Armando

From: Kevin Fall <[email-masked]>
To: Daniel Ellard <[email-masked]>
Date: Wed, 29 Jul 2009 06:04:01 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

On Jul 29, 2009, at Jul 295:58 AMPDT, Daniel Ellard wrote:

> Kevin Fall wrote:
>> I have some thoughts...
>>
>> I am suspicious of the idea that synchronized clocks are that hard to
>> obtain.  I understand that there are certain cases where this can
>> happen, but I would like to preserve the notion that not have sync'd
>> time is mistake, and not a normal operating condition.  I'm of the
>> opinion that in the vast majority of cases, loose sync'd time is
>> possible and is to be desired.
>
> I agree that in many cases it is possible and desirable, but
> not all.  Synch'd time should be viewed as a convenient
> luxury: desirable and useful, but it must NOT be required.

I sense agreement but a difference in perspective.  It's not a  
convenient luxury, it is the "normal case".  However, yes, it seems as  
though it should be possible to operate even in the "abnormal" case.   
So, for example, we can operate in the Internet even when the DNS  
isn't quite working correctly.

>
>
>> The comments regarding GPS are too limited.  GPS may not be available
>> in some cases, but others (including military systems) very often
>> still require time and position even if GPS may be denied.
>
> Often, but not always--see previous point.  We don't want a
> protocol that usually works (where the value of "usually" is
> the matter of some debate); we want a protocol that works on
> all the relevant systems where DTN adds value in the field.
> We know that this does and will continue to include a large
> number of systems with terrible clocks.
>
> Why would we want a protocol that makes assumptions we know
> don't always hold, when we can have a protocol based on
> assumptions that do?

I'm not sure its worth arguing over "large" and "often".  My point is  
that most of the world (and much of 'beyond this world') have  
reasonably sync'd clocks and that if they don't they probably should  
because its not that hard.  But yes there are some cases where it is  
hard, so we should find a way of working there too...  But I see no  
reason to optimize for the worst possible case.  imho...

- K

>
>
> -Dan
>
> -- 
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]

Date: Wed, 29 Jul 2009 08:58:52 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Kevin Fall <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

Kevin Fall wrote:
> I have some thoughts...
> 
> I am suspicious of the idea that synchronized clocks are that hard to  
> obtain.  I understand that there are certain cases where this can  
> happen, but I would like to preserve the notion that not have sync'd  
> time is mistake, and not a normal operating condition.  I'm of the  
> opinion that in the vast majority of cases, loose sync'd time is  
> possible and is to be desired.

I agree that in many cases it is possible and desirable, but
not all.  Synch'd time should be viewed as a convenient
luxury: desirable and useful, but it must NOT be required.

> The comments regarding GPS are too limited.  GPS may not be available  
> in some cases, but others (including military systems) very often  
> still require time and position even if GPS may be denied.

Often, but not always--see previous point.  We don't want a
protocol that usually works (where the value of "usually" is
the matter of some debate); we want a protocol that works on
all the relevant systems where DTN adds value in the field.
We know that this does and will continue to include a large
number of systems with terrible clocks.

Why would we want a protocol that makes assumptions we know
don't always hold, when we can have a protocol based on
assumptions that do?

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: Will Leland <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 29 Jul 2009 06:16:10 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions forthe bundle protocol

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Will Leland
>Sent: Wednesday, July 29, 2009 4:23 AM
>
>We'd appreciate ideas and feedback on the following strawman;
>we'll briefly outline these ideas in Friday's DTNRG meeting as
>well, but are hoping that the bulk of that timeslot will be RG
>discussion.
>
>Three issues have proven to be important in our main environments
>(such as MANETs): Relative Timestamps, Hops to Live, and more
>bits for the Class of Service field. This note summarizes their
>motivations and requirements, based on our experience:

These also are important to me based on both our experiences
with DTN/BP in the lab and with a small set of bundle agents
around the world (plus one in orbit).  I also believe that
from general principles of design for robust, interoperable,
and easily-usable networking technologies, these are very
well motivated.

I only have one small comment below:

>
>   - Relative Timestamps SHOULD preserve interoperability with
>     DTN implementations conforming to RFC 5050.
>
> ...
>
>   - Hops To Live SHOULD interoperate with nodes conforming to
>     RFC 5050.

I wouldn't make this a requirement; it's limiting and there's
not much need to worry about it that I see.  The spec in 5050
is "Experimental", and now that we've all experimented with it,
it's a good time to improve it!  Changes to the BA software
should be minimal, and given the current early state of
(in?)interoperability, there's not much worry about incremental
deployment or disturbing the installed base.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: "Airst, Malcolm J." <[email-masked]>
To: Kevin Fall <[email-masked]>, Will Leland <[email-masked]>
Date: Wed, 29 Jul 2009 06:53:56 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions	for the bundle protocol

Yes, many military systems use a low current heater element for the ovenized crystal oscillator as a keep alive in extreme climates. Many military systems do need to continue operation in a GPS-denied environment, with GPS being lost due to adversary action or rugged terrain, location (underwater, caves, etc). 

Also, to reduce GPS time-to-first-fix (TTFF), some idea of the time is highly desirable. TTFF from a cold start can take many minutes, especially without a good view of the sky. Thus the oscillator need not be highly accurate, just within several seconds of UTC...

Malcolm 

********************************************************
Malcolm J Airst,
Sr. Principal Network & Dist. Systems Engineer,
The MITRE Corporation,
49185 Transmitter Rd.,
San Diego, CA 92152-7335
�
(619) 758-7822 (w)
(619) 318-3837 (c)
(619) 222-2260 (f)
********************************************************

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin Fall
Sent: Wednesday, July 29, 2009 12:41 PM
To: Will Leland
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

I have some thoughts...

I am suspicious of the idea that synchronized clocks are that hard to  
obtain.  I understand that there are certain cases where this can  
happen, but I would like to preserve the notion that not have sync'd  
time is mistake, and not a normal operating condition.  I'm of the  
opinion that in the vast majority of cases, loose sync'd time is  
possible and is to be desired.

The comments regarding GPS are too limited.  GPS may not be available  
in some cases, but others (including military systems) very often  
still require time and position even if GPS may be denied.

Problems in clock oscillating rates should, hopefully, be under a  
threshold level so that it doesn't become limiting for us.  What I  
mean is that if you are worrying about nanoseconds you probably don't  
have 'loose' sync.

I don't buy the comment "military systems usually do not have any  
battery backed up clock".  Maybe the particular systems you are  
working with are this way, but this statement is too general.

Regarding a notion of relative time stamps, I would prefer that:

- if real TSs become available, the system will start using them
- use of relative TSs are to be indicated as a warning condition by BP  
software

How would you intend to carry RTSs with retaining compatibility with  
5050?

Regarding the 'hops to live'..  For DTN, the routing loops may not be  
transient, but rather persistent, intentional and optimal.  That said,  
I understand that such a related concept may be useful.  However, I am  
not a big fan of either the IP or IPv6 hop limit fields because  
information is lost.  In particular, when you have a packet, you don't  
know how many hops it has come so far.  I would suggest something more  
like a BP option that contains a hop count and hop limit.  These could  
be separate options.

It may be useful to extend the CoS area, but I don't find the  
reasoning here compelling.  "Fit in the IP bits", without an example  
use case, just doesn't seem sufficient to me.

The upshot of my opinions:

- I think most of the capabilities you are after could be useful
- Many of the particular motivations you have chosen seem to me overly  
broad or make unnecessary assumptions
- There are other mechanisms we could use to get you what you want

- K

On Jul 29, 2009, at Jul 291:22 AMPDT, Will Leland wrote:

> We'd appreciate ideas and feedback on the following strawman;
> we'll briefly outline these ideas in Friday's DTNRG meeting as
> well, but are hoping that the bulk of that timeslot will be RG
> discussion.
>
> Three issues have proven to be important in our main environments
> (such as MANETs): Relative Timestamps, Hops to Live, and more
> bits for the Class of Service field. This note summarizes their
> motivations and requirements, based on our experience:
>
> RELATIVE TIMESTAMPS
>
> == Motivation:
>
> The use of absolute timestamps, as specified in RFC 5050, requires
> that nodes within a DTN to have synchronized clocks. However,
> synchronized clocks is not always attainable in many target
> operational environments, such as military networks. There are many
> reasons why it may not be feasible to synchronize clocks across a
> DTN:
>
>      - Protocols like Network Time Protocol (NTP) cannot function
>         properly in a disruption prone network.
>
>      - Nodes may not have GPS, or may not be able to rely on GPS
>        for accurate time. For example, military systems often
>        cannot rely on GPS due to the possibility of jamming.
>
>     - Nodes may not have accurate clocks. The size and cost of
>        atomic clocks make them impractical for many fielded systems.
>        Systems with low-cost clocks typically incur high and
>        highly variable drift rates in environments that are not
>        themselves well controlled. (Field environments, for
>        example, may expose DTN nodes to temperatures below
>        -50 C or above +50 C.)
>
>     - Nodes may not have battery backed up clocks. For example,
>       military systems usually do not have any battery backed up
>       clock for issues of storage and maintenance.
>
> == Requirements:
>
> - Relative Timestamps MUST NOT depend on time synchronization
>   between nodes.
>
> - Relative Timestamps MUST NOT depend on a node maintaining
>   time across reboots.
>
> - Relative Timestamps MUST assure unique timestamp sequence
>   numbers.
>
> - Relative Timestamps and supporting fields SHOULD be in the
>   primary bundle block.
>
> - Relative Timestamps SHOULD not interfere with BSP's ability to
>   perform end-to-end integrity.
>
> - To support Relative Timestamps the BPA MAY accept input/hints
>   from CLAs.
>
> - Relative Timestamps SHOULD preserve interoperability with
>   DTN implementations conforming to RFC 5050.
>
>
> HOPS TO LIVE
>
> == Motivation:
>
> Transient routing loops are unavoidable in many networks. Hops To
> Live provides a heuristic for detecting when a bundle is traversing
> a loop and a mechanism for discarding those bundles from the
> network. These capabilities are important for saving resources
> (bandwidth, battery, and storage) in the case of transient routing
> loops. In MANETs, the roundtrip time for a routing loop will
> often be far shorter than the lifetime of the bundle.
>
> == Requirements:
>
> - If Hops To Live is greater than zero, Hops To Live MUST
>   be decremented each time a bundle is forwarded.
>
> - Hops To Live SHOULD be a field in the primary bundle block.
>
> - Hops To Live SHOULD NOT impact the BSP specification.
>
> - Hops To Live SHOULD interoperate with nodes conforming to
>   RFC 5050.
>
>
> CLASS OF SERVICE
>
> == Motivation:
>
> The CoS field has fewer bits than the IP ToS field. To directly
> map IP ToS bits to CoS bits, the CoS field should have at least
> the same number of bits. This direct mapping is important to
> some users.
>
> == Requirements:
>
> - The CoS field SHOULD have at least as many bits as the
>   IP ToS field.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: Will Leland <[email-masked]>
Date: Wed, 29 Jul 2009 03:40:48 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

I have some thoughts...

I am suspicious of the idea that synchronized clocks are that hard to  
obtain.  I understand that there are certain cases where this can  
happen, but I would like to preserve the notion that not have sync'd  
time is mistake, and not a normal operating condition.  I'm of the  
opinion that in the vast majority of cases, loose sync'd time is  
possible and is to be desired.

The comments regarding GPS are too limited.  GPS may not be available  
in some cases, but others (including military systems) very often  
still require time and position even if GPS may be denied.

Problems in clock oscillating rates should, hopefully, be under a  
threshold level so that it doesn't become limiting for us.  What I  
mean is that if you are worrying about nanoseconds you probably don't  
have 'loose' sync.

I don't buy the comment "military systems usually do not have any  
battery backed up clock".  Maybe the particular systems you are  
working with are this way, but this statement is too general.

Regarding a notion of relative time stamps, I would prefer that:

- if real TSs become available, the system will start using them
- use of relative TSs are to be indicated as a warning condition by BP  
software

How would you intend to carry RTSs with retaining compatibility with  
5050?

Regarding the 'hops to live'..  For DTN, the routing loops may not be  
transient, but rather persistent, intentional and optimal.  That said,  
I understand that such a related concept may be useful.  However, I am  
not a big fan of either the IP or IPv6 hop limit fields because  
information is lost.  In particular, when you have a packet, you don't  
know how many hops it has come so far.  I would suggest something more  
like a BP option that contains a hop count and hop limit.  These could  
be separate options.

It may be useful to extend the CoS area, but I don't find the  
reasoning here compelling.  "Fit in the IP bits", without an example  
use case, just doesn't seem sufficient to me.

The upshot of my opinions:

- I think most of the capabilities you are after could be useful
- Many of the particular motivations you have chosen seem to me overly  
broad or make unnecessary assumptions
- There are other mechanisms we could use to get you what you want

- K

On Jul 29, 2009, at Jul 291:22 AMPDT, Will Leland wrote:

> We'd appreciate ideas and feedback on the following strawman;
> we'll briefly outline these ideas in Friday's DTNRG meeting as
> well, but are hoping that the bulk of that timeslot will be RG
> discussion.
>
> Three issues have proven to be important in our main environments
> (such as MANETs): Relative Timestamps, Hops to Live, and more
> bits for the Class of Service field. This note summarizes their
> motivations and requirements, based on our experience:
>
> RELATIVE TIMESTAMPS
>
> == Motivation:
>
> The use of absolute timestamps, as specified in RFC 5050, requires
> that nodes within a DTN to have synchronized clocks. However,
> synchronized clocks is not always attainable in many target
> operational environments, such as military networks. There are many
> reasons why it may not be feasible to synchronize clocks across a
> DTN:
>
>      - Protocols like Network Time Protocol (NTP) cannot function
>         properly in a disruption prone network.
>
>      - Nodes may not have GPS, or may not be able to rely on GPS
>        for accurate time. For example, military systems often
>        cannot rely on GPS due to the possibility of jamming.
>
>     - Nodes may not have accurate clocks. The size and cost of
>        atomic clocks make them impractical for many fielded systems.
>        Systems with low-cost clocks typically incur high and
>        highly variable drift rates in environments that are not
>        themselves well controlled. (Field environments, for
>        example, may expose DTN nodes to temperatures below
>        -50 C or above +50 C.)
>
>     - Nodes may not have battery backed up clocks. For example,
>       military systems usually do not have any battery backed up
>       clock for issues of storage and maintenance.
>
> == Requirements:
>
> - Relative Timestamps MUST NOT depend on time synchronization
>   between nodes.
>
> - Relative Timestamps MUST NOT depend on a node maintaining
>   time across reboots.
>
> - Relative Timestamps MUST assure unique timestamp sequence
>   numbers.
>
> - Relative Timestamps and supporting fields SHOULD be in the
>   primary bundle block.
>
> - Relative Timestamps SHOULD not interfere with BSP's ability to
>   perform end-to-end integrity.
>
> - To support Relative Timestamps the BPA MAY accept input/hints
>   from CLAs.
>
> - Relative Timestamps SHOULD preserve interoperability with
>   DTN implementations conforming to RFC 5050.
>
>
> HOPS TO LIVE
>
> == Motivation:
>
> Transient routing loops are unavoidable in many networks. Hops To
> Live provides a heuristic for detecting when a bundle is traversing
> a loop and a mechanism for discarding those bundles from the
> network. These capabilities are important for saving resources
> (bandwidth, battery, and storage) in the case of transient routing
> loops. In MANETs, the roundtrip time for a routing loop will
> often be far shorter than the lifetime of the bundle.
>
> == Requirements:
>
> - If Hops To Live is greater than zero, Hops To Live MUST
>   be decremented each time a bundle is forwarded.
>
> - Hops To Live SHOULD be a field in the primary bundle block.
>
> - Hops To Live SHOULD NOT impact the BSP specification.
>
> - Hops To Live SHOULD interoperate with nodes conforming to
>   RFC 5050.
>
>
> CLASS OF SERVICE
>
> == Motivation:
>
> The CoS field has fewer bits than the IP ToS field. To directly
> map IP ToS bits to CoS bits, the CoS field should have at least
> the same number of bits. This direct mapping is important to
> some users.
>
> == Requirements:
>
> - The CoS field SHOULD have at least as many bits as the
>   IP ToS field.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: Will Leland <[email-masked]>
Date: Wed, 29 Jul 2009 03:37:34 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

I have some thoughts...

I am suspicious of the idea that synchronized clocks are that hard to  
obtain.  I understand that there are certain cases where this can  
happen, but I would like to preserve the notion that not have sync'd  
time is mistake, and not a normal operating condition.  I'm of the  
opinion that in the vast majority of cases, loose sync'd time is  
possible and is to be desired.

The comments regarding GPS are too limited.  GPS may not be available  
in some cases, but others (including military systems) very often  
still require time and position even if GPS may be denied.

Problems in clock oscillating rates should, hopefully, be under a  
threshold level so that it doesn't become limiting for us.  What I  
mean is that if you are worrying about nanoseconds you probably don't  
have 'loose' sync.

I don't buy the comment "military systems usually do not have any  
battery backed up clock".  Maybe the particular systems you are  
working with are this way, but this statement is too general.

Regarding a notion of relative time stamps, I would prefer that:

- if real TSs become available, the system will start using them
- use of relative TSs are to be indicated as a warning condition by BP  
software

How would you intend to carry RTSs with retaining compatibility with  
5050?

Regarding the 'hops to live'..  For DTN, the routing loops may not be  
transient, but rather persistent, intentional and optimal.  That said,  
I understand that such a related concept may be useful.  However, I am  
not a big fan of either the IP or IPv6 hop limit fields because  
information is lost.  In particular, when you have a packet, you don't  
know how many hops it has come so far.  I would suggest something more  
like a BP option that contains a hop count and hop limit.  These could  
be separate options.

It may be useful to extend the CoS area, but I don't find the  
reasoning here compelling.  "Fit in the IP bits", without an example  
use case, just doesn't seem sufficient to me.

The upshot of my opinions:

- I think most of the capabilities you are after could be useful
- Many of the particular motivations you have chosen seem to me overly  
broad or make unnecessary assumptions
- There are other mechanisms we could use to get you what you want

- K

On Jul 29, 2009, at Jul 291:22 AMPDT, Will Leland wrote:

> We'd appreciate ideas and feedback on the following strawman;
> we'll briefly outline these ideas in Friday's DTNRG meeting as
> well, but are hoping that the bulk of that timeslot will be RG
> discussion.
>
> Three issues have proven to be important in our main environments
> (such as MANETs): Relative Timestamps, Hops to Live, and more
> bits for the Class of Service field. This note summarizes their
> motivations and requirements, based on our experience:
>
> RELATIVE TIMESTAMPS
>
> == Motivation:
>
>  The use of absolute timestamps, as specified in RFC 5050, requires
>  that nodes within a DTN to have synchronized clocks. However,
>  synchronized clocks is not always attainable in many target
>  operational environments, such as military networks. There are many
>  reasons why it may not be feasible to synchronize clocks across a
>  DTN:
>
>       - Protocols like Network Time Protocol (NTP) cannot function
>          properly in a disruption prone network.
>
>       - Nodes may not have GPS, or may not be able to rely on GPS
>         for accurate time. For example, military systems often
>         cannot rely on GPS due to the possibility of jamming.
>
>      - Nodes may not have accurate clocks. The size and cost of
>         atomic clocks make them impractical for many fielded systems.
>         Systems with low-cost clocks typically incur high and
>         highly variable drift rates in environments that are not
>         themselves well controlled. (Field environments, for
>         example, may expose DTN nodes to temperatures below
>         -50 C or above +50 C.)
>
>      - Nodes may not have battery backed up clocks. For example,
>        military systems usually do not have any battery backed up
>        clock for issues of storage and maintenance.
>
> == Requirements:
>
>  - Relative Timestamps MUST NOT depend on time synchronization
>    between nodes.
>
>  - Relative Timestamps MUST NOT depend on a node maintaining
>    time across reboots.
>
>  - Relative Timestamps MUST assure unique timestamp sequence
>    numbers.
>
>  - Relative Timestamps and supporting fields SHOULD be in the
>    primary bundle block.
>
>  - Relative Timestamps SHOULD not interfere with BSP's ability to
>    perform end-to-end integrity.
>
>  - To support Relative Timestamps the BPA MAY accept input/hints
>    from CLAs.
>
>  - Relative Timestamps SHOULD preserve interoperability with
>    DTN implementations conforming to RFC 5050.
>
>
> HOPS TO LIVE
>
> == Motivation:
>
>  Transient routing loops are unavoidable in many networks. Hops To
>  Live provides a heuristic for detecting when a bundle is traversing
>  a loop and a mechanism for discarding those bundles from the
>  network. These capabilities are important for saving resources
>  (bandwidth, battery, and storage) in the case of transient routing
>  loops. In MANETs, the roundtrip time for a routing loop will
>  often be far shorter than the lifetime of the bundle.
>
> == Requirements:
>
>  - If Hops To Live is greater than zero, Hops To Live MUST
>    be decremented each time a bundle is forwarded.
>
>  - Hops To Live SHOULD be a field in the primary bundle block.
>
>  - Hops To Live SHOULD NOT impact the BSP specification.
>
>  - Hops To Live SHOULD interoperate with nodes conforming to
>    RFC 5050.
>
>
> CLASS OF SERVICE
>
> == Motivation:
>
>  The CoS field has fewer bits than the IP ToS field. To directly
>  map IP ToS bits to CoS bits, the CoS field should have at least
>  the same number of bits. This direct mapping is important to
>  some users.
>
> == Requirements:
>
>  - The CoS field SHOULD have at least as many bits as the
>    IP ToS field.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Airst, Malcolm J." <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Wed, 29 Jul 2009 06:14:15 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for	the bundle protocol

Will- I agree with your relative timestamp concept. However even in hostile or disrupted environments, I suspect you'd still need *frequency* references or a source of accurate local or derived frequency information to calibrate on-board equipment such as radios etc. 

The requirements draft in. TICTOC differentiates between time and frequency reference information and transmission of each through a network. 

Just a thought,
Malcolm

--------------------------
Malcolm J Airst, 
Sr Principal Engineer,
MITRE San Diego
619-318-3837

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Wed Jul 29 04:22:47 2009
Subject: [dtn-interest] For our discussion Friday: possible extensions for	the bundle protocol

We'd appreciate ideas and feedback on the following strawman;
we'll briefly outline these ideas in Friday's DTNRG meeting as
well, but are hoping that the bulk of that timeslot will be RG
discussion.

Three issues have proven to be important in our main environments
(such as MANETs): Relative Timestamps, Hops to Live, and more
bits for the Class of Service field. This note summarizes their
motivations and requirements, based on our experience:

RELATIVE TIMESTAMPS

== Motivation:

   The use of absolute timestamps, as specified in RFC 5050, requires
   that nodes within a DTN to have synchronized clocks. However,
   synchronized clocks is not always attainable in many target
   operational environments, such as military networks. There are many
   reasons why it may not be feasible to synchronize clocks across a
   DTN:

        - Protocols like Network Time Protocol (NTP) cannot function
           properly in a disruption prone network.

        - Nodes may not have GPS, or may not be able to rely on GPS
          for accurate time. For example, military systems often
          cannot rely on GPS due to the possibility of jamming.

       - Nodes may not have accurate clocks. The size and cost of
          atomic clocks make them impractical for many fielded systems.
          Systems with low-cost clocks typically incur high and
          highly variable drift rates in environments that are not
          themselves well controlled. (Field environments, for
          example, may expose DTN nodes to temperatures below
          -50 C or above +50 C.)

       - Nodes may not have battery backed up clocks. For example,
         military systems usually do not have any battery backed up
         clock for issues of storage and maintenance.

== Requirements:

   - Relative Timestamps MUST NOT depend on time synchronization
     between nodes.
 
   - Relative Timestamps MUST NOT depend on a node maintaining
     time across reboots.

   - Relative Timestamps MUST assure unique timestamp sequence
     numbers.

   - Relative Timestamps and supporting fields SHOULD be in the
     primary bundle block.

   - Relative Timestamps SHOULD not interfere with BSP's ability to
     perform end-to-end integrity.

   - To support Relative Timestamps the BPA MAY accept input/hints
     from CLAs.

   - Relative Timestamps SHOULD preserve interoperability with
     DTN implementations conforming to RFC 5050.

HOPS TO LIVE

== Motivation:

   Transient routing loops are unavoidable in many networks. Hops To
   Live provides a heuristic for detecting when a bundle is traversing
   a loop and a mechanism for discarding those bundles from the
   network. These capabilities are important for saving resources
   (bandwidth, battery, and storage) in the case of transient routing
   loops. In MANETs, the roundtrip time for a routing loop will
   often be far shorter than the lifetime of the bundle.

== Requirements:

   - If Hops To Live is greater than zero, Hops To Live MUST
     be decremented each time a bundle is forwarded.

   - Hops To Live SHOULD be a field in the primary bundle block.

   - Hops To Live SHOULD NOT impact the BSP specification.

   - Hops To Live SHOULD interoperate with nodes conforming to
     RFC 5050.

CLASS OF SERVICE

== Motivation:

   The CoS field has fewer bits than the IP ToS field. To directly
   map IP ToS bits to CoS bits, the CoS field should have at least
   the same number of bits. This direct mapping is important to
   some users.

== Requirements:

   - The CoS field SHOULD have at least as many bits as the
     IP ToS field.

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 29 Jul 2009 05:22:08 -0400
From: Will Leland <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for	the bundle protocol

Splendid! Thanks for your interest, Will. Collaboration
would be very welcome.

We have some preliminary designs and experience
for our environment, but we want to get the requirements
and context right as the foundation for working on
wider solutions.

-- the other Will

Ivancic, William D. (GRC-RHN0) wrote:
> At first look, I am in agreement with your assessment and requirements below.  If BBN has not already implemented this, NASA GRC was consider implementing the same or similar for outside the space backbone environment.  We would certainly be interested in collaborating on a solution.
>
> I believe my colleagues at GRC are also in agreement, but I'll let them confirm or deny.
>
> On Friday, I or Joseph Ishac will be presenting NASA's DTN development status (both for space and non-space environments).
>
> -- Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Will Leland <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 29 Jul 2009 03:59:59 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] For our discussion Friday: possible extensions for	the bundle protocol

At first look, I am in agreement with your assessment and requirements below.  If BBN has not already implemented this, NASA GRC was consider implementing the same or similar for outside the space backbone environment.  We would certainly be interested in collaborating on a solution.

I believe my colleagues at GRC are also in agreement, but I'll let them confirm or deny.

On Friday, I or Joseph Ishac will be presenting NASA's DTN development status (both for space and non-space environments).

-- Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Will Leland
>Sent: Wednesday, July 29, 2009 4:23 AM
>To: [email-masked]
>Subject: [dtn-interest] For our discussion Friday: possible extensions
>for the bundle protocol
>
>We'd appreciate ideas and feedback on the following strawman;
>we'll briefly outline these ideas in Friday's DTNRG meeting as
>well, but are hoping that the bulk of that timeslot will be RG
>discussion.
>
>Three issues have proven to be important in our main environments
>(such as MANETs): Relative Timestamps, Hops to Live, and more
>bits for the Class of Service field. This note summarizes their
>motivations and requirements, based on our experience:
>
>RELATIVE TIMESTAMPS
>
>== Motivation:
>
>   The use of absolute timestamps, as specified in RFC 5050, requires
>   that nodes within a DTN to have synchronized clocks. However,
>   synchronized clocks is not always attainable in many target
>   operational environments, such as military networks. There are many
>   reasons why it may not be feasible to synchronize clocks across a
>   DTN:
>
>        - Protocols like Network Time Protocol (NTP) cannot function
>           properly in a disruption prone network.
>
>        - Nodes may not have GPS, or may not be able to rely on GPS
>          for accurate time. For example, military systems often
>          cannot rely on GPS due to the possibility of jamming.
>
>       - Nodes may not have accurate clocks. The size and cost of
>          atomic clocks make them impractical for many fielded systems.
>          Systems with low-cost clocks typically incur high and
>          highly variable drift rates in environments that are not
>          themselves well controlled. (Field environments, for
>          example, may expose DTN nodes to temperatures below
>          -50 C or above +50 C.)
>
>       - Nodes may not have battery backed up clocks. For example,
>         military systems usually do not have any battery backed up
>         clock for issues of storage and maintenance.
>
>== Requirements:
>
>   - Relative Timestamps MUST NOT depend on time synchronization
>     between nodes.
>
>   - Relative Timestamps MUST NOT depend on a node maintaining
>     time across reboots.
>
>   - Relative Timestamps MUST assure unique timestamp sequence
>     numbers.
>
>   - Relative Timestamps and supporting fields SHOULD be in the
>     primary bundle block.
>
>   - Relative Timestamps SHOULD not interfere with BSP's ability to
>     perform end-to-end integrity.
>
>   - To support Relative Timestamps the BPA MAY accept input/hints
>     from CLAs.
>
>   - Relative Timestamps SHOULD preserve interoperability with
>     DTN implementations conforming to RFC 5050.
>
>
>HOPS TO LIVE
>
>== Motivation:
>
>   Transient routing loops are unavoidable in many networks. Hops To
>   Live provides a heuristic for detecting when a bundle is traversing
>   a loop and a mechanism for discarding those bundles from the
>   network. These capabilities are important for saving resources
>   (bandwidth, battery, and storage) in the case of transient routing
>   loops. In MANETs, the roundtrip time for a routing loop will
>   often be far shorter than the lifetime of the bundle.
>
>== Requirements:
>
>   - If Hops To Live is greater than zero, Hops To Live MUST
>     be decremented each time a bundle is forwarded.
>
>   - Hops To Live SHOULD be a field in the primary bundle block.
>
>   - Hops To Live SHOULD NOT impact the BSP specification.
>
>   - Hops To Live SHOULD interoperate with nodes conforming to
>     RFC 5050.
>
>
>CLASS OF SERVICE
>
>== Motivation:
>
>   The CoS field has fewer bits than the IP ToS field. To directly
>   map IP ToS bits to CoS bits, the CoS field should have at least
>   the same number of bits. This direct mapping is important to
>   some users.
>
>== Requirements:
>
>   - The CoS field SHOULD have at least as many bits as the
>     IP ToS field.
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 29 Jul 2009 04:22:47 -0400
From: Will Leland <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] For our discussion Friday: possible extensions for the bundle protocol

We'd appreciate ideas and feedback on the following strawman;
we'll briefly outline these ideas in Friday's DTNRG meeting as
well, but are hoping that the bulk of that timeslot will be RG
discussion.

Three issues have proven to be important in our main environments
(such as MANETs): Relative Timestamps, Hops to Live, and more
bits for the Class of Service field. This note summarizes their
motivations and requirements, based on our experience:

RELATIVE TIMESTAMPS

== Motivation:

   The use of absolute timestamps, as specified in RFC 5050, requires
   that nodes within a DTN to have synchronized clocks. However,
   synchronized clocks is not always attainable in many target
   operational environments, such as military networks. There are many
   reasons why it may not be feasible to synchronize clocks across a
   DTN:

        - Protocols like Network Time Protocol (NTP) cannot function
           properly in a disruption prone network.

        - Nodes may not have GPS, or may not be able to rely on GPS
          for accurate time. For example, military systems often
          cannot rely on GPS due to the possibility of jamming.

       - Nodes may not have accurate clocks. The size and cost of
          atomic clocks make them impractical for many fielded systems.
          Systems with low-cost clocks typically incur high and
          highly variable drift rates in environments that are not
          themselves well controlled. (Field environments, for
          example, may expose DTN nodes to temperatures below
          -50 C or above +50 C.)

       - Nodes may not have battery backed up clocks. For example,
         military systems usually do not have any battery backed up
         clock for issues of storage and maintenance.

== Requirements:

   - Relative Timestamps MUST NOT depend on time synchronization
     between nodes.
 
   - Relative Timestamps MUST NOT depend on a node maintaining
     time across reboots.

   - Relative Timestamps MUST assure unique timestamp sequence
     numbers.

   - Relative Timestamps and supporting fields SHOULD be in the
     primary bundle block.

   - Relative Timestamps SHOULD not interfere with BSP's ability to
     perform end-to-end integrity.

   - To support Relative Timestamps the BPA MAY accept input/hints
     from CLAs.

   - Relative Timestamps SHOULD preserve interoperability with
     DTN implementations conforming to RFC 5050.

HOPS TO LIVE

== Motivation:

   Transient routing loops are unavoidable in many networks. Hops To
   Live provides a heuristic for detecting when a bundle is traversing
   a loop and a mechanism for discarding those bundles from the
   network. These capabilities are important for saving resources
   (bandwidth, battery, and storage) in the case of transient routing
   loops. In MANETs, the roundtrip time for a routing loop will
   often be far shorter than the lifetime of the bundle.

== Requirements:

   - If Hops To Live is greater than zero, Hops To Live MUST
     be decremented each time a bundle is forwarded.

   - Hops To Live SHOULD be a field in the primary bundle block.

   - Hops To Live SHOULD NOT impact the BSP specification.

   - Hops To Live SHOULD interoperate with nodes conforming to
     RFC 5050.

CLASS OF SERVICE

== Motivation:

   The CoS field has fewer bits than the IP ToS field. To directly
   map IP ToS bits to CoS bits, the CoS field should have at least
   the same number of bits. This direct mapping is important to
   some users.

== Requirements:

   - The CoS field SHOULD have at least as many bits as the
     IP ToS field.

Date: Tue, 28 Jul 2009 05:11:54 -0400
From: Joseph Ishac <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Disconnectathon Teleconference 21 July 2009-15:00 UTC - Agenda
Reply-To: Joseph Ishac <[email-masked]>

Any update on this server?  I tried to set a host up with TSIG keys and
the server didn't seem responsive.  Any data on the configuration?  Are
you using SIG(0) keys instead?

Thanks,

-Joseph

On Mon, Jul 20, 2009 at 08:09:42AM -0500, Hans Kruse wrote:
> the domain will be <host>.dtnbone.ocp.ohiou.edu
> 
> We are currently testing our setup.
> 
> On Jul 20, 2009, at 8:56 AM, Ivancic, William D. (GRC-RHN0) wrote:
> 
> > 2)  Ohio University will be setting up a Secure DNS server and  
> > providing a script to update the DNS. DTN users can point to this  
> > server for name resolution.
> > *  To use this name to address resolver, your machines should be  
> > named "something.DTNbone.osp.ohiou.edu"
> >   (Hans, please correct the domain if I have it wrong here)
> 
> 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
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 28 Jul 2009 00:39:57 +0200
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] ICNP 2009 Call for Demos

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly forward to your colleagues and students for consideration
of a demo contribution to ICNP'09 - Please note there will be a best
demo prize (at the courtesy of Microsoft)!

The deadline for submitting a demo abstract (as well as posters) to
ICNP'09 is August 7, 2009 (Fri 23:59 PDT).

Thanks and best regards,
Xiaoming Fu (ICNP 2009 Publicity Chair)

ICNP'09 Call for Demos:
======================
IEEE ICNP 2009 will include a demo session. Proposals for research
demonstrations and exhibits are strongly solicited. Research
demonstrations should be innovative research prototypes that show new
research related to the topics included in the ICNP call for papers. The
best demo will receive a cash prize of USD 500, courtesy of Microsoft
Research.

Submission Instructions:
-----------------------
Submit demo proposal at: http://edas.info/N7882.

The proposals should include a two-page (10 pt) abstract describing the
goals of the demo and the basic idea it supports. Submissions are single
blind, so please include authors' names and affiliation.

In addition, include a list of equipment the demo will use, as well as
space and power requirements. Note that the organizers can provide only
space and power. We may be able to provide Internet access for the demos
as well, but this is not guaranteed. Let us also know if you will need a
large amount of setup time.

All demo proposals will be reviewed by the ICNP 2009 Poster and Demo
committee. Selected demo abstracts will be published in the ICNP
proceedings.

Important Dates:
---------------
Submission deadline (on EDAS)     August 7, 2009, (Fri 23:59 PDT)
Notification of acceptance        August 28, 2009
Camera ready deadline             September 4, 2009

Organizing Committee:
--------------------
Jitendra Padhye (Chair)  Microsoft Research, USA
Srikanth Krishnamurthy   UC Riverside, USA
Henning Schulzrinne      Columbia University, USA
K. K. Ramakrishnan       AT&T labs, USA

Date: Tue, 28 Jul 2009 00:27:44 +0200
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To: [email-masked], [email-masked], [email-masked], [email-masked], "[email-masked] >> sam" <[email-masked]>
Subject: [dtn-interest] ICNP 2009 Call for Posters

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly consider a poster contribution to ICNP'09 and/or forward
the following call for posters to interested people/students.

Thank you!
Xiaoming Fu (ICNP'09 Publicity Chair)

ICNP'09 Call for Posters:
========================
ICNP 2009 will hold a poster session to showcase "work-in-progress".
This has been a successful regular event at ICNP in past years and has
attracted many bright ideas that have developed into mature conference
and journal papers over time. The poster session will provide a great
chance for students to obtain feedback on their ongoing research from
knowledgeable conference attendees. In the past, these sessions have
been very well attended. While posters are welcome from everyone, we
particularly encourage on-going work in which the primary contributor
(i.e., first author) is a student. Extended (2-page) abstracts of the
posters will be reviewed by members of the Poster Session Committee. At
the conference, posters must be presented by one of the co-authors.

Posters submitted to this call for papers should contain unpublished
original ideas and not be abbreviations of published papers. The poster
extended abstract (2 pages) will be published in the conference
proceedings and CD, and put on the ICNP website.

Note that acceptance and presentation of a poster at ICNP 2009 will not
prevent authors from publishing a more complete version of their ideas
in future conferences and journals.

Important dates:
---------------
Submission deadline:          August 7, 2009, (Fri 23:59 PDT)
Notification of decisions:    August 28, 2009
Final version of abstracts:   September 4, 2009

Where to submit?
----------------
By email to: [email-masked]
Use Subject Line: ICNP 2009 poster submission Registration

At least one person must be registered for the conference to present the
poster. Students may register for the conference at the student rate for
presenting posters (if they are not presenting a full paper in the
conference which requires a full registration).
What the final poster should look like?

We define a poster to be 12 pages 8.5in x11in (letter size) on which you
can affix visually appealing material that describes your research.
Alternatively you can use the space as a continuum. You can arrange the
space and orient the poster either horizontally or vertically. You
should prepare the best material (visually appealing and succinct) that
effectively communicates your research problem, techniques, results, and
what is novel and important about your work. You are responsible for
printing your poster and bringing it to the conference site. We will
provide stands for you to mount your poster materials on.

Posters Review Committee
------------------------
Ahmed Helmy        University of Florida (Chair)
Sonia Fahmy        Purdue University
Romit Choudhury    Duke University

For questions: Email [email-masked]

Date: Mon, 27 Jul 2009 14:11:25 -0600
From: "Sushil Chaudhari" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Network address and EID

Hi,

can anybody comment on the following: 

Is there a form of "native" DTN routing - e.g. is it possible for DTN2 daemon to forward the bundle if EID of the next hop is not linked to IP, or MAC address?

Can EID be linked to subnet address? Multicast, or broadcast address?

thanks..

Sender: [email-masked]
Date: Fri, 24 Jul 2009 09:01:54 +0200
From: Emmanuel Lochin <[email-masked]>
To: [email-masked]
Cc: Pierre Ugo Tournoux <[email-masked]>, Jerome Lacan <[email-masked]>, [email-masked], Vincent Roca <[email-masked]>, Amine Bouabdallah <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

Please have a look to these papers :

"On-the-Fly Coding to Enable Full Reliability Without Retransmission"
http://arxiv.org/pdf/0809.4576v1

"On-the-fly coding for time-constrained applications"
http://arxiv.org/abs/0904.4202

where we detail a novel on-the-fly erasure coding concept for DTN and
realtime applications.

Emmanuel

2009/7/18 Emin Martinian <[email-masked]>:
> Dear DTN Experts,
>
> I am curious how error correcting codes fit in to DTN. I looked
> through the mailing lists and other docs at http://www.dtnrg.org but
> couldn't find any references.
>
> I know that in classical networking, packet losses are usually handled
> through automatic repeat request (ARQ) by resending the lost packets.
> When the network nodes are close together, this isn't too bad. But
> when the network nodes are far apart it seems like depending on
> resends could add a lot of extra delay. For example, if the link
> between A and B takes 5 minutes for a one-way transmission, resending
> a lost packet will add 10 minutes of delay. Sending a little bit of
> redundant information in the form of error correction codes seems like
> it could dramatically reduce the latency when occasional packet drops
> occur.
>
> I am curious about whether this has come up for the DTN and would love
> to see pointers to any previous discussions or research papers.
>
> In addition to natural curiosity, I am interested because I spent some
> time working on various kinds of error correcting codes specifically
> for situations where packet delays are a primary issue (see links
> below). Since DTN seems like a great application area, I'm curious to
> know what DTN experts think of the subject. To me, it seems like a
> little redundancy in the form of error correcting codes can provide
> large reductions in delay but perhaps I have the wrong models in mind
> or otherwise missed some key ideas. Feedback would be much
> appreciated.
>
> Links to work on error correcting codes for delay:
>
> �1. Brief, non-technical discussion of error correcting codes for
> correcting bursts of packet losses with provably optimal delay:
> http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
> �2. Preprint of a paper discussing some example codes for correcting
> burst of packet losses with minimum delay:
> http://www.mit.edu/~emin/research/it2000_paper.pdf
> �3. Paper on "universal" error correcting codes with some provably
> good delay properties for correcting packet losses:
> http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
> slides for the paper are at
> http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
> �4. Ph.D dissertation related to low delay error correcting codes:
> http://www.mit.edu/~emin/research/phd_thesis.pdf
>
> In particular, the above links are different than the well known
> "digital fountain" approach discussed in
>
> � [BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A �Digital
> � Fountain �Approach �to �Reliable Distribution �of �Bulk
> � Data", SIGCOMM �1998.
>
> The fountain approach is mainly intended for non-real time data such
> as a file transfer where the sender can package up the full data and
> send chunks of it to the receiver who will be able to decode when
> enough chunks are received. One problem with the fountain approach (as
> well as Reed-Solomon codes) is that the receiver has to wait until
> enough chunks are received before any chunks can be decoded. This
> makes the fountain codes less suitable for real-time or "streaming"
> applications where the receiver should be able to continuously decode
> the message as it is received instead of waiting for the full message
> to be received before decoding the earlier part of the message.
>
> Feedback on relevance or uses of error correcting codes in DTN would
> be much appreciated.
>
> Thanks,
> -Emin Martinian
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed"

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 23 Jul 2009 10:46:26 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] [disconnectathon] Disconnectathon - notes from the Telecon Tuesday

--_000_3A5AA67A8B120B48825BFFCF5443856137E542F925NDJSSCC03ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I will have this teleconference number active all day Wednesday and Thursda=
y the 29th and 30th.

If we need a Webex, I can do that at any time, but I would need to start it=
 on a system that would remain up throughout the Webex.

Teleconference:
Outside US Toll Phone 1-517-600-5252
Toll Free inside US  866-783-5733
Participant Passcode: 1095920

/Will

From: Hans Kruse [mailto:[email-masked]]
Sent: Thursday, July 23, 2009 11:29 AM
To: [email-masked]
Cc: [email-masked]
Subject: [disconnectathon] Disconnectathon - notes from the Telecon Tuesday

Please note, as we move towards more technical details, these discussion wi=
ll move off dtn-interest.   If you have not yet done so, please subscribe t=
o the disconnectathon list.  Instructions are on the dtnrg.org wiki, go the=
 the DTNBone page and follow the Disconnectathon link.  The wiki is the pla=
ce where we are collecting all information for the event.

>From the Telecon (based on the agenda sent out by Will Ivancik)

1)  Each person or group that want has specific items to test should provid=
e Hans Kruse and Will Ivancic with the following to be posted on the wiki:
I have information from Dan Ellard (BBN), Elwyn Davies (Folly Consulting), =
Teemu K=E4rkk=E4inen and J=F6rg Ott (Comnet, TKK), and PJ Dillon (U. of Pit=
tsburgh).
I am in the process of transcribing these to the wiki.  If you are planning=
 to run tests, please send your information.

2)  Ohio University will be setting up a Secure DNS server and providing a =
script to update the DNS. DTN users can point to this server for name resol=
ution.
The dynamic DNS domain dtnbone.ocp.ohiou.edu is up and running.   We are co=
mpleting test and will post key files and a shell script shortly, to allow =
participants to enter, update, and delete their DNS information.   Network =
information on the wiki will include raw IP addresses as well, since some i=
mplementations cannot use DNS.

3)  LTP testing.  Is anyone going to be performing LTP interoperability tes=
ting?
So far OU will be the only site running LTP.  Participants will be able to =
send bundles via OU gateways to machines behind a degraded link (using LTP =
inside the OU network).  Please send ideas or requirements for tests that w=
ould be useful to your implementations or applications to me.

4)  BSP.  There has been discussion of security testing.
Dan Ellard will coordinate BSP testing, if any.  Several implementers were =
unsure whether their BSP code would be ready next week.   Dan will follow u=
p with NASA Glenn to see if there is interest in running security tests aga=
inst ION.

5) Logistics Reminder:
The wiki has updated times for Wednesday (we got lost in time zones and day=
light savings time ...).  No decision was made as to whether tests would re=
sume Thursday.

6)  Can someone provide toll-free teleconferencing for this?  If not, Will =
Ivancic (NASA) can provide toll-free in US and toll elsewhere.
It appears that Skype permits toll free calls to US toll-free numbers; Will=
 has agreed to set up the conference number.

7)  Simple test scenario
*  Ohio University and NASA can put together some simple test scenarios and=
 recommended applications based on what was learned in testing ION and DTN2=
 in the NASA internal testbed.
These will appear on the wiki by the end of the week.

8)  Applications
*  If you have applications to share, Hans or Will can post them under the =
"Applications" page of the DTNbone section of the DTNRG wiki.
Teemu will have the web cam application available.  Kevin and J=F6rg voiced=
 interest in testing the Voice over DTN application.  Information on this h=
as been sent out on the list.

9)  Other items / Open discussion

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

--_000_3A5AA67A8B120B48825BFFCF5443856137E542F925NDJSSCC03ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" 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=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal>I will have this teleconference number active all day
Wednesday and Thursday the 29<sup>th</sup> and 30<sup>th</sup>.<o:p></o:p><=
/p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>If we need a Webex, I can do that at any time, but I w=
ould
need to start it on a system that would remain up throughout the Webex.<o:p=
></o:p></p>

<p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p>

<p class=3DMsoNormal><b>Teleconference:&nbsp;&nbsp; <o:p></o:p></b></p>

<p class=3DMsoNormal>Outside US Toll Phone 1-517-600-5252 <o:p></o:p></p>

<p class=3DMsoNormal>Toll Free inside US &nbsp;866-783-5733 <br>
Participant Passcode: 1095920<span style=3D'font-size:11.0pt;font-family:"C=
alibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>/Will<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Hans Kruse
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, July 23, 2009 11:29 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> [disconnectathon] Disconnectathon - notes from the Telecon
Tuesday<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Please note, as we move towards more technical details=
,
these discussion will move off dtn-interest. &nbsp; If you have not yet don=
e
so, please subscribe to the disconnectathon list. &nbsp;Instructions are on=
 the
dtnrg.org wiki, go the the DTNBone page and follow the Disconnectathon link=
.
&nbsp;The wiki is the place where we are collecting all information for the
event.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>From the Telecon (based on the agenda sent out by Will
Ivancik)<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>1) &nbsp;Each person or=
 group
that want has specific items to test should provide Hans Kruse and Will Iva=
ncic
with the following to be posted on the wiki:<o:p></o:p></p>

</div>

</blockquote>

<p class=3DMsoNormal>I have information from Dan Ellard (BBN), Elwyn Davies
(Folly Consulting), Teemu K=E4rkk=E4inen and J=F6rg Ott (Comnet, TKK), and =
PJ Dillon
(U. of Pittsburgh).<o:p></o:p></p>

<div>

<p class=3DMsoNormal>I am in the process of transcribing these to the wiki.
&nbsp;If you are planning to run tests, please send your information.<o:p><=
/o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
2) &nbsp;Ohio University will be setting up a Secure DNS server and providi=
ng a
script to update the DNS. DTN users can point to this server for name
resolution. &nbsp;<o:p></o:p></p>

</div>

</blockquote>

<p class=3DMsoNormal>The dynamic DNS domain dtnbone.ocp.ohiou.edu is up and
running. &nbsp; We are
completing&nbsp;test&nbsp;and&nbsp;will&nbsp;post&nbsp;key&nbsp;files&nbsp;=
and&nbsp;a&nbsp;shell&nbsp;script&nbsp;shortly,&nbsp;to&nbsp;allow&nbsp;par=
ticipants&nbsp;to&nbsp;enter,&nbsp;update,&nbsp;and&nbsp;delete&nbsp;their&=
nbsp;DNS&nbsp;information.&nbsp;&nbsp;&nbsp;Network&nbsp;information&nbsp;o=
n&nbsp;the&nbsp;wiki&nbsp;will&nbsp;include&nbsp;raw&nbsp;IP&nbsp;addresses=
&nbsp;as&nbsp;well,&nbsp;since&nbsp;some&nbsp;implementations&nbsp;cannot&n=
bsp;use&nbsp;DNS.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal>3) &nbsp;LTP testing. &nbsp;Is anyone going to be perf=
orming
LTP interoperability testing?<o:p></o:p></p>

</div>

<p class=3DMsoNormal>So far OU will be the only site running LTP. &nbsp;Par=
ticipants
will be able to send bundles via OU gateways to machines behind a degraded =
link
(using LTP inside the OU network). &nbsp;Please send ideas or requirements =
for
tests that would be useful to your implementations or applications to me.<o=
:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
4) &nbsp;BSP. &nbsp;There has been discussion of security testing.&nbsp;<o:=
p></o:p></p>

</div>

<p class=3DMsoNormal>Dan Ellard will
coordinate&nbsp;BSP&nbsp;testing,&nbsp;if&nbsp;any.&nbsp;&nbsp;Several&nbsp=
;implementers&nbsp;were
unsure whether their BSP code would be ready next week. &nbsp; Dan will fol=
low
up with NASA Glenn to see if there is interest in running security tests
against ION.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal>5) Logistics Reminder:<o:p></o:p></p>

</div>

<p class=3DMsoNormal>The wiki has updated times for Wednesday (we got lost =
in
time zones and daylight savings time ...). &nbsp;No decision was made as to
whether tests would resume Thursday.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
6) &nbsp;Can someone provide toll-free teleconferencing for this? &nbsp;If =
not,
Will Ivancic (NASA) can provide toll-free in US and toll elsewhere. &nbsp;<=
o:p></o:p></p>

</div>

<p class=3DMsoNormal>It appears that Skype permits toll free calls to US
toll-free numbers; Will has agreed to set up the conference number.<o:p></o=
:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
7) &nbsp;Simple test scenario<br>
* &nbsp;Ohio University and NASA can put together some simple test scenario=
s
and recommended applications based on what was learned in testing ION and D=
TN2
in the NASA internal testbed.<o:p></o:p></p>

</div>

<p class=3DMsoNormal>These will appear on the wiki by the end of the week.<=
o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
8) &nbsp;Applications<br>
* &nbsp;If you have applications to share, Hans or Will can post them under=
 the
&quot;Applications&quot; page of the DTNbone section of the DTNRG wiki.<o:p=
></o:p></p>

</div>

<p class=3DMsoNormal>Teemu will have the web cam application available.
&nbsp;Kevin and J=F6rg voiced interest in testing the Voice over DTN applic=
ation.
&nbsp;Information on this has been sent out on the list.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
9) &nbsp;Other items / Open discussion<o:p></o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif"'>Hans Kruse, Professor</span><span
style=3D'font-size:9.0pt'><o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif"'>J. Warren McClure School of Informati=
on
and Telecommunication Systems</span><span style=3D'font-size:9.0pt'><o:p></=
o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif"'>Adjunct Associate Professor of Electr=
ical
Engineering and Computer Science</span><span style=3D'font-size:9.0pt'><o:p=
></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif"'>292 Lindley Hall, Ohio University,
Athens, OH, 45701</span><span style=3D'font-size:9.0pt'><o:p></o:p></span><=
/p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif"'>740-593-4891 voice, 740-593-4889 fax<=
/span><span
style=3D'font-size:9.0pt'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856137E542F925NDJSSCC03ndcn_--

From: Hans Kruse <[email-masked]>
To: [email-masked]
Date: Thu, 23 Jul 2009 11:29:07 -0400
Cc: [email-masked]
Subject: [dtn-interest] Disconnectathon - notes from the Telecon Tuesday

--Apple-Mail-4--527192150
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Please note, as we move towards more technical details, these =20
discussion will move off dtn-interest.   If you have not yet done so, =20=

please subscribe to the disconnectathon list.  Instructions are on the =20=

dtnrg.org wiki, go the the DTNBone page and follow the Disconnectathon =20=

link.  The wiki is the place where we are collecting all information =20
for the event.

 =46rom the Telecon (based on the agenda sent out by Will Ivancik)

> 1)  Each person or group that want has specific items to test should =20=

> provide Hans Kruse and Will Ivancic with the following to be posted =20=

> on the wiki:
>
I have information from Dan Ellard (BBN), Elwyn Davies (Folly =20
Consulting), Teemu K=E4rkk=E4inen and J=F6rg Ott (Comnet, TKK), and PJ =20=

Dillon (U. of Pittsburgh).
I am in the process of transcribing these to the wiki.  If you are =20
planning to run tests, please send your information.

>
> 2)  Ohio University will be setting up a Secure DNS server and =20
> providing a script to update the DNS. DTN users can point to this =20
> server for name resolution.
>
The dynamic DNS domain dtnbone.ocp.ohiou.edu is up and running.   We =20
are completing test and will post key files and a shell script =20
shortly, to allow participants to enter, update, and delete their DNS =20=

information.   Network information on the wiki will include raw IP =20
addresses as well, since some implementations cannot use DNS.

> 3)  LTP testing.  Is anyone going to be performing LTP =20
> interoperability testing?
So far OU will be the only site running LTP.  Participants will be =20
able to send bundles via OU gateways to machines behind a degraded =20
link (using LTP inside the OU network).  Please send ideas or =20
requirements for tests that would be useful to your implementations or =20=

applications to me.

>
> 4)  BSP.  There has been discussion of security testing.
>
Dan Ellard will coordinate BSP testing, if any.  Several implementers =20=

were unsure whether their BSP code would be ready next week.   Dan =20
will follow up with NASA Glenn to see if there is interest in running =20=

security tests against ION.

> 5) Logistics Reminder:
The wiki has updated times for Wednesday (we got lost in time zones =20
and daylight savings time ...).  No decision was made as to whether =20
tests would resume Thursday.

>
> 6)  Can someone provide toll-free teleconferencing for this?  If =20
> not, Will Ivancic (NASA) can provide toll-free in US and toll =20
> elsewhere.
It appears that Skype permits toll free calls to US toll-free numbers; =20=

Will has agreed to set up the conference number.

>
> 7)  Simple test scenario
> *  Ohio University and NASA can put together some simple test =20
> scenarios and recommended applications based on what was learned in =20=

> testing ION and DTN2 in the NASA internal testbed.
These will appear on the wiki by the end of the week.

>
> 8)  Applications
> *  If you have applications to share, Hans or Will can post them =20
> under the "Applications" page of the DTNbone section of the DTNRG =20
> wiki.
Teemu will have the web cam application available.  Kevin and J=F6rg =20
voiced interest in testing the Voice over DTN application.  =20
Information on this has been sent out on the list.

>
> 9)  Other items / Open discussion
>
Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer =20
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

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

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>Please note, as we move =
towards more technical details, these discussion will move off =
dtn-interest. &nbsp; If you have not yet done so, please subscribe to =
the disconnectathon list. &nbsp;Instructions are on the dtnrg.org wiki, =
go the the DTNBone page and follow the Disconnectathon link. &nbsp;The =
wiki is the place where we are collecting all information for the =
event.</div><div><br></div><div>=46rom the Telecon (based on the agenda =
sent out by Will Ivancik)</div><div><br></div><div></div><blockquote =
type=3D"cite"><div>1) &nbsp;Each person or group that want has specific =
items to test should provide Hans Kruse and Will Ivancic with the =
following to be posted on the wiki:<br><br></div></blockquote>I have =
information from Dan Ellard (BBN), Elwyn Davies (Folly Consulting), =
Teemu K=E4rkk=E4inen and J=F6rg Ott (Comnet, TKK), and PJ Dillon (U. of =
Pittsburgh).<div>I am in the process of transcribing these to the wiki. =
&nbsp;If you are planning to run tests, please send your =
information.</div><div><br><div><blockquote type=3D"cite"><div><br>2) =
&nbsp;Ohio University will be setting up a Secure DNS server and =
providing a script to update the DNS. DTN users can point to this server =
for name resolution. &nbsp;<br><br></div></blockquote>The dynamic DNS =
domain dtnbone.ocp.ohiou.edu is up and running. &nbsp; We are =
completing&nbsp;test&nbsp;and&nbsp;will&nbsp;post&nbsp;key&nbsp;files&nbsp=
;and&nbsp;a&nbsp;shell&nbsp;script&nbsp;shortly,&nbsp;to&nbsp;allow&nbsp;p=
articipants&nbsp;to&nbsp;enter,&nbsp;update,&nbsp;and&nbsp;delete&nbsp;the=
ir&nbsp;DNS&nbsp;information.&nbsp;&nbsp;&nbsp;Network&nbsp;information&nb=
sp;on&nbsp;the&nbsp;wiki&nbsp;will&nbsp;include&nbsp;raw&nbsp;IP&nbsp;addr=
esses&nbsp;as&nbsp;well,&nbsp;since&nbsp;some&nbsp;implementations&nbsp;ca=
nnot&nbsp;use&nbsp;DNS.</div><div><br><blockquote type=3D"cite"><div>3) =
&nbsp;LTP testing. &nbsp;Is anyone going to be performing LTP =
interoperability testing?<br></div></blockquote>So far OU will be the =
only site running LTP. &nbsp;Participants will be able to send bundles =
via OU gateways to machines behind a degraded link (using LTP inside the =
OU network). &nbsp;Please send ideas or requirements for tests that =
would be useful to your implementations or applications to =
me.</div><div><br><blockquote type=3D"cite"><div><br>4) &nbsp;BSP. =
&nbsp;There has been discussion of security =
testing.&nbsp;<br><br></div></blockquote>Dan Ellard will =
coordinate&nbsp;BSP&nbsp;testing,&nbsp;if&nbsp;any.&nbsp;&nbsp;Several&nbs=
p;implementers&nbsp;were unsure whether their BSP code would be ready =
next week. &nbsp; Dan will follow up with NASA Glenn to see if there is =
interest in running security tests against =
ION.</div><div><br><blockquote type=3D"cite"><div>5) Logistics =
Reminder:<br></div></blockquote>The wiki has updated times for Wednesday =
(we got lost in time zones and daylight savings time ...). &nbsp;No =
decision was made as to whether tests would resume =
Thursday.</div><div><br><blockquote type=3D"cite"><div><br>6) &nbsp;Can =
someone provide toll-free teleconferencing for this? &nbsp;If not, Will =
Ivancic (NASA) can provide toll-free in US and toll elsewhere. =
&nbsp;<br></div></blockquote>It appears that Skype permits toll free =
calls to US toll-free numbers; Will has agreed to set up the conference =
number.</div><div><br><blockquote type=3D"cite"><div><br>7) &nbsp;Simple =
test scenario<br>* &nbsp;Ohio University and NASA can put together some =
simple test scenarios and recommended applications based on what was =
learned in testing ION and DTN2 in the NASA internal =
testbed.<br></div></blockquote>These will appear on the wiki by the end =
of the week.</div><div><br><blockquote type=3D"cite"><div><br>8) =
&nbsp;Applications<br>* &nbsp;If you have applications to share, Hans or =
Will can post them under the "Applications" page of the DTNbone section =
of the DTNRG wiki.<br></div></blockquote>Teemu will have the web cam =
application available. &nbsp;Kevin and J=F6rg voiced interest in testing =
the Voice over DTN application. &nbsp;Information on this has been sent =
out on the list.</div><div><br><blockquote type=3D"cite"><div><br>9) =
&nbsp;Other items / Open discussion<br></div><br></blockquote><div> =
<span class=3D"Apple-style-span" style=3D"font-size: 12px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></div></body></html>=

--Apple-Mail-4--527192150--

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 22 Jul 2009 13:16:33 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Proposal for DTN-oriented IP-based Neighbor Discovery

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Daniel
>Ellard
>Sent: Friday, July 17, 2009 9:44 AM
>To: [email-masked]
>Subject: [dtn-interest] Proposal for DTN-oriented IP-based Neighbor
>Discovery
>
>
>Attached is a proposal for a general neighbor discovery
>protocol specifically for DTN.  The protocol is described in
>terms of IP, although it can be generalized to work with
>other packet or datagram protocols.
>
>The IETF site is closed to new submissions (because of the
>IETF meeting in a few weeks) but we hope to discuss this in
>Stockholm, so I'm mailing this to the list.  (we will post
>it to the site as soon as possible)
>
>Looking forward to your comments,
>	-Dan

A couple years ago, we (mainly Jim Wyllie) created a bundle-based
neighbor discovery mechanism, and implemented it in DTN2 using
multicasted UDP packets similar to your beacons, but a bit more
complex (I think) in trying to convey not only current, but
future known contacts, and the rough expected properties of a
contact.

Draft spec:
http://tools.ietf.org/html/draft-wyllie-dtnrg-badisc-01
Code:
http://www.dtnrg.org/wiki/DraftAutodiscoveryCode?highlight=(discovery)

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

Date: Wed, 22 Jul 2009 11:04:46 -0400
From: David Young <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] New ION version available

We have made available a new release of ION in preparation for the
disconnectathon event: ION-2.0_r245_ou708-disconnectathon.tar.bz2.  It
can be found at our download site:
https://ion.ocp.ohiou.edu/obtainrelease.php

This new release contains a much more efficient and streamlined LTP
implementation and security utilities.  Be aware that configuration
commands have changed- especially LTP and dtn2 (renamed from dtn), and
that due to time restraints we have not changed the tutorials to
reflect these changes.  For further details, please consult the
example configuration files in the configs directory, as well as the
relevant MAN pages:
ionadmin ionrc ltpadmin ltprc bpadmin bprc ipnadmin ipnrc dtn2admin dtn2rc

-- 
David Young

Date: Wed, 22 Jul 2009 10:06:56 -0400
From: David Young <[email-masked]>
To: DTN <[email-masked]>, [email-masked]
Subject: [dtn-interest] ION/DTN2 Sockets API now freely available.

After some modularization, we have been able to split our Socket-like
bundling API (SBP API) from the ion release, and have made it
available directly at this location:

https://ion.ocp.ohiou.edu/SBP-API.tar.bz2

This package contains the API itself as well as some generic bundle
message sender and receiver programs which function both in ION and
the DTN2 reference implementation.  This code is provided as-is.
Documentation can be found both within the package and at our website:

https://ion.ocp.ohiou.edu/sbpdoc/index.html

For those of you participating in the disconnectathon, we at Ohio
University intend to run these programs on our ION nodes, and invite
dtn2 users to run the same programs on their nodes for testing.

I apologize to those of you who receive this message multiple times.

-- 
David Young
Ohio University

Date: Tue, 21 Jul 2009 15:02:03 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] "native" DTN -??

Hello,
I wonder what is referred as "native" DTN in some of the research papers...
Is that mean: "DTN over non-IP transports"?
Is BSP standard designed to work with that?
Thank you,
-V

Content-class: urn:content-classes:message
Date: Tue, 21 Jul 2009 17:23:09 +0100
From: <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] using Mercurial with SSH

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA0A1F.8971C4D4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
I have to use the mercurial for DTN2 development.. I have following =
issues, any help will be appreciated:=20

1. The link given on dtnrg page for generating SSH key is not working =
(can any one send updated link)..=20
2. Just procedure to use to connect to " shell.sf.net "=20
3. For development of DTN2 which development IDE, developers are =
using... It will be easy to configure, if I use the same IDE..=20

thanks for help once again,

regards,
Nasir=20

------_=_NextPart_001_01CA0A1F.8971C4D4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>using Mercurial with SSH</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi,<BR>
I have to use the mercurial for DTN2 development.. I have following =
issues, any help will be appreciated:<BR>
<BR>
1. The link given on dtnrg page for generating SSH key is not working =
(can any one send updated link)..<BR>
2. Just procedure to use to connect to &quot; shell.sf.net &quot;<BR>
3. For development of DTN2 which development IDE, developers are =
using... It will be easy to configure, if I use the same IDE..<BR>
<BR>
thanks for help once again,<BR>
<BR>
regards,<BR>
Nasir<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA0A1F.8971C4D4--

From: Marshall Eubanks <[email-masked]>
To: "Paulo Rogerio Barreiros d'Almeida Pereira" <[email-masked]>
Date: Tue, 21 Jul 2009 10:21:43 -0400
Cc: [email-masked], Augusto Casaca <[email-masked]>
Subject: Re: [dtn-interest] Paper on DTN

Is there a way to obtain this that is not password protected ?

Regards
Marshall

On Jul 21, 2009, at 9:39 AM, Paulo Rogerio Barreiros d'Almeida Pereira  
wrote:

> Hello,
>
>   I would like that our paper:
> Jos� Santiago, Augusto Casaca, Paulo Rog�rio Pereira.
> Multicast in Delay Tolerant Networks using Probabilities and Mobility
> Information.
> Ad Hoc & Sensor Wireless Networks, An International Journal, vol. 7,
> number 1-2, pp.51-68, 2009.
> http://www.oldcitypublishing.com/AHSWN/AHSWN%207.1-2%20contents.html
>
> be listed in the paper section of the DTNRG web pages.
>
> Best regards,
>
> -- 
> Paulo Rog�rio Barreiros d'Almeida Pereira
> Email: [email-masked]  Tel.: +351-213100345  Fax: +351-213145843
> WWW: http://mariel.inesc-id.pt/people/prbp.html
> INESC-ID LISBOA (Instituto de Eng. de Sistemas e Computadores)
> Rua Alves Redol No 9, sala 507A.
> 1000-029 LISBOA - Portugal
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Sender: [email-masked]
Date: Tue, 21 Jul 2009 10:14:45 -0400
From: Mostafa Ammar <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

--001636c5a7366dc669046f37e090
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

This reference may also be of interest:
Vellambi, B. N., Subramanian, R., Fekri, F., and Ammar, M. 2007. Reliable
and efficient message delivery in delay tolerant networks using rateless
codes. In *Proceedings of the 1st international Mobisys Workshop on Mobile
Opportunistic Networking* (San Juan, Puerto Rico, June 11 - 11, 2007).
MobiOpp '07. ACM, New York, NY, 91-98. DOI=
http://doi.acm.org/10.1145/1247694.1247712

Mostafa

-- 
Mostafa Ammar
Regents' Professor
School of Computer Science
Georgia Institute of Technology

On Tue, Jul 21, 2009 at 6:37 AM, Emin Martinian <[email-masked]>wrote:

> Thanks for the references. Those codes look like they are at the
> lowest level (something like the physical layer). I am more interested
> in applying codes at the packet level to deal with occasional packet
> losses or link level problems. At the higher level, I believe that one
> can correct bursts with lower delay than LDPC codes by using a new
> type of coding approach. At the physical layer addressed by the
> references you mentioned, I would think that LDPC codes and the like
> are pretty had to beat.
>
> Are there any working groups or similar things for coding at the
> packet level or higher?
>
> Thank you,
> -Emin
>
> On Mon, Jul 20, 2009 at 8:28 AM, Hooke, Adrian J
> (9000)<[email-masked]> wrote:
> >> I am curious how error correcting codes fit in to DTN. I looked
> >> through the mailing lists and other docs at http://www.dtnrg.org but
> >> couldn't find any references.
> >
> > Emin: for data transmission through space links we routinely use powerful
> forward error correction. You might want to start looking here:
> >
> > http://cwe.ccsds.org/sls/default.aspx#_SLS-C&S
> > http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC
> >
> > also here:
> > http://public.ccsds.org/publications/archive/131x1o2e2.pdf
> >
> > ///adrian
> >
> > Adrian J. Hooke
> > Manager: Space Networking Architecture, Technology and Standards
> > Space Communications and Navigation Office (7L70)
> > Space Operations Mission Directorate
> > NASA HEADQUARTERS
> > Washington, DC 20546-0001
> >
> >
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
Mostafa Ammar
Regents' Professor
School of Computer Science
Georgia Institute of Technology

--001636c5a7366dc669046f37e090
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This reference may also be of interest:<div><div><br></div><div><span class=
=3D"Apple-style-span" style=3D"font-family: &#39;Times New Roman&#39;; font=
-size: 16px; ">Vellambi, B. N., Subramanian, R., Fekri, F., and Ammar, M. 2=
007. Reliable and efficient message delivery in delay tolerant networks usi=
ng rateless codes. In=A0<i>Proceedings of the 1st international Mobisys Wor=
kshop on Mobile Opportunistic Networking</i>=A0(San Juan, Puerto Rico, June=
 11 - 11, 2007). MobiOpp &#39;07. ACM, New York, NY, 91-98. DOI=3D <a href=
=3D"http://doi.acm.org/10.1145/1247694.1247712">http://doi.acm.org/10.1145/=
1247694.1247712</a></span></div>
<div><font class=3D"Apple-style-span" face=3D"&#39;Times New Roman&#39;" si=
ze=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 16px;"><br></=
span></font></div><div><font class=3D"Apple-style-span" face=3D"&#39;Times =
New Roman&#39;" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-s=
ize: 16px;">Mostafa</span></font></div>
<div><font class=3D"Apple-style-span" face=3D"&#39;Times New Roman&#39;" si=
ze=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 16px;"><br></=
span></font></div><div><font class=3D"Apple-style-span" face=3D"&#39;Times =
New Roman&#39;" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-s=
ize: 16px;"><span class=3D"Apple-style-span" style=3D"font-family: arial; f=
ont-size: 13px; ">--=A0<br>
Mostafa Ammar<br>Regents&#39; Professor<br>School of Computer Science<br>Ge=
orgia Institute of Technology<br></span></span></font></div><div><font clas=
s=3D"Apple-style-span" face=3D"&#39;Times New Roman&#39;" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 16px;"><br>
</span></font></div><div><font class=3D"Apple-style-span" face=3D"&#39;Time=
s New Roman&#39;" size=3D"4"><span class=3D"Apple-style-span" style=3D"font=
-size: 16px;"><br></span></font></div><br><div class=3D"gmail_quote">On Tue=
, Jul 21, 2009 at 6:37 AM, Emin Martinian <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email-masked]">[email-masked]</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Thanks for the references. Those codes look=
 like they are at the<br>
lowest level (something like the physical layer). I am more interested<br>
in applying codes at the packet level to deal with occasional packet<br>
losses or link level problems. At the higher level, I believe that one<br>
can correct bursts with lower delay than LDPC codes by using a new<br>
type of coding approach. At the physical layer addressed by the<br>
references you mentioned, I would think that LDPC codes and the like<br>
are pretty had to beat.<br>
<br>
Are there any working groups or similar things for coding at the<br>
packet level or higher?<br>
<br>
Thank you,<br>
<font color=3D"#888888">-Emin<br>
</font><div><div></div><div class=3D"h5"><br>
On Mon, Jul 20, 2009 at 8:28 AM, Hooke, Adrian J<br>
(9000)&lt;<a href=3D"mailto:[email-masked]">adrian.j.hooke@jpl=
.nasa.gov</a>&gt; wrote:<br>
&gt;&gt; I am curious how error correcting codes fit in to DTN. I looked<br=
>
&gt;&gt; through the mailing lists and other docs at <a href=3D"http://www.=
dtnrg.org" target=3D"_blank">http://www.dtnrg.org</a> but<br>
&gt;&gt; couldn&#39;t find any references.<br>
&gt;<br>
&gt; Emin: for data transmission through space links we routinely use power=
ful forward error correction. You might want to start looking here:<br>
&gt;<br>
&gt; <a href=3D"http://cwe.ccsds.org/sls/default.aspx#_SLS-C&amp;S" target=
=3D"_blank">http://cwe.ccsds.org/sls/default.aspx#_SLS-C&amp;S</a><br>
&gt; <a href=3D"http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC" target=3D"_=
blank">http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC</a><br>
&gt;<br>
&gt; also here:<br>
&gt; <a href=3D"http://public.ccsds.org/publications/archive/131x1o2e2.pdf"=
 target=3D"_blank">http://public.ccsds.org/publications/archive/131x1o2e2.p=
df</a><br>
&gt;<br>
&gt; ///adrian<br>
&gt;<br>
&gt; Adrian J. Hooke<br>
&gt; Manager: Space Networking Architecture, Technology and Standards<br>
&gt; Space Communications and Navigation Office (7L70)<br>
&gt; Space Operations Mission Directorate<br>
&gt; NASA HEADQUARTERS<br>
&gt; Washington, DC 20546-0001<br>
&gt;<br>
&gt;<br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t" target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/d=
tn-interest</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Mostafa Amm=
ar<br>Regents&#39; Professor<br>School of Computer Science<br>Georgia Insti=
tute of Technology<br><br><br>
</div>

--001636c5a7366dc669046f37e090--

Content-class: urn:content-classes:message
Date: Tue, 21 Jul 2009 14:47:26 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA0A09.C832B7A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Finally, and maybe of interest here, you can in some cases do =20
> surprisingly well by combining link layer FEC at the bit level and =20
> packet FEC at layer 3, if your bit errors are highly non-Poisson (for  =

> example, from RF interference) or if you have a mixture of bit errors  =

> and other loss sources.

Note that the symbol Forward _Error_ Correction below the bit level
offered to the link is very different from the packet Forward _Erasure_
Correction at layer 3.

http://www.ietf.org/id/draft-ietf-fecframe-framework-05.txt
still says:

   (Note that the term "Forward Erasure
   Correction" is sometimes used, 'erasures' being a type of error in
   which data is lost and this loss can be detected, rather than being
   received in corrupted form - the focus of this document is strictly
   on erasures, however the term Forward Error Correction is more widely
   used).

Which is a fudge - the title of the document should mention 'Erasures'.
There's a difference between zeros turning to ones and not receiving
said zeros or ones, and in how those different problems are handled.

sigh.

L.

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

------_=_NextPart_001_01CA0A09.C832B7A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] How do error correcting codes fit in to =
DTN?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&gt; Finally, and maybe of interest here, you can in =
some cases do&nbsp;<BR>
&gt; surprisingly well by combining link layer FEC at the bit level =
and&nbsp;<BR>
&gt; packet FEC at layer 3, if your bit errors are highly non-Poisson =
(for&nbsp;<BR>
&gt; example, from RF interference) or if you have a mixture of bit =
errors&nbsp;<BR>
&gt; and other loss sources.<BR>
<BR>
Note that the symbol Forward _Error_ Correction below the bit level<BR>
offered to the link is very different from the packet Forward =
_Erasure_<BR>
Correction at layer 3.<BR>
<BR>
<A =
HREF=3D"http://www.ietf.org/id/draft-ietf-fecframe-framework-05.txt">http=
://www.ietf.org/id/draft-ietf-fecframe-framework-05.txt</A><BR>
still says:<BR>
<BR>
&nbsp;&nbsp; (Note that the term &quot;Forward Erasure<BR>
&nbsp;&nbsp; Correction&quot; is sometimes used, 'erasures' being a type =
of error in<BR>
&nbsp;&nbsp; which data is lost and this loss can be detected, rather =
than being<BR>
&nbsp;&nbsp; received in corrupted form - the focus of this document is =
strictly<BR>
&nbsp;&nbsp; on erasures, however the term Forward Error Correction is =
more widely<BR>
&nbsp;&nbsp; used).<BR>
<BR>
Which is a fudge - the title of the document should mention =
'Erasures'.<BR>
There's a difference between zeros turning to ones and not receiving<BR>
said zeros or ones, and in how those different problems are handled.<BR>
<BR>
sigh.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA0A09.C832B7A0--

Date: Tue, 21 Jul 2009 14:39:27 +0100
From: "Paulo Rogerio Barreiros d'Almeida Pereira" <[email-masked]>
Organization: Inesc
To: [email-masked]
Cc: Augusto Casaca <[email-masked]>
Subject: [dtn-interest] Paper on DTN

Hello,

    I would like that our paper:
Jos� Santiago, Augusto Casaca, Paulo Rog�rio Pereira.
Multicast in Delay Tolerant Networks using Probabilities and Mobility
Information.
Ad Hoc & Sensor Wireless Networks, An International Journal, vol. 7,
number 1-2, pp.51-68, 2009.
http://www.oldcitypublishing.com/AHSWN/AHSWN%207.1-2%20contents.html

be listed in the paper section of the DTNRG web pages.

Best regards,

-- 
Paulo Rog�rio Barreiros d'Almeida Pereira
Email: [email-masked]  Tel.: +351-213100345  Fax: +351-213145843
WWW: http://mariel.inesc-id.pt/people/prbp.html
INESC-ID LISBOA (Instituto de Eng. de Sistemas e Computadores)
Rua Alves Redol No 9, sala 507A.
1000-029 LISBOA - Portugal

From: "Hooke, Adrian J (9000)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 21 Jul 2009 06:01:46 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

The CCSDS Long Erasure Codes BOF is examining upper-layer FEC for space use:

http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC

///Adrian

Date: Tue, 21 Jul 2009 14:39:13 +0300
From: Giorgos Papastergiou <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

Emin, you can also check out our initial work regarding packet-level
redundant transmission over deep-space links:

G. Papastergiou, I. Psaras and V. Tsaoussidis, "Deep-Space Transport
Protocol: A Novel Transport Scheme for Space DTNs", Computer
Communications (COMCOM), Elsevier Science, Special Issue on
Delay-/Disruption-Tolerant Networks

-Giorgos Papastergiou
PhD student
Dept. of Electrical and Computer Engineering
Democritus University of Thrace
Xanthi, Greece

On Tue, Jul 21, 2009 at 1:34 PM, Emin Martinian<[email-masked]> wrote:
> Thank you. That is a very interesting paper which introduces some DTN
> issues I hadn't thought about. This is exactly the kind of area I am
> interested in: one where path level issues are the problem and one
> codes at the packet or path level to improve throughput or reduce
> delay.
>
> I believe that these are the kinds of scenarios where new types of
> coding can significantly reduce delay. In particular if you are
> sending data with a given redundancy factor over M paths where one of
> the paths could suffer B consecutive packet erasures, the standard
> Reed-Solomon, LDPC, or other FEC is suboptimal and special delay based
> codes give you provably minimum delays.
>
> I will have to think more about how to apply these delay optimal codes
> to models such as the ones in the SIGCOMM paper.
>
> Thanks,
> -Emin
>
>
>
> On Tue, Jul 21, 2009 at 1:30 AM, Kevin Fall<[email-masked]> wrote:
>> this paper might be of interest:
>>
>> http://www.citeulike.org/group/100/article/486046
>>
>> - K
>>
>>
>> On Jul 20, 2009, at Jul 205:15 AMPDT, Ivancic, William D. (GRC-RHN0) wrote:
>>
>>> It depends. �That is, were you put you error protection depends on the
>>> environment you are in and what you want to protect. �The DTN space is so
>>> broad that you can probably write a book on scenarios and the proper place
>>> to put error correction.
>>>
>>> One example might be that telemetry data often repeats or imagery data may
>>> be OK with errors (just a hole in what is a good image everywhere else).
>>> �But, I still need the header data intact and accurate as this tells me
>>> where to send the DTN bundle.
>>>
>>> Note, for example the LTP has RED and GREEN pieces of information.
>>>
>>>
>>> /Will
>>>
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:dtn-
>>>> [email-masked]] On Behalf Of Emin
>>>> Martinian
>>>> Sent: Saturday, July 18, 2009 9:19 AM
>>>> To: [email-masked]
>>>> Subject: [dtn-interest] How do error correcting codes fit in to DTN?
>>>>
>>>> Dear DTN Experts,
>>>>
>>>> I am curious how error correcting codes fit in to DTN. I looked
>>>> through the mailing lists and other docs at http://www.dtnrg.org but
>>>> couldn't find any references.
>>>>
>>>> I know that in classical networking, packet losses are usually handled
>>>> through automatic repeat request (ARQ) by resending the lost packets.
>>>> When the network nodes are close together, this isn't too bad. But
>>>> when the network nodes are far apart it seems like depending on
>>>> resends could add a lot of extra delay. For example, if the link
>>>> between A and B takes 5 minutes for a one-way transmission, resending
>>>> a lost packet will add 10 minutes of delay. Sending a little bit of
>>>> redundant information in the form of error correction codes seems like
>>>> it could dramatically reduce the latency when occasional packet drops
>>>> occur.
>>>>
>>>> I am curious about whether this has come up for the DTN and would love
>>>> to see pointers to any previous discussions or research papers.
>>>>
>>>> In addition to natural curiosity, I am interested because I spent some
>>>> time working on various kinds of error correcting codes specifically
>>>> for situations where packet delays are a primary issue (see links
>>>> below). Since DTN seems like a great application area, I'm curious to
>>>> know what DTN experts think of the subject. To me, it seems like a
>>>> little redundancy in the form of error correcting codes can provide
>>>> large reductions in delay but perhaps I have the wrong models in mind
>>>> or otherwise missed some key ideas. Feedback would be much
>>>> appreciated.
>>>>
>>>> Links to work on error correcting codes for delay:
>>>>
>>>> 1. Brief, non-technical discussion of error correcting codes for
>>>> correcting bursts of packet losses with provably optimal delay:
>>>> http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
>>>> 2. Preprint of a paper discussing some example codes for correcting
>>>> burst of packet losses with minimum delay:
>>>> http://www.mit.edu/~emin/research/it2000_paper.pdf
>>>> 3. Paper on "universal" error correcting codes with some provably
>>>> good delay properties for correcting packet losses:
>>>> http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
>>>> slides for the paper are at
>>>> http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
>>>> 4. Ph.D dissertation related to low delay error correcting codes:
>>>> http://www.mit.edu/~emin/research/phd_thesis.pdf
>>>>
>>>> In particular, the above links are different than the well known
>>>> "digital fountain" approach discussed in
>>>>
>>>> �[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A �Digital
>>>> �Fountain �Approach �to �Reliable Distribution �of �Bulk
>>>> �Data", SIGCOMM �1998.
>>>>
>>>> The fountain approach is mainly intended for non-real time data such
>>>> as a file transfer where the sender can package up the full data and
>>>> send chunks of it to the receiver who will be able to decode when
>>>> enough chunks are received. One problem with the fountain approach (as
>>>> well as Reed-Solomon codes) is that the receiver has to wait until
>>>> enough chunks are received before any chunks can be decoded. This
>>>> makes the fountain codes less suitable for real-time or "streaming"
>>>> applications where the receiver should be able to continuously decode
>>>> the message as it is received instead of waiting for the full message
>>>> to be received before decoding the earlier part of the message.
>>>>
>>>> Feedback on relevance or uses of error correcting codes in DTN would
>>>> be much appreciated.
>>>>
>>>> Thanks,
>>>> -Emin Martinian
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Marshall Eubanks <[email-masked]>
To: [email-masked]
Date: Tue, 21 Jul 2009 07:28:14 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

On Jul 21, 2009, at 6:37 AM, Emin Martinian wrote:

> Thanks for the references. Those codes look like they are at the
> lowest level (something like the physical layer). I am more interested
> in applying codes at the packet level to deal with occasional packet
> losses or link level problems. At the higher level, I believe that one
> can correct bursts with lower delay than LDPC codes by using a new
> type of coding approach. At the physical layer addressed by the
> references you mentioned, I would think that LDPC codes and the like
> are pretty had to beat.
>
> Are there any working groups or similar things for coding at the
> packet level or higher?

Much of this work has been done in AVT, at the packet replacement level.

Now there is FECFRAME (FEC framework), which is charged with
"develop[ing] a framework for application of FEC codes to arbitrary  
packet flows over unreliable transport protocols over both IP  
multicast and unicast."

http://www.ietf.org/dyn/wg/charter/fecframe-charter.html
(but see http://mirror.switch.ch/ftp/doc/ietf/fecframe/fecframe-charter.2009-07-09.12.txt
until the description problem in our charters is fixed).

http://www.ietf.org/id/draft-ietf-fecframe-framework-05.txt

I am co-chair of this WG and would be glad to discuss this in  
Stockholm. Here are some general thoughts.

The environment for packet erasure protection is different in several  
ways from link layer / RF protection

- The codes typically do not worry about detecting corruption of the  
packet. These
are just replacement encodings. (Checksums, etc., remove corrupted  
packets before they reach the FEC.)

- But they do have to worry about identifying flows of packets,  
sequence numbers, etc. For FEC over UDP, RTP is frequently used to  
provide this infrastructure (and, of course, many flows needing  
protection are
audio / video in nature, for which RTP is a natural fit).

- Packet losses are typically very non-Poisson statistically.

- Systematic codes are almost never used.

- For a wide part of the parameter space (basically, fairly low packet  
loss rates), simple XOR encodings come pretty close to the optimum.  
Raptor codes are typically used for higher loss rates.

See Figures 6-8 and discussion of
http://www.dvb.org/technology/standards/a115.tm3783.AL-FEC_Evaluation.pdf

Finally, and maybe of interest here, you can in some cases do  
surprisingly well by combining link layer FEC at the bit level and  
packet FEC at layer 3, if your bit errors are highly non-Poisson (for  
example, from RF interference) or if you have a mixture of bit errors  
and other loss sources.

Regards
Marshall

>
>
> Thank you,
> -Emin
>
> On Mon, Jul 20, 2009 at 8:28 AM, Hooke, Adrian J
> (9000)<[email-masked]> wrote:
>>> I am curious how error correcting codes fit in to DTN. I looked
>>> through the mailing lists and other docs at http://www.dtnrg.org but
>>> couldn't find any references.
>>
>> Emin: for data transmission through space links we routinely use  
>> powerful forward error correction. You might want to start looking  
>> here:
>>
>> http://cwe.ccsds.org/sls/default.aspx#_SLS-C&S
>> http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC
>>
>> also here:
>> http://public.ccsds.org/publications/archive/131x1o2e2.pdf
>>
>> ///adrian
>>
>> Adrian J. Hooke
>> Manager: Space Networking Architecture, Technology and Standards
>> Space Communications and Navigation Office (7L70)
>> Space Operations Mission Directorate
>> NASA HEADQUARTERS
>> Washington, DC 20546-0001
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Tue, 21 Jul 2009 06:37:20 -0400
From: Emin Martinian <[email-masked]>
To: "Hooke, Adrian J (9000)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?
Reply-To: [email-masked]

Thanks for the references. Those codes look like they are at the
lowest level (something like the physical layer). I am more interested
in applying codes at the packet level to deal with occasional packet
losses or link level problems. At the higher level, I believe that one
can correct bursts with lower delay than LDPC codes by using a new
type of coding approach. At the physical layer addressed by the
references you mentioned, I would think that LDPC codes and the like
are pretty had to beat.

Are there any working groups or similar things for coding at the
packet level or higher?

Thank you,
-Emin

On Mon, Jul 20, 2009 at 8:28 AM, Hooke, Adrian J
(9000)<[email-masked]> wrote:
>> I am curious how error correcting codes fit in to DTN. I looked
>> through the mailing lists and other docs at http://www.dtnrg.org but
>> couldn't find any references.
>
> Emin: for data transmission through space links we routinely use powerful forward error correction. You might want to start looking here:
>
> http://cwe.ccsds.org/sls/default.aspx#_SLS-C&S
> http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC
>
> also here:
> http://public.ccsds.org/publications/archive/131x1o2e2.pdf
>
> ///adrian
>
> Adrian J. Hooke
> Manager: Space Networking Architecture, Technology and Standards
> Space Communications and Navigation Office (7L70)
> Space Operations Mission Directorate
> NASA HEADQUARTERS
> Washington, DC 20546-0001
>
>

Date: Tue, 21 Jul 2009 06:34:42 -0400
From: Emin Martinian <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?
Reply-To: [email-masked]

Thank you. That is a very interesting paper which introduces some DTN
issues I hadn't thought about. This is exactly the kind of area I am
interested in: one where path level issues are the problem and one
codes at the packet or path level to improve throughput or reduce
delay.

I believe that these are the kinds of scenarios where new types of
coding can significantly reduce delay. In particular if you are
sending data with a given redundancy factor over M paths where one of
the paths could suffer B consecutive packet erasures, the standard
Reed-Solomon, LDPC, or other FEC is suboptimal and special delay based
codes give you provably minimum delays.

I will have to think more about how to apply these delay optimal codes
to models such as the ones in the SIGCOMM paper.

Thanks,
-Emin

On Tue, Jul 21, 2009 at 1:30 AM, Kevin Fall<[email-masked]> wrote:
> this paper might be of interest:
>
> http://www.citeulike.org/group/100/article/486046
>
> - K
>
>
> On Jul 20, 2009, at Jul 205:15 AMPDT, Ivancic, William D. (GRC-RHN0) wrote:
>
>> It depends. �That is, were you put you error protection depends on the
>> environment you are in and what you want to protect. �The DTN space is so
>> broad that you can probably write a book on scenarios and the proper place
>> to put error correction.
>>
>> One example might be that telemetry data often repeats or imagery data may
>> be OK with errors (just a hole in what is a good image everywhere else).
>> �But, I still need the header data intact and accurate as this tells me
>> where to send the DTN bundle.
>>
>> Note, for example the LTP has RED and GREEN pieces of information.
>>
>>
>> /Will
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Emin
>>> Martinian
>>> Sent: Saturday, July 18, 2009 9:19 AM
>>> To: [email-masked]
>>> Subject: [dtn-interest] How do error correcting codes fit in to DTN?
>>>
>>> Dear DTN Experts,
>>>
>>> I am curious how error correcting codes fit in to DTN. I looked
>>> through the mailing lists and other docs at http://www.dtnrg.org but
>>> couldn't find any references.
>>>
>>> I know that in classical networking, packet losses are usually handled
>>> through automatic repeat request (ARQ) by resending the lost packets.
>>> When the network nodes are close together, this isn't too bad. But
>>> when the network nodes are far apart it seems like depending on
>>> resends could add a lot of extra delay. For example, if the link
>>> between A and B takes 5 minutes for a one-way transmission, resending
>>> a lost packet will add 10 minutes of delay. Sending a little bit of
>>> redundant information in the form of error correction codes seems like
>>> it could dramatically reduce the latency when occasional packet drops
>>> occur.
>>>
>>> I am curious about whether this has come up for the DTN and would love
>>> to see pointers to any previous discussions or research papers.
>>>
>>> In addition to natural curiosity, I am interested because I spent some
>>> time working on various kinds of error correcting codes specifically
>>> for situations where packet delays are a primary issue (see links
>>> below). Since DTN seems like a great application area, I'm curious to
>>> know what DTN experts think of the subject. To me, it seems like a
>>> little redundancy in the form of error correcting codes can provide
>>> large reductions in delay but perhaps I have the wrong models in mind
>>> or otherwise missed some key ideas. Feedback would be much
>>> appreciated.
>>>
>>> Links to work on error correcting codes for delay:
>>>
>>> 1. Brief, non-technical discussion of error correcting codes for
>>> correcting bursts of packet losses with provably optimal delay:
>>> http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
>>> 2. Preprint of a paper discussing some example codes for correcting
>>> burst of packet losses with minimum delay:
>>> http://www.mit.edu/~emin/research/it2000_paper.pdf
>>> 3. Paper on "universal" error correcting codes with some provably
>>> good delay properties for correcting packet losses:
>>> http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
>>> slides for the paper are at
>>> http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
>>> 4. Ph.D dissertation related to low delay error correcting codes:
>>> http://www.mit.edu/~emin/research/phd_thesis.pdf
>>>
>>> In particular, the above links are different than the well known
>>> "digital fountain" approach discussed in
>>>
>>> �[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A �Digital
>>> �Fountain �Approach �to �Reliable Distribution �of �Bulk
>>> �Data", SIGCOMM �1998.
>>>
>>> The fountain approach is mainly intended for non-real time data such
>>> as a file transfer where the sender can package up the full data and
>>> send chunks of it to the receiver who will be able to decode when
>>> enough chunks are received. One problem with the fountain approach (as
>>> well as Reed-Solomon codes) is that the receiver has to wait until
>>> enough chunks are received before any chunks can be decoded. This
>>> makes the fountain codes less suitable for real-time or "streaming"
>>> applications where the receiver should be able to continuously decode
>>> the message as it is received instead of waiting for the full message
>>> to be received before decoding the earlier part of the message.
>>>
>>> Feedback on relevance or uses of error correcting codes in DTN would
>>> be much appreciated.
>>>
>>> Thanks,
>>> -Emin Martinian
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 20 Jul 2009 22:30:58 -0700
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

this paper might be of interest:

http://www.citeulike.org/group/100/article/486046

- K

On Jul 20, 2009, at Jul 205:15 AMPDT, Ivancic, William D. (GRC-RHN0)  
wrote:

> It depends.  That is, were you put you error protection depends on  
> the environment you are in and what you want to protect.  The DTN  
> space is so broad that you can probably write a book on scenarios  
> and the proper place to put error correction.
>
> One example might be that telemetry data often repeats or imagery  
> data may be OK with errors (just a hole in what is a good image  
> everywhere else).  But, I still need the header data intact and  
> accurate as this tells me where to send the DTN bundle.
>
> Note, for example the LTP has RED and GREEN pieces of information.
>
>
> /Will
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Emin
>> Martinian
>> Sent: Saturday, July 18, 2009 9:19 AM
>> To: [email-masked]
>> Subject: [dtn-interest] How do error correcting codes fit in to DTN?
>>
>> Dear DTN Experts,
>>
>> I am curious how error correcting codes fit in to DTN. I looked
>> through the mailing lists and other docs at http://www.dtnrg.org but
>> couldn't find any references.
>>
>> I know that in classical networking, packet losses are usually  
>> handled
>> through automatic repeat request (ARQ) by resending the lost packets.
>> When the network nodes are close together, this isn't too bad. But
>> when the network nodes are far apart it seems like depending on
>> resends could add a lot of extra delay. For example, if the link
>> between A and B takes 5 minutes for a one-way transmission, resending
>> a lost packet will add 10 minutes of delay. Sending a little bit of
>> redundant information in the form of error correction codes seems  
>> like
>> it could dramatically reduce the latency when occasional packet drops
>> occur.
>>
>> I am curious about whether this has come up for the DTN and would  
>> love
>> to see pointers to any previous discussions or research papers.
>>
>> In addition to natural curiosity, I am interested because I spent  
>> some
>> time working on various kinds of error correcting codes specifically
>> for situations where packet delays are a primary issue (see links
>> below). Since DTN seems like a great application area, I'm curious to
>> know what DTN experts think of the subject. To me, it seems like a
>> little redundancy in the form of error correcting codes can provide
>> large reductions in delay but perhaps I have the wrong models in mind
>> or otherwise missed some key ideas. Feedback would be much
>> appreciated.
>>
>> Links to work on error correcting codes for delay:
>>
>> 1. Brief, non-technical discussion of error correcting codes for
>> correcting bursts of packet losses with provably optimal delay:
>> http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
>> 2. Preprint of a paper discussing some example codes for correcting
>> burst of packet losses with minimum delay:
>> http://www.mit.edu/~emin/research/it2000_paper.pdf
>> 3. Paper on "universal" error correcting codes with some provably
>> good delay properties for correcting packet losses:
>> http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
>> slides for the paper are at
>> http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
>> 4. Ph.D dissertation related to low delay error correcting codes:
>> http://www.mit.edu/~emin/research/phd_thesis.pdf
>>
>> In particular, the above links are different than the well known
>> "digital fountain" approach discussed in
>>
>>  [BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A  Digital
>>  Fountain  Approach  to  Reliable Distribution  of  Bulk
>>  Data", SIGCOMM  1998.
>>
>> The fountain approach is mainly intended for non-real time data such
>> as a file transfer where the sender can package up the full data and
>> send chunks of it to the receiver who will be able to decode when
>> enough chunks are received. One problem with the fountain approach  
>> (as
>> well as Reed-Solomon codes) is that the receiver has to wait until
>> enough chunks are received before any chunks can be decoded. This
>> makes the fountain codes less suitable for real-time or "streaming"
>> applications where the receiver should be able to continuously decode
>> the message as it is received instead of waiting for the full message
>> to be received before decoding the earlier part of the message.
>>
>> Feedback on relevance or uses of error correcting codes in DTN would
>> be much appreciated.
>>
>> Thanks,
>> -Emin Martinian
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Mon, 20 Jul 2009 22:08:36 -0700
Subject: [dtn-interest] IETF 75 updated agenda

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

Here is an updated draft agenda, based on input from a number of  
folks.   -K

http://www3.ietf.org/proceedings/75/agenda/DTNRG.txt

IETF 75 DTNRG (draft) Agenda
[updated: 20-Jul-2009]

Jul 31, 2009 / 0900-1130 (Morning Session I)
Location: Cabaret

0900	Agenda bash			(10m; chairs)
0910	RFC/ID review			(15m; chairs)
	   [plus IAB comments from thu]
0925	Disconnectathon Report		(15m; Ott?)
0940	BBN BP Extensions		(15m; Leland?)
0955	DT Bulk Transfer		(15m; Laoutaris)
1010	Neighbor Discovery		(10m; Beverly)
1020	Management			(10m; Ivancic?)
1030	DTN URI Scheme (more name/addr)	(10m; Burleigh?, Fall?)
1040	Intentional Naming/Late Binding	(15m; Prithwish)
1055	APIs				(15m; TBD)
1110	NASA Activities Update		(15m; Ishac/?)
1125	Opens / close

Other potential topics of interest:
	cipher suites
	time sync
	bundle security
	N4C update

--Apple-Mail-5--737223034
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Here is an updated draft =
agenda, based on input from a number of folks. &nbsp; =
-K<div><br></div><div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; color: rgb(0, 0, 255); "><span style=3D""><a =
href=3D"http://www3.ietf.org/proceedings/75/agenda/DTNRG.txt" =
style=3D""><span class=3D"Apple-style-span" style=3D"text-decoration: =
none;"><font class=3D"Apple-style-span" size=3D"3"><span =
class=3D"Apple-style-span" style=3D"font-size: =
13px;">http://www3.ietf.org/proceedings/75/agenda/DTNRG.txt</span></font><=
/span></a></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; color: rgb(0, 0, 255); "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; color: =
rgb(0, 0, 255); "><br></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; color: rgb(0, 0, 255); "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; color: =
rgb(0, 0, 255); "><span class=3D"Apple-style-span" style=3D""><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">IETF 75 DTNRG =
(draft) Agenda</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">[updated: 20-Jul-2009]</span></font></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 11px/normal Calibri; "><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Jul 31, 2009 / =
0900-1130 (Morning Session I)</span></font></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 11px/normal Calibri; "><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">Location: Cabaret</span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;"><br></span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">0900</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Agenda =
bash</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
	</span></font></span><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">(10m; chairs)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">0910</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">RFC/ID =
review</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
	</span></font></span><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">(15m; chairs)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;"> &nbsp; [plus IAB =
comments from thu]</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">0925</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Disconnectathon =
Report</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(15m; =
Ott?)</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">0940</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">BBN BP =
Extensions</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(15m; =
Leland?)</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">0955</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">DT Bulk =
Transfer</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(15m; =
Laoutaris)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">1010</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Neighbor =
Discovery</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(10m; =
Beverly)</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">1020</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">Management</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
	</span></font></span><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">(10m; Ivancic?)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">1030</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">DTN URI Scheme =
(more name/addr)</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(10m; Burleigh?, =
Fall?)</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">1040</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Intentional =
Naming/Late Binding</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(15m; =
Prithwish)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">1055</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">APIs</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
		</span></font></span><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">(15m; TBD)</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">1110</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">NASA Activities =
Update</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">		=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">(15m; =
Ishac/?)</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;">1125</span></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 15px;">	=
</span></font></span><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 15px;">Opens / =
close</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
11px/normal Calibri; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
15px;"><br></span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 11px/normal Calibri; "><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
15px;">Other potential topics of interest:</span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">	</span></font></span><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">cipher suites</span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">	</span></font></span><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">time sync</span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">	</span></font></span><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">bundle security</span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 11px/normal Calibri; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">	</span></font></span><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 15px;">N4C update</span></font></div><div =
style=3D"text-decoration: =
underline;"><br></div></span></div></div></body></html>=

--Apple-Mail-5--737223034--

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 20 Jul 2009 09:09:42 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon Teleconference 21 July 2009 -15:00 UTC - Agenda

the domain will be <host>.dtnbone.ocp.ohiou.edu

We are currently testing our setup.

On Jul 20, 2009, at 8:56 AM, Ivancic, William D. (GRC-RHN0) wrote:

> 2)  Ohio University will be setting up a Secure DNS server and  
> providing a script to update the DNS. DTN users can point to this  
> server for name resolution.
> *  To use this name to address resolver, your machines should be  
> named "something.DTNbone.osp.ohiou.edu"
>   (Hans, please correct the domain if I have it wrong here)

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

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 20 Jul 2009 07:56:01 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Disconnectathon Teleconference 21 July 2009 -15:00 UTC - Agenda

The next planning teleconference will be 
21 July 2009  (Tuesday)

15:00 UTC (11:00 EDT, 8:00 Pacific, 16:00 London, 17:00 Stockholm)

Toll Outside US 1-517-600-5252
Toll Free US Only 866-783-5733
pass code  1095920

Note: I will not be on the teleconference as I will be disconnected - in flight to NASA DTN planning meeting in Colorado Springs.  However, the line will be open.

Agenda
=======
1)  ACTION ITEMS:  Each person or group that want has specific items to test should provide Hans Kruse and Will Ivancic with the following to be posted on the wiki:
* Test Goal
* Equipment requirements
* Sufficient test plan and procedures so we can fulfill your goals

(Will has received anything as of July 19th. I suspect Hans has not either.)

2)  Ohio University will be setting up a Secure DNS server and providing a script to update the DNS. DTN users can point to this server for name resolution.  
*  To use this name to address resolver, your machines should be named "something.DTNbone.osp.ohiou.edu"
   (Hans, please correct the domain if I have it wrong here)

3)  LTP testing.  Is anyone going to be performing LTP interoperability testing?

4)  BSP.  There has been discussion of security testing. 
 *  Who will be testing security?
 *  What will you be testing and what might you need to aid in the tests (i.e. test keys on the wiki?)

5) Logistics Reminder:
*  The DTNRG Jabber room will be available for chat interaction.
*  The Disconnectathon time will start 13:00 UTC (9:00 EDT, 14:00 Stockholm).

6)  Can someone provide toll-free teleconferencing for this?  If not, Will Ivancic (NASA) can provide toll-free in US and toll elsewhere.  

7)  Simple test scenario
*  Ohio University and NASA can put together some simple test scenarios and recommended applications based on what was learned in testing ION and DTN2 in the NASA internal testbed.

8)  Applications
*  If you have applications to share, Hans or Will can post them under the "Applications" page of the DTNbone section of the DTNRG wiki.

9)  Other items / Open discussion

The more planning and organization we can complete up front the better chance we have to successfully complete these tests.

/Will

From: "Hooke, Adrian J (9000)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 20 Jul 2009 05:28:38 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

> I am curious how error correcting codes fit in to DTN. I looked
> through the mailing lists and other docs at http://www.dtnrg.org but
> couldn't find any references.

Emin: for data transmission through space links we routinely use powerful forward error correction. You might want to start looking here:

http://cwe.ccsds.org/sls/default.aspx#_SLS-C&S
http://cwe.ccsds.org/sls/default.aspx#_SLS-LEC

also here:
http://public.ccsds.org/publications/archive/131x1o2e2.pdf

///adrian

Adrian J. Hooke
Manager: Space Networking Architecture, Technology and Standards
Space Communications and Navigation Office (7L70)
Space Operations Mission Directorate
NASA HEADQUARTERS
Washington, DC 20546-0001

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 20 Jul 2009 07:15:53 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] How do error correcting codes fit in to DTN?

It depends.  That is, were you put you error protection depends on the environment you are in and what you want to protect.  The DTN space is so broad that you can probably write a book on scenarios and the proper place to put error correction.

One example might be that telemetry data often repeats or imagery data may be OK with errors (just a hole in what is a good image everywhere else).  But, I still need the header data intact and accurate as this tells me where to send the DTN bundle.

Note, for example the LTP has RED and GREEN pieces of information.

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Emin
>Martinian
>Sent: Saturday, July 18, 2009 9:19 AM
>To: [email-masked]
>Subject: [dtn-interest] How do error correcting codes fit in to DTN?
>
>Dear DTN Experts,
>
>I am curious how error correcting codes fit in to DTN. I looked
>through the mailing lists and other docs at http://www.dtnrg.org but
>couldn't find any references.
>
>I know that in classical networking, packet losses are usually handled
>through automatic repeat request (ARQ) by resending the lost packets.
>When the network nodes are close together, this isn't too bad. But
>when the network nodes are far apart it seems like depending on
>resends could add a lot of extra delay. For example, if the link
>between A and B takes 5 minutes for a one-way transmission, resending
>a lost packet will add 10 minutes of delay. Sending a little bit of
>redundant information in the form of error correction codes seems like
>it could dramatically reduce the latency when occasional packet drops
>occur.
>
>I am curious about whether this has come up for the DTN and would love
>to see pointers to any previous discussions or research papers.
>
>In addition to natural curiosity, I am interested because I spent some
>time working on various kinds of error correcting codes specifically
>for situations where packet delays are a primary issue (see links
>below). Since DTN seems like a great application area, I'm curious to
>know what DTN experts think of the subject. To me, it seems like a
>little redundancy in the form of error correcting codes can provide
>large reductions in delay but perhaps I have the wrong models in mind
>or otherwise missed some key ideas. Feedback would be much
>appreciated.
>
>Links to work on error correcting codes for delay:
>
> 1. Brief, non-technical discussion of error correcting codes for
>correcting bursts of packet losses with provably optimal delay:
>http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
> 2. Preprint of a paper discussing some example codes for correcting
>burst of packet losses with minimum delay:
>http://www.mit.edu/~emin/research/it2000_paper.pdf
> 3. Paper on "universal" error correcting codes with some provably
>good delay properties for correcting packet losses:
>http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
>slides for the paper are at
>http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
> 4. Ph.D dissertation related to low delay error correcting codes:
>http://www.mit.edu/~emin/research/phd_thesis.pdf
>
>In particular, the above links are different than the well known
>"digital fountain" approach discussed in
>
>   [BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A  Digital
>   Fountain  Approach  to  Reliable Distribution  of  Bulk
>   Data", SIGCOMM  1998.
>
>The fountain approach is mainly intended for non-real time data such
>as a file transfer where the sender can package up the full data and
>send chunks of it to the receiver who will be able to decode when
>enough chunks are received. One problem with the fountain approach (as
>well as Reed-Solomon codes) is that the receiver has to wait until
>enough chunks are received before any chunks can be decoded. This
>makes the fountain codes less suitable for real-time or "streaming"
>applications where the receiver should be able to continuously decode
>the message as it is received instead of waiting for the full message
>to be received before decoding the earlier part of the message.
>
>Feedback on relevance or uses of error correcting codes in DTN would
>be much appreciated.
>
>Thanks,
>-Emin Martinian
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Sat, 18 Jul 2009 19:37:02 +0000 (GMT)
From: Scott Fowler <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE NGWS 2009 -- Submission extended to July 31st

--0-207458801-1247945822=:69379
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0ADue to many requests, paper submission deadline has been extended to Jul=
y 31st.=0A=0AThe First International Conference on Next Generation Wireless=
 Systems will be held on October 12 ~ 14, 2009, Melbourne, Australia.=0A=0A=
NGWS 2009 will be the most comprehensive conference focused on the various =
aspects of advances in Next Generation Wireless Systems. Our Conference pro=
vides a chance for academic and industry professionals to discuss recent pr=
ogress in the area of Next Generation Wireless Systems. =0AThe goal of this=
 conference is to bring together the researchers from academia and industry=
 as well as practitioners to share ideas, problems and solutions relating t=
o the multifaceted aspects of the Wireless Systems. =0A=0AAll accepted and =
registered papers will be included in the conference proceeding published b=
y IEEE CS (as a Short Paper, 4 pages. Indexed by EI). And most presented pa=
pers at the conference, after revision and extension, will be included in C=
CIS (as a Full Paper, at least 12 pages. New LNCS sister-series, indexed by=
 EI). And some papers selected will be included in some journals (pending).=
 =0AThis conference will be organized and hosted by SERSC.=0A=0ASpecial Iss=
ue  =0A=0ADistinguished papers accepted and presented in NGWS 2008, after f=
urther revisions, will be published in the special issues of the following =
international journals:=0A=0ASecurity and Communication Networks (Wiley and=
 Sons)=0AJournal of Internet Technology (SCIE)=0AInternational Journal of H=
ybrid Information Technology =0AInternational Journal of Future Generation =
Communication and Networking =0AInternational Journal of Multimedia and Ubi=
quitous Engineering=0A=0ATOPICS=0A=0AThe main topics include but will not b=
e limited to: (Excellent surveying works in these areas are welcome, too.)=
=0A=0A=E2=80=A2    Mobility Management=0A=E2=80=A2    Cross-layer schemes a=
nd optimizations=0A=E2=80=A2    End-to-End Quality of service support=0A=E2=
=80=A2    Mobility Management=0A=E2=80=A2    Handoff Techniques=0A=E2=80=A2=
    Resource management and admission control=0A=E2=80=A2    QoS routing an=
d signaling=0A=E2=80=A2    QoS management in heterogeneous wireless systems=
=0A=E2=80=A2    Wireless Mesh Networks=0A=E2=80=A2    Pricing and Charging =
Models=0A=E2=80=A2    Multimedia delivery over wireless networks=0A=E2=80=
=A2    Security and Privacy in wireless systems=0A=E2=80=A2    Performance =
evaluation of wireless systems and protocols=0A=E2=80=A2    Mobil Ad-hoc Ne=
tworks=0A=E2=80=A2    Wireless Sensor Networks=0A=E2=80=A2    Energy and po=
wer management in wireless systems=0A=E2=80=A2    Next Generation Wireless =
Systems=0A=E2=80=A2    Mobile Broadband Wireless Access=0A=E2=80=A2    Wire=
less Internet and All-IP integration=0A=E2=80=A2    Location based services=
 and tracking=0A=E2=80=A2    Wireless network testbeds and applications=0A=
=E2=80=A2    Wireless LANs and PANs, WiMAX=0A=E2=80=A2    RFID protocols an=
d systems=0A=E2=80=A2    Traffic Control and Engineering=0A=E2=80=A2    3G,=
 4G, and beyond systems=0A=E2=80=A2    Experimental wireless systems and tr=
ials=0A=E2=80=A2    Cognitive radio networks=0A=E2=80=A2    Interworking he=
terogeneous wired/wireless networks=0A=E2=80=A2    Middleware support for w=
ireless systems=0A =0A=0A=0AEvery submitted paper will be carefully reviewe=
d by at least two members of the International Program Committee. The probl=
ematic (borderline) papers will be additionally evaluated by the members of=
 the International Advisory Board and the Chairs of the conference. =0A=0AA=
ll accepted and registered papers will be included in the conference procee=
ding published by IEEE CS (as a Short Paper, 4 pages. Indexed by EI). And m=
ost presented papers at the conference, after revision and extension, will =
be included in CCIS (as a Full Paper, at least 12 pages. New LNCS sister-se=
ries, indexed by EI). =0A=0APaper Submission  =0A=0AAll papers should be su=
bmitted by online system for review with IEEE CS paper format (at least 4 p=
ages).=0A=0APlease use IEEE CS paper format: ftp://pubftp.computer.org/pres=
s/outgoing/proceedings/format.pdf=0A=0AAll submissions should be done at: h=
ttp://submission.sersc.org/NGWS2009/=0A=0A=0ADates and Deadlines  =0A=0ASub=
mission of paper : 31st July, 2009=0A=0ANotification of acceptance : 31st A=
ugust, 2009 =0A=0ASubmission of the camera ready: 7th September,  2009 =0A=
=0ARegular Registration: 8th August-28th August, 2009 =0A=0A=0ACommittee  =
=0A=0A=0ASteering Co-Chairs:=0A=0ATai-hoon Kim, Hannam Unviersity, Korea=0A=
=0AByeongho Kang, University of Tasmania, Australia=0A=0A=0AGeneral Co-Chai=
rs:=0A=0ANaveen Chilamkurti, La Trobe University, Australia =0A=0AHsiao-Hwa=
 Chen, National Cheng Kung University, Taiwan=0A=0A=0AProgram Co-Chairs:=0A=
=0ASang-Soo Yeo, Hannam University, Korea=0A=0ASherali Zeadally, University=
 of the District of Columbia, USA=0A=0A=0AInternational Advisory Board:=0A=
=0AWai Chi Fang, NASA JPL, USA=0A=0AJong Hyuk Park, Kyungnam University, Ko=
rea =0A=0ARuay-Shiung Chang, National Dong Hwa University, Taiwan=0A=0A=0AP=
ublicity Co-Chairs:=0A=0ALaura Rusu, La Trobe University, Australia =0A=0AA=
vinash Srinivasan, Bloomsburg University, Pennsylvania, USA=0A=0AScott Fowl=
er, Aston University, United Kingdom=0A=0A=0AProgram Committee: =0Ahttp://w=
ww.sersc.org/NGWS2009/comm.php=0A=0ASubmission System: http://submission.se=
rsc.org/NGWS2009/=0A=0AFor general enquiries about NGWS 2009 Conference or =
in case of any difficulty, please contact:=0A=0AThe NGWS Secretariat=0AScie=
nce & Engineering Research Support Center, Korea.=0AEmail: [email-masked]=
g=0ATel: +82 42 629 8386=0AFax: +82 42 624 2205=0A=0A=0A      
--0-207458801-1247945822=:69379
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div><br>Due to many requests, paper submission deadline has b=
een extended to July 31st.<br><br>The First International Conference on Nex=
t Generation Wireless Systems will be held on October 12 ~ 14, 2009, Melbou=
rne, Australia.<br><br>NGWS 2009 will be the most comprehensive conference =
focused on the various aspects of advances in Next Generation Wireless Syst=
ems. Our Conference provides a chance for academic and industry professiona=
ls to discuss recent progress in the area of Next Generation Wireless Syste=
ms. <br>The goal of this conference is to bring together the researchers fr=
om academia and industry as well as practitioners to share ideas, problems =
and solutions relating to the multifaceted aspects of the Wireless Systems.=
 <br><br>All accepted and registered papers will be included in the
 conference proceeding published by IEEE CS (as a Short Paper, 4 pages. Ind=
exed by EI). And most presented papers at the conference, after revision an=
d extension, will be included in CCIS (as a Full Paper, at least 12 pages. =
New LNCS sister-series, indexed by EI). And some papers selected will be in=
cluded in some journals (pending). <br>This conference will be organized an=
d hosted by SERSC.<br><br>Special Issue&nbsp; <br><br>Distinguished papers =
accepted and presented in NGWS 2008, after further revisions, will be publi=
shed in the special issues of the following international journals:<br><br>=
Security and Communication Networks (Wiley and Sons)<br>Journal of Internet=
 Technology (SCIE)<br>International Journal of Hybrid Information Technolog=
y <br>International Journal of Future Generation Communication and Networki=
ng <br>International Journal of Multimedia and Ubiquitous Engineering<br><b=
r>TOPICS<br><br>The main topics include but will not be limited to:
 (Excellent surveying works in these areas are welcome, too.)<br><br>=E2=80=
=A2&nbsp;&nbsp;&nbsp; Mobility Management<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Cr=
oss-layer schemes and optimizations<br>=E2=80=A2&nbsp;&nbsp;&nbsp; End-to-E=
nd Quality of service support<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Mobility Manag=
ement<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Handoff Techniques<br>=E2=80=A2&nbsp;&=
nbsp;&nbsp; Resource management and admission control<br>=E2=80=A2&nbsp;&nb=
sp;&nbsp; QoS routing and signaling<br>=E2=80=A2&nbsp;&nbsp;&nbsp; QoS mana=
gement in heterogeneous wireless systems<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Wir=
eless Mesh Networks<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Pricing and Charging Mod=
els<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Multimedia delivery over wireless networ=
ks<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Security and Privacy in wireless systems<=
br>=E2=80=A2&nbsp;&nbsp;&nbsp; Performance evaluation of wireless systems a=
nd protocols<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Mobil Ad-hoc Networks<br>=E2=80=
=A2&nbsp;&nbsp;&nbsp; Wireless Sensor Networks<br>=E2=80=A2&nbsp;&nbsp;&nbs=
p; Energy and
 power management in wireless systems<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Next G=
eneration Wireless Systems<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Mobile Broadband =
Wireless Access<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Wireless Internet and All-IP=
 integration<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Location based services and tra=
cking<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Wireless network testbeds and applicat=
ions<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Wireless LANs and PANs, WiMAX<br>=E2=80=
=A2&nbsp;&nbsp;&nbsp; RFID protocols and systems<br>=E2=80=A2&nbsp;&nbsp;&n=
bsp; Traffic Control and Engineering<br>=E2=80=A2&nbsp;&nbsp;&nbsp; 3G, 4G,=
 and beyond systems<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Experimental wireless sy=
stems and trials<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Cognitive radio networks<br=
>=E2=80=A2&nbsp;&nbsp;&nbsp; Interworking heterogeneous wired/wireless netw=
orks<br>=E2=80=A2&nbsp;&nbsp;&nbsp; Middleware support for wireless systems=
<br>&nbsp;<br><br><br>Every submitted paper will be carefully reviewed by a=
t least two members of the International Program Committee. The
 problematic (borderline) papers will be additionally evaluated by the memb=
ers of the International Advisory Board and the Chairs of the conference. <=
br><br>All accepted and registered papers will be included in the conferenc=
e proceeding published by IEEE CS (as a Short Paper, 4 pages. Indexed by EI=
). And most presented papers at the conference, after revision and extensio=
n, will be included in CCIS (as a Full Paper, at least 12 pages. New LNCS s=
ister-series, indexed by EI). <br><br>Paper Submission&nbsp; <br><br>All pa=
pers should be submitted by online system for review with IEEE CS paper for=
mat (at least 4 pages).<br><br>Please use IEEE CS paper format: ftp://pubft=
p.computer.org/press/outgoing/proceedings/format.pdf<br><br><span>All submi=
ssions should be done at: <a target=3D"_blank" href=3D"http://submission.se=
rsc.org/NGWS2009/">http://submission.sersc.org/NGWS2009/</a></span><br><br>=
<br>Dates and Deadlines&nbsp; <br><br>Submission of paper : 31st July,
 2009<br><br>Notification of acceptance : 31st August, 2009 <br><br>Submiss=
ion of the camera ready: 7th September,&nbsp; 2009 <br><br>Regular Registra=
tion: 8th August-28th August, 2009 <br><br><br>Committee&nbsp; <br><br><br>=
Steering Co-Chairs:<br><br>Tai-hoon Kim, Hannam Unviersity, Korea<br><br>By=
eongho Kang, University of Tasmania, Australia<br><br><br>General Co-Chairs=
:<br><br>Naveen Chilamkurti, La Trobe University, Australia <br><br>Hsiao-H=
wa Chen, National Cheng Kung University, Taiwan<br><br><br>Program Co-Chair=
s:<br><br>Sang-Soo Yeo, Hannam University, Korea<br><br>Sherali Zeadally, U=
niversity of the District of Columbia, USA<br><br><br>International Advisor=
y Board:<br><br>Wai Chi Fang, NASA JPL, USA<br><br>Jong Hyuk Park, Kyungnam=
 University, Korea <br><br>Ruay-Shiung Chang, National Dong Hwa University,=
 Taiwan<br><br><br>Publicity Co-Chairs:<br><br>Laura Rusu, La Trobe Univers=
ity, Australia <br><br>Avinash Srinivasan, Bloomsburg University,
 Pennsylvania, USA<br><br>Scott Fowler, Aston University, United Kingdom<br=
><br><br>Program Committee: <br><span><a target=3D"_blank" href=3D"http://w=
ww.sersc.org/NGWS2009/comm.php">http://www.sersc.org/NGWS2009/comm.php</a><=
/span><br><br><span>Submission System: <a target=3D"_blank" href=3D"http://=
submission.sersc.org/NGWS2009/">http://submission.sersc.org/NGWS2009/</a></=
span><br><br>For general enquiries about NGWS 2009 Conference or in case of=
 any difficulty, please contact:<br><br>The NGWS Secretariat<br>Science &am=
p; Engineering Research Support Center, Korea.<br>Email: [email-masked]<=
br>Tel: +82 42 629 8386<br>Fax: +82 42 624 2205<br><br></div></div><br>=0A=
=0A=0A=0A      </body></html>
--0-207458801-1247945822=:69379--

Date: Sat, 18 Jul 2009 09:19:07 -0400
From: Emin Martinian <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] How do error correcting codes fit in to DTN?
Reply-To: [email-masked]

Dear DTN Experts,

I am curious how error correcting codes fit in to DTN. I looked
through the mailing lists and other docs at http://www.dtnrg.org but
couldn't find any references.

I know that in classical networking, packet losses are usually handled
through automatic repeat request (ARQ) by resending the lost packets.
When the network nodes are close together, this isn't too bad. But
when the network nodes are far apart it seems like depending on
resends could add a lot of extra delay. For example, if the link
between A and B takes 5 minutes for a one-way transmission, resending
a lost packet will add 10 minutes of delay. Sending a little bit of
redundant information in the form of error correction codes seems like
it could dramatically reduce the latency when occasional packet drops
occur.

I am curious about whether this has come up for the DTN and would love
to see pointers to any previous discussions or research papers.

In addition to natural curiosity, I am interested because I spent some
time working on various kinds of error correcting codes specifically
for situations where packet delays are a primary issue (see links
below). Since DTN seems like a great application area, I'm curious to
know what DTN experts think of the subject. To me, it seems like a
little redundancy in the form of error correcting codes can provide
large reductions in delay but perhaps I have the wrong models in mind
or otherwise missed some key ideas. Feedback would be much
appreciated.

Links to work on error correcting codes for delay:

 1. Brief, non-technical discussion of error correcting codes for
correcting bursts of packet losses with provably optimal delay:
http://logoptimal.blogspot.com/2009/02/burst-delay-problem.html
 2. Preprint of a paper discussing some example codes for correcting
burst of packet losses with minimum delay:
http://www.mit.edu/~emin/research/it2000_paper.pdf
 3. Paper on "universal" error correcting codes with some provably
good delay properties for correcting packet losses:
http://www.mit.edu/~emin/research/allerton_univ_2003.pdf (power point
slides for the paper are at
http://www.mit.edu/~emin/research/allerton_univ_slides.pdf)
 4. Ph.D dissertation related to low delay error correcting codes:
http://www.mit.edu/~emin/research/phd_thesis.pdf

In particular, the above links are different than the well known
"digital fountain" approach discussed in

   [BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A  Digital
   Fountain  Approach  to  Reliable Distribution  of  Bulk
   Data", SIGCOMM  1998.

The fountain approach is mainly intended for non-real time data such
as a file transfer where the sender can package up the full data and
send chunks of it to the receiver who will be able to decode when
enough chunks are received. One problem with the fountain approach (as
well as Reed-Solomon codes) is that the receiver has to wait until
enough chunks are received before any chunks can be decoded. This
makes the fountain codes less suitable for real-time or "streaming"
applications where the receiver should be able to continuously decode
the message as it is received instead of waiting for the full message
to be received before decoding the earlier part of the message.

Feedback on relevance or uses of error correcting codes in DTN would
be much appreciated.

Thanks,
-Emin Martinian

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, Keith Scott <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>, [email-masked]
Date: Fri, 17 Jul 2009 21:57:07 -0400
Subject: [dtn-interest] Re(4): Question regarding CBHE and Bundle Security Protocol

On Fri, Jul 17, 2009, Burleigh, Scott C (313B)
<[email-masked]> wrote:

>> There's an additional possibility for identifying the sending node for
>> BAB (one-hop) besides the PHN block. The "key info" item tells you what
>> key to use, or how to get it, and that could include an indicator for
>> the sending node.
>
>Interesting idea, Peter -- using the key info to look up the key and
>taking the endpoint ID that's associated with that key as the ID of the
>sending node.  It only works when you never use the same key for
>authenticating bundles from different nodes, but I imagine you shouldn't
>be doing that anyway.  Maybe this simplifies my life.

Hi Scott,

it's actually even simpler. The key-info is a composite field and can
have various components. It could say, for example, "I'm node 15 and
used group key number seven".

Regards.....Peter

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Peter Lovell <[email-masked]>, Keith Scott <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Jul 2009 17:45:09 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2): Question regarding CBHE and Bundle Security Protocol

> -----Original Message-----
> From: Peter Lovell [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 5:08 PM
> To: Burleigh, Scott C; Keith Scott; William D. (GRC-RCN0) Ivancic; dtn-
> [email-masked]
> Subject: Re(2): [dtn-interest] Question regarding CBHE and Bundle Security
> Protocol
> 
> Hi Scott and Keith and Will,
> 
> On Wed, Jul 15, 2009, Burleigh, Scott C <[email-masked]>
> wrote:
> 
> >Can somebody who has a stronger grasp of BSP than I do
> >offer a recommendation on this?
> 
> I get the feeling that I'm "it" on this one :)
> 
> > The EID reference bit in the block flags, together with canonicalization
> of
> > the primary bundle header by the security mechanisms, MAY obviate the
> need
> > for the CBHE note below restricting the order and contents of the
> > dictionary.  That is, because we know which blocks reference entries into
> > the dictionary (and their offsets) we can fix them as needed.  Also,
> > because security canonicalizes the primary bundle header, it doesn't
> really
> > care about order, and it ONLY cares about certain strings from the
> > dictionary.
> 
> Canonicalization is an issue for PIB because the bundle must be
> reconstituted exactly, within the description of the canonicalization.
> Right now we have a good understanding of what that is but there could
> be other ciphersuites that have different rules. For example, a PIB
> suite that protects just the payload is more CBHE-friendly than the
> current PI2 ciphersuite.
> 
> As things stand, references for EIDs other than the standard four are
> "killers" for CBHE.
> 
> I remember that there was some discussion a long time ago about a scheme
> that would allow a dictionary even within CBHE bundles. I don't
> presently recall the details and will dig into the email archive to find
> out.
> 
> There's an additional possibility for identifying the sending node for
> BAB (one-hop) besides the PHN block. The "key info" item tells you what
> key to use, or how to get it, and that could include an indicator for
> the sending node.

Interesting idea, Peter -- using the key info to look up the key and taking the endpoint ID that's associated with that key as the ID of the sending node.  It only works when you never use the same key for authenticating bundles from different nodes, but I imagine you shouldn't be doing that anyway.  Maybe this simplifies my life.

Scott

From: Kevin Fall <[email-masked]>
To: Will Leland <[email-masked]>
Date: Fri, 17 Jul 2009 13:16:22 -0700
Cc: [email-masked]
Subject: Re: [dtn-interest] IETF 75 Draft Agenda

I will be working on a revision and look at putting these in too.

thx,
- K

On Jul 17, 2009, at Jul 179:29 AMPDT, Will Leland wrote:

> Good morning, Kevin,
> Would it be feasible to include time for 3 topics from BBN?
> Ideally, it'd be good to have the following, though of course
> some trimming may be required to fit into the schedule:
>
> 15 minutes on Prithwish's draft on Intentional
>  Naming and Late Binding
>
> 15 minutes on three extensions to the bundle
>  protocol that we've found useful
>  (a draft on these will be sent to dtn-interest ASAP)
>
> 5 minutes on Rob Beverly's neighbor discovery
>
> With thanks,
> -- Will
>
> Kevin Fall wrote:
>> I have uploaded a draft agenda for the upcoming IETF meeting.  We  
>> meet
>> on Friday in the morning.
>> The link is here:
>>
>> http://www.ietf.org/proceedings/09jul/agenda/DTNRG.txt
>>
>> Below is the current contents of the file.  It is very much subject  
>> to
>> change, depending on what we would like to cover.  Please submit
>> requests for changes to myself or Stephen (and cc the list).
>>
>> thx,
>> -K
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Scott, Keith L." <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Jul 2009 15:51:22 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Proposal for DTN-oriented IP-based Neighbor Discovery

I think this is great; we'd been thinking of the same thing after we added support for the NORM CL to DTN2's IP neighbor discovery.

I think standardizing at least some service names and parameters is important, and that's probably eventually an IANA consideration.  Maybe this document could specify the canonical names and parameter formats for at least TCP, UDP, and NORM CLs (and maybe Ethernet and BT as well)?  Or maybe (esp. since we don't have any CL RFCs yet) each CL spec could define its own service parameters and format (with service names centrally administered by IANA)?

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Ellard
Sent: Friday, July 17, 2009 9:44 AM
To: [email-masked]
Subject: [dtn-interest] Proposal for DTN-oriented IP-based Neighbor Discovery

Attached is a proposal for a general neighbor discovery
protocol specifically for DTN.  The protocol is described in
terms of IP, although it can be generalized to work with
other packet or datagram protocols.

The IETF site is closed to new submissions (because of the
IETF meeting in a few weeks) but we hope to discuss this in
Stockholm, so I'm mailing this to the list.  (we will post
it to the site as soon as possible)

Looking forward to your comments,
	-Dan

Date: Fri, 17 Jul 2009 12:29:22 -0400
From: Will Leland <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] IETF 75 Draft Agenda

Good morning, Kevin,
Would it be feasible to include time for 3 topics from BBN?
Ideally, it'd be good to have the following, though of course
some trimming may be required to fit into the schedule:

15 minutes on Prithwish's draft on Intentional
   Naming and Late Binding

15 minutes on three extensions to the bundle
   protocol that we've found useful
   (a draft on these will be sent to dtn-interest ASAP)

5 minutes on Rob Beverly's neighbor discovery

With thanks,
-- Will

Kevin Fall wrote:
> I have uploaded a draft agenda for the upcoming IETF meeting.  We meet  
> on Friday in the morning.
> The link is here:
>
> http://www.ietf.org/proceedings/09jul/agenda/DTNRG.txt
>
> Below is the current contents of the file.  It is very much subject to  
> change, depending on what we would like to cover.  Please submit  
> requests for changes to myself or Stephen (and cc the list).
>
> thx,
>   -K
>   

Date: Fri, 17 Jul 2009 09:43:40 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Proposal for DTN-oriented IP-based Neighbor Discovery

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

Attached is a proposal for a general neighbor discovery
protocol specifically for DTN.  The protocol is described in
terms of IP, although it can be generalized to work with
other packet or datagram protocols.

The IETF site is closed to new submissions (because of the
IETF meeting in a few weeks) but we hope to discuss this in
Stockholm, so I'm mailing this to the list.  (we will post
it to the site as soon as possible)

Looking forward to your comments,
	-Dan

--------------050005010006080203030704
Content-Type: text/plain;
 name="draft-irtf-dtnrg-ipnd-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-irtf-dtnrg-ipnd-00.txt"

Network Working Group                                         R. Beverly
Internet-Draft                                                 D. Ellard
Intended status: Experimental                                        BBN
Expires: January 18, 2010                                  July 17, 2009

                    DTN IP Neighbor Discovery (IPND)
                        draft-irtf-dtnrg-ipnd-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 18, 2010.

Beverly & Ellard        Expires January 18, 2010                [Page 1]

Internet-Draft                  DTN-IPND                       July 2009

Abstract

   Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is
   a method for otherwise oblivious nodes to learn of the existence,
   availability, and addresses of other DTN participants.  IPND both
   sends and listens for small IP UDP announcement "beacons."  Beacon
   messages are addressed to an IP unicast, multicast, or broadcast
   destination to discover specified remote neighbors, or unspecified
   local neighbors in the topology, e.g. within wireless range.  IPND
   beacons advertise neighbor availability by including the DTN node's
   canonical endpoint identifier.  IPND beacons optionally include
   service availability and parameters.  In this way, neighbor discovery
   and service discovery may be coupled or decoupled as required.  Once
   discovered, new neighbor pairs use advertised availabilities to
   connect, exchange routing information, etc.  This document describes
   DTN IPND.

Beverly & Ellard        Expires January 18, 2010                [Page 2]

Internet-Draft                  DTN-IPND                       July 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Unknown Neighbors  . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Enumerated Neighbors . . . . . . . . . . . . . . . . . . .  7
     2.3.  Beacon Message Format  . . . . . . . . . . . . . . . . . .  7
       2.3.1.  Services . . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.2.  Zero-length EID Beacons  . . . . . . . . . . . . . . .  9
     2.4.  Connection Establishment . . . . . . . . . . . . . . . . .  9
     2.5.  Disconnection  . . . . . . . . . . . . . . . . . . . . . . 10
   3.  Relation to Other Discovery Protocols  . . . . . . . . . . . . 11
   4.  Implementation Experience  . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Beverly & Ellard        Expires January 18, 2010                [Page 3]

Internet-Draft                  DTN-IPND                       July 2009

1.  Introduction

   Delay and Disruption Tolerant Networks (DTNs) [RFC4838] make no
   presumptions about network topology, routing, or availability.  DTNs
   therefore attempt to provide communication in challenged environments
   where, for instance, contemporaneous end-to-end paths do not exist.
   Examples of such DTNs arise is a variety of contexts including mobile
   social networks, space communications, rural message delivery,
   military networks, etc.

   In many DTN scenarios, the identity and meeting schedule of other
   participating nodes is not known in advance.  Therefore, an important
   primitive is Neighbor Discovery (ND), or the ability to dynamically
   locate other DTN nodes.  This document specifies Internet Protocol
   Neighbor Discovery (IPND).  In contrast to link or physical layer
   discovery, IPND enables a general form of neighbor discovery across a
   heterogeneous range of links, as are often found in DTN networks.
   IPND is particularly useful in mobile, ad-hoc DTN environments where
   meeting opportunities are not known a priori and connections may
   appear or disappear without warning.  For example, two mobile nodes
   might come into radio distance of each other, discover the new
   connection, and move data along that connection before physically
   disconnecting.

   In addition to discovering neighbors, it is often valuable to
   simultaneously discover services available from that neighbor.
   Examples of DTN services include a neighbor's available Convergence
   Layer Adapters (CLAs) and their parameters (e.g.  [TCPCLA]),
   available routers (e.g.  [PROPHET]), tunnels, etc.  Newly discovered
   nodes will then typically participate in bundle [RFC5050] routing and
   delivery.

   In other situations it is useful to decouple service discovery from
   neighbor discovery for efficiency and generality.  For example, upon
   discovering a neighbor, a DTN node might initiate a separate
   negotiation process to establish 1-hop connectivity via a particular
   convergence layer, perform routing setup, exchange availability
   information, etc.

   IPND beacons thus optionally advertise a node's available services
   while maintaining the ability to decouple node and service discovery
   as necessary.  This flexibility is important to various DTN use
   scenarios where connection opportunities may be limited (thus
   necessitating an atomic message for all availability information),
   bandwidth might be scarce (thus implying that service discovery
   should be an independent negotiation to lower beacon overhead), or
   connections have very large round-trip-times (service negotiation is
   therefore too costly with respect to time).

Beverly & Ellard        Expires January 18, 2010                [Page 4]

Internet-Draft                  DTN-IPND                       July 2009

   DTN IPND is designed to be simple, efficient, and general.

   Although this document describes a neighbor discovery protocol in
   terms of IP, the principles and basic mechanisms used in this
   protocol may also be expressed in terms of other datagram protocols.

   The remainder of this document describes DTN IPND.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following terminology is used for describing DTN IPND.

      Bundle: A PDU as defined in [RFC5050].

      Node: A DTN entity in the network that receives and processes
      bundles.

      Beacon message: An IPND-specific message, defined in this
      document, used to announce the presence of a DTN node and
      parameters with which to connect to that node.

      Convergence layer adapter: A convergence layer adapter (CLA) sends
      and receives bundles on behalf of a node by providing the
      conversion between bundles and a transport protocol such as TCP or
      UDP.

Beverly & Ellard        Expires January 18, 2010                [Page 5]

Internet-Draft                  DTN-IPND                       July 2009

2.  Protocol Description

   Nodes use DTN IPND beacons, small UDP messages in the IP underlay, to
   advertise presence.  Similarly, IPND beacons received from other
   nodes serve to detect the availability of DTN neighbors.  Nodes
   SHOULD both send and receive beacons.  These beacon messages,
   detailed in Section 2.3, may be sent either as IP unicast, multicast,
   or broadcast UDP packets.  The beacon message content is agnostic to
   the underlying transport mode.

   Broadcast beacons are designed to reach unknown neighbors in
   neighborhoods within the local network broadcast domain.  Multicast
   [RFC1112] beacons extend the scope of beacon dissemination to
   potentially include multiple networks across routed boundaries.  On
   broadcast media such as Ethernet or wireless, multicast and broadcast
   beacons are sent as link-layer broadcast messages.

   Broadcast and multicast discovery are described in Section 2.1.  In
   contrast, unicast beacons are sent only to explicitly known and
   enumerated neighbors as described in Section 2.2.

   Upon discovering a neighbor, IPND can establish a connection to the
   new neighbor via an IP-based Convergence Layer Adapter (CLA), for
   example the TCP [TCPCLA] or UDP [UDPCLA] CLA.  The CLA then
   negotiates the connection per its individual specification and
   installs the appropriate next-hop routing information in the BPA.

2.1.  Unknown Neighbors

   In the general case, the IP addresses of potential neighbors are not
   known in advance.  To discover unknown neighbors, IPND beacon
   messages are sent as IP packets with either multicast or broadcast
   destination addresses.  IPND MUST support multicast IP destination
   addresses [RFC1112] and multicast IGMP group membership [RFC3376].
   IPND MAY support IP broadcast destinations.  IPND multicast addresses
   SHOULD be from the IANA assigned local network control block
   224.0.0/24 [RFC3171].  This block of multicast addresses is
   intentionally scoped to the local network to prevent dissemination to
   the wider Internet.

   IPND MAY also use other multicast addresses as required, such as
   multicast addresses from the IANA assigned Internetwork Control Block
   [RFC3171].

   In all cases, IPND MUST support a configurable IP time-to-live value
   for all beacon messages.

Beverly & Ellard        Expires January 18, 2010                [Page 6]

Internet-Draft                  DTN-IPND                       July 2009

2.2.  Enumerated Neighbors

   IPND SHOULD support unicast beacons.  IPND is primarily designed for
   discovery of nodes in the current broadcast or multicast domain.
   However, some situations mandate discovery across multiple Internet
   IP overlay hops.  Across the wide-area Internet, multicast or
   broadcast discovery is not feasible.  In such instances, the IP
   addresses of potential neighbors must be explicitly enumerated.
   While the neighbor's address is therefore known, the availability of
   that neighbor is not known.  IPND thus permits DTN nodes to discover
   available remote neighbors across multiple IP overlay hops simply by
   enumerating their addresses.

   Note that unicast discovery scales with the square of the number of
   enumerated nodes, i.e. one beacon packet per enumerated destination.
   Therefore, unicast discovery is intended for relatively small numbers
   of neighbors.

2.3.  Beacon Message Format

   Figure 1 depicts the format of beacon messages.  Note that IPND
   follows the DTN convention of using Self-Delimiting Numeric Values
   (SDNVs) [SDNV] to represent variable length integers (denoted by *).
   IPND MUST use UDP checksums to ensure correctness.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |     Flags     |         Beacon Len (*)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          EID Len  (*)         |   Canonical EID (variable)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                   Service Blocks (optional)                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: Beacon Message Format

   The beacon message is comprised of the following fields:

   o  Version: A 1-byte field indicating the version of IPND that
      constructed this beacon.  The present document describes version
      0x01 of IPND.

   o  Flags: A 1-byte field indicating IPND processing flags.  Two flags
      are currently defined. 0x00 indicates that no special processing
      should be performed on the beacon. 0x01 indicates that no length

Beverly & Ellard        Expires January 18, 2010                [Page 7]

Internet-Draft                  DTN-IPND                       July 2009

      or local EID fields follow and allows for very short, efficient
      beacons; see Section 2.3.2 for details.

   o  Beacon Length: The byte length of the beacon inclusive of the
      entire beacon message, but exclusive of IP or UDP headers.  The
      length field is an SDNV and is therefore variable length.  A two-
      octet length is shown for convenience of representation.

   o  EID Length: The byte length of the canonical EID contained in the
      beacon.  The EID length field is an SDNV and is therefore variable
      length.  A two-octet length is shown for convenience of
      representation.

   o  Canonical EID: The canonical end node identifier of the neighbor
      advertised by the beacon message.  The canonical EID is variable
      length and represented as a Uniform Resource Identifier [RFC3986].

   o  Service Blocks: Optional announced services in the beacon,
      described in Section 2.3.1.

2.3.1.  Services

   As described previously, beacon messages may optionally include
   service availability information.  The services are intended to
   represent available CLAs, routers, etc., but are sufficiently general
   to accommodate unanticipated services provided by the advertising
   node.

   For example, the source IP address of a received beacon suffices to
   identify the remote node at the IP level.  However, the IP address
   alone does not inform other processes via which transport mechanism
   (e.g.  TCP or UDP) or via which transport port the remote node is
   offering a connection.  Similarly, nodes do not know which routers
   (e.g.  [PROPHET]) are running on a remote node in order to inform
   bundle exchange.

   Therefore, beacons may contain service blocks.  An end-node
   determines the length of the announced service blocks as follows.

   A node parses the beacon length and EID length SDNV fields.  Let v(b)
   represent the value of the beacon length and v(e) represent the value
   of the EID length.  The SDNV representation of beacon and EID length
   is itself variable length.  Let l(b) represent the on-wire length of
   the beacon length SDNV and l(e) represent the on-wire length of the
   EID length SDNV.  The total byte length of any option service blocks
   is then:

               service block length = v(b) - 2 - l(b) - l(e) - v(e)

Beverly & Ellard        Expires January 18, 2010                [Page 8]

Internet-Draft                  DTN-IPND                       July 2009

   The format of a service block is given in Figure 2.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Service Name Len (*)      | Service Name (variable)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Service Param Len (*)     | Service Parameters (variable) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Service Block Format

   A service block is comprised of the following fields:

   o  Service Name Length: The length of the advertised service name or
      description.  The service name length is an SDNV and is therefore
      variable length.  The service name MUST have non-zero length.

   o  Service Name: An identifying name for the service, e.g.  "UDPCLA."

   o  Service Parameters Length: The length of service-specific
      parameters that accompany this announcement.  The service
      parameters length is an SDNV and is therefore variable length.

   o  Service Parameters: Service-specific parameters required to use
      the service, e.g. "port=4453."

2.3.2.  Zero-length EID Beacons

   A beacon with a 0x01 flag has special meaning and indicates a "zero-
   length EID."  IPND MUST support zero-length EID beacons.  Neither the
   beacon length, canonical EID, nor any service block fields are
   present in these beacons, and the total length of the beacon is
   therefore only two octets.  Nodes SHALL assume that the canonical EID
   of a zero-length EID is the dotted-quad URI representation of the
   beacon's source IP address.

   Zero-length beacons imply that any remote node receiving the beacon
   may connect via the source IP address of the beacon, using the UDP
   CLA on UDP port 4556.  This optimization is made for efficiency and
   ease of implementation reasons, for instance in constrained scenarios
   where devices are unwilling or unable to implement SDNV and a default
   connection procedure suffices.

2.4.  Connection Establishment

   Once IPND discovers a new node and the connection parameters, it may
   initiate the connection.  The exact means by which IPND communicates
   with the CLAs is implementation dependent.  The specified CLA should
   establish the connection using the methods and conventions defined

Beverly & Ellard        Expires January 18, 2010                [Page 9]

Internet-Draft                  DTN-IPND                       July 2009

   for that CLA.

   Note that two nodes may discover each other simultaneously and
   attempt to initiate connections simultaneously.  In instances of uni-
   directional CLAs, IPND must provide uni-directional discovery.
   However, in general, bi-direction CLAs such as TCP should attempt to
   form a single connection rather than two separate connections.  IPND
   does not discern between uni and bi-directional connections or
   address potential race conditions in bilateral connection
   establishment.

2.5.  Disconnection

   Note that IPND SHOULD maintain state over all existing neighbors in
   order to prevent CLAs from needlessly attempting to establish
   connections between nodes that are already connected.  To maintain
   the current neighbor set, IPND removes stale neighbors after the
   defined neighbor receive timeout period elapses without receiving any
   beacon messages from a particular neighbor.

   Upon detecting a neighbor that is no longer available, IPND MAY
   provide hints to the CLA that the neighbor is gone.  Note that some
   CLAs themselves provide keepalive-type functionality and therefore
   IPND is not necessarily required to detect down neighbors.  However,
   placing both discovery and availability information in IPND provides
   a single, coherent point in the system design to maintain neighbor
   information.

Beverly & Ellard        Expires January 18, 2010               [Page 10]

Internet-Draft                  DTN-IPND                       July 2009

3.  Relation to Other Discovery Protocols

   A variety of discovery protocols exist in other contexts and domains.
   These discovery protocols include the ability to discover available
   neighbors and services.  For example, the IETF zero configuration
   working group [RFC3927], the bonjour protocol [BONJOUR], and the OLSR
   discovery protocol [NHDP] all provide similar functionality.

   Other rendezvous mechanisms are possible that allow a node to find a
   neighbor of a particular type or with particular properties.  For
   example, the Domain Name System (DNS) or Distributed Hash Tables
   (DHTs) could be used to find a neighbor that provides an inter-
   planetary gateway.  Such advanced rendezvous schemes are beyond the
   scope of this document.

   In contrast, DTN-IPND is designed to be DTN-specific, efficient, and
   extremely lightweight.  For instance, DTN-IPND is capable of
   supporting arbitrary length DTN EIDs, and includes CLA information in
   order to maximize the utility of each beacon message without
   requiring multiple round-trip times in order to perform complex
   protocol negotiation.

   While DTN-IPND MAY be used in non-DTN environments, its use is
   RECOMMENDED only in DTNs.

Beverly & Ellard        Expires January 18, 2010               [Page 11]

Internet-Draft                  DTN-IPND                       July 2009

4.  Implementation Experience

   BBN Technologies has implemented and deployed DTN IPND as part of the
   SPINDLE [SPINDLE] project.

Beverly & Ellard        Expires January 18, 2010               [Page 12]

Internet-Draft                  DTN-IPND                       July 2009

5.  Security Considerations

   Neighbor discovery may be perceived as an impediment to security
   because it advertises a potential target for attacks.  Discovering
   the existence of a particular node is orthogonal to securing the
   services of that node.  Nodes that desire or require higher-levels of
   security SHOULD disable the broadcast IPND beacons and rely instead
   on static neighbor configuration.

   Further, neighbor discovery represents a potential source of network
   congestion and contention.  Therefore, careful consideration should
   be made to the frequency and TTL scope of beacons when setting
   implementation-specific parameters, particularly when a setting
   affects larger regions of the network.

Beverly & Ellard        Expires January 18, 2010               [Page 13]

Internet-Draft                  DTN-IPND                       July 2009

6.  IANA Considerations

   None at this time.

Beverly & Ellard        Expires January 18, 2010               [Page 14]

Internet-Draft                  DTN-IPND                       July 2009

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

7.2.  Informative References

   [BONJOUR]  Cheshire, S., "Bonjour", Apr 2005.

   [NHDP]     Clausen, T., Dearlove, C., and J. Dean, "MANET
              Neighborhood Discovery Protocol (NHDP)", Mar 2009.

   [PROPHET]  Lindgren, A. and A. Doria, "Probabilistic Routing Protocol
              for Intermittently  Connected Networks", Mar 2006.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC3171]  Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
              "IANA Guidelines for IPv4 Multicast Address Assignments",
              BCP 51, RFC 3171, August 2001.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [SDNV]     Eddy, W., "Using Self-Delimiting Numeric Values in
              Protocols", Jan 2009.

   [SPINDLE]  Krishnan, R., "Survivable Policy-Influenced Networking:
              Disruption-tolerance through Learning and Evolution",

Beverly & Ellard        Expires January 18, 2010               [Page 15]

Internet-Draft                  DTN-IPND                       July 2009

              Oct 2006.

   [TCPCLA]   Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
              Convergence Layer Protocol", Nov 2008.

   [UDPCLA]   Kruse, H. and S. Ostermann, "UDP Convergence Layers for
              the DTN Bundle and LTP Protocols", Nov 2008.

Beverly & Ellard        Expires January 18, 2010               [Page 16]

Internet-Draft                  DTN-IPND                       July 2009

Authors' Addresses

   Robert Beverly
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   US

   Email: [email-masked]

   Daniel Ellard
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   US

   Email: [email-masked]

Beverly & Ellard        Expires January 18, 2010               [Page 17]

Internet-Draft                  DTN-IPND                       July 2009

Full Copyright Statement

   Copyright (C) The IETF Trust (2009).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Beverly & Ellard        Expires January 18, 2010               [Page 18]


--------------050005010006080203030704--

Date: Fri, 17 Jul 2009 08:52:30 +0000 (GMT)
From: Scott Fowler <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE VCNA 2009 -- Submission extended to August 1st

--0-2125529763-1247820750=:57789
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Due to many requests, paper submission deadline has been extended to August=
 1st.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AWe apologies if=
 you receive multiple copies of this announcement.=0APlease disseminate thi=
s CFP in any lists you subscribed and among=0Ayour colleagues/students. We =
also take this chance to invite you=0A(or anyone from your research group) =
to contribute papers to this=0Aconference. Thanks in advance.=0A=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AFinal call for Papers=0AThe Vehic=
ular Wireless Networks and Vehicular Intelligent Transportation Systems=0Ah=
ave recently received much attention. The aim is to improve traffic safety,=
 protect=0Aenvironment by reducing traffic congestion and fuel consumption,=
 and enable a=0Aplethora of new applications such as mobile infotainment. T=
o facilitate both safety=0Aand non-safety applications, there is a necessit=
y to integrate communications and=0Acomputing technologies into vehicular a=
nd transportation systems. To facilitate=0Athese applications, many differe=
nt types of communications and networking would be=0Ainvolved, including in=
tra-vehicle, vehicle-to-vehicle (V2V), vehicle-to-roadside=0A(V2R) and vehi=
cle-to-infrastructure (V2I) communications. Therefore, this workshop=0Ainte=
nds to foster state-of-the-art research in the areas of Vehicular=0ACommuni=
cations, Networks, and Applications through a forum for novel results and=
=0Asolutions to solve various problems and challenges foreseen in the futur=
e.=0A=0AImportant Dates:=0A=0A    Submission Deadline: August  1, 2009=0A  =
  Authors Notification: Aug. 22, 2009=0A    Final Manuscript Due: Sept. 1, =
2009=0A    Workshop: Dec. 14-16, 2009=0A=0ATopic: ( The topical areas cover=
ed by this workshop include but are not limited to)=0A=0A=0A *   Network Ar=
chitecture of V-Winet/V-ITS=0A *   V-Winet/V-ITS Services and Applications=
=0A *   Cooperative Aspects of V-Winet/V-ITS=0A *   Availability and Scalab=
ility Issues in V-Winet/V-ITS=0A *   Mobility, Traffic Models and Network M=
anagement for V-Winet/V-ITS=0A *   Cross-layer Optimization Techniques for =
V-Winet/V-ITS=0A *   Modulation, Coding, and Channel Modeling for V-Winet/V=
-ITS=0A *   Vehicle-to-Vehicle Communication Protocols=0A *   Vehicle-to-Ro=
adside Communication Protocols=0A *   Vehicle-to-Infrastructure Communicati=
on Protocols=0A *   Simulation Framework and Real-World Testbeds for V-Wine=
t/V-ITS=0A *   Driving Safety and Related Applications and Services=0A *   =
Green Technologies and V-Winet/V-ITS=0A *   Cooperative Vehicular Communica=
tions=0A *   Cross-layer Design and Optimization for Vehicular Communicatio=
n Networks=0A *   Intra-vehicle, V2I, V2R, and V2V Communication Protocols=
=0A *   MAC, Routing, Congestion Control, Multicast, Mobility Management, e=
tc.=0A *   Network Architecture for Vehicular Communication Networks=0A *  =
 Physical Layer and RF Level Technologies=0A *   Radio Resource Management =
and QoS Support=0A *   Real-time Experimental Systems and Testbeds for Vehi=
cular Communications=0A *   Safety and Non-safety Applications and Services=
=0A *   Security and Privacy Technologies=0A *   Mobility and Vehicle Traff=
ic Models=0A=0ATechnical Program Co-Chairs=0A------------------------------=
-----=0AProf. Sherali Zeadally=0ADepartment of Computer Science and Informa=
tion Technology, University of the=0ADistrict of Columbia, USA=0AEmail: sze=
[email-masked]=0A=0AProf. Kuei-Ping Shih=0ADepartment of Computer Science a=
nd Information Engineering, Tamkang University,=0ATaiwan, ROC=0AEmail: kpsh=
[email-masked]=0A=0AProf. Tin-Yu Wu=0ADepartment of Electrical Engineer=
ing, Tamkang University, Taiwan, ROC=0AEmail: [email-masked]=0A=0A=0AP=
ublicity Co-Chairs=0A-------------------=0A=0ADr. Scott Fowler=0ADepartment=
 of Engineering & Applied Science, Aston University, Birmingham, UK=0AEmail=
: [email-masked]=0A=0ADr. Zonghua Zhang=0AInformation Security Researc=
h Center, NICT, Japan=0AEmail: [email-masked]=0A=0A=0ATechnical Program =
Committee Members=0A-----------------------------------=0A=0AKaterina Mitro=
kotsa, Technical University of Delft=0AJesus A. Tellez, Universidad de Cara=
bobo=0ARashid Mehmood, Swansea University, UK=0ACarlos Bernardos, Universid=
ad Carlos III de, Madrid, Spain=0AAlbena Mihovska, Aalborg University, Denm=
ark=0AMohsin Iftikhar, University of Sydney, Australia=0ANaveen Chilamkurti=
, La TrobeUniversity, Australia=0AMohamad Badra, LIMOS Laboratory, CNRS, Fr=
ance=0AHassnaa Moustafa, France Telecom (R&D), Orange Labs, France=0AIoanni=
s Anagnostopoulos, University of the Aegean, Greece=0AEduardo Cerqueira, Un=
iversity of Coimbra, Portugal=0AJ. L. Chen, National Taiwan University of S=
cience and Technology, Taiwan=0ARung-Shiang Cheng, Kun Shan University, Tai=
wan=0AW. E. Chen, National Ilan University, Taiwan=0ADer-Jiunn Deng, Nation=
al Changhua University of Education, Taiwan=0AJen-Wen Ding, National Kaohsi=
ung University of Applied Sciences, Taiwan=0AYueh-Min Huang, National Cheng=
 Kung University, Taiwan=0AChih-Heng Ke, National Kinmen Institute of techn=
ology, Taiwan=0AWei-Tsong Lee, Tamkang University, Taiwan=0AGuan-Hsiung Lia=
w, I-Shou University, Taiwan=0ASan-Yuan Wang, I-Shou University, Taiwan=0AT=
. L. Kao, I-Shou University, Taiwan=0AQuincy Wu, National Chi Nan Universit=
y, Taiwan=0AWei-Kuo Chiang, National Chung Cheng University, Taiwan=0ALi-De=
r Chou, National Taipei University, Taiwan=0ARen-Hung Hwang, National Chung=
 Cheng University, Taiwan=0AShun-Ren Yang, National Tsing Hua University, T=
aiwan=0AHui-Tang Lin, National Cheng Kung University, Taiwan=0ASok-Ian (Ine=
s) Sou, National Cheng Kung University, Taiwan=0AJen-Yi Pan, National Chung=
 Cheng University, Taiwan=0ALain-Chyr Hwang, I-Shou University, Taiwan=0AIn=
g-Yi Chen, National Taipei University of Technology, Taiwan=0ALi-Ling Hung,=
 Aletheia University, Taiwan=0AChao-Tsun Chang, Hsiuping Institute Technolo=
gy, Taiwan=0AGwo-Jong Yu, Aletheia University, Taiwan=0ASheng-Shih Wang, Mi=
nghsin University of Science and Technology, Taiwan=0AYen-Da Chen, Lunghwa =
University of Science and Technology, Taiwan=0AHung-Chang Chen, Ching Kuo I=
nstitute of Management and Health, Taiwan=0AWen-Hwa Liao, Tatung University=
, Taiwan=0AChih-Min Chao, National Taiwan Ocean University, Taiwan=0A=0A=0A=
=0A      
--0-2125529763-1247820750=:57789
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div>Due to many requests, paper submission deadline has been =
extended to August 1st.<br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>We apologies if you receive multiple copies of this announcement.<br=
>Please disseminate this CFP in any lists you subscribed and among<br>your =
colleagues/students. We also take this chance to invite you<br>(or anyone f=
rom your research group) to contribute papers to this<br>conference. Thanks=
 in advance.<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>Fina=
l call for Papers<br>The Vehicular Wireless Networks and Vehicular Intellig=
ent Transportation Systems<br>have recently received much attention. The ai=
m is to improve traffic safety, protect<br>environment by reducing traffic =
congestion and fuel consumption, and
 enable a<br>plethora of new applications such as mobile infotainment. To f=
acilitate both safety<br>and non-safety applications, there is a necessity =
to integrate communications and<br>computing technologies into vehicular an=
d transportation systems. To facilitate<br>these applications, many differe=
nt types of communications and networking would be<br>involved, including i=
ntra-vehicle, vehicle-to-vehicle (V2V), vehicle-to-roadside<br>(V2R) and ve=
hicle-to-infrastructure (V2I) communications. Therefore, this workshop<br>i=
ntends to foster state-of-the-art research in the areas of Vehicular<br>Com=
munications, Networks, and Applications through a forum for novel results a=
nd<br>solutions to solve various problems and challenges foreseen in the fu=
ture.<br><br>Important Dates:<br><br>&nbsp;&nbsp;&nbsp; Submission Deadline=
: August&nbsp; 1, 2009<br>&nbsp;&nbsp;&nbsp; Authors Notification: Aug. 22,=
 2009<br>&nbsp;&nbsp;&nbsp; Final Manuscript Due: Sept. 1,
 2009<br>&nbsp;&nbsp;&nbsp; Workshop: Dec. 14-16, 2009<br><br>Topic: ( The =
topical areas covered by this workshop include but are not limited to)<br><=
br><br>&nbsp;*&nbsp;&nbsp; Network Architecture of V-Winet/V-ITS<br>&nbsp;*=
&nbsp;&nbsp; V-Winet/V-ITS Services and Applications<br>&nbsp;*&nbsp;&nbsp;=
 Cooperative Aspects of V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Availability a=
nd Scalability Issues in V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Mobility, Tra=
ffic Models and Network Management for V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp;=
 Cross-layer Optimization Techniques for V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbs=
p; Modulation, Coding, and Channel Modeling for V-Winet/V-ITS<br>&nbsp;*&nb=
sp;&nbsp; Vehicle-to-Vehicle Communication Protocols<br>&nbsp;*&nbsp;&nbsp;=
 Vehicle-to-Roadside Communication Protocols<br>&nbsp;*&nbsp;&nbsp; Vehicle=
-to-Infrastructure Communication Protocols<br>&nbsp;*&nbsp;&nbsp; Simulatio=
n Framework and Real-World Testbeds for
 V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Driving Safety and Related Applicatio=
ns and Services<br>&nbsp;*&nbsp;&nbsp; Green Technologies and V-Winet/V-ITS=
<br>&nbsp;*&nbsp;&nbsp; Cooperative Vehicular Communications<br>&nbsp;*&nbs=
p;&nbsp; Cross-layer Design and Optimization for Vehicular Communication Ne=
tworks<br>&nbsp;*&nbsp;&nbsp; Intra-vehicle, V2I, V2R, and V2V Communicatio=
n Protocols<br>&nbsp;*&nbsp;&nbsp; MAC, Routing, Congestion Control, Multic=
ast, Mobility Management, etc.<br>&nbsp;*&nbsp;&nbsp; Network Architecture =
for Vehicular Communication Networks<br>&nbsp;*&nbsp;&nbsp; Physical Layer =
and RF Level Technologies<br>&nbsp;*&nbsp;&nbsp; Radio Resource Management =
and QoS Support<br>&nbsp;*&nbsp;&nbsp; Real-time Experimental Systems and T=
estbeds for Vehicular Communications<br>&nbsp;*&nbsp;&nbsp; Safety and Non-=
safety Applications and Services<br>&nbsp;*&nbsp;&nbsp; Security and Privac=
y Technologies<br>&nbsp;*&nbsp;&nbsp; Mobility and Vehicle Traffic
 Models<br><br>Technical Program Co-Chairs<br>-----------------------------=
------<br>Prof. Sherali Zeadally<br>Department of Computer Science and Info=
rmation Technology, University of the<br>District of Columbia, USA<br>Email=
: [email-masked]<br><br>Prof. Kuei-Ping Shih<br>Department of Computer S=
cience and Information Engineering, Tamkang University,<br>Taiwan, ROC<br>E=
mail: [email-masked]<br><br>Prof. Tin-Yu Wu<br>Department of Electr=
ical Engineering, Tamkang University, Taiwan, ROC<br>Email: [email-masked]=
u.tw<br><br><br>Publicity Co-Chairs<br>-------------------<br><br>Dr. Scott=
 Fowler<br>Department of Engineering &amp; Applied Science, Aston Universit=
y, Birmingham, UK<br>Email: [email-masked]<br><br>Dr. Zonghua Zhang<br=
>Information Security Research Center, NICT, Japan<br>Email: zonehua@gmail.=
com<br><br><br>Technical Program Committee Members<br>---------------------=
--------------<br><br>Katerina Mitrokotsa, Technical University of
 Delft<br>Jesus A. Tellez, Universidad de Carabobo<br>Rashid Mehmood, Swans=
ea University, UK<br>Carlos Bernardos, Universidad Carlos III de, Madrid, S=
pain<br>Albena Mihovska, Aalborg University, Denmark<br>Mohsin Iftikhar, Un=
iversity of Sydney, Australia<br>Naveen Chilamkurti, La TrobeUniversity, Au=
stralia<br>Mohamad Badra, LIMOS Laboratory, CNRS, France<br>Hassnaa Moustaf=
a, France Telecom (R&amp;D), Orange Labs, France<br>Ioannis Anagnostopoulos=
, University of the Aegean, Greece<br>Eduardo Cerqueira, University of Coim=
bra, Portugal<br>J. L. Chen, National Taiwan University of Science and Tech=
nology, Taiwan<br>Rung-Shiang Cheng, Kun Shan University, Taiwan<br>W. E. C=
hen, National Ilan University, Taiwan<br>Der-Jiunn Deng, National Changhua =
University of Education, Taiwan<br>Jen-Wen Ding, National Kaohsiung Univers=
ity of Applied Sciences, Taiwan<br>Yueh-Min Huang, National Cheng Kung Univ=
ersity, Taiwan<br>Chih-Heng Ke, National Kinmen Institute of
 technology, Taiwan<br>Wei-Tsong Lee, Tamkang University, Taiwan<br>Guan-Hs=
iung Liaw, I-Shou University, Taiwan<br>San-Yuan Wang, I-Shou University, T=
aiwan<br>T. L. Kao, I-Shou University, Taiwan<br>Quincy Wu, National Chi Na=
n University, Taiwan<br>Wei-Kuo Chiang, National Chung Cheng University, Ta=
iwan<br>Li-Der Chou, National Taipei University, Taiwan<br>Ren-Hung Hwang, =
National Chung Cheng University, Taiwan<br>Shun-Ren Yang, National Tsing Hu=
a University, Taiwan<br>Hui-Tang Lin, National Cheng Kung University, Taiwa=
n<br>Sok-Ian (Ines) Sou, National Cheng Kung University, Taiwan<br>Jen-Yi P=
an, National Chung Cheng University, Taiwan<br>Lain-Chyr Hwang, I-Shou Univ=
ersity, Taiwan<br>Ing-Yi Chen, National Taipei University of Technology, Ta=
iwan<br>Li-Ling Hung, Aletheia University, Taiwan<br>Chao-Tsun Chang, Hsiup=
ing Institute Technology, Taiwan<br>Gwo-Jong Yu, Aletheia University, Taiwa=
n<br>Sheng-Shih Wang, Minghsin University of Science and Technology,
 Taiwan<br>Yen-Da Chen, Lunghwa University of Science and Technology, Taiwa=
n<br>Hung-Chang Chen, Ching Kuo Institute of Management and Health, Taiwan<=
br>Wen-Hwa Liao, Tatung University, Taiwan<br>Chih-Min Chao, National Taiwa=
n Ocean University, Taiwan<br></div></div><br>=0A=0A=0A=0A      </body></ht=
ml>
--0-2125529763-1247820750=:57789--

Date: Fri, 17 Jul 2009 08:49:18 +0000 (GMT)
From: Scott Fowler <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE VCNA 2009 -- Submission extended to August 1st

--0-1805638323-1247820558=:40928
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Due to many requests, paper submission deadline has been extended to August=
 1st.=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AWe apologies if=
 you receive multiple copies of this announcement.=0APlease disseminate thi=
s CFP in any lists you subscribed and among=0Ayour colleagues/students. We =
also take this chance to invite you=0A(or anyone from your research group) =
to contribute papers to this=0Aconference. Thanks in advance.=0A=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AFinal call for Papers=0AThe Vehic=
ular Wireless Networks and Vehicular Intelligent Transportation Systems=0Ah=
ave recently received much attention. The aim is to improve traffic safety,=
 protect=0Aenvironment by reducing traffic congestion and fuel consumption,=
 and enable a=0Aplethora of new applications such as mobile infotainment. T=
o facilitate both safety=0Aand non-safety applications, there is a necessit=
y to integrate communications and=0Acomputing technologies into vehicular a=
nd transportation systems. To facilitate=0Athese applications, many differe=
nt types of communications and networking would be=0Ainvolved, including in=
tra-vehicle, vehicle-to-vehicle (V2V), vehicle-to-roadside=0A(V2R) and vehi=
cle-to-infrastructure (V2I) communications. Therefore, this workshop=0Ainte=
nds to foster state-of-the-art research in the areas of Vehicular=0ACommuni=
cations, Networks, and Applications through a forum for novel results and=
=0Asolutions to solve various problems and challenges foreseen in the futur=
e.=0A=0AImportant Dates:=0A=0A    Submission Deadline: August  1, 2009=0A  =
  Authors Notification: Aug. 22, 2009=0A    Final Manuscript Due: Sept. 1, =
2009=0A    Workshop: Dec. 14-16, 2009=0A=0ATopic: ( The topical areas cover=
ed by this workshop include but are not limited to)=0A=0A=0A *   Network Ar=
chitecture of V-Winet/V-ITS=0A *   V-Winet/V-ITS Services and Applications=
=0A *   Cooperative Aspects of V-Winet/V-ITS=0A *   Availability and Scalab=
ility Issues in V-Winet/V-ITS=0A *   Mobility, Traffic Models and Network M=
anagement for V-Winet/V-ITS=0A *   Cross-layer Optimization Techniques for =
V-Winet/V-ITS=0A *   Modulation, Coding, and Channel Modeling for V-Winet/V=
-ITS=0A *   Vehicle-to-Vehicle Communication Protocols=0A *   Vehicle-to-Ro=
adside Communication Protocols=0A *   Vehicle-to-Infrastructure Communicati=
on Protocols=0A *   Simulation Framework and Real-World Testbeds for V-Wine=
t/V-ITS=0A *   Driving Safety and Related Applications and Services=0A *   =
Green Technologies and V-Winet/V-ITS=0A *   Cooperative Vehicular Communica=
tions=0A *   Cross-layer Design and Optimization for Vehicular Communicatio=
n Networks=0A *   Intra-vehicle, V2I, V2R, and V2V Communication Protocols=
=0A *   MAC, Routing, Congestion Control, Multicast, Mobility Management, e=
tc.=0A *   Network Architecture for Vehicular Communication Networks=0A *  =
 Physical Layer and RF Level Technologies=0A *   Radio Resource Management =
and QoS Support=0A *   Real-time Experimental Systems and Testbeds for Vehi=
cular Communications=0A *   Safety and Non-safety Applications and Services=
=0A *   Security and Privacy Technologies=0A *   Mobility and Vehicle Traff=
ic Models=0A=0ATechnical Program Co-Chairs=0A------------------------------=
-----=0AProf. Sherali Zeadally=0ADepartment of Computer Science and Informa=
tion Technology, University of the=0ADistrict of Columbia, USA=0AEmail: sze=
[email-masked]=0A=0AProf. Kuei-Ping Shih=0ADepartment of Computer Science a=
nd Information Engineering, Tamkang University,=0ATaiwan, ROC=0AEmail: kpsh=
[email-masked]=0A=0AProf. Tin-Yu Wu=0ADepartment of Electrical Engineer=
ing, Tamkang University, Taiwan, ROC=0AEmail: [email-masked]=0A=0A=0AP=
ublicity Co-Chairs=0A-------------------=0A=0ADr. Scott Fowler=0ADepartment=
 of Engineering & Applied Science, Aston University, Birmingham, UK=0AEmail=
: [email-masked]=0A=0ADr. Zonghua Zhang=0AInformation Security Researc=
h Center, NICT, Japan=0AEmail: [email-masked]=0A=0A=0ATechnical Program =
Committee Members=0A-----------------------------------=0A=0AKaterina Mitro=
kotsa, Technical University of Delft=0AJesus A. Tellez, Universidad de Cara=
bobo=0ARashid Mehmood, Swansea University, UK=0ACarlos Bernardos, Universid=
ad Carlos III de, Madrid, Spain=0AAlbena Mihovska, Aalborg University, Denm=
ark=0AMohsin Iftikhar, University of Sydney, Australia=0ANaveen Chilamkurti=
, La TrobeUniversity, Australia=0AMohamad Badra, LIMOS Laboratory, CNRS, Fr=
ance=0AHassnaa Moustafa, France Telecom (R&D), Orange Labs, France=0AIoanni=
s Anagnostopoulos, University of the Aegean, Greece=0AEduardo Cerqueira, Un=
iversity of Coimbra, Portugal=0AJ. L. Chen, National Taiwan University of S=
cience and Technology, Taiwan=0ARung-Shiang Cheng, Kun Shan University, Tai=
wan=0AW. E. Chen, National Ilan University, Taiwan=0ADer-Jiunn Deng, Nation=
al Changhua University of Education, Taiwan=0AJen-Wen Ding, National Kaohsi=
ung University of Applied Sciences, Taiwan=0AYueh-Min Huang, National Cheng=
 Kung University, Taiwan=0AChih-Heng Ke, National Kinmen Institute of techn=
ology, Taiwan=0AWei-Tsong Lee, Tamkang University, Taiwan=0AGuan-Hsiung Lia=
w, I-Shou University, Taiwan=0ASan-Yuan Wang, I-Shou University, Taiwan=0AT=
. L. Kao, I-Shou University, Taiwan=0AQuincy Wu, National Chi Nan Universit=
y, Taiwan=0AWei-Kuo Chiang, National Chung Cheng University, Taiwan=0ALi-De=
r Chou, National Taipei University, Taiwan=0ARen-Hung Hwang, National Chung=
 Cheng University, Taiwan=0AShun-Ren Yang, National Tsing Hua University, T=
aiwan=0AHui-Tang Lin, National Cheng Kung University, Taiwan=0ASok-Ian (Ine=
s) Sou, National Cheng Kung University, Taiwan=0AJen-Yi Pan, National Chung=
 Cheng University, Taiwan=0ALain-Chyr Hwang, I-Shou University, Taiwan=0AIn=
g-Yi Chen, National Taipei University of Technology, Taiwan=0ALi-Ling Hung,=
 Aletheia University, Taiwan=0AChao-Tsun Chang, Hsiuping Institute Technolo=
gy, Taiwan=0AGwo-Jong Yu, Aletheia University, Taiwan=0ASheng-Shih Wang, Mi=
nghsin University of Science and Technology, Taiwan=0AYen-Da Chen, Lunghwa =
University of Science and Technology, Taiwan=0AHung-Chang Chen, Ching Kuo I=
nstitute of Management and Health, Taiwan=0AWen-Hwa Liao, Tatung University=
, Taiwan=0AChih-Min Chao, National Taiwan Ocean University, Taiwan=0A=0A=0A=
=0A      
--0-1805638323-1247820558=:40928
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt"><div>Due to many requests, paper submission deadline has been =
extended to August 1st.<br><br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D<br>We apologies if you receive multiple copies of this announcement.<br=
>Please disseminate this CFP in any lists you subscribed and among<br>your =
colleagues/students. We also take this chance to invite you<br>(or anyone f=
rom your research group) to contribute papers to this<br>conference. Thanks=
 in advance.<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>Fina=
l call for Papers<br>The Vehicular Wireless Networks and Vehicular Intellig=
ent Transportation Systems<br>have recently received much attention. The ai=
m is to improve traffic safety, protect<br>environment by reducing traffic =
congestion and fuel consumption, and
 enable a<br>plethora of new applications such as mobile infotainment. To f=
acilitate both safety<br>and non-safety applications, there is a necessity =
to integrate communications and<br>computing technologies into vehicular an=
d transportation systems. To facilitate<br>these applications, many differe=
nt types of communications and networking would be<br>involved, including i=
ntra-vehicle, vehicle-to-vehicle (V2V), vehicle-to-roadside<br>(V2R) and ve=
hicle-to-infrastructure (V2I) communications. Therefore, this workshop<br>i=
ntends to foster state-of-the-art research in the areas of Vehicular<br>Com=
munications, Networks, and Applications through a forum for novel results a=
nd<br>solutions to solve various problems and challenges foreseen in the fu=
ture.<br><br>Important Dates:<br><br>&nbsp;&nbsp;&nbsp; Submission Deadline=
: August&nbsp; 1, 2009<br>&nbsp;&nbsp;&nbsp; Authors Notification: Aug. 22,=
 2009<br>&nbsp;&nbsp;&nbsp; Final Manuscript Due: Sept. 1,
 2009<br>&nbsp;&nbsp;&nbsp; Workshop: Dec. 14-16, 2009<br><br>Topic: ( The =
topical areas covered by this workshop include but are not limited to)<br><=
br><br>&nbsp;*&nbsp;&nbsp; Network Architecture of V-Winet/V-ITS<br>&nbsp;*=
&nbsp;&nbsp; V-Winet/V-ITS Services and Applications<br>&nbsp;*&nbsp;&nbsp;=
 Cooperative Aspects of V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Availability a=
nd Scalability Issues in V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Mobility, Tra=
ffic Models and Network Management for V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp;=
 Cross-layer Optimization Techniques for V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbs=
p; Modulation, Coding, and Channel Modeling for V-Winet/V-ITS<br>&nbsp;*&nb=
sp;&nbsp; Vehicle-to-Vehicle Communication Protocols<br>&nbsp;*&nbsp;&nbsp;=
 Vehicle-to-Roadside Communication Protocols<br>&nbsp;*&nbsp;&nbsp; Vehicle=
-to-Infrastructure Communication Protocols<br>&nbsp;*&nbsp;&nbsp; Simulatio=
n Framework and Real-World Testbeds for
 V-Winet/V-ITS<br>&nbsp;*&nbsp;&nbsp; Driving Safety and Related Applicatio=
ns and Services<br>&nbsp;*&nbsp;&nbsp; Green Technologies and V-Winet/V-ITS=
<br>&nbsp;*&nbsp;&nbsp; Cooperative Vehicular Communications<br>&nbsp;*&nbs=
p;&nbsp; Cross-layer Design and Optimization for Vehicular Communication Ne=
tworks<br>&nbsp;*&nbsp;&nbsp; Intra-vehicle, V2I, V2R, and V2V Communicatio=
n Protocols<br>&nbsp;*&nbsp;&nbsp; MAC, Routing, Congestion Control, Multic=
ast, Mobility Management, etc.<br>&nbsp;*&nbsp;&nbsp; Network Architecture =
for Vehicular Communication Networks<br>&nbsp;*&nbsp;&nbsp; Physical Layer =
and RF Level Technologies<br>&nbsp;*&nbsp;&nbsp; Radio Resource Management =
and QoS Support<br>&nbsp;*&nbsp;&nbsp; Real-time Experimental Systems and T=
estbeds for Vehicular Communications<br>&nbsp;*&nbsp;&nbsp; Safety and Non-=
safety Applications and Services<br>&nbsp;*&nbsp;&nbsp; Security and Privac=
y Technologies<br>&nbsp;*&nbsp;&nbsp; Mobility and Vehicle Traffic
 Models<br><br>Technical Program Co-Chairs<br>-----------------------------=
------<br>Prof. Sherali Zeadally<br>Department of Computer Science and Info=
rmation Technology, University of the<br>District of Columbia, USA<br>Email=
: [email-masked]<br><br>Prof. Kuei-Ping Shih<br>Department of Computer S=
cience and Information Engineering, Tamkang University,<br>Taiwan, ROC<br>E=
mail: [email-masked]<br><br>Prof. Tin-Yu Wu<br>Department of Electr=
ical Engineering, Tamkang University, Taiwan, ROC<br>Email: [email-masked]=
u.tw<br><br><br>Publicity Co-Chairs<br>-------------------<br><br>Dr. Scott=
 Fowler<br>Department of Engineering &amp; Applied Science, Aston Universit=
y, Birmingham, UK<br>Email: [email-masked]<br><br>Dr. Zonghua Zhang<br=
>Information Security Research Center, NICT, Japan<br>Email: zonehua@gmail.=
com<br><br><br>Technical Program Committee Members<br>---------------------=
--------------<br><br>Katerina Mitrokotsa, Technical University of
 Delft<br>Jesus A. Tellez, Universidad de Carabobo<br>Rashid Mehmood, Swans=
ea University, UK<br>Carlos Bernardos, Universidad Carlos III de, Madrid, S=
pain<br>Albena Mihovska, Aalborg University, Denmark<br>Mohsin Iftikhar, Un=
iversity of Sydney, Australia<br>Naveen Chilamkurti, La TrobeUniversity, Au=
stralia<br>Mohamad Badra, LIMOS Laboratory, CNRS, France<br>Hassnaa Moustaf=
a, France Telecom (R&amp;D), Orange Labs, France<br>Ioannis Anagnostopoulos=
, University of the Aegean, Greece<br>Eduardo Cerqueira, University of Coim=
bra, Portugal<br>J. L. Chen, National Taiwan University of Science and Tech=
nology, Taiwan<br>Rung-Shiang Cheng, Kun Shan University, Taiwan<br>W. E. C=
hen, National Ilan University, Taiwan<br>Der-Jiunn Deng, National Changhua =
University of Education, Taiwan<br>Jen-Wen Ding, National Kaohsiung Univers=
ity of Applied Sciences, Taiwan<br>Yueh-Min Huang, National Cheng Kung Univ=
ersity, Taiwan<br>Chih-Heng Ke, National Kinmen Institute of
 technology, Taiwan<br>Wei-Tsong Lee, Tamkang University, Taiwan<br>Guan-Hs=
iung Liaw, I-Shou University, Taiwan<br>San-Yuan Wang, I-Shou University, T=
aiwan<br>T. L. Kao, I-Shou University, Taiwan<br>Quincy Wu, National Chi Na=
n University, Taiwan<br>Wei-Kuo Chiang, National Chung Cheng University, Ta=
iwan<br>Li-Der Chou, National Taipei University, Taiwan<br>Ren-Hung Hwang, =
National Chung Cheng University, Taiwan<br>Shun-Ren Yang, National Tsing Hu=
a University, Taiwan<br>Hui-Tang Lin, National Cheng Kung University, Taiwa=
n<br>Sok-Ian (Ines) Sou, National Cheng Kung University, Taiwan<br>Jen-Yi P=
an, National Chung Cheng University, Taiwan<br>Lain-Chyr Hwang, I-Shou Univ=
ersity, Taiwan<br>Ing-Yi Chen, National Taipei University of Technology, Ta=
iwan<br>Li-Ling Hung, Aletheia University, Taiwan<br>Chao-Tsun Chang, Hsiup=
ing Institute Technology, Taiwan<br>Gwo-Jong Yu, Aletheia University, Taiwa=
n<br>Sheng-Shih Wang, Minghsin University of Science and Technology,
 Taiwan<br>Yen-Da Chen, Lunghwa University of Science and Technology, Taiwa=
n<br>Hung-Chang Chen, Ching Kuo Institute of Management and Health, Taiwan<=
br>Wen-Hwa Liao, Tatung University, Taiwan<br>Chih-Min Chao, National Taiwa=
n Ocean University, Taiwan<br></div></div><br>=0A=0A=0A=0A      </body></ht=
ml>
--0-1805638323-1247820558=:40928--

Date: Fri, 17 Jul 2009 09:35:49 +0100
From: Paulo Mendes <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: U-NET'09 (User-provided networking) workshop, co-located with ACM CoNext

(Apologies if you get this twice)

ACM U-NET'09 � User-provided Networking: Challenges and Opportunities
Co-located with ACM CoNEXT 2009
Rome, Italy, December 1, 2009
http://conferences.sigcomm.org/co-next/2009/workshops/unet/

*NEW SUBMISSION DEADLINE*: August 7th, 2009

Submit at: http://edas.info/N7753

**(Now with a Technical Panel)**

*Motivation*

This workshop is dedicated to the debate of concepts, challenges, and 
opportunities concerning user-provided networking, i.e., scenarios where 
users cooperate by sharing wireless resources as well as Internet services.
To provide a specific example that relates to Internet access 
(connectivity), the end-user (or a community of end-users) is a 
micro-operator in the sense that he/she shares his/her subscribed 
broadband Internet access based on some form of incentive scheme. In 
addition, the end-user may or may not provide other network 
functionality such as local mobility management, or persistent storage 
and forwarding services. This new role is disruptive in what concerns 
Internet service models, since there is no distinction between what is 
today known as end-user device and network device: in the future, 
end-user devices will actively participate as part of the network. In 
contrast, the Internet has been up to now mostly the means for end-users 
to obtain some form of network service, originally related to 
connectivity, person-to-person communication, or information retrieval. 
Such user-centric provider role is also disruptive given that the 
regular network boundaries of trust have to be extended in a way that 
should mimic social behavior: there is the need to form networks of 
trust in order to accommodate a robust network growth, given that the 
key to such growth is the willingness to cooperate.

Another disruptive aspect of user-provided networking is that due to the 
nature of the wireless media and the way that humans move, support for 
intermittent connectivity as well as fast and transparent roaming 
between micro-operators needs to be considered. Finally, and given that 
user-provided networking spreads dynamically having as network elements 
regular end-user devices, there is the need to consider cases where 
information is opportunistically relayed instead of routed based on 
topological information.

Due to the disruptive aspects mentioned, user-provided networking seem 
to have the potential to provide a paradigm shift in Internet 
communication models, given that such novel functionality allow wireless 
networks to operate in a completely autonomic way and also given that 
the end-user becomes a provider of Internet services (e.g. connectivity) 
based upon cooperation incentives or rewards and based upon his/her own 
mobility and social patterns. Services are established on the fly, and 
do not necessarily imply the use of multihop technology or routing. For 
instance, connectivity may be, in most cases, simply relayed.

The workshop program will include presentations of peer-reviewed papers 
and a discussion panel with guests from industry and academia. We 
envision U-NET as a forum aiming to ignite a debate concerning technical 
challenges and impact (negatively or positively) that user-provided 
networking may have on Internet communication models.

*Topics*

U-NET'09 solicits high quality technical contributions within the 
context of user-provided networking. Topics of interest include but are 
not limited to:

* Challenges and opportunities for access providers.
* Impact on Internet architectures.
* Internet connectivity.
* Trust models, incentives to share broadband access.
* Human behaviour and mobility patterns.
* Self-organization.
* Wireless cooperation.

Papers submitted are expected to be highly innovative and may 
incorporate early stage ideas; position papers (clearly identified as 
such) pointing to new directions and capable of generating discussion 
are also welcome. Submission must be original and not already published 
in any other conference proceeding or journal. Proceedings of the 
workshop will be published in the ACM Digital Library.

*Technical Panel Discussion*

U-NET'09 aims to be a forum to debate the technical challenges and 
impact of deploying user-provided networking technology. For this 
propose, this first edition of U-NET will host a technical discussion 
panel constituted by:

* Shivendra S. Panwar, Professor at Polytechnic Institute of New York 
University, USA
* James Kempf, Senior Architect at Ericsson Research, USA
* David Kennedy, Director at Eurescom GmbH, Germany
* Jordi Vallejo, CTO at FON Wireless Ltd, Spain
* Dirk Trossen, Chief Researcher at BT Design and Innovation, United 
Kingdom

*Submissions*

Submitted papers must be at most 6 (six) pages long (including figures, 
tables and references) in the standard ACM double column format. All 
text must use font sizes of 10 points or larger. Longer submissions will 
not be reviewed. The review process is single-blind. Submissions will be 
done via EDAS at http://edas.info/N7753.

*Important Dates*

Submissions due: August 7, 2009
Notification of acceptance: September 4, 2009
Camera ready version due: October 1, 2009
Workshop date: December 1, 2009

*Program Committee*

PC Chairs

Paulo Mendes, INESC Porto, Portugal
Olivier Marc�, Alcatel-Lucent Bell Labs, France

Technical Program Committee

Rute Sofia, INESC Porto, Portugal
Andr� Z�quete, University of Aveiro, Portugal
Vassilis Kostakos, University of Madeira, Portugal
Jon Crowcroft, University of Cambridge, United Kingdom
Cecilia Mascolo, University of Cambridge, United Kingdom
Eiko Yoneki, University of Cambridge, United Kingdom
Dirk Trossen, British Telecom Innovate, United Kingdom
Prosper Chemouli, France Telecom, France
Martin May, Thomson Paris Research Laboratory, France
Karen Sollins, MIT, USA
Lixia Zhang, UCLA, USA
James Kempf, Ericsson Research, USA
Dipankar Raychaudhuri, Rutgders University, USA
Bernhard Plattner, ETH, Switzerland
George Polyzos, Athens University of Economics and Business, Greece
Maria Papadopouli, FORTH/University of Creete, Greece
Anand Prasand, NEC, Japan
Gunnar Karlsson, KTH, Sweden
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Marcus Brunner, NEC, Germany
Petri M�h�nen, RWTH Aachen University, Germany

-- 
-----------------------------------------------------
Paulo Mendes, Ph.D
Area Leader, Internet Architectures and Networking
Telecommunication and Multimedia Unit
INESC Porto
Tel. +351 22 209 4264
Fax. +351 22 209 4050
http://ian.inescporto.pt

Date: Thu, 16 Jul 2009 14:59:56 -0400
From: Armando Caro <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: Kevin Fall <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Yes, I understand that in engineering there are several possible design 
decisions and trade-offs with each. I also understand that the 
trade-offs are weighed based on many things, one of which is how 
common/important an issue is. I didn't intend to convey ideology. My 
point was that the lack of accurate and precise time should not be 
considered an anomaly in DTNs, especially when the D stands for 
Disruption. I realize that the D initially stood for Delay (only), and 
that NASA networks do not have the same time sync issues that military 
networks do (for example). But if we are generalizing a delay/disruption 
tolerant store and forward networking protocol, I do not think that time 
sync should be a requirement.

Armando

Burleigh, Scott C wrote:
> Sure, and unsigned 16-bit integer port numbers shouldn't be needed to do terrestrial networking either -- and in fact they are not, there are other designs that also work.  RFC 5050's reliance on time sync is a design decision, for which an argument can be made, and one can also make a counter-argument.  Both positions have merit and are worth discussing.  This isn't ideology, it's engineering, and the assertion of a personal conviction doesn't really do much to advance it.
> 
> Scott 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Armando Caro
>> Sent: Wednesday, July 15, 2009 1:56 PM
>> To: Kevin Fall
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>> Kevin Fall wrote:
>>> While I agree there are some special cases where time isn't available
>>> or is just so far out of sync as to be wrong, I believe this should be
>>> considered more of an anomaly.
>> That's debatable. IMHO, time sync shouldn't be needed to do store and
>> forward networking.
>>
>> --
>> Armando
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Jul 2009 07:38:34 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] IETF 75 Draft Agenda

I suggest putting the naming/addressing last (and there really isn't addressing as of this time, just naming).  I suggest this as I suspect it will be the most difficult topic and run long and needs more than 1/2 hour.

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Thursday, July 16, 2009 12:45 AM
>To: [email-masked]
>Subject: [dtn-interest] IETF 75 Draft Agenda
>
>
>I have uploaded a draft agenda for the upcoming IETF meeting.  We meet
>on Friday in the morning.
>The link is here:
>
>http://www.ietf.org/proceedings/09jul/agenda/DTNRG.txt
>
>Below is the current contents of the file.  It is very much subject to
>change, depending on what we would like to cover.  Please submit
>requests for changes to myself or Stephen (and cc the list).
>
>thx,
>  -K
>
>IETF 75
>DTNRG (draft) Agenda
>Jul 31, 2009 / 0900-1130 (Morning Session I)
>Location: Cabaret
>
>0900	Agenda bash			(chairs)
>0915	RFC/ID review			(chairs)
>	   [plus IAB comments from thu]
>0945	Disconnectathon Report		(Ott?)
>1015	DTN URI Scheme (more name/addr)	(Burleigh?, Fall?)
>1045	Management			(Ivancic?)
>1100	APIs
>1115	Opens / close
>
>Other potential topics of interest:
>	cipher suites
>	time sync
>	bundle security
>	N4C update
>	NASA update
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Wed, 15 Jul 2009 21:44:41 -0700
Subject: [dtn-interest] IETF 75 Draft Agenda

I have uploaded a draft agenda for the upcoming IETF meeting.  We meet  
on Friday in the morning.
The link is here:

http://www.ietf.org/proceedings/09jul/agenda/DTNRG.txt

Below is the current contents of the file.  It is very much subject to  
change, depending on what we would like to cover.  Please submit  
requests for changes to myself or Stephen (and cc the list).

thx,
  -K

IETF 75
DTNRG (draft) Agenda
Jul 31, 2009 / 0900-1130 (Morning Session I)
Location: Cabaret

0900	Agenda bash			(chairs)
0915	RFC/ID review			(chairs)
	   [plus IAB comments from thu]
0945	Disconnectathon Report		(Ott?)
1015	DTN URI Scheme (more name/addr)	(Burleigh?, Fall?)
1045	Management			(Ivancic?)
1100	APIs
1115	Opens / close

Other potential topics of interest:
	cipher suites
	time sync
	bundle security
	N4C update
	NASA update

From: Peter Lovell <[email-masked]>
To: Scott Burleigh <[email-masked]>, Keith Scott <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>, [email-masked]
Date: Wed, 15 Jul 2009 20:08:23 -0400
Subject: [dtn-interest] Re(2): Question regarding CBHE and Bundle Security Protocol

Hi Scott and Keith and Will,

On Wed, Jul 15, 2009, Burleigh, Scott C <[email-masked]> wrote:

>Can somebody who has a stronger grasp of BSP than I do
>offer a recommendation on this?

I get the feeling that I'm "it" on this one :)

> The EID reference bit in the block flags, together with canonicalization of
> the primary bundle header by the security mechanisms, MAY obviate the need
> for the CBHE note below restricting the order and contents of the
> dictionary.  That is, because we know which blocks reference entries into
> the dictionary (and their offsets) we can fix them as needed.  Also,
> because security canonicalizes the primary bundle header, it doesn't really
> care about order, and it ONLY cares about certain strings from the
> dictionary.

Canonicalization is an issue for PIB because the bundle must be
reconstituted exactly, within the description of the canonicalization.
Right now we have a good understanding of what that is but there could
be other ciphersuites that have different rules. For example, a PIB
suite that protects just the payload is more CBHE-friendly than the
current PI2 ciphersuite.

As things stand, references for EIDs other than the standard four are
"killers" for CBHE.

I remember that there was some discussion a long time ago about a scheme
that would allow a dictionary even within CBHE bundles. I don't
presently recall the details and will dig into the email archive to find out.

There's an additional possibility for identifying the sending node for
BAB (one-hop) besides the PHN block. The "key info" item tells you what
key to use, or how to get it, and that could include an indicator for
the sending node.

Cheers.....Peter

From: "Burleigh, Scott C" <[email-masked]>
To: Joseph Ishac <[email-masked]>
Date: Wed, 15 Jul 2009 15:03:21 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

> -----Original Message-----
> From: Joseph Ishac [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 2:39 PM
> To: Burleigh, Scott C
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> 
> Well, I guess I was thinking along the lines of starting cold and
> sending a bunch of 0-timestamp bundles... and then finally resetting the
> sequence counter when you finally do sync up by X method.

Sure, but at that point you're reusing the sequence numbers within the context of a different timestamp.  You continue using the same method and it continues to work fine.

> However, say
> you fall out of that back into a state where your out of sync and want
> to start sending bundles with timestamps of 0.  Did you remember where
> you left off last time?  After all those initial bundles could still be
> floating out there, given the large TTL.

But why would you drop back to 0?  Why not just stay at whatever your most recent clock value was and continue incrementing from there?

> I suppose that a large sequential history of what you sent isn't needed,
> but some history specifically for this case would be.
> 
> Also, if your database were to become corrupted, what does your status
> as a DTN citizen become if you do start doubling up on the sequence
> number?

Duplicate bundle IDs are always invalid, so you would certainly be reviled by other DTN citizens.  But likewise you would suffer grave embarrassment if you forgot your own endpoint IDs and started using somebody else's, or started disregarding your own security policy, or descended into any of a zillion other pathologies that only a healthy and uncorrupted memory can prevent.  If you've got a corrupted database, duplicate bundle IDs are the least of your problems.

Scott

> On Wed, Jul 15, 2009 at 04:23:46PM -0500, Burleigh, Scott C wrote:
> > Joseph, I think you are perceiving a difficulty that I am missing, so
> please help me understand.  To me, it seems simple: you have a counter in
> non-volatile storage somewhere (e.g., a database) and whenever you need a
> new timestamp sequence number you retrieve the value of that counter, add 1
> to it, store the result back into non-volatile storage, and use that result
> as your timestamp sequence number.  It's unique (within source EID) because
> you always increment it, and it never has to cycle around to re-use old
> values because it's sent as an SDNV: no single bundle agent is likely to
> emit more than 16 million trillion bundles, so there's no need to keep a
> record of what sequence numbers you used.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:dtn-
> > > [email-masked]] On Behalf Of Joseph
> Ishac
> > > Sent: Wednesday, July 15, 2009 1:51 PM
> > > To: [email-masked]
> > > Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> > >
> > > If you set the timestamp to 0 and your EID is fairly fixed... how do
> you
> > > ensure that you consistently pick a unique timestamp sequence number?
> > > (since that's the only field left that's changing)  Especially since
> the
> > > TTL has to be set very large to ensure the bundle is not tossed due to
> > > your lack of knowledge of time and sec 5.5 in 5050, forcing you to keep
> > > a large history of sequence numbers...

Date: Wed, 15 Jul 2009 17:38:48 -0400
From: Joseph Ishac <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs
Reply-To: Joseph Ishac <[email-masked]>

Well, I guess I was thinking along the lines of starting cold and
sending a bunch of 0-timestamp bundles... and then finally resetting the
sequence counter when you finally do sync up by X method.  However, say
you fall out of that back into a state where your out of sync and want
to start sending bundles with timestamps of 0.  Did you remember where
you left off last time?  After all those initial bundles could still be
floating out there, given the large TTL.

I suppose that a large sequential history of what you sent isn't needed,
but some history specifically for this case would be.

Also, if your database were to become corrupted, what does your status
as a DTN citizen become if you do start doubling up on the sequence
number?

-Joseph

On Wed, Jul 15, 2009 at 04:23:46PM -0500, Burleigh, Scott C wrote:
> Joseph, I think you are perceiving a difficulty that I am missing, so please help me understand.  To me, it seems simple: you have a counter in non-volatile storage somewhere (e.g., a database) and whenever you need a new timestamp sequence number you retrieve the value of that counter, add 1 to it, store the result back into non-volatile storage, and use that result as your timestamp sequence number.  It's unique (within source EID) because you always increment it, and it never has to cycle around to re-use old values because it's sent as an SDNV: no single bundle agent is likely to emit more than 16 million trillion bundles, so there's no need to keep a record of what sequence numbers you used.
> 
> Scott
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> > [email-masked]] On Behalf Of Joseph Ishac
> > Sent: Wednesday, July 15, 2009 1:51 PM
> > To: [email-masked]
> > Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> > 
> > If you set the timestamp to 0 and your EID is fairly fixed... how do you
> > ensure that you consistently pick a unique timestamp sequence number?
> > (since that's the only field left that's changing)  Especially since the
> > TTL has to be set very large to ensure the bundle is not tossed due to
> > your lack of knowledge of time and sec 5.5 in 5050, forcing you to keep
> > a large history of sequence numbers...
> > 
> > -Joseph
> > 
> > 
> > 
> > On Wed, Jul 15, 2009 at 02:40:03PM -0500, Hans Kruse wrote:
> > > There are two cases mixed here:
> > >
> > > (1) Current use, absolute time.  Used when RTT is large, time to live is
> > coarse grained, and I don't want every forwarder to have to subtract
> > transit times from the TTL.  Bootstrap timing with Timestamp=0,
> > sequence+EID unique, very large time  to live.   In an earlier message I
> > suggested that I would not forward such a bundle, but accept it for
> > delivery to a local applications (e.g. a time server).  Only usable if
> > working clocks are the normal case, and I need to bootstrap very rarely.
> > >
> > > (2) Future case, after some more ID writing:  Previously reserved header
> > flag N now defined to mean 0=absolute time as before, 1=ignore time stamp,
> > treat time to live as relative time to be decremented.  Flag=1 used where
> > RTTs are small, time to live needs to be fine grained, and clock sync is
> > hard or adds too much cost.
> > >
> > >
> > >
> > > On Jul 15, 2009, at 3:13 PM, Ivancic, William D. (GRC-RHN0) wrote:
> > >
> > > I was already assuming the EID unique, but I need uniqueness per EID.
> > The sequence number will give me that as the timestamp will not if always
> > set to zero.
> > >
> > > So now I send a packet and if I want it have not expired, I make sure
> > that it is at least July15,2009 20:00 UTC, but of course I many not know
> > the date on bootup so I make it infinitely long (or really really long).
> > >
> > > Do you pass such a bundle?
> > >
> > > What happens if the bundle is from the future?  What is your storage and
> > forwarding policy for that?
> > >
> > >
> > > /will
> > >
> > >
> > >
> > > From: Hans Kruse [mailto:[email-masked]]
> > > Sent: Wednesday, July 15, 2009 2:36 PM
> > > To: Ivancic, William D. (GRC-RHN0)
> > > Cc: Peter Lovell; [email-masked]<mailto:dtn-
> > [email-masked]>
> > > Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> > >
> > > There are two fields, the time stamp (seconds after 2000), and a sequence
> > number.  Time stamp + sequence number + EID must be unique.
> > >
> > > On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
> > >
> > >
> > >
> > >
> > > Personally, I think that some implementations might use a zero time as
> > > an indication that the "lifetime" is to be treated as a hop count
> > > (probably small). This could be useful for the initialization phase for
> > > new nodes, or ones restarting after power failure etc.
> > >
> > > Regards.....Peter
> > >
> > > This sounded really good until ....
> > >
> > > The creation timestamp determines the uniqueness of the packet.
> > >
> > > And....
> > >
> > > Really long lifetimes are likely to be discarded.
> > >
> > >
> > > /Will
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > 
> > Content-Description: ATT00001.txt
> > > _______________________________________________
> > > dtn-interest mailing list
> > > [email-masked]
> > > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> > 
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Armando Caro <[email-masked]>, Kevin Fall <[email-masked]>
Date: Wed, 15 Jul 2009 14:34:38 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Sure, and unsigned 16-bit integer port numbers shouldn't be needed to do terrestrial networking either -- and in fact they are not, there are other designs that also work.  RFC 5050's reliance on time sync is a design decision, for which an argument can be made, and one can also make a counter-argument.  Both positions have merit and are worth discussing.  This isn't ideology, it's engineering, and the assertion of a personal conviction doesn't really do much to advance it.

Scott 

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Armando Caro
> Sent: Wednesday, July 15, 2009 1:56 PM
> To: Kevin Fall
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Time synchronization within DTNs
> 
> Kevin Fall wrote:
> > While I agree there are some special cases where time isn't available
> > or is just so far out of sync as to be wrong, I believe this should be
> > considered more of an anomaly.
> 
> That's debatable. IMHO, time sync shouldn't be needed to do store and
> forward networking.
> 
> --
> Armando
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Joseph Ishac <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 14:23:46 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

Joseph, I think you are perceiving a difficulty that I am missing, so please help me understand.  To me, it seems simple: you have a counter in non-volatile storage somewhere (e.g., a database) and whenever you need a new timestamp sequence number you retrieve the value of that counter, add 1 to it, store the result back into non-volatile storage, and use that result as your timestamp sequence number.  It's unique (within source EID) because you always increment it, and it never has to cycle around to re-use old values because it's sent as an SDNV: no single bundle agent is likely to emit more than 16 million trillion bundles, so there's no need to keep a record of what sequence numbers you used.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Joseph Ishac
> Sent: Wednesday, July 15, 2009 1:51 PM
> To: [email-masked]
> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> 
> If you set the timestamp to 0 and your EID is fairly fixed... how do you
> ensure that you consistently pick a unique timestamp sequence number?
> (since that's the only field left that's changing)  Especially since the
> TTL has to be set very large to ensure the bundle is not tossed due to
> your lack of knowledge of time and sec 5.5 in 5050, forcing you to keep
> a large history of sequence numbers...
> 
> -Joseph
> 
> 
> 
> On Wed, Jul 15, 2009 at 02:40:03PM -0500, Hans Kruse wrote:
> > There are two cases mixed here:
> >
> > (1) Current use, absolute time.  Used when RTT is large, time to live is
> coarse grained, and I don't want every forwarder to have to subtract
> transit times from the TTL.  Bootstrap timing with Timestamp=0,
> sequence+EID unique, very large time  to live.   In an earlier message I
> suggested that I would not forward such a bundle, but accept it for
> delivery to a local applications (e.g. a time server).  Only usable if
> working clocks are the normal case, and I need to bootstrap very rarely.
> >
> > (2) Future case, after some more ID writing:  Previously reserved header
> flag N now defined to mean 0=absolute time as before, 1=ignore time stamp,
> treat time to live as relative time to be decremented.  Flag=1 used where
> RTTs are small, time to live needs to be fine grained, and clock sync is
> hard or adds too much cost.
> >
> >
> >
> > On Jul 15, 2009, at 3:13 PM, Ivancic, William D. (GRC-RHN0) wrote:
> >
> > I was already assuming the EID unique, but I need uniqueness per EID.
> The sequence number will give me that as the timestamp will not if always
> set to zero.
> >
> > So now I send a packet and if I want it have not expired, I make sure
> that it is at least July15,2009 20:00 UTC, but of course I many not know
> the date on bootup so I make it infinitely long (or really really long).
> >
> > Do you pass such a bundle?
> >
> > What happens if the bundle is from the future?  What is your storage and
> forwarding policy for that?
> >
> >
> > /will
> >
> >
> >
> > From: Hans Kruse [mailto:[email-masked]]
> > Sent: Wednesday, July 15, 2009 2:36 PM
> > To: Ivancic, William D. (GRC-RHN0)
> > Cc: Peter Lovell; [email-masked]<mailto:dtn-
> [email-masked]>
> > Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> >
> > There are two fields, the time stamp (seconds after 2000), and a sequence
> number.  Time stamp + sequence number + EID must be unique.
> >
> > On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
> >
> >
> >
> >
> > Personally, I think that some implementations might use a zero time as
> > an indication that the "lifetime" is to be treated as a hop count
> > (probably small). This could be useful for the initialization phase for
> > new nodes, or ones restarting after power failure etc.
> >
> > Regards.....Peter
> >
> > This sounded really good until ....
> >
> > The creation timestamp determines the uniqueness of the packet.
> >
> > And....
> >
> > Really long lifetimes are likely to be discarded.
> >
> >
> > /Will
> >
> > 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
> >
> >
> >
> >
> >
> > 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
> >
> >
> 
> Content-Description: ATT00001.txt
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 15 Jul 2009 16:56:04 -0400
From: Armando Caro <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Kevin Fall wrote:
> While I agree there are some special cases where time isn't available  
> or is just so far out of sync as to be wrong, I believe this should be  
> considered more of an anomaly.  

That's debatable. IMHO, time sync shouldn't be needed to do store and 
forward networking.

-- 
Armando

Date: Wed, 15 Jul 2009 16:51:19 -0400
From: Joseph Ishac <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs
Reply-To: Joseph Ishac <[email-masked]>

If you set the timestamp to 0 and your EID is fairly fixed... how do you
ensure that you consistently pick a unique timestamp sequence number?
(since that's the only field left that's changing)  Especially since the
TTL has to be set very large to ensure the bundle is not tossed due to
your lack of knowledge of time and sec 5.5 in 5050, forcing you to keep
a large history of sequence numbers...

-Joseph

On Wed, Jul 15, 2009 at 02:40:03PM -0500, Hans Kruse wrote:
> There are two cases mixed here:
> 
> (1) Current use, absolute time.  Used when RTT is large, time to live is coarse grained, and I don't want every forwarder to have to subtract transit times from the TTL.  Bootstrap timing with Timestamp=0, sequence+EID unique, very large time  to live.   In an earlier message I suggested that I would not forward such a bundle, but accept it for delivery to a local applications (e.g. a time server).  Only usable if working clocks are the normal case, and I need to bootstrap very rarely.
> 
> (2) Future case, after some more ID writing:  Previously reserved header flag N now defined to mean 0=absolute time as before, 1=ignore time stamp, treat time to live as relative time to be decremented.  Flag=1 used where RTTs are small, time to live needs to be fine grained, and clock sync is hard or adds too much cost.
> 
> 
> 
> On Jul 15, 2009, at 3:13 PM, Ivancic, William D. (GRC-RHN0) wrote:
> 
> I was already assuming the EID unique, but I need uniqueness per EID.   The sequence number will give me that as the timestamp will not if always set to zero.
> 
> So now I send a packet and if I want it have not expired, I make sure that it is at least July15,2009 20:00 UTC, but of course I many not know the date on bootup so I make it infinitely long (or really really long).
> 
> Do you pass such a bundle?
> 
> What happens if the bundle is from the future?  What is your storage and forwarding policy for that?
> 
> 
> /will
> 
> 
> 
> From: Hans Kruse [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 2:36 PM
> To: Ivancic, William D. (GRC-RHN0)
> Cc: Peter Lovell; [email-masked]<mailto:[email-masked]>
> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> 
> There are two fields, the time stamp (seconds after 2000), and a sequence number.  Time stamp + sequence number + EID must be unique.
> 
> On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
> 
> 
> 
> 
> Personally, I think that some implementations might use a zero time as
> an indication that the "lifetime" is to be treated as a hop count
> (probably small). This could be useful for the initialization phase for
> new nodes, or ones restarting after power failure etc.
> 
> Regards.....Peter
> 
> This sounded really good until ....
> 
> The creation timestamp determines the uniqueness of the packet.
> 
> And....
> 
> Really long lifetimes are likely to be discarded.
> 
> 
> /Will
> 
> 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
> 
> 
> 
> 
> 
> 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
> 
> 

Content-Description: ATT00001.txt
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 15 Jul 2009 16:49:57 -0400
From: Armando Caro <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

I should clarify that what I have described is what we have implemented 
now, but the I-D we are working on is slightly different. We are working 
on making our approach more inter-operable with RFC 5050.

- Armando

Armando Caro wrote:
> We are working on an I-D for some BP mods we have designed and plan to 
> present them at Stockholm. This discussion touches on a couple of them 
> (relative timestamps and hops to live).
> 
> Our BPA has 2 modes of operation: absolute timestamp (rfc 5050) and 
> relative timestamp mode. We distinguish between the two modes by the 
> Timestamp-time field itself. If non-zero, the bundle is using absolute 
> timestamps so the BPA should follow RFC 5050 operation. If zero, the 
> bundle is using relative timestamps.
> 
> With relative timestamps, the Timestamp-seqnum field is used to encode 
> an "incarnation number" and "sequence number". The incarnation number is 
> to avoid sequence number collisions across reboots. The lifetime field 
> is set by the source, and is set to the number of seconds remaining til 
> the bundle expires. As the bundle traverses the network, each node is 
> responsible for decrementing the lifetime field as seconds elapse. When 
> the lifetime is decremented to 0, the bundle is expired.  (As Eric 
> Travis mentioned, CLA assistance is useful for accounting for 
> queueing/propagation delays.)
> 
> We have been using relative timestamps for 1+ years now in a couple of 
> DARPA programs, where GPS and time sync is not always available on the 
> nodes.
> 
> We do not intentionally use relative timestamps for routing loops. In 
> some scenarios/configurations, relative timestamps would be slow at 
> discarding bundles traversing loops. Instead, we plan to use Hops To 
> Live, which explicitly discards bundles that traversed more than some 
> threshold number of hops.
> 
> Armando

From: "Burleigh, Scott C" <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>, Hans Kruse <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 15 Jul 2009 13:42:45 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

I think this concept doesn't really diverge from the spec, Wes.  Section 4.5.1 says "Sequence count is the latest value (as of the time at which that transmission request was received) of a monotonically increasing positive integer counter managed by the source node's bundle protocol agent that may be reset to zero whenever the current time advances by one second.  A source Bundle Protocol Agent must never create two distinct bundles with the same source endpoint ID and bundle creation timestamp" -- the key phrase being "may be reset to zero" rather than "shall be reset to zero."  The intent explicitly is (and I believe always has been) to permit that sequence number to advance indefinitely.  So this approach would work fine and would be conformant.

An obvious question then would be "if the sequence number [within source EID] can be the unique bundle identifier anyway, why bother with creation time?"  To which I think the answer would be that we normally need the timestamp anyway to make other stuff work, in which case we only need the sequence number to disambiguate among bundles created within the same second.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Eddy, Wesley M.
> (GRC-MS00)[Verizon]
> Sent: Wednesday, July 15, 2009 12:44 PM
> To: Hans Kruse; Ivancic, William D. (GRC-RHN0)
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> 
> This is a dangerous paraphrase of the spec (RFC 5050), since the
> sequence number is a "creation timestamp sequence number"; it
> only increases within the context of a fixed creation timestamp
> (one second granularity), and then rolls back to 0.
> 
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:dtn-
> >[email-masked]] On Behalf Of Hans Kruse
> >Sent: Wednesday, July 15, 2009 2:36 PM
> >To: Ivancic, William D. (GRC-RHN0)
> >Cc: [email-masked]
> >Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
> >
> >There are two fields, the time stamp (seconds after 2000), and a
> >sequence number.  Time stamp + sequence number + EID must be unique.
> >
> >On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
> >
> >
> >
> >		Personally, I think that some implementations might use a
> >zero time as
> >
> >
> >		an indication that the "lifetime" is to be treated as a hop
> >count
> >
> >
> >		(probably small). This could be useful for the
> >initialization phase for
> >
> >
> >		new nodes, or ones restarting after power failure etc.
> >
> >
> >
> >		Regards.....Peter
> >
> >
> >
> >	This sounded really good until ....
> >
> >	The creation timestamp determines the uniqueness of the packet.
> >
> >	And....
> >
> >	Really long lifetimes are likely to be discarded.
> >
> >
> >	/Will
> >
> >
> >
> >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
> >
> >
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 15 Jul 2009 16:31:03 -0400
From: Armando Caro <[email-masked]>
To: Hans Kruse <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

We are working on an I-D for some BP mods we have designed and plan to 
present them at Stockholm. This discussion touches on a couple of them 
(relative timestamps and hops to live).

Our BPA has 2 modes of operation: absolute timestamp (rfc 5050) and 
relative timestamp mode. We distinguish between the two modes by the 
Timestamp-time field itself. If non-zero, the bundle is using absolute 
timestamps so the BPA should follow RFC 5050 operation. If zero, the 
bundle is using relative timestamps.

With relative timestamps, the Timestamp-seqnum field is used to encode 
an "incarnation number" and "sequence number". The incarnation number is 
to avoid sequence number collisions across reboots. The lifetime field 
is set by the source, and is set to the number of seconds remaining til 
the bundle expires. As the bundle traverses the network, each node is 
responsible for decrementing the lifetime field as seconds elapse. When 
the lifetime is decremented to 0, the bundle is expired.  (As Eric 
Travis mentioned, CLA assistance is useful for accounting for 
queueing/propagation delays.)

We have been using relative timestamps for 1+ years now in a couple of 
DARPA programs, where GPS and time sync is not always available on the 
nodes.

We do not intentionally use relative timestamps for routing loops. In 
some scenarios/configurations, relative timestamps would be slow at 
discarding bundles traversing loops. Instead, we plan to use Hops To 
Live, which explicitly discards bundles that traversed more than some 
threshold number of hops.

Armando

Hans Kruse wrote:
> Yup, and beyond that one might contemplate making a design like that a 
> formal addition to the protocol.  This may be a case where different 
> options "win" in different environments.
> 
> On Jul 15, 2009, at 12:40 PM, Peter Lovell wrote:
> 
>> Hi Hans,
>>
>> neither do I see any such requirement.
>>
>> Of course, RFC 5050 doesn't mandate that a zero time and long life
>> *must* be accepted, but it doesn't prohibit it.
>>
>> Personally, I think that some implementations might use a zero time as
>> an indication that the "lifetime" is to be treated as a hop count
>> (probably small). This could be useful for the initialization phase for
>> new nodes, or ones restarting after power failure etc.
>>
>> Regards.....Peter
>>
>>
>> On Wed, Jul 15, 2009, Hans Kruse <[email-masked]> wrote:
>>
>>> Why does that follow from RFC 5050?   I just scanned that again, and
>>> can't see why a timestamp of "0" (1/1/2000) would be invalid?   5050
>>> seems to also not place a limit on the lifetime, so setting it to,
>>> say, 1000 years would insure that it does not expire.
>>>
>>> As an implementer, I would generally not want to _forward_ bundles
>>> with extreme lifetime -- which is why I suggested to retrieve the
>>> clock initialization from the neighboring node.  Again, I only scanned
>>> 5050, what am I missing?
>>>
>>> On Jul 14, 2009, at 6:16 PM, Lloyd Wood wrote:
>>>
>>>>
>>>> On 14 Jul 2009, at 21:56, Hans Kruse wrote:
>>>>>
>>>>> Seems to me that we could define an administrative bundle exchange
>>>>> to get this device a (approximate) time from the next hop node when
>>>>> it finds one in range.
>>>>
>>>> except the device requesting the time doesn't know the time, and its
>>>> query bundles are dropped immediately by the receiving node for not
>>>> having valid timestamps or expiry times...
>>
>>
> 
> 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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
Armando

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>, Hans Kruse <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 15 Jul 2009 15:03:07 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

I just tested against DTN2, and this actually works, since it uses
the "bundle id" in order to fill the creation timestamp sequence
number, and bundle id doesn't reset to 0 based on a second tick. YMMV
with other bundle agents :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Eddy, Wesley
>M. (GRC-MS00)[Verizon]
>Sent: Wednesday, July 15, 2009 3:44 PM
>To: Hans Kruse; Ivancic, William D. (GRC-RHN0)
>Cc: [email-masked]
>Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>
>This is a dangerous paraphrase of the spec (RFC 5050), since the
>sequence number is a "creation timestamp sequence number"; it
>only increases within the context of a fixed creation timestamp
>(one second granularity), and then rolls back to 0.
>
>---------------------------
>Wes Eddy
>Network & Systems Architect
>Verizon FNS / NASA GRC
>Office: (216) 433-6682
>---------------------------
>
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Hans Kruse
>>Sent: Wednesday, July 15, 2009 2:36 PM
>>To: Ivancic, William D. (GRC-RHN0)
>>Cc: [email-masked]
>>Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>>
>>There are two fields, the time stamp (seconds after 2000), and a
>>sequence number.  Time stamp + sequence number + EID must be unique.
>>
>>On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
>>
>>
>>
>>		Personally, I think that some implementations might use a
>>zero time as
>>
>>
>>		an indication that the "lifetime" is to be treated as a hop
>>count
>>
>>
>>		(probably small). This could be useful for the
>>initialization phase for
>>
>>
>>		new nodes, or ones restarting after power failure etc.
>>
>>
>>
>>		Regards.....Peter
>>
>>
>>
>>	This sounded really good until ....
>>
>>	The creation timestamp determines the uniqueness of the packet.
>>
>>	And....
>>
>>	Really long lifetimes are likely to be discarded.
>>
>>
>>	/Will
>>
>>
>>
>>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
>>
>>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: Hans Kruse <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 15 Jul 2009 14:44:20 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

This is a dangerous paraphrase of the spec (RFC 5050), since the
sequence number is a "creation timestamp sequence number"; it
only increases within the context of a fixed creation timestamp
(one second granularity), and then rolls back to 0.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Hans Kruse
>Sent: Wednesday, July 15, 2009 2:36 PM
>To: Ivancic, William D. (GRC-RHN0)
>Cc: [email-masked]
>Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>
>There are two fields, the time stamp (seconds after 2000), and a
>sequence number.  Time stamp + sequence number + EID must be unique.
>
>On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
>
>
>
>		Personally, I think that some implementations might use a
>zero time as
>
>
>		an indication that the "lifetime" is to be treated as a hop
>count
>
>
>		(probably small). This could be useful for the
>initialization phase for
>
>
>		new nodes, or ones restarting after power failure etc.
>
>
>
>		Regards.....Peter
>
>
>
>	This sounded really good until ....
>
>	The creation timestamp determines the uniqueness of the packet.
>
>	And....
>
>	Really long lifetimes are likely to be discarded.
>
>
>	/Will
>
>
>
>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
>
>

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 15 Jul 2009 15:40:03 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

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

There are two cases mixed here:

(1) Current use, absolute time.  Used when RTT is large, time to live  
is coarse grained, and I don't want every forwarder to have to  
subtract transit times from the TTL.  Bootstrap timing with  
Timestamp=0, sequence+EID unique, very large time  to live.   In an  
earlier message I suggested that I would not forward such a bundle,  
but accept it for delivery to a local applications (e.g. a time  
server).  Only usable if working clocks are the normal case, and I  
need to bootstrap very rarely.

(2) Future case, after some more ID writing:  Previously reserved  
header flag N now defined to mean 0=absolute time as before, 1=ignore  
time stamp, treat time to live as relative time to be decremented.   
Flag=1 used where RTTs are small, time to live needs to be fine  
grained, and clock sync is hard or adds too much cost.

On Jul 15, 2009, at 3:13 PM, Ivancic, William D. (GRC-RHN0) wrote:

> I was already assuming the EID unique, but I need uniqueness per  
> EID.   The sequence number will give me that as the timestamp will  
> not if always set to zero.
>
> So now I send a packet and if I want it have not expired, I make  
> sure that it is at least July15,2009 20:00 UTC, but of course I many  
> not know the date on bootup so I make it infinitely long (or really  
> really long).
>
> Do you pass such a bundle?
>
> What happens if the bundle is from the future?  What is your storage  
> and forwarding policy for that?
>
>
> /will
>
>
>
> From: Hans Kruse [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 2:36 PM
> To: Ivancic, William D. (GRC-RHN0)
> Cc: Peter Lovell; [email-masked]
> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>
> There are two fields, the time stamp (seconds after 2000), and a  
> sequence number.  Time stamp + sequence number + EID must be unique.
>
> On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:
>
>
>
>
> Personally, I think that some implementations might use a zero time as
> an indication that the "lifetime" is to be treated as a hop count
> (probably small). This could be useful for the initialization phase  
> for
> new nodes, or ones restarting after power failure etc.
>
> Regards.....Peter
>
> This sounded really good until ....
>
> The creation timestamp determines the uniqueness of the packet.
>
> And....
>
> Really long lifetimes are likely to be discarded.
>
>
> /Will
>
> 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
>
>
>

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-17-944147686
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">There are two cases mixed =
here:<div><br></div><div>(1) Current use, absolute time. &nbsp;Used when =
RTT is large, time to live is coarse grained, and I don't want every =
forwarder to have to subtract transit times from the TTL. =
&nbsp;Bootstrap timing with&nbsp;Timestamp=3D0, sequence+EID unique, =
very large time &nbsp;to live. &nbsp; In an earlier message I suggested =
that I would not forward such a bundle, but accept it for delivery to a =
local applications (e.g. a time server). &nbsp;Only usable if working =
clocks are the normal case, and I need to bootstrap very rarely. =
&nbsp;</div><div><br></div><div>(2) Future case, after some more ID =
writing: &nbsp;Previously reserved header flag N now defined to mean =
0=3Dabsolute time as before, 1=3Dignore time stamp, treat time to live =
as relative time to be decremented. &nbsp;Flag=3D1 used where RTTs are =
small, time to live needs to be fine grained, and clock sync is hard or =
adds too much =
cost.</div><div><br></div><div><br></div><div><br><div><div>On Jul 15, =
2009, at 3:13 PM, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple" style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; "><div =
class=3D"Section1"><div style=3D"margin-right: 0in; margin-left: 0in; =
font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; =
margin-bottom: 0.0001pt; "><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125); ">I was already assuming =
the EID unique, but I need uniqueness per EID.&nbsp; &nbsp;The sequence =
number will give me that as the timestamp will not if always set to =
zero.<o:p></o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">So now I send a packet and if I =
want it have not expired, I make sure that it is at least July15,2009 =
20:00 UTC, but of course I many not know the date on bootup so I make it =
infinitely long (or really really long).<o:p></o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">Do you pass such a =
bundle?<o:p></o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); ">What happens if the bundle is =
from the future?&nbsp; What is your storage and forwarding policy for =
that?<o:p></o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">/will<o:p></o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"border-top-style: none; =
border-right-style: none; border-bottom-style: none; border-width: =
initial; border-color: initial; border-left-style: solid; =
border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; =
padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div =
style=3D"border-right-style: none; border-bottom-style: none; =
border-left-style: none; border-width: initial; border-color: initial; =
border-top-style: solid; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; =
padding-bottom: 0in; padding-left: 0in; "><div style=3D"margin-right: =
0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; =
">From:</span></b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif; "><span class=3D"Apple-converted-space">&nbsp;</span>Hans =
Kruse [<a href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Wednesday, July 15, 2009 =
2:36 PM<br><b>To:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Ivancic, William D. =
(GRC-RHN0)<br><b>Cc:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Peter Lovell;<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: =
blue; text-decoration: underline; =
">[email-masked]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [dtn-interest] Re(2): =
Time synchronization within DTNs<o:p></o:p></span></div></div></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><o:p>&nbsp;</o:p></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; ">There are two fields, =
the time stamp (seconds after 2000), and a sequence number. &nbsp;Time =
stamp + sequence number + EID must be unique.<o:p></o:p></div><div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><o:p>&nbsp;</o:p></div><div><div><div style=3D"margin-right: =
0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; ">On Jul 15, 2009, at =
2:09 PM, Ivancic, William D. (GRC-RHN0) =
wrote:<o:p></o:p></div></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; =
"><br><br><o:p></o:p></div><div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; =
"><br><br><o:p></o:p></div><div style=3D"margin-right: 0in; margin-left: =
0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: =
0in; margin-bottom: 0.0001pt; ">Personally, I think that some =
implementations might use a zero time as<o:p></o:p></div><blockquote =
style=3D"margin-top: 5pt; margin-bottom: 5pt; "><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; ">an indication that the "lifetime" is to be treated as a hop =
count<o:p></o:p></div></blockquote><blockquote style=3D"margin-top: 5pt; =
margin-bottom: 5pt; "><div style=3D"margin-right: 0in; margin-left: 0in; =
font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; =
margin-bottom: 0.0001pt; ">(probably small). This could be useful for =
the initialization phase for<o:p></o:p></div></blockquote><blockquote =
style=3D"margin-top: 5pt; margin-bottom: 5pt; "><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; ">new nodes, or ones restarting after power failure =
etc.<o:p></o:p></div></blockquote><blockquote style=3D"margin-top: 5pt; =
margin-bottom: 5pt; "><div style=3D"margin-right: 0in; margin-left: 0in; =
font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: 0in; =
margin-bottom: 0.0001pt; =
"><o:p>&nbsp;</o:p></div></blockquote><blockquote style=3D"margin-top: =
5pt; margin-bottom: 5pt; "><div style=3D"margin-right: 0in; margin-left: =
0in; font-size: 12pt; font-family: 'Times New Roman', serif; margin-top: =
0in; margin-bottom: 0.0001pt; =
">Regards.....Peter<o:p></o:p></div></blockquote><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><br>This sounded really good until ....<br><br>The creation =
timestamp determines the uniqueness of the packet.<span =
class=3D"Apple-converted-space">&nbsp;</span><br><br>And....<br><br>Really=
 long lifetimes are likely to be =
discarded.<br><br><br>/Will<o:p></o:p></div></div></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><o:p>&nbsp;</o:p></div><div><div><div style=3D"margin-right: =
0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
black; ">Hans Kruse, Professor<o:p></o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 9pt; font-family: Helvetica, =
sans-serif; color: black; ">J. Warren McClure School of Information and =
Telecommunication Systems<o:p></o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 9pt; font-family: Helvetica, =
sans-serif; color: black; ">Adjunct Associate Professor of Electrical =
Engineering and Computer Science<o:p></o:p></span></div><div =
style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; =
font-family: 'Times New Roman', serif; margin-top: 0in; margin-bottom: =
0.0001pt; "><span style=3D"font-size: 9pt; font-family: Helvetica, =
sans-serif; color: black; ">292 Lindley Hall, Ohio University, Athens, =
OH, 45701<o:p></o:p></span></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
black; ">740-593-4891 voice, 740-593-4889 =
fax<o:p></o:p></span></div></div><div style=3D"margin-right: 0in; =
margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; "><span =
style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
black; "><br><br></span><o:p></o:p></div></div><div style=3D"margin-right:=
 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; margin-top: 0in; margin-bottom: 0.0001pt; =
"><o:p>&nbsp;</o:p></div></div></div></div></div></span></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-17-944147686--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Wed, 15 Jul 2009 14:13:33 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

--_000_3A5AA67A8B120B48825BFFCF5443856137E50D07D1NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I was already assuming the EID unique, but I need uniqueness per EID.   The=
 sequence number will give me that as the timestamp will not if always set =
to zero.

So now I send a packet and if I want it have not expired, I make sure that =
it is at least July15,2009 20:00 UTC, but of course I many not know the dat=
e on bootup so I make it infinitely long (or really really long).

Do you pass such a bundle?

What happens if the bundle is from the future?  What is your storage and fo=
rwarding policy for that?

/will

From: Hans Kruse [mailto:[email-masked]]
Sent: Wednesday, July 15, 2009 2:36 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: Peter Lovell; [email-masked]
Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs

There are two fields, the time stamp (seconds after 2000), and a sequence n=
umber.  Time stamp + sequence number + EID must be unique.

On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:

Personally, I think that some implementations might use a zero time as
an indication that the "lifetime" is to be treated as a hop count
(probably small). This could be useful for the initialization phase for
new nodes, or ones restarting after power failure etc.

Regards.....Peter

This sounded really good until ....

The creation timestamp determines the uniqueness of the packet.

And....

Really long lifetimes are likely to be discarded.

/Will

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

--_000_3A5AA67A8B120B48825BFFCF5443856137E50D07D1NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>I was already assuming the EID unique, but I need uniqueness=
 per
EID.&nbsp; &nbsp;The sequence number will give me that as the timestamp wil=
l
not if always set to zero.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>So now I send a packet and if I want it have not expired, I =
make
sure that it is at least July15,2009 20:00 UTC, but of course I many not kn=
ow
the date on bootup so I make it infinitely long (or really really long).<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Do you pass such a bundle?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>What happens if the bundle is from the future?&nbsp; What is
your storage and forwarding policy for that?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>/will<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Hans Kruse
[mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, July 15, 2009 2:36 PM<br>
<b>To:</b> Ivancic, William D. (GRC-RHN0)<br>
<b>Cc:</b> Peter Lovell; [email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Re(2): Time synchronization within DTNs<=
o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>There are two fields, the time stamp (seconds after 20=
00),
and a sequence number. &nbsp;Time stamp + sequence number + EID must be uni=
que.<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=3DMsoNormal>On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-=
RHN0)
wrote:<o:p></o:p></p>

</div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal>Personally, I think that some implementations might us=
e a
zero time as<o:p></o:p></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal>an indication that the &quot;lifetime&quot; is to be t=
reated
as a hop count<o:p></o:p></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal>(probably small). This could be useful for the
initialization phase for<o:p></o:p></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal>new nodes, or ones restarting after power failure etc.=
<o:p></o:p></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</blockquote>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal>Regards.....Peter<o:p></o:p></p>

</blockquote>

<p class=3DMsoNormal><br>
This sounded really good until ....<br>
<br>
The creation timestamp determines the uniqueness of the packet. <br>
<br>
And....<br>
<br>
Really long lifetimes are likely to be discarded.<br>
<br>
<br>
/Will<o:p></o:p></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>Hans Kruse, Professor<o:p=
></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>J. Warren McClure School =
of
Information and Telecommunication Systems<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>Adjunct Associate Profess=
or
of Electrical Engineering and Computer Science<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>292 Lindley Hall, Ohio
University, Athens, OH, 45701<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>740-593-4891 voice,
740-593-4889 fax<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Helvetica"=
,"sans-serif";
color:black'><br>
<br>
</span><o:p></o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856137E50D07D1NDJSSCC03ndcn_--

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 15 Jul 2009 14:35:35 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

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

There are two fields, the time stamp (seconds after 2000), and a  
sequence number.  Time stamp + sequence number + EID must be unique.

On Jul 15, 2009, at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:

>
>> Personally, I think that some implementations might use a zero time  
>> as
>> an indication that the "lifetime" is to be treated as a hop count
>> (probably small). This could be useful for the initialization phase  
>> for
>> new nodes, or ones restarting after power failure etc.
>>
>> Regards.....Peter
>
> This sounded really good until ....
>
> The creation timestamp determines the uniqueness of the packet.
>
> And....
>
> Really long lifetimes are likely to be discarded.
>
>
> /Will

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-9-940279293
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">There are two fields, the time =
stamp (seconds after 2000), and a sequence number. &nbsp;Time stamp + =
sequence number + EID must be unique.<div><br><div><div>On Jul 15, 2009, =
at 2:09 PM, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br><blockquote type=3D"cite">Personally, I think =
that some implementations might use a zero time =
as<br></blockquote><blockquote type=3D"cite">an indication that the =
"lifetime" is to be treated as a hop count<br></blockquote><blockquote =
type=3D"cite">(probably small). This could be useful for the =
initialization phase for<br></blockquote><blockquote type=3D"cite">new =
nodes, or ones restarting after power failure =
etc.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Regards.....Peter<br></blockquote><br>This sounded really =
good until ....<br><br>The creation timestamp determines the uniqueness =
of the packet. <br><br>And....<br><br>Really long lifetimes are likely =
to be discarded.<br><br><br>/Will<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-9-940279293--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Peter Lovell <[email-masked]>, Hans Kruse <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 13:09:48 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

>Personally, I think that some implementations might use a zero time as
>an indication that the "lifetime" is to be treated as a hop count
>(probably small). This could be useful for the initialization phase for
>new nodes, or ones restarting after power failure etc.
>
>Regards.....Peter

This sounded really good until ....

The creation timestamp determines the uniqueness of the packet. 

And....

Really long lifetimes are likely to be discarded.

/Will

From: Hans Kruse <[email-masked]>
To: [email-masked]
Date: Wed, 15 Jul 2009 13:51:37 -0400
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

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

Yup, and beyond that one might contemplate making a design like that a  
formal addition to the protocol.  This may be a case where different  
options "win" in different environments.

On Jul 15, 2009, at 12:40 PM, Peter Lovell wrote:

> Hi Hans,
>
> neither do I see any such requirement.
>
> Of course, RFC 5050 doesn't mandate that a zero time and long life
> *must* be accepted, but it doesn't prohibit it.
>
> Personally, I think that some implementations might use a zero time as
> an indication that the "lifetime" is to be treated as a hop count
> (probably small). This could be useful for the initialization phase  
> for
> new nodes, or ones restarting after power failure etc.
>
> Regards.....Peter
>
>
> On Wed, Jul 15, 2009, Hans Kruse <[email-masked]> wrote:
>
>> Why does that follow from RFC 5050?   I just scanned that again, and
>> can't see why a timestamp of "0" (1/1/2000) would be invalid?   5050
>> seems to also not place a limit on the lifetime, so setting it to,
>> say, 1000 years would insure that it does not expire.
>>
>> As an implementer, I would generally not want to _forward_ bundles
>> with extreme lifetime -- which is why I suggested to retrieve the
>> clock initialization from the neighboring node.  Again, I only  
>> scanned
>> 5050, what am I missing?
>>
>> On Jul 14, 2009, at 6:16 PM, Lloyd Wood wrote:
>>
>>>
>>> On 14 Jul 2009, at 21:56, Hans Kruse wrote:
>>>>
>>>> Seems to me that we could define an administrative bundle exchange
>>>> to get this device a (approximate) time from the next hop node when
>>>> it finds one in range.
>>>
>>> except the device requesting the time doesn't know the time, and its
>>> query bundles are dropped immediately by the receiving node for not
>>> having valid timestamps or expiry times...
>
>

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-5-937641949
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Yup, and beyond that one might =
contemplate making a design like that a formal addition to the protocol. =
&nbsp;This may be a case where different options "win" in different =
environments.<div><br><div><div>On Jul 15, 2009, at 12:40 PM, Peter =
Lovell wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Hi Hans,<br><br>neither do I see any such =
requirement. <br><br>Of course, RFC 5050 doesn't mandate that a zero =
time and long life<br>*must* be accepted, but it doesn't prohibit it. =
<br><br>Personally, I think that some implementations might use a zero =
time as<br>an indication that the "lifetime" is to be treated as a hop =
count<br>(probably small). This could be useful for the initialization =
phase for<br>new nodes, or ones restarting after power failure =
etc.<br><br>Regards.....Peter<br><br><br>On Wed, Jul 15, 2009, Hans =
Kruse &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">Why does that follow from RFC =
5050? &nbsp;&nbsp;I just scanned that again, and =
&nbsp;<br></blockquote><blockquote type=3D"cite">can't see why a =
timestamp of "0" (1/1/2000) would be invalid? &nbsp;&nbsp;5050 =
&nbsp;<br></blockquote><blockquote type=3D"cite">seems to also not place =
a limit on the lifetime, so setting it to, =
&nbsp;<br></blockquote><blockquote type=3D"cite">say, 1000 years would =
insure that it does not expire.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">As an =
implementer, I would generally not want to _forward_ bundles =
&nbsp;<br></blockquote><blockquote type=3D"cite">with extreme lifetime =
-- which is why I suggested to retrieve the =
&nbsp;<br></blockquote><blockquote type=3D"cite">clock initialization =
from the neighboring node. &nbsp;Again, I only scanned =
&nbsp;<br></blockquote><blockquote type=3D"cite">5050, what am I =
missing?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">On Jul 14, =
2009, at 6:16 PM, Lloyd Wood wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">On 14 Jul 2009, at 21:56, Hans =
Kruse wrote:<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Seems =
to me that we could define an administrative bundle exchange =
&nbsp;<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">to get =
this device a (approximate) time from the next hop node when =
&nbsp;<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">it =
finds one in =
range.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">except the device requesting the =
time doesn't know the time, and its =
&nbsp;<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">query bundles are dropped immediately by the receiving =
node for not &nbsp;<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">having valid timestamps or =
expiry =
times...<br></blockquote></blockquote><br><br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-5-937641949--

From: Peter Lovell <[email-masked]>
To: Hans Kruse <[email-masked]>, [email-masked]
Date: Wed, 15 Jul 2009 12:40:44 -0400
Subject: [dtn-interest] Re(2):  Time synchronization within DTNs

Hi Hans,

neither do I see any such requirement. 

Of course, RFC 5050 doesn't mandate that a zero time and long life
*must* be accepted, but it doesn't prohibit it. 

Personally, I think that some implementations might use a zero time as
an indication that the "lifetime" is to be treated as a hop count
(probably small). This could be useful for the initialization phase for
new nodes, or ones restarting after power failure etc.

Regards.....Peter

On Wed, Jul 15, 2009, Hans Kruse <[email-masked]> wrote:

>Why does that follow from RFC 5050?   I just scanned that again, and  
>can't see why a timestamp of "0" (1/1/2000) would be invalid?   5050  
>seems to also not place a limit on the lifetime, so setting it to,  
>say, 1000 years would insure that it does not expire.
>
>As an implementer, I would generally not want to _forward_ bundles  
>with extreme lifetime -- which is why I suggested to retrieve the  
>clock initialization from the neighboring node.  Again, I only scanned  
>5050, what am I missing?
>
>On Jul 14, 2009, at 6:16 PM, Lloyd Wood wrote:
>
>>
>> On 14 Jul 2009, at 21:56, Hans Kruse wrote:
>>>
>>> Seems to me that we could define an administrative bundle exchange  
>>> to get this device a (approximate) time from the next hop node when  
>>> it finds one in range.
>>
>> except the device requesting the time doesn't know the time, and its  
>> query bundles are dropped immediately by the receiving node for not  
>> having valid timestamps or expiry times...

Date: Wed, 15 Jul 2009 09:29:26 -0600
From: Andrew James Jenkins <[email-masked]>
To: "Scott, Keith L." <[email-masked]>
Cc: "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Question regarding CBHE and Bundle Security	Protocol

The CBHE spec (and the latest public ION code) use the dictionary length
to determine whether a bundle is CBHE (dictionaryLength == 0) or not.
If you allow CBHE bundes to carry a dictionary, you need a new way to
signal to the bundle agent that a bundle is CBHE-encoded.

If the security-source is CBHE-compressible (i.e. ipn:32.4), why not use
the same CBHE compression in the BSP as in the BPB (scheme-offset=32,
ssp-offset=4)?

If the security-source is not CBHE-compressible, I think you would have
to unpack the CBHE compression in the BPB, so you have a dictionary with
nominally 5 entries (4 that could be CBHE, but aren't, used by the BPB;
and 1, the security-source, that isn't CBHE, used by BSP-BAB).

Andrew

Scott, Keith L. wrote:
> The bundle security protocol defines a canonical form for the primary bundle block that de-references the elements of the dictionary in a prescribed order.
> 
> It seems that if an EID reference to the sender (for BAB) were needed that it would have to be in the dictionary, but this wouldn't entirely obviate the utility of CBHE, though it might require some modification.  In particular, I think CBHE removes the dictionary altogether when CBHE is used, so one could not add a transmitting EID.  However, if one allowed the dictionary to exist (or if it's the case that this is already permitted under CBHE), even though there were no references into it from the primary bundle header, then the BAB could carry a reference to the transmitting node EID and we'd be OK.
> 
> The EID reference bit in the block flags, together with canonicalization of the primary bundle header by the security mechanisms, MAY obviate the need for the CBHE note below restricting the order and contents of the dictionary.  That is, because we know which blocks reference entries into the dictionary (and their offsets) we can fix them as needed.  Also, because security canonicalizes the primary bundle header, it doesn't really care about order, and it ONLY cares about certain strings from the dictionary.
> 
> Or we can assert the case where 'we just know' who the transmitter is (directional antennas, communications schedules, ...) and the transmitting EID can be omitted from the BAB.
> 
> 		--keith
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Wednesday, July 15, 2009 10:01 AM
> To: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; [email-masked]
> Subject: [dtn-interest] Question regarding CBHE and Bundle Security Protocol
> 
> Scott, 
> 
>>From the Note in  section  2.1 of ghe CBHE -  Constraints
> 
> http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe-02
> 
> 
> Note the "NOTE"  
> 
> Also note that the BAB is not the source, it is the neighbor, the previous hop.
> 
> 
>    Note, however, that CBHE decompression cannot faithfully recreate the
>    dictionary of a compressed primary block from an array of integers
>    unless the order of the endpoint ID reference strings in the
>    dictionary of the original, uncompressed block is known.  (The bundle
>    protocol specification does not require that the strings in the
>    dictionary appear in any particular order and does not require that
>    redundant strings be omitted from the dictionary.)  Therefore, a
>    further precondition to CBHE compression is that the endpoint ID
>    reference strings in the dictionary of the bundle to be compressed
>    must be exactly as follows, in this order and without addition:
> 
>    1.  The scheme name of the destination endpoint ID.
> 
>    2.  The scheme-specific part of the destination endpoint ID.
> 
>    3.  The scheme name of the source endpoint ID, if and only if
>        different from any prior string in the dictionary.
> 
>    4.  The scheme-specific part of the source endpoint ID, if and only
>        if different from any prior string in the dictionary.
> 
>    5.  The scheme name of the report-to endpoint ID, if and only if
>        different from any prior string in the dictionary.
> 
>    6.  The scheme-specific part of the report-to endpoint ID, if and
>        only if different from any prior string in the dictionary.
> 
>    7.  The scheme name of the current custodian endpoint ID, if and only
>        if different from any prior string in the dictionary.
> 
>    8.  The scheme-specific part of the current custodian endpoint ID, if
>        and only if different from any prior string in the dictionary.
> 
>    Note: this constraint implies that a bundle which includes any
>    extension blocks containing EID references to endpoint IDs other than
>    the block's destination, source, report-to, and current custodian
>    cannot be CBHE-compressed.
> 
> 
> Then looking at the BSP
> 
> The relevant text from the security draft on BAB is:
> 
>       An EID reference to the security-source SHOULD be present and, if
>       so, it MUST identify the forwarder of the bundle.  (If the
>       forwarding node is identified in another block of the bundle that
>       the next hop supports, e.g., the Previous Hop Insertion Block, the
>       forwarding node need not be identified in the BAB.  Similarly, if
>       the forwarding node is known through other implementation-specific
>       means, such as from the convergence layer, an EID reference need
>       not be included.)
> 
> If the security-source for the BAB (previous hop), isn't otherwise in the dictionary, I believe it has to be added.  If that is the case, then I believe BAB cannot be used with CBHE unless " the forwarding node is known through other implementation-specific means, such as from the convergence layer. "
> 
> Thus, can BAB be used with CBHE and if so, is this ION LPT implementation specific?
> 
> 
> /Will
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: "Scott, Keith L." <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 08:28:09 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Question regarding CBHE and Bundle Security Protocol

Some remarks in-line below:

> -----Original Message-----
> From: Scott, Keith L. [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 7:41 AM
> To: Ivancic, William D. (GRC-RHN0); Burleigh, Scott C. (JPL-313B)[Caltech-
> JPL]; [email-masked]
> Subject: RE: Question regarding CBHE and Bundle Security Protocol
> 
> The bundle security protocol defines a canonical form for the primary
> bundle block that de-references the elements of the dictionary in a
> prescribed order.
> 
> It seems that if an EID reference to the sender (for BAB) were needed that
> it would have to be in the dictionary, but this wouldn't entirely obviate
> the utility of CBHE, though it might require some modification.  In
> particular, I think CBHE removes the dictionary altogether when CBHE is
> used, so one could not add a transmitting EID.  However, if one allowed the
> dictionary to exist (or if it's the case that this is already permitted
> under CBHE), even though there were no references into it from the primary
> bundle header, then the BAB could carry a reference to the transmitting
> node EID and we'd be OK.

CBHE never requires that a bundle be compressed, even if compression is possible.  However, the signal that tells a receiving CBHE implementation that a bundle is compressed is a dictionary length of zero.  So if you need an EID reference to the sender in the BAB then you need a dictionary and therefore you can't do CBHE compression; the 8 SDNVs in the primary header have got to be dictionary offsets rather than node and service numbers.  Everything still works fine, you just don't get the overhead reduction.

> The EID reference bit in the block flags, together with canonicalization of
> the primary bundle header by the security mechanisms, MAY obviate the need
> for the CBHE note below restricting the order and contents of the
> dictionary.  That is, because we know which blocks reference entries into
> the dictionary (and their offsets) we can fix them as needed.  Also,
> because security canonicalizes the primary bundle header, it doesn't really
> care about order, and it ONLY cares about certain strings from the
> dictionary.

Right, it's possible that the canonicalization in BSP makes this restriction in CBHE unnecessary.  Can somebody who has a stronger grasp of BSP than I do offer a recommendation on this?

> Or we can assert the case where 'we just know' who the transmitter is
> (directional antennas, communications schedules, ...) and the transmitting
> EID can be omitted from the BAB.

Actually that is the direction I think we're moving toward in ION.  As an interim measure we've implemented the Previous Hop Node block, another approved mechanism for noting the sending EID without requiring a dictionary, but that's not completely satisfactory.  The PHN block is necessarily not parsed until after the pre-payload BAB is parsed (because the pre-payload BAB is required to be the first pre-payload extension block), but the ideal time to have this information is at the time you're parsing the pre-payload BAB: you've still got the received bundle in relatively pristine serialized form and you know the ciphersuite from the BAB, so you could easily compute the hash at this point if only you knew the key, which is a function of the sender EID, which you don't know yet.

So I am warming to the concept of having the convergence-layer adapter always declare the sender EID at the time a bundle is received, so that the pre-payload BAB handler has got this information from the start.  I've built some hooks into ION to support this, and I believe it's doable in the general case, but so far it's only implemented for the LTP CLA.
 
> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Wednesday, July 15, 2009 10:01 AM
> To: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; dtn-
> [email-masked]
> Subject: [dtn-interest] Question regarding CBHE and Bundle Security
> Protocol
> 
> Scott,
> 
> >From the Note in  section  2.1 of ghe CBHE -  Constraints
> 
> http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe-02
> 
> 
> Note the "NOTE"
> 
> Also note that the BAB is not the source, it is the neighbor, the previous
> hop.

Right, I think all of the CBHE text is pretty careful to say "security source" (i.e., for BAB, "neighbor") rather than just "source", where appropriate.  Let me know if there are places where I've slipped up.

>    Note, however, that CBHE decompression cannot faithfully recreate the
>    dictionary of a compressed primary block from an array of integers
>    unless the order of the endpoint ID reference strings in the
>    dictionary of the original, uncompressed block is known.  (The bundle
>    protocol specification does not require that the strings in the
>    dictionary appear in any particular order and does not require that
>    redundant strings be omitted from the dictionary.)  Therefore, a
>    further precondition to CBHE compression is that the endpoint ID
>    reference strings in the dictionary of the bundle to be compressed
>    must be exactly as follows, in this order and without addition:
> 
>    1.  The scheme name of the destination endpoint ID.
> 
>    2.  The scheme-specific part of the destination endpoint ID.
> 
>    3.  The scheme name of the source endpoint ID, if and only if
>        different from any prior string in the dictionary.
> 
>    4.  The scheme-specific part of the source endpoint ID, if and only
>        if different from any prior string in the dictionary.
> 
>    5.  The scheme name of the report-to endpoint ID, if and only if
>        different from any prior string in the dictionary.
> 
>    6.  The scheme-specific part of the report-to endpoint ID, if and
>        only if different from any prior string in the dictionary.
> 
>    7.  The scheme name of the current custodian endpoint ID, if and only
>        if different from any prior string in the dictionary.
> 
>    8.  The scheme-specific part of the current custodian endpoint ID, if
>        and only if different from any prior string in the dictionary.
> 
>    Note: this constraint implies that a bundle which includes any
>    extension blocks containing EID references to endpoint IDs other than
>    the block's destination, source, report-to, and current custodian
>    cannot be CBHE-compressed.
> 
> 
> Then looking at the BSP
> 
> The relevant text from the security draft on BAB is:
> 
>       An EID reference to the security-source SHOULD be present and, if
>       so, it MUST identify the forwarder of the bundle.  (If the
>       forwarding node is identified in another block of the bundle that
>       the next hop supports, e.g., the Previous Hop Insertion Block, the
>       forwarding node need not be identified in the BAB.  Similarly, if
>       the forwarding node is known through other implementation-specific
>       means, such as from the convergence layer, an EID reference need
>       not be included.)
> 
> If the security-source for the BAB (previous hop), isn't otherwise in the
> dictionary, I believe it has to be added.

It has to be added unless there's a Previous Hop Insertion Block, or the convergence-layer adapter announces the sending EID, or some other implementation-specific mechanism for determining the sending EID is present.  When you want CBHE compression, you've got to implement one of these other mechanisms rather than use an EID reference to the security source in the BAB.

> If that is the case, then I
> believe BAB cannot be used with CBHE unless " the forwarding node is known
> through other implementation-specific means, such as from the convergence
> layer. "

Fortunately, the latter doesn't seem to be too difficult.

> Thus, can BAB be used with CBHE and if so, is this ION LPT implementation
> specific?

BAB can be used with CBHE if you implement the PHN extension or if you've got an EID-aware convergence-layer adapter (or if you've figured out some other clever device); if not, you can still use a CBHE-enabled implementation but you can't let it do any actual compression.

It's certainly the case that the implementation of BAB that's integrated with ION, which is compatible with CBHE compression, is ION-specific.  Currently it gets the sender EID from the Previous Hop Insertion Block, which is not limited to neighbors reachable by LTP.  I hope to get to the point where all of the ION CL adapters are smart enough to figure out the sender EID themselves so that we can eliminate the overhead of the PHN block and simplify the BAB implementation a little, but that's at least a few weeks away.

Scott

From: "Scott, Keith L." <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 10:40:48 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Question regarding CBHE and Bundle Security Protocol

The bundle security protocol defines a canonical form for the primary bundle block that de-references the elements of the dictionary in a prescribed order.

It seems that if an EID reference to the sender (for BAB) were needed that it would have to be in the dictionary, but this wouldn't entirely obviate the utility of CBHE, though it might require some modification.  In particular, I think CBHE removes the dictionary altogether when CBHE is used, so one could not add a transmitting EID.  However, if one allowed the dictionary to exist (or if it's the case that this is already permitted under CBHE), even though there were no references into it from the primary bundle header, then the BAB could carry a reference to the transmitting node EID and we'd be OK.

The EID reference bit in the block flags, together with canonicalization of the primary bundle header by the security mechanisms, MAY obviate the need for the CBHE note below restricting the order and contents of the dictionary.  That is, because we know which blocks reference entries into the dictionary (and their offsets) we can fix them as needed.  Also, because security canonicalizes the primary bundle header, it doesn't really care about order, and it ONLY cares about certain strings from the dictionary.

Or we can assert the case where 'we just know' who the transmitter is (directional antennas, communications schedules, ...) and the transmitting EID can be omitted from the BAB.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Wednesday, July 15, 2009 10:01 AM
To: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; [email-masked]
Subject: [dtn-interest] Question regarding CBHE and Bundle Security Protocol

Scott, 

>From the Note in  section  2.1 of ghe CBHE -  Constraints

http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe-02

Note the "NOTE"  

Also note that the BAB is not the source, it is the neighbor, the previous hop.

   Note, however, that CBHE decompression cannot faithfully recreate the
   dictionary of a compressed primary block from an array of integers
   unless the order of the endpoint ID reference strings in the
   dictionary of the original, uncompressed block is known.  (The bundle
   protocol specification does not require that the strings in the
   dictionary appear in any particular order and does not require that
   redundant strings be omitted from the dictionary.)  Therefore, a
   further precondition to CBHE compression is that the endpoint ID
   reference strings in the dictionary of the bundle to be compressed
   must be exactly as follows, in this order and without addition:

   1.  The scheme name of the destination endpoint ID.

   2.  The scheme-specific part of the destination endpoint ID.

   3.  The scheme name of the source endpoint ID, if and only if
       different from any prior string in the dictionary.

   4.  The scheme-specific part of the source endpoint ID, if and only
       if different from any prior string in the dictionary.

   5.  The scheme name of the report-to endpoint ID, if and only if
       different from any prior string in the dictionary.

   6.  The scheme-specific part of the report-to endpoint ID, if and
       only if different from any prior string in the dictionary.

   7.  The scheme name of the current custodian endpoint ID, if and only
       if different from any prior string in the dictionary.

   8.  The scheme-specific part of the current custodian endpoint ID, if
       and only if different from any prior string in the dictionary.

   Note: this constraint implies that a bundle which includes any
   extension blocks containing EID references to endpoint IDs other than
   the block's destination, source, report-to, and current custodian
   cannot be CBHE-compressed.

Then looking at the BSP

The relevant text from the security draft on BAB is:

      An EID reference to the security-source SHOULD be present and, if
      so, it MUST identify the forwarder of the bundle.  (If the
      forwarding node is identified in another block of the bundle that
      the next hop supports, e.g., the Previous Hop Insertion Block, the
      forwarding node need not be identified in the BAB.  Similarly, if
      the forwarding node is known through other implementation-specific
      means, such as from the convergence layer, an EID reference need
      not be included.)

If the security-source for the BAB (previous hop), isn't otherwise in the dictionary, I believe it has to be added.  If that is the case, then I believe BAB cannot be used with CBHE unless " the forwarding node is known through other implementation-specific means, such as from the convergence layer. "

Thus, can BAB be used with CBHE and if so, is this ION LPT implementation specific?

/Will

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>,  "[email-masked]" <[email-masked]>
Date: Wed, 15 Jul 2009 09:00:40 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Question regarding CBHE and Bundle Security Protocol

Scott, 

>From the Note in  section  2.1 of ghe CBHE -  Constraints

http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe-02

Note the "NOTE"  

Also note that the BAB is not the source, it is the neighbor, the previous hop.

   Note, however, that CBHE decompression cannot faithfully recreate the
   dictionary of a compressed primary block from an array of integers
   unless the order of the endpoint ID reference strings in the
   dictionary of the original, uncompressed block is known.  (The bundle
   protocol specification does not require that the strings in the
   dictionary appear in any particular order and does not require that
   redundant strings be omitted from the dictionary.)  Therefore, a
   further precondition to CBHE compression is that the endpoint ID
   reference strings in the dictionary of the bundle to be compressed
   must be exactly as follows, in this order and without addition:

   1.  The scheme name of the destination endpoint ID.

   2.  The scheme-specific part of the destination endpoint ID.

   3.  The scheme name of the source endpoint ID, if and only if
       different from any prior string in the dictionary.

   4.  The scheme-specific part of the source endpoint ID, if and only
       if different from any prior string in the dictionary.

   5.  The scheme name of the report-to endpoint ID, if and only if
       different from any prior string in the dictionary.

   6.  The scheme-specific part of the report-to endpoint ID, if and
       only if different from any prior string in the dictionary.

   7.  The scheme name of the current custodian endpoint ID, if and only
       if different from any prior string in the dictionary.

   8.  The scheme-specific part of the current custodian endpoint ID, if
       and only if different from any prior string in the dictionary.

   Note: this constraint implies that a bundle which includes any
   extension blocks containing EID references to endpoint IDs other than
   the block's destination, source, report-to, and current custodian
   cannot be CBHE-compressed.

Then looking at the BSP

The relevant text from the security draft on BAB is:

      An EID reference to the security-source SHOULD be present and, if
      so, it MUST identify the forwarder of the bundle.  (If the
      forwarding node is identified in another block of the bundle that
      the next hop supports, e.g., the Previous Hop Insertion Block, the
      forwarding node need not be identified in the BAB.  Similarly, if
      the forwarding node is known through other implementation-specific
      means, such as from the convergence layer, an EID reference need
      not be included.)

If the security-source for the BAB (previous hop), isn't otherwise in the dictionary, I believe it has to be added.  If that is the case, then I believe BAB cannot be used with CBHE unless " the forwarding node is known through other implementation-specific means, such as from the convergence layer. "

Thus, can BAB be used with CBHE and if so, is this ION LPT implementation specific?

/Will

From: Hans Kruse <[email-masked]>
To: [email-masked]
Date: Wed, 15 Jul 2009 09:55:11 -0400
Subject: Re: [dtn-interest] Time synchronization within DTNs

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

Why does that follow from RFC 5050?   I just scanned that again, and  
can't see why a timestamp of "0" (1/1/2000) would be invalid?   5050  
seems to also not place a limit on the lifetime, so setting it to,  
say, 1000 years would insure that it does not expire.

As an implementer, I would generally not want to _forward_ bundles  
with extreme lifetime -- which is why I suggested to retrieve the  
clock initialization from the neighboring node.  Again, I only scanned  
5050, what am I missing?

On Jul 14, 2009, at 6:16 PM, Lloyd Wood wrote:

>
> On 14 Jul 2009, at 21:56, Hans Kruse wrote:
>>
>> Seems to me that we could define an administrative bundle exchange  
>> to get this device a (approximate) time from the next hop node when  
>> it finds one in range.
>
> except the device requesting the time doesn't know the time, and its  
> query bundles are dropped immediately by the receiving node for not  
> having valid timestamps or expiry times...
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>

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-1-923455965
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Why does that follow from RFC =
5050? &nbsp; I just scanned that again, and can't see why a timestamp of =
"0" (1/1/2000) would be invalid? &nbsp; 5050 seems to also not place a =
limit on the lifetime, so setting it to, say, 1000 years would insure =
that it does not expire.<div><br></div><div>As an implementer, I would =
generally not want to _forward_ bundles with extreme lifetime -- which =
is why I suggested to retrieve the clock initialization from the =
neighboring node. &nbsp;Again, I only scanned 5050, what am I =
missing?</div><div><br><div><div>On Jul 14, 2009, at 6:16 PM, Lloyd Wood =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br>On 14 Jul 2009, at 21:56, Hans Kruse =
wrote:<br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Seems to me that we could define an administrative bundle =
exchange to get this device a (approximate) time from the next hop node =
when it finds one in range.<br></blockquote><br>except the device =
requesting the time doesn't know the time, and its query bundles are =
dropped immediately by the receiving node for not having valid =
timestamps or expiry times...<br><br>DTN work: <a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a><br><br>&lt;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>&gt;&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br><br=
><br><br><br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-1-923455965--

Date: Wed, 15 Jul 2009 04:51:23 +0000
From: David Mills <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Relativity & GPS clock synchronization

Fred,

Thanks. My discourse has been influenced by the papers by Nelson and 
Pettit. I managed to duplicate Nelson's results and that was cool.

Dave

Fred Bourbour wrote:

> The link bellow gives a good overview of the effects of special and 
> general relativity on the GPS satellite clock speed.
>  
> http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html 
> <http://www.astronomy.ohio-state.edu/%7Epogge/Ast162/Unit5/gps.html>
>  
> Fred
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>  
>

From: "Fred Bourbour" <[email-masked]>
To: <[email-masked]>
Date: Tue, 14 Jul 2009 02:48:17 -0700
Subject: [dtn-interest] Relativity & GPS clock synchronization

This is a multi-part message in MIME format.

------=_NextPart_000_0025_01CA042D.8A595470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The link bellow gives a good overview of the effects of special and =
general relativity on the GPS satellite clock speed.

http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html

Fred
------=_NextPart_000_0025_01CA042D.8A595470
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The link bellow gives a good overview =
of the=20
effects of special and general relativity&nbsp;on the GPS satellite =
clock=20
speed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html"=
>http://www.astronomy.ohio-state.edu/~pogge/Ast162/Unit5/gps.html</A></FO=
NT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Fred</FONT></DIV></BODY></HTML>

------=_NextPart_000_0025_01CA042D.8A595470--

From: Kevin Fall <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Tue, 14 Jul 2009 13:39:00 -0700
Cc: "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

are you wearing a watch?

- K

On Jul 14, 2009, at Jul 141:37 PMPDT, Peter Lovell wrote:

> Is there a shadow on the wall of the cave?
>
>
> On Tue, Jul 14, 2009, Ivancic, William D. (GRC-RHN0)
> <[email-masked]> wrote:
>
>> I power up a new system in the middle of the desert or in a cave  
>> and I
>> do not have GPS.  What time is it?  What day is it? What year is it?
>>
>> Should one need to be synchronized to perform store and forward?
>>
>> Can this requirement be exploited?
>>
>> Don't think space systems, think anything.
>>
>>
>> /Will
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Henry B.
>>> Hotz
>>> Sent: Tuesday, July 14, 2009 3:00 PM
>>> To: [email-masked]
>>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>>
>>> Are there any anticipated DTN nodes which will not know UTC within a
>>> few 10's of minutes?
>>>
>>> Isn't that sufficient to make the protocol work?
>>>
>>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>>> varying requirements of different applications make it difficult to
>>> define the requirements for such a protocol.  I do think that we  
>>> might
>>> clarify the accuracy required by the protocol.  I also think there
>>> might be security issues, but they should be largely outside the  
>>> scope
>>> of the DTN protocols themselves if the timing requirements are as
>>> loose as they should be.
>>> ------------------------------------------------------
>>> The opinions expressed in this message are mine,
>>> not those of Caltech, JPL, NASA, or the US Government.
>>> [email-masked], or [email-masked]
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Marshall Eubanks <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 14 Jul 2009 20:09:55 -0400
Cc: "[email-masked]" <[email-masked]>, "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

On Jul 14, 2009, at 4:20 PM, Ivancic, William D. (GRC-RHN0) wrote:

> I power up a new system in the middle of the desert or in a cave and  
> I do not have GPS.  What time is it?  What day is it? What year is it?

There are ways.

Generally, if you don't know the time you are unlikely to know either  
location or your attitude, so you have to determine that too. If you  
are in a cave you may be out of luck without a decent neutrino detector.

In the spacecraft case, the motions of the asteroids can be predicted  
out for years at the arc second (micro radian) level. There exist  
stand-alone "star trackers" (fixed, wide angle cameras with a built in  
computer used for spacecraft navigation) that can from a cold start  
look at the sky, figure out what stars they are looking at, and thus  
get the spacecraft attitude to say maybe a milli radian or even 100  
micro radians in a few minutes from built in tables of stars. These  
devices are also sensitive enough to see the brighter asteroids, and  
thus can be used for cold-start navigation. Using built in tables of  
ephemerides for the Sun, planets and asteroids the same devices could  
figure out positions in the solar system at the 10^-4 level, or say  
order 10^4 km, anywhere in the inner solar system and again from a  
cold start with only a few minutes of observations. That would be good  
enough to, say, point an antenna at the Earth. Since bodies in the  
inner solar system move at order 10 km / sec, that would also give you  
timing to order 1000 seconds, all in principle without any moving  
parts. If you happened to be near a body with a moon you should be  
able to use two bodies for the same purpose and obtain much better  
accuracies.  Presumably in actual use you would bootstrap this result  
to lock onto a beacon or pulsar or somesuch.

The USNO at one time developed an automatic celestial navigator which  
could do star sights and determine position on the Earth's surface at  
the km level from a cold start, but IIRC it required a clock. It's  
very tough to do positioning to any useful accuracy on the Earth's  
surface at an arbitrary epoch without a clock, and thus tough to get  
the time if you don't know the position.

However, do we have to assume any of this ? What about a NONCE type  
clock - start with a random time, and
run the clock for as long as the node is up. That way, the time offset  
is random, but time intervals after the start could be assumed to be  
monotonically increasing at more or less the correct rate. (I.e., the  
clock would be syntonized, but not synchronized.) There could be a  
flag to indicate this mode of use. Wouldn't that (after 1 RTT of  
operation) suffice to avoid loops ?

Regards
Marshall

>
>
> Should one need to be synchronized to perform store and forward?
>
> Can this requirement be exploited?
>
> Don't think space systems, think anything.
>
>
> /Will
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Henry B.
>> Hotz
>> Sent: Tuesday, July 14, 2009 3:00 PM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>> Are there any anticipated DTN nodes which will not know UTC within a
>> few 10's of minutes?
>>
>> Isn't that sufficient to make the protocol work?
>>
>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>> varying requirements of different applications make it difficult to
>> define the requirements for such a protocol.  I do think that we  
>> might
>> clarify the accuracy required by the protocol.  I also think there
>> might be security issues, but they should be largely outside the  
>> scope
>> of the DTN protocols themselves if the timing requirements are as
>> loose as they should be.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Henry B. Hotz" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 14 Jul 2009 15:38:37 -0700
Cc: "[email-masked]" <[email-masked]>, "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

I think the bootstrap problem is different from the operating problem,  
though solutions to the latter might be applicable to the former.

On Jul 14, 2009, at 1:20 PM, Ivancic, William D. (GRC-RHN0) wrote:

> I power up a new system in the middle of the desert or in a cave and  
> I do not have GPS.  What time is it?  What day is it? What year is it?
>
> Should one need to be synchronized to perform store and forward?
>
> Can this requirement be exploited?
>
> Don't think space systems, think anything.

I don't think I said anything space-specific.  I'm just asking how  
tightly-synchronized nodes need to be in order for the protocols to  
function.  I'm suggesting that some 10's of minutes might be  
sufficient.  Applications probably need better than that for other  
reasons.  (IMO that's a good place to be, design-wise.)

We should specify our time-sync needs to satisfy the three uses that  
W. Eddy listed.  If we provide any time-sync solutions then we should  
specify how good they are since there will always be applications that  
need something better.

> /Will
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Henry B.
>> Hotz
>> Sent: Tuesday, July 14, 2009 3:00 PM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>> Are there any anticipated DTN nodes which will not know UTC within a
>> few 10's of minutes?
>>
>> Isn't that sufficient to make the protocol work?
>>
>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>> varying requirements of different applications make it difficult to
>> define the requirements for such a protocol.  I do think that we  
>> might
>> clarify the accuracy required by the protocol.  I also think there
>> might be security issues, but they should be largely outside the  
>> scope
>> of the DTN protocols themselves if the timing requirements are as
>> loose as they should be.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From: Lloyd Wood <[email-masked]>
To: Hans Kruse <[email-masked]>
Date: Tue, 14 Jul 2009 23:16:47 +0100
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

On 14 Jul 2009, at 21:56, Hans Kruse wrote:
>
> Seems to me that we could define an administrative bundle exchange  
> to get this device a (approximate) time from the next hop node when  
> it finds one in range.

except the device requesting the time doesn't know the time, and its  
query bundles are dropped immediately by the receiving node for not  
having valid timestamps or expiry times...

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 14 Jul 2009 23:13:30 +0100
Cc: "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <[email-masked]>, "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

NVRAM doesn't write itself.

Maintaining power for an accurate time is not always possible.

Sleeping sensor motes will not want to waste power on maintaining
an onboard clock; writing NVRAM when they're on only gives the last
previous time powered as a minimum.

On 14 Jul 2009, at 21:40, Kevin Fall wrote:

> Well, most of the 'new' systems I take to a cave have been set up at
> least a little (say with software) at which time you can write the
> year and approx time into NVRAM (which, as the futurists tell me will
> be all sort of RAM eventually).
>
> Also, I usually look at my watch to get the time instead of depending
> on GPS.
>
> - K
>
>
> On Jul 14, 2009, at Jul 141:20 PMPDT, Ivancic, William D. (GRC-RHN0)
> wrote:
>
>> I power up a new system in the middle of the desert or in a cave and
>> I do not have GPS.  What time is it?  What day is it? What year is  
>> it?
>>
>> Should one need to be synchronized to perform store and forward?
>>
>> Can this requirement be exploited?
>>
>> Don't think space systems, think anything.
>>
>>
>> /Will
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Henry B.
>>> Hotz
>>> Sent: Tuesday, July 14, 2009 3:00 PM
>>> To: [email-masked]
>>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>>
>>> Are there any anticipated DTN nodes which will not know UTC within a
>>> few 10's of minutes?
>>>
>>> Isn't that sufficient to make the protocol work?
>>>
>>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>>> varying requirements of different applications make it difficult to
>>> define the requirements for such a protocol.  I do think that we
>>> might
>>> clarify the accuracy required by the protocol.  I also think there
>>> might be security issues, but they should be largely outside the
>>> scope
>>> of the DTN protocols themselves if the timing requirements are as
>>> loose as they should be.
>>> ------------------------------------------------------
>>> The opinions expressed in this message are mine,
>>> not those of Caltech, JPL, NASA, or the US Government.
>>> [email-masked], or [email-masked]
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Hans Kruse <[email-masked]>
To: [email-masked]
Date: Tue, 14 Jul 2009 16:56:21 -0400
Subject: Re: [dtn-interest] Time synchronization within DTNs

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

Hm, so from the discussions so far, there are two problems for this  
device:

1.) if it relies on a schedule to know when a connection is usable, it  
is SOL -- can't get there from here.

2.) based on 1. above, such a device will need to do neighbor  
discovery.  Without a clock the device can't mark bundles properly to  
avoid infinite loops, and
security is probably an issue as well.

Seems to me that we could define an administrative bundle exchange to  
get this device a (approximate) time from the next hop node when it  
finds one in range.   That is much easier than full NTP, and does not  
encumber all DTN nodes with elapsed time tracking functions to deal  
with this corner case (but yes, the corner case needs to be taken care  
of).

On Jul 14, 2009, at 4:20 PM, Ivancic, William D. (GRC-RHN0) wrote:

> I power up a new system in the middle of the desert or in a cave and  
> I do not have GPS.  What time is it?  What day is it? What year is it?
>
> Should one need to be synchronized to perform store and forward?
>
> Can this requirement be exploited?
>
> Don't think space systems, think anything.
>
>
> /Will
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Henry B.
>> Hotz
>> Sent: Tuesday, July 14, 2009 3:00 PM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>> Are there any anticipated DTN nodes which will not know UTC within a
>> few 10's of minutes?
>>
>> Isn't that sufficient to make the protocol work?
>>
>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>> varying requirements of different applications make it difficult to
>> define the requirements for such a protocol.  I do think that we  
>> might
>> clarify the accuracy required by the protocol.  I also think there
>> might be security issues, but they should be largely outside the  
>> scope
>> of the DTN protocols themselves if the timing requirements are as
>> loose as they should be.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/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-4-862326038
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Hm, so from the discussions so =
far, there are two problems for this device:<div><br></div><div>1.) if =
it relies on a schedule to know when a connection is usable, it is SOL =
-- can't get there from here.</div><div><br></div><div>2.) based on 1. =
above, such a device will need to do neighbor discovery. &nbsp;Without a =
clock the device can't mark bundles properly to avoid infinite loops, =
and</div><div>security is probably an issue as well. =
&nbsp;&nbsp;</div><div><br></div><div>Seems to me that we could define =
an administrative bundle exchange to get this device a (approximate) =
time from the next hop node when it finds one in range. &nbsp; That is =
much easier than full NTP, and does not&nbsp;encumber all DTN nodes with =
elapsed time tracking functions to deal with this corner case (but yes, =
the corner case needs to be taken care of).</div><div><br><div><div>On =
Jul 14, 2009, at 4:20 PM, Ivancic, William D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>I =
power up a new system in the middle of the desert or in a cave and I do =
not have GPS. &nbsp;What time is it? &nbsp;What day is it? What year is =
it?<br><br>Should one need to be synchronized to perform store and =
forward?<br><br>Can this requirement be exploited? <br><br>Don't think =
space systems, think anything.<br><br><br>/Will<br><br><blockquote =
type=3D"cite">-----Original Message-----<br></blockquote><blockquote =
type=3D"cite">From: [email-masked] =
[<a href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of Henry =
B.<br></blockquote><blockquote =
type=3D"cite">Hotz<br></blockquote><blockquote type=3D"cite">Sent: =
Tuesday, July 14, 2009 3:00 PM<br></blockquote><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote =
type=3D"cite">Subject: Re: [dtn-interest] Time synchronization within =
DTNs<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Are there any =
anticipated DTN nodes which will not know UTC within =
a<br></blockquote><blockquote type=3D"cite">few 10's of =
minutes?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Isn't that =
sufficient to make the protocol work?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">While the idea =
of a DTN-NTP sounds interesting, I think the =
widely-<br></blockquote><blockquote type=3D"cite">varying requirements =
of different applications make it difficult =
to<br></blockquote><blockquote type=3D"cite">define the requirements for =
such a protocol. &nbsp;I do think that we =
might<br></blockquote><blockquote type=3D"cite">clarify the accuracy =
required by the protocol. &nbsp;I also think =
there<br></blockquote><blockquote type=3D"cite">might be security =
issues, but they should be largely outside the =
scope<br></blockquote><blockquote type=3D"cite">of the DTN protocols =
themselves if the timing requirements are as<br></blockquote><blockquote =
type=3D"cite">loose as they should be.<br></blockquote><blockquote =
type=3D"cite">------------------------------------------------------<br></=
blockquote><blockquote type=3D"cite">The opinions expressed in this =
message are mine,<br></blockquote><blockquote type=3D"cite">not those of =
Caltech, JPL, NASA, or the US Government.<br></blockquote><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">[email-masked]</a>, =
or <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote><blockqu=
ote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br>_______________________________________________<br>dtn-in=
terest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-4-862326038--

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Tue, 14 Jul 2009 13:40:38 -0700
Cc: "[email-masked]" <[email-masked]>, "Hotz, Henry B. \(JPL-173G\)\[JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Well, most of the 'new' systems I take to a cave have been set up at  
least a little (say with software) at which time you can write the  
year and approx time into NVRAM (which, as the futurists tell me will  
be all sort of RAM eventually).

Also, I usually look at my watch to get the time instead of depending  
on GPS.

- K

On Jul 14, 2009, at Jul 141:20 PMPDT, Ivancic, William D. (GRC-RHN0)  
wrote:

> I power up a new system in the middle of the desert or in a cave and  
> I do not have GPS.  What time is it?  What day is it? What year is it?
>
> Should one need to be synchronized to perform store and forward?
>
> Can this requirement be exploited?
>
> Don't think space systems, think anything.
>
>
> /Will
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Henry B.
>> Hotz
>> Sent: Tuesday, July 14, 2009 3:00 PM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>> Are there any anticipated DTN nodes which will not know UTC within a
>> few 10's of minutes?
>>
>> Isn't that sufficient to make the protocol work?
>>
>> While the idea of a DTN-NTP sounds interesting, I think the widely-
>> varying requirements of different applications make it difficult to
>> define the requirements for such a protocol.  I do think that we  
>> might
>> clarify the accuracy required by the protocol.  I also think there
>> might be security issues, but they should be largely outside the  
>> scope
>> of the DTN protocols themselves if the timing requirements are as
>> loose as they should be.
>> ------------------------------------------------------
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [email-masked], or [email-masked]
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Peter Lovell <[email-masked]>
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>, "Hotz, Henry B. (JPL-173G)[JPL]" <[email-masked]>, [email-masked]
Date: Tue, 14 Jul 2009 16:37:32 -0400
Subject: [dtn-interest] Re(2):  Time synchronization within DTNs

Is there a shadow on the wall of the cave?

On Tue, Jul 14, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>I power up a new system in the middle of the desert or in a cave and I
>do not have GPS.  What time is it?  What day is it? What year is it?
>
>Should one need to be synchronized to perform store and forward?
>
>Can this requirement be exploited?
>
>Don't think space systems, think anything.
>
>
>/Will
>
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Henry B.
>>Hotz
>>Sent: Tuesday, July 14, 2009 3:00 PM
>>To: [email-masked]
>>Subject: Re: [dtn-interest] Time synchronization within DTNs
>>
>>Are there any anticipated DTN nodes which will not know UTC within a
>>few 10's of minutes?
>>
>>Isn't that sufficient to make the protocol work?
>>
>>While the idea of a DTN-NTP sounds interesting, I think the widely-
>>varying requirements of different applications make it difficult to
>>define the requirements for such a protocol.  I do think that we might
>>clarify the accuracy required by the protocol.  I also think there
>>might be security issues, but they should be largely outside the scope
>>of the DTN protocols themselves if the timing requirements are as
>>loose as they should be.
>>------------------------------------------------------
>>The opinions expressed in this message are mine,
>>not those of Caltech, JPL, NASA, or the US Government.
>>[email-masked], or [email-masked]
>>
>>
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Hotz, Henry B. (JPL-173G)[JPL]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Jul 2009 15:20:04 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time synchronization within DTNs

I power up a new system in the middle of the desert or in a cave and I do not have GPS.  What time is it?  What day is it? What year is it?

Should one need to be synchronized to perform store and forward?

Can this requirement be exploited? 

Don't think space systems, think anything.

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Henry B.
>Hotz
>Sent: Tuesday, July 14, 2009 3:00 PM
>To: [email-masked]
>Subject: Re: [dtn-interest] Time synchronization within DTNs
>
>Are there any anticipated DTN nodes which will not know UTC within a
>few 10's of minutes?
>
>Isn't that sufficient to make the protocol work?
>
>While the idea of a DTN-NTP sounds interesting, I think the widely-
>varying requirements of different applications make it difficult to
>define the requirements for such a protocol.  I do think that we might
>clarify the accuracy required by the protocol.  I also think there
>might be security issues, but they should be largely outside the scope
>of the DTN protocols themselves if the timing requirements are as
>loose as they should be.
>------------------------------------------------------
>The opinions expressed in this message are mine,
>not those of Caltech, JPL, NASA, or the US Government.
>[email-masked], or [email-masked]
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 14 Jul 2009 19:40:26 +0000
From: David Mills <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Time synchronization within DTNs

Henry,

Have you talked with Jay Gao at JPL?

Ten minutes? Godz; I'm working on the microseconds and the effects of 
general relativity and radiometric raning. Chapter 17 in my new book is 
on time transfer for space data links (Mars); Chapter 18 is on time 
transfer for deep space missions. I gave preliminary rough drafts of 
those two chapters to Jay, but they keep evovling

Dave

Henry B. Hotz wrote:

>Are there any anticipated DTN nodes which will not know UTC within a  
>few 10's of minutes?
>
>Isn't that sufficient to make the protocol work?
>
>While the idea of a DTN-NTP sounds interesting, I think the widely- 
>varying requirements of different applications make it difficult to  
>define the requirements for such a protocol.  I do think that we might  
>clarify the accuracy required by the protocol.  I also think there  
>might be security issues, but they should be largely outside the scope  
>of the DTN protocols themselves if the timing requirements are as  
>loose as they should be.
>------------------------------------------------------
>The opinions expressed in this message are mine,
>not those of Caltech, JPL, NASA, or the US Government.
>[email-masked], or [email-masked]
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>  
>

From: "Henry B. Hotz" <[email-masked]>
To: [email-masked]
Date: Tue, 14 Jul 2009 12:00:01 -0700
Subject: Re: [dtn-interest] Time synchronization within DTNs

Are there any anticipated DTN nodes which will not know UTC within a  
few 10's of minutes?

Isn't that sufficient to make the protocol work?

While the idea of a DTN-NTP sounds interesting, I think the widely- 
varying requirements of different applications make it difficult to  
define the requirements for such a protocol.  I do think that we might  
clarify the accuracy required by the protocol.  I also think there  
might be security issues, but they should be largely outside the scope  
of the DTN protocols themselves if the timing requirements are as  
loose as they should be.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

From: Marshall Eubanks <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Date: Tue, 14 Jul 2009 13:06:52 -0400
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

On Jul 14, 2009, at 2:21 AM, Burleigh, Scott C wrote:

> A couple of answers:
>
> We found that quite rough clock synchronization, to within 8-10  
> seconds, was actually good enough.  If the time-to-live on a bundle  
> is a week or so, as it was for DINET, then a 10-second clock error  
> is in the noise in terms of bundle expiration timing.  Of course,  
> the better synchronized the clocks were, the more fully we could use  
> scheduled contacts (10 seconds of error might be 10 seconds worth of  
> transmission that you're missing because you're not listening yet),  
> so we did try to narrow the error on each pass.  The spacecraft  
> clock was drifting about 1 second per day, I think, and as I recall  
> we uploaded a new UTC delta at the end of each pass -- setting the  
> delta to the value we expected to be correct on the *next* pass, 2-5  
> days later.
>
> Although the clock was drifting at a rather high rate, the rate of  
> drift was nowhere near high enough to impose any risk of premature  
> bundle expiration when we uploaded these UTC delta corrections.   
> Again, we just used a fairly high time-to-live, probably at least  
> five minutes (sorry, can't remember exactly).  So we never had to do  
> anything fancy like spoof bundle creation times.
>
> You're correct that a completely reset clock would have been another  
> matter altogether.  But I think (for EPOXI, at least) a spacecraft  
> clock reset would have been a dramatic enough anomaly to warrant a  
> whole lot of special attention from the spacecraft team; bundle  
> expiration would have been the furthest thing from anybody's  
> thoughts, and I would expect they'd have used some sort of direct  
> commanding to reset the clock to a reasonable current value.
>

There are people who are interested in "TMA" type spacecraft - i.e.,  
put something out there which remains quiet or even off until  
something triggers it (like the TMA Monolith in 2001). For such craft,  
completely resetting the
clock would not be an emergency, but SOP. Don't know if anything like  
this has flown, but it would not shock me if
it has.

Regards
Marshall

> I don't think anybody claims that DTN is anywhere near being ready  
> to supplant low-level commanding altogether, and in fact I expect it  
> never will do so -- much as in terrestrial internetworking we still  
> sometimes have to give up and press ctrl^alt^del.  For routine  
> operations on spacecraft equipped with the clocks they need for  
> command sequence execution anyway, though, a DTN-based approach is  
> not difficult.
>
> Scott
> ________________________________________
> From: Lloyd Wood [[email-masked]]
> Sent: Monday, July 13, 2009 5:44 PM
> To: Burleigh, Scott C
> Cc: Lloyd Wood; Scott, Keith L.; [email-masked]
> Subject: Re: [dtn-interest] Time synchronization within DTNs
>
> Scott,
>
> a couple of questions related to this.
>
> didn't EPOXI's drifting-in-the-extremes-of-space clock have to be
> reset to the correct time before every DINET experiment?
>
> and, if you set the UTC delta value via bundling itself, did you have
> to spoof the bundle creation time with the offset to make sure that
> EPOXI wouldn't drop the bundle before processing it - as well as
> making receipt of bundles from EPOXI containing time offsets very
> tolerant of large offsets to avoid dropping any out-of-bounds bundles
> created with a highly drifting clock?
>
> In other words, how do you tolerate extreme deltas on an incorrect or
> just plain reset clock?
>
> thanks,
>
> L.
>
> On 13 Jul 2009, at 18:56, Burleigh, Scott C wrote:
>
>> Actually we did this pretty successfully for DINET:
>> �         Obviously the ability to set the bundle creation time on
>> issuance and check the expiration time on reception depends on DTN�s
>> ability to read the local system clock and know what the correct
>> time is.  ION provides a getUTCTime() function for this purpose; the
>> function reads the system clock value, adds to it a �UTC delta� (in
>> seconds), and returns the sum.  Assuming your system clock is
>> already reporting UTC time, the value of the UTC delta is the
>> current clock error, i.e., the known difference between the UTC
>> reported by the clock and the actual UTC as reported by a reference
>> clock somewhere (e.g., GPS).  [If your system clock is reporting
>> time for some local time zone rather than UTC, then the time-zone
>> difference needs to be included in the UTC delta as well.]
>> �         Aha! you respond, but how is this magical UTC delta
>> �known�?  No problemo, at least for JPL missions: the spacecraft
>> team for every spacecraft needs to know this clock error anyway, for
>> loads of other purposes, so they are already collecting time
>> correlation packets from the spacecraft and using them to construct
>> sclk/scet correlation tables (where �sclk� is spacecraft clock time
>> and �scet� is the corresponding actual spacecraft event time, both
>> notionally in UTC).  The sclk/scet table tracks and predicts the
>> drift of the spacecraft clock, so one can derive from it the
>> difference between spacecraft clock time and the actual UTC at any
>> time.  The EPOXI spacecraft team kindly extracted this information
>> for us for each DINET tracking pass.
>> �         Given the known UTC delta, we used the standard ION load/
>> go system to set the UTC delta value on the spacecraft via DTN,
>> ensuring that the values reported by getUTCTime() were correct (to
>> within a few seconds) from that point on.
>>
>> This highly manual process wouldn�t scale up well beyond a small
>> number of spacecraft, of course, but there�s nothing about it that
>> is necessarily manual.  The system that computes the updated sclk/
>> scet table for a spacecraft could certainly be modified to emit a
>> load/go bundle to update that spacecraft�s UTC delta as well.
>>
>> Which is to say that, just as with contact graph routing, for DTN in
>> space flight we have the advantage of being able to leverage off
>> work that is already being done in order to fly the spacecraft; we
>> don�t have to invent everything ourselves.  Not very helpful for
>> terrestrial DTN environments, I know, and the eventual development
>> of a full-up delay-tolerant NTP will be an attractive alternative
>> for flight DTN as well, but in the meantime I think it�s worth
>> suggesting that in some cases these problems are less daunting than
>> they may seem.
>>
>> Scott
>>
>> From: [email-masked] [mailto:[email-masked]
>> ] On Behalf Of Scott, Keith L.
>> Sent: Monday, July 13, 2009 5:54 AM
>> To: [email-masked]
>> Subject: [dtn-interest] Time synchronization within DTNs
>>
>> The bundle protocol requires loose time synchronization to support
>> the time-to-live parameter.  Does anyone have results from doing
>> time synchronization using the bundle protocol itself (i.e. time
>> synchronization over BP) and disrupted networks?
>>
>>                                --keith
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: [email-masked]
Date: Tue, 14 Jul 2009 12:36:44 EDT
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Relativistic time transfer in the solar system

<HTML><PRE><FONT FACE=arial,helvetica>Thanks, Marshall,

A few additional remarks.

&gt;&gt;  Myles Standish always refused to move JPL to the TCB. Well see if Bill  
Folkner is as resistant.

At a relativity conference sponsored by the IAU in Virginia Beach in May, 
this was discussed.  Bill is very sympathtic to the theoretical motivations.  
But my understanding of his view is that there is too much software in 
place to change the philosophy at this time.  Of course, as Myles always pointed 
out, there is no issue of "accuracy."  The choice of coordinate time is 
arbitary and is solely based upon perceptions of convenience.  Either way, TCB 
or Teph must ultimately be related to clocks registering UTC through a 
mathematical algorithm.

&gt;&gt;  The only thing I would add to this is that all solar system work is  
conducted in the harmonic gauge. These times being coordinate dependent 
quantities, not proper  times, you can get into trouble very quickly if
you start mixing gauges. It's much more dangerous than mixing drinks.

The harmonic gauge is recommended by the IAU and is advocated by many 
theorists in Europe.  JPL uses the standard Post-Newtonian formalism as 
described, for example, in MTW.  Personally, I see no advantage to harmonic 
coordinates.  However, any coordinate system may be used.  As I noted, the 
coordinates eventually disappear and the only operational quantities are the proper 
times registered by clocks.

But as you emphasize, whichever coordinate system one uses -- and thus 
whichever coordinate time one adopts -- it is essential to analyze the entire 
problem in the same coordinate system.  Mistakes would be made if one 
coordinate system were used for one aspect of a problem and another coordinate 
system were used for another aspect, without correctly making a transformation 
between them.

&gt;&gt;  And the internal GPS time has the UTC offset that obtained when the  
GPS clock was set up. Why they didn't set it to TAI I will never know.

The use of TAI, a uniform timescale without steps, as an alternative to UTC 
has been often proposed in discussions, such as at meetings of the PTTI and 
ad hoc meetings to consider a revision to UTC.  But as the BIPM notes, TAI 
is a "background laboratory timescale" that is not disseminated.  In 
practice, atomic time is obtained from a realization of UTC that is disseminated by 
a domestic laboratory, such as USNO and NIST in the USA.  The difference 
between UTC(LAB) and UTC is published later by the BIPM in its Circular T.

A significant consideration in the choice of a timescale to meet the 
desired precision in an engineering application is the method of acquisition. The 
atomic timescales maintained by USNO and NIST have a precision of roughly 
ten picoseconds per day.  By comparison, GPS Time has a precision on the order 
of ten nanoseconds per day.  Thus GPS Time, while not having steps, is 
three orders less precise than UTC(USNO) or UTC(NIST).  Although GPS Time is 
steered to UTC(USNO) with leap seconds removed, it would not be correct to say 
that GPS Time is equivalent to UTC(USNO).  (You did not imply this, but I 
have often heard this assumption stated.)

&gt;&gt; Which should be done "above" DTN to the extent possible IMHO.

I completely agree.

Thanks again for your message.

Bob<BR><BR><BR>**************<BR>Can love help you live longer? Find out now. 
(http://personals.aol.com/articles/2009/02/18/longer-lives-through-relationships/?ncid=eml
weuslove00000001)</HTML></PRE></HTML>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Jul 2009 11:00:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Disconnectathon Teleconference Notes 14 July 2009 - Next planning teleconference 21 July

The next planning teleconference will be 
21 July 2009  (Tuesday)

15:00 UTC (11:00 EDT, 8:00 Pacific, 16:00 London, 17:00 Stockholm)

Toll Outside US 1-517-600-5252
Toll Free US Only 866-783-5733
pass code  1095920

Note: I will not be on the teleconference as I will be disconnected - in flight to NASA DTN planning meeting in Colorado Springs.  However, the line will be open.

A Draft AGENDA will be sent out after Hans Kruse and I get together Thursday afternoon.  Anybody that has agenda items, please send them to Hans Kruse and Will Ivancic.

Meeting Notes 14 July 14:00 UTC
===============================
NASA Glenn will have 3 people in Stockholm and the NASA DTNbone machines will be up.

BBN will have 4 people in Stockholm and their DTNbone machines will be up.  They will also have DTN running on their laptops

OU will be in Athens Ohio supporting the Disconnectathon.  OU will post some applications that use a "socket-type" API to the DTN wiki under the DTNbone Applications page.

Kevin Fall will have some (one?) Nokia 810 tablet and would like to test the Bluetooth Convergence Layer

Elwyn Davis will be in Stockholm on his way to the N4C Summer trials.  Elwyn hopes to bring up to eleven Nokia 810s and would like to test Prophet routing and whatever portions of the Bundle Security Specification he has working.  I believe Erwin may also test DTN on some Symbian Phones

TKK will bring a JAVA TCPCL implementation and portions of the Bundle Processing.  I believe this will either be implemented on the Symbian platform or be in addition to the Symbian DTN implementation.

Elwyn has setup a mail list for participants of the Disconnectathon ONLY to reduce allow for file sharing.  Please ONLY join this if you need to share files.  It is a private controlled list.  If you wish to join, send an email to Elwyn Davis or Will Ivancic.

The Jabber room runs year round so the Jabber room for DTNRG will be used for real-time chat.

Those meeting in Stockholm will setup a meeting Wednesday morning to plan and get configurations up as much as possible.

The Disconnectathon time will start 13:00 UTC (9:00 EDT, 14:00 Stockholm).  Of course, this is the time for real-time interaction between Stockholm and the Americas and whatever part of the world others may be participating from.  It just seems like the most practical time.

Ohio University will look into establishing a Dynamic DNS server for real-time name resolution.

A host file will also be maintained on the wiki probably with the following format:

URI, IP address if fixed or DNS if in global DNS or dynamic DNS name resolver if dynamic or MAC in not communication over IP in addition to the Convergence Layer.

The DTN wiki will be used to the fullest extent possible to post real-time system configurations, Host tables for name resolution, system and network configurations.  

SEE
http://www.dtnrg.org/wiki/DtnBone

In addition to the DTNbone configurations, we will place the applications here as well.  The Disconnectathon configurations and test plans and procedures  will be placed under "Disconnectathon".  

Glenn Research Center will look at providing some test keys under:
http://www.dtnrg.org/wiki/DtnBone/SecurityTestKeys
(anyone who has tested the BSP - particularly the PIB and PSB and has some idea of what certificates should be generated - how do you pick the key? - please contact Will Ivancic).  Do people identify the keys via serial number, organization name, FQDN, other information?

We may try and establish some dtn naming schemes and associated certificates for testing.  Much of what we learn will remain for future use.  I believe Elwyn needs something for Prophet, so that may be a good starting point.

ACTION ITEMS:  Each person or group that want has specific items to test should provide Hans Kruse and Will Ivancic with the following to be posted on the wiki:
* Test Goal
* Equipment requirements
* Sufficient test plan and procedures so we can fulfill your goals.  

The more planning and organization we can complete up front the better chance we have to successfully complete these tests.

/Will

From: Marshall Eubanks <[email-masked]>
To: [email-masked]
Date: Tue, 14 Jul 2009 11:59:39 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Relativistic time transfer in the solar system

Dear Bob;

A very nice summary. A few notes in line.

On Jul 14, 2009, at 11:42 AM, [email-masked] wrote:

> All,
>
> This is a useful discussion.  It is important that relativistic  
> effects
> should be kept in mind and be recognized as important to the  
> synchronization of
> clocks.  They are not merely of theoretical scientific interest.
> Relativity has entered into the realm of practical engineering.
>
> Clocks on GPS satellites would run fast by 38 microseconds per day  
> relative
> to terrestrial clocks

As seen on the ground. Another way to put this is that GPS clocks  
(except for the very first one) do
not keep proper time, but an adjusted terrestrial time.

> if they were not offset prior to launch.  In
> addition, the navigation solution in the GPS would be in error by 46  
> feet if the
> residual periodic effects of time dilation and gravitational  
> redshift due to
> orbit eccentricity (of only 0.02) were not corrected in the  
> receiver.  (It
> would be better if the secular offset were treated mathematically in  
> the same
> way as the periodic effect instead of by a physical offset.   
> Apparently
> Galileo will do this.)  For a spacecraft in a Molnya-type 12-hour  
> orbit with
> eccentricity 0.722 the amplitude of the periodic effect is 1.7 us.
>
> Similarly, the times registered by clocks on Mars will need to be  
> corrected
> for relativity.  If the only objective is to schedule an event, such  
> as
> digging a trench, then of course such precision is not necessary.   
> But if
> signals from a clock on the planetary surface were used for  
> navigation by an
> approaching spacecraft, then serious errors would be engendered if  
> the physics
> of relativity were not considered.  Similarly, any precisely timed
> astronomical event measured from the planetary surface or from a  
> spacecraft must be
> calibrated correctly.
>
> In addition, the gravitational delay in the propagation of an
> electromagnetic signal must be considered.  The round trip time  
> delays for ranging to
> Mercury, Venus, and Mars at superior conjunction are respectively  
> 240 us, 180
> us, and 250 us.  These delays were originally measured by Shapiro.
Well, technically there were measured by the DSN.
Irwin and Bob Reasenberg just interpreted these measurements (and I  
worked on the
Mariner / Viking analysis under them).

>   Recently,
> the gravitational time delay has been observed in the APL New Horizons
> mission.
And the time delay rate by Cassini.

>
> The fundamental notion is that time is the reading of a clock.  All  
> time
> comparisons are made between clocks.  These readings are called  
> "proper time"
> (in the sense of "self time").  In any coordinate system, the relation
> between coordinate time and proper time is given by the invariant  
> spacetime
> interval, whose metric components depend on the gravitational  
> potentials in that
> coordinate system.
>
> Barycentric Coordinate Time (TCB) is a coordinate time that is defined
> mathematically as the independent argument of solar system  
> ephemerides.  (JPL
> uses its own version, called Teph, which takes out the secular  
> component and
> is, for all practical purposes, equivalent to Barycentric Dynamical  
> Time,
> TDB.)

Myles Standish always refused to move JPL to the TCB. Well see if Bill  
Folkner is as resistant.

> TCB, TDB, and Teph are mathematical coordinates that are used as
> intermediate variables in the mathematical prescription for proper  
> time
> comparisons. These coordinate times are not themselves registered by  
> clocks.  The
> actual clock readings -- on Earth or Mars or a spacecraft -- must be  
> correlated
> to them by mathematical transformations.
The only thing I would add to this is that all solar system work is  
conducted in the harmonic
gauge. These times being coordinate dependent quantities, not proper  
times, you can get into trouble very quickly if
you start mixing gauges. It's much more dangerous than mixing drinks.

>
>
> The coordinate time associated with ephemerides whose arguments are
> expressed relative to a coordinate system on the geoid is  
> Terrestrial Time (TT).
> International Atomic Time (TAI) is a coordinate time related to TT  
> by an
> offset of 32.184 seconds.  It is computed from the actual proper  
> time readings
> of atomic clocks distributed around the world, taking into account
> differences caused by their elevations above the geoid.
>
> Coordinated Universal Time (UTC) is derived from TAI by an offset of  
> an
> integral number of leap seconds to maintain a coarse approximation  
> to Earth
> Rotation Time, UT1 (which is really an angle expressed in time  
> units).  When
> UTC was introduced for broadcast radio signals in 1972, UT1 was  
> needed for
> celestial navigation by ships at sea.  The GPS has made this  
> application
> obsolete.  A much better realization of the difference between UTC  
> and UT1 for
> those who still need it, such as astronomers for pointing telescopes  
> and
> engineers for satellite tracking, is provided by the IERS via its  
> website.
> (Because the original motivation for leap seconds is no longer  
> valid, and because
> sophisticated timekeeping systems ought not to have steps, there are
> deliberations underway at the ITU and CCTF to consider a proposal to  
> eliminate leap
> seconds at some time in the future.  UTC would then be continuous  
> with the
> value of UTC at the time of adoption and TAI would become redundant  
> and
> would be discontinued.)

And the internal GPS time has the UTC offset that obtained when the  
GPS clock was set up. Why they didn't set it to
TAI I will never know.

>
> To the extent that the DTN is concerned only with protocols, these
> considerations may not seem relevant.  But to the extent that  
> precise time
> synchronization is an objective, they are of paramount importance.   
> They can, and
> should, be handled mathematically in the algorithms at the  
> appropriate level in
> the network architecture.
Which should be done "above" DTN to the extent possible IMHO.

Regards
Marshall

>
>
> Bob
>
>
> (Thanks to Lloyd Wood for calling attention to the IEEE site where  
> my paper
> can be downloaded.  I would be pleased to send it directly to anyone  
> who
> requests it.)
>
> >>  The mailing list archive doesn't record attachments. Bob  
> mentioned:
> http://dx.doi.org/10.1109/FREQ.2007.4319282
> Robert A. Nelson, Relativistic Time Transfer in the Solar System,
> Frequency Control Symposium, Joint with the 21st European Frequency
> and Time Forum, Geneva, June 2007, pp. 1278-1283.
>
>
> **************
> Looking for
> love this summer? Find it now on AOL Personals.
> (http://personals.aol.com/?ncid=emlcntuslove00000003)

From: [email-masked]
Date: Tue, 14 Jul 2009 11:42:40 EDT
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Relativistic time transfer in the solar system

<HTML><PRE><FONT FACE=arial,helvetica>All,

This is a useful discussion.  It is important that relativistic effects 
should be kept in mind and be recognized as important to the synchronization of 
clocks.  They are not merely of theoretical scientific interest.  
Relativity has entered into the realm of practical engineering.

Clocks on GPS satellites would run fast by 38 microseconds per day relative 
to terrestrial clocks if they were not offset prior to launch.  In 
addition, the navigation solution in the GPS would be in error by 46 feet if the 
residual periodic effects of time dilation and gravitational redshift due to 
orbit eccentricity (of only 0.02) were not corrected in the receiver.  (It 
would be better if the secular offset were treated mathematically in the same 
way as the periodic effect instead of by a physical offset.  Apparently 
Galileo will do this.)  For a spacecraft in a Molnya-type 12-hour orbit with 
eccentricity 0.722 the amplitude of the periodic effect is 1.7 us.

Similarly, the times registered by clocks on Mars will need to be corrected 
for relativity.  If the only objective is to schedule an event, such as 
digging a trench, then of course such precision is not necessary.  But if 
signals from a clock on the planetary surface were used for navigation by an 
approaching spacecraft, then serious errors would be engendered if the physics 
of relativity were not considered.  Similarly, any precisely timed 
astronomical event measured from the planetary surface or from a spacecraft must be 
calibrated correctly.

In addition, the gravitational delay in the propagation of an 
electromagnetic signal must be considered.  The round trip time delays for ranging to 
Mercury, Venus, and Mars at superior conjunction are respectively 240 us, 180 
us, and 250 us.  These delays were originally measured by Shapiro.  Recently, 
the gravitational time delay has been observed in the APL New Horizons 
mission.

The fundamental notion is that time is the reading of a clock.  All time 
comparisons are made between clocks.  These readings are called "proper time" 
(in the sense of "self time").  In any coordinate system, the relation 
between coordinate time and proper time is given by the invariant spacetime 
interval, whose metric components depend on the gravitational potentials in that 
coordinate system.

Barycentric Coordinate Time (TCB) is a coordinate time that is defined 
mathematically as the independent argument of solar system ephemerides.  (JPL 
uses its own version, called Teph, which takes out the secular component and 
is, for all practical purposes, equivalent to Barycentric Dynamical Time, 
TDB.)  TCB, TDB, and Teph are mathematical coordinates that are used as 
intermediate variables in the mathematical prescription for proper time 
comparisons. These coordinate times are not themselves registered by clocks.  The 
actual clock readings -- on Earth or Mars or a spacecraft -- must be correlated 
to them by mathematical transformations.

The coordinate time associated with ephemerides whose arguments are 
expressed relative to a coordinate system on the geoid is Terrestrial Time (TT).  
International Atomic Time (TAI) is a coordinate time related to TT by an 
offset of 32.184 seconds.  It is computed from the actual proper time readings 
of atomic clocks distributed around the world, taking into account 
differences caused by their elevations above the geoid.

Coordinated Universal Time (UTC) is derived from TAI by an offset of an 
integral number of leap seconds to maintain a coarse approximation to Earth 
Rotation Time, UT1 (which is really an angle expressed in time units).  When 
UTC was introduced for broadcast radio signals in 1972, UT1 was needed for 
celestial navigation by ships at sea.  The GPS has made this application 
obsolete.  A much better realization of the difference between UTC and UT1 for 
those who still need it, such as astronomers for pointing telescopes and 
engineers for satellite tracking, is provided by the IERS via its website.  
(Because the original motivation for leap seconds is no longer valid, and because 
sophisticated timekeeping systems ought not to have steps, there are 
deliberations underway at the ITU and CCTF to consider a proposal to eliminate leap 
seconds at some time in the future.  UTC would then be continuous with the 
value of UTC at the time of adoption and TAI would become redundant and 
would be discontinued.)

To the extent that the DTN is concerned only with protocols, these 
considerations may not seem relevant.  But to the extent that precise time 
synchronization is an objective, they are of paramount importance.  They can, and 
should, be handled mathematically in the algorithms at the appropriate level in 
the network architecture.

Bob

(Thanks to Lloyd Wood for calling attention to the IEEE site where my paper 
can be downloaded.  I would be pleased to send it directly to anyone who 
requests it.)

&gt;&gt;  The mailing list archive doesn't record attachments. Bob mentioned:
http://dx.doi.org/10.1109/FREQ.2007.4319282
Robert A. Nelson, Relativistic Time Transfer in the Solar System,  
Frequency Control Symposium, Joint with the 21st European Frequency  
and Time Forum, Geneva, June 2007, pp. 1278-1283.<BR><BR><BR>**************<BR>Looking for 
love this summer? Find it now on AOL Personals. 
(http://personals.aol.com/?ncid=emlcntuslove00000003)</HTML></PRE></HTML>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Elwyn Davies <[email-masked]>, DTN interest <[email-masked]>
Date: Tue, 14 Jul 2009 10:33:33 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Disconnectathon mailing list

Please note, this list is for the Disconnectathon participants to allow for things such as file sharing prior to and during the Disconnectathon.  Please only subscribe if you plan to participate in the Disconnectathon and need such services.  

Thanks,

Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Elwyn Davies
>Sent: Tuesday, July 14, 2009 11:13 AM
>To: DTN interest
>Subject: [dtn-interest] Disconnectathon mailing list
>
>Hi.
>
>As promised on the teleconference, I have created a mailing list for the
>Disconnectathon.
>
>The list is
>[email-masked]
>
>To get subscribed either send me an email or access the mailing list via
>http://info.n4c.eu/sympa
>
>Click on the Disconnectathon mailing list link and select Subscribe from
>the left hand menu.
>
>The list owners have to confirm your subscription.  The welcome message
>has some more info about the shared files system.
>
>Regards,
>Elwyn
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Elwyn Davies <[email-masked]>
To: DTN interest <[email-masked]>
Organization: Folly Consulting
Date: Tue, 14 Jul 2009 16:13:01 +0100
Subject: [dtn-interest] Disconnectathon mailing list

Hi.

As promised on the teleconference, I have created a mailing list for the
Disconnectathon.

The list is
[email-masked]

To get subscribed either send me an email or access the mailing list via
http://info.n4c.eu/sympa

Click on the Disconnectathon mailing list link and select Subscribe from
the left hand menu.

The list owners have to confirm your subscription.  The welcome message
has some more info about the shared files system.

Regards,
Elwyn

From: Kevin Fall <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Date: Tue, 14 Jul 2009 06:58:06 -0700
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

right.

Also, we might recall that DTN really came about in generalizing from  
the space/IPN to other (more terrestrial) applications.  These may be  
more challenging in some ways.  That said, most of the systems for  
which DTN was conceived need time anyhow and therefore usually have it.

While I agree there are some special cases where time isn't available  
or is just so far out of sync as to be wrong, I believe this should be  
considered more of an anomaly.  Arguments to the effect that getting  
time right is too expensive I don't find especially persuasive... we  
avoided a variable-length IP address because that would be too  
expensive to deal with.  We didn't really require any sync'd notion of  
time in the Internet so we wind up with log files with wrong dates and  
various fixes to get security right.

- K

On Jul 13, 2009, at Jul 1311:45 PMPDT, Burleigh, Scott C wrote:

> Loath as I usually am to disagree with Vint Cerf, in this particular  
> instance I do.  At least in the DTN context, where clock  
> synchronization on the order of a second or two is more than  
> sufficient, I would say there certainly is such a thing as "now".   
> If I have got a clock on a spacecraft that's 60 light seconds away,  
> and I command it to send me a message at 1300 UTC, and its clock is  
> synchronized to within 1 second of UTC as reported by an atomic  
> clock on Earth, and I am holding a watch that is likewise set to  
> within 1 second of UTC, and when my watch reads 1300 I say "now",  
> and when I do so my confederate starts a stopwatch which he stops  
> when our co-worker says "Got it" upon detecting the arrival of the  
> message, and the stopwatch thereupon reads 60 seconds (plus or minus  
> one or two seconds), then I would contend that the spacecraft sent  
> the message at the time I said "now".  Of course there's a "now".   
> If there weren't, we couldn't operate deep-space spacecraft at all.
>
> This is not to say that deep space communications doesn't open up  
> endless opportunities for exchanging well-argued email on the subtle  
> relativistic effects introduced by the motion of the spacecraft, the  
> motion of Earth, the curvature of space, whatever.  It is to say  
> that, for the purposes of DTN-based communication with spacecraft,  
> none of that matters in the slightest.  It is simply not a problem.
>
> Scott
> ________________________________________
> From: [email-masked] [[email-masked] 
> ] On Behalf Of Lloyd Wood [[email-masked]]
> Sent: Monday, July 13, 2009 6:32 PM
> To: [email-masked]
> Cc: [email-masked]; Lloyd Wood
> Subject: Re: [dtn-interest] Time synchronization within DTNs
>
> The mailing list archive doesn't record attachments. Bob mentioned:
> http://dx.doi.org/10.1109/FREQ.2007.4319282
> Robert A. Nelson, Relativistic Time Transfer in the Solar System,
> Frequency Control Symposium, Joint with the 21st European Frequency
> and Time Forum, Geneva, June 2007, pp. 1278-1283.
>
> I wish we'd known of this paper before writing the section of our
> 'Bundle of Problems' paper discussing time sync and relativity. Some
> relevant quotes:
>
> '"The problem with the interplanetary environment is that there ain't
> no such thing as 'now,' " Cerf says.'
> -- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, Aug 2005.
>
> 'The DTN architecture depends on time synchronization among DTN nodes
> (supported by external, non-DTN protocols) for four primary purposes:
> bundle and fragment identification, routing with scheduled or
> predicted contacts, bundle expiration time computations, and
> application registration expiration.'
> -- RFC4938, section 3.12, V. Cerf et al., April 2007.
>
> Once one knows that there is no such thing as 'now' and that time is
> relative, not absolute, and once one realises that the environment one
> is designing for will keep bringing that awkward reality up (not to
> mention larger clock drifts in space due to temperature variations -
> keeping time under harsh conditions is not easy) - why would the
> reality be ignored by making clock synchronization critical to the
> design?
>
> L.
>
> 'Only two things are infinite, the universe and human stupidity, and
> I'm not sure about the former.'
> -- Albert Einstein, discoverer of relativity.
>
> On 13 Jul 2009, at 22:29, [email-masked] wrote:
>
>> All,
>>
>> For precise time synchronization, relativistic effects need to be
>> considered.  These effects are not negligible.  Corrections
>> analogous to those
>> already implemented in the GPS are needed for solar system time
>> transfer.
>>
>> I attach a paper I presented at the EFTF/IEEE conference in Geneva
>> in 2007
>> for background.  The paper shows that for time transfer between Mars
>> and
>> Earth the periodic effects have amplitudes on the order of one to ten
>> milliseconds at the planetary orbital periods.
>>
>>
>> Bob  Nelson
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Marshall Eubanks <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Date: Tue, 14 Jul 2009 09:16:27 -0400
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

On Jul 14, 2009, at 2:45 AM, Burleigh, Scott C wrote:

> Loath as I usually am to disagree with Vint Cerf, in this particular  
> instance I do.  At least in the DTN context, where clock  
> synchronization on the order of a second or two is more than  
> sufficient, I would say there certainly is such a thing as "now".   
> If I have got a clock on a spacecraft that's 60 light seconds away,  
> and I command it to send me a message at 1300 UTC, and its clock is  
> synchronized to within 1 second of UTC as reported by an atomic  
> clock on Earth, and I am holding a watch that is likewise set to  
> within 1 second of UTC, and when my watch reads 1300 I say "now",  
> and when I do so my confederate starts a stopwatch which he stops  
> when our co-worker says "Got it" upon detecting the arrival of the  
> message, and the stopwatch thereupon reads 60 seconds (plus or minus  
> one or two seconds), then I would contend that the spacecraft sent  
> the message at the time I said "now".  Of course there's a "now".   
> If there weren't, we couldn't operate deep-space spacecraft at all.
>

That sets up (implicitly) a terrestrial adjusted time. That's ok, as  
long as you realize that the remote
clocks are not going to be keeping proper time. In other words, if I  
take a good clock to Mars, I will find that
your adjusted clock is running slow by a few parts in 10^-9, or maybe  
a tenth of a second per year. So, it's not just simultaneity issues.

Of course, there are simultaneity issues and at the millisecond level  
your "now" would not match the "now" set up by, say, a simultaneous  
Mars - Venus communication, but these simultaneity effects only matter  
as you move to a mesh of communications, not just a set of Earth to  
where-ever links as we have now. (It would also matter if external  
references, such as pulsars or gamma ray bursts, were to be used for  
solar system navigation and time-keeping.)

All of this of course can be and is calculated routinely and  
corrections can be applied to the extent necessary. I would suggest  
that these matters be kept at a level above DTN. In just the same way  
that Internet communications do not depend on the definition of TAI,  
DTN should be able to work with barycentric time (TCB or TDT) or a  
terrestrial adjusted time or whatever time is available / needed.

Regards
Marshall

> This is not to say that deep space communications doesn't open up  
> endless opportunities for exchanging well-argued email on the subtle  
> relativistic effects introduced by the motion of the spacecraft, the  
> motion of Earth, the curvature of space, whatever.  It is to say  
> that, for the purposes of DTN-based communication with spacecraft,  
> none of that matters in the slightest.  It is simply not a problem.
>
> Scott
> ________________________________________
> From: [email-masked] [[email-masked] 
> ] On Behalf Of Lloyd Wood [[email-masked]]
> Sent: Monday, July 13, 2009 6:32 PM
> To: [email-masked]
> Cc: [email-masked]; Lloyd Wood
> Subject: Re: [dtn-interest] Time synchronization within DTNs
>
> The mailing list archive doesn't record attachments. Bob mentioned:
> http://dx.doi.org/10.1109/FREQ.2007.4319282
> Robert A. Nelson, Relativistic Time Transfer in the Solar System,
> Frequency Control Symposium, Joint with the 21st European Frequency
> and Time Forum, Geneva, June 2007, pp. 1278-1283.
>
> I wish we'd known of this paper before writing the section of our
> 'Bundle of Problems' paper discussing time sync and relativity. Some
> relevant quotes:
>
> '"The problem with the interplanetary environment is that there ain't
> no such thing as 'now,' " Cerf says.'
> -- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, Aug 2005.
>
> 'The DTN architecture depends on time synchronization among DTN nodes
> (supported by external, non-DTN protocols) for four primary purposes:
> bundle and fragment identification, routing with scheduled or
> predicted contacts, bundle expiration time computations, and
> application registration expiration.'
> -- RFC4938, section 3.12, V. Cerf et al., April 2007.
>
> Once one knows that there is no such thing as 'now' and that time is
> relative, not absolute, and once one realises that the environment one
> is designing for will keep bringing that awkward reality up (not to
> mention larger clock drifts in space due to temperature variations -
> keeping time under harsh conditions is not easy) - why would the
> reality be ignored by making clock synchronization critical to the
> design?
>
> L.
>
> 'Only two things are infinite, the universe and human stupidity, and
> I'm not sure about the former.'
> -- Albert Einstein, discoverer of relativity.
>
> On 13 Jul 2009, at 22:29, [email-masked] wrote:
>
>> All,
>>
>> For precise time synchronization, relativistic effects need to be
>> considered.  These effects are not negligible.  Corrections
>> analogous to those
>> already implemented in the GPS are needed for solar system time
>> transfer.
>>
>> I attach a paper I presented at the EFTF/IEEE conference in Geneva
>> in 2007
>> for background.  The paper shows that for time transfer between Mars
>> and
>> Earth the periodic effects have amplitudes on the order of one to ten
>> milliseconds at the planetary orbital periods.
>>
>>
>> Bob  Nelson
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Elwyn Davies <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Organization: Folly Consulting
Date: Tue, 14 Jul 2009 13:53:34 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Meeting time correction DTN Disconnectathon	(14:00 UTC, 10:00 EDT)

Hi.

I intend to show up in Stockholm.

I  have two goals:
- To try out a new implementation on Symbian S60 mobile phones - which
should do at least part of the BSP (this was delayed due to the main
programmer getting ill but we hope that it is now likely to be ready for
testing).
- To do some work on the PRoPHET routing protocol in DTN2 with a 'low
footprint' email application.

I expect to be bringing a small swarm of nodes - mainly Nokia N810
tablets (11 of them) - which will be going on to the N4C summer field
tests after Stockholm.  I  have DTN2 running on the N810 and will be
trying out PRoPHET on a decent sized swarm.

I will be on the call (which is in an hour's time I think).

Regards,
Elwyn 
  
On Mon, 2009-07-13 at 15:02 -0500, Ivancic, William D. (GRC-RHN0) wrote:
> Meeting time is still 14:00 UTC.  I just corrected the East Coast
> time.
> 
>  
> 
> Agenda is:
> 
> 
> DRAFT AGENDA (open for suggestions)
> 
> ======================================
> 
> Primary Interoperability Tests 
> 
>  - Ohio Univ and GRC
> 
>     ** TCP CL between IP and DTN2 (requires ION update and DTN2 patch)
> 
>     ** OU has a "socket-type" API that allows the same applications to
> run over ION and DTN2
> 
>  
> 
>  - DTN Bundle Security Specification Interoperability Tests ???
> 
>  
> 
> Testing Times
> 
>  - With DTNbone machines, some of this testing could be continuous.
> 
>  
> 
> Network configurations (other than point-to-point)
> 
>  - OU and GRC would like to see some multi-hop, intermittent
> connectivity, and limited bandwidth links
> 
>    ** should these be static route or routing protocols.
> 
>    ** One will quickly see that without some type of route (name)
> aggregation, a multi-hop chain is pretty nasty to configure. 
> 
>  - Are there some routing protocols that could be tested for
> interoperability or just plain tested?
> 
>  
> 
> Post configurations on DTNRG wiki in real-time
> 
>  - NASA did this on an internal wiki for multi-center testing and it
> helped.
> 
>  
> 
> Thoughts on using unsecure dynamic DNS on DTNbone and nsupdate to
> update names to addresses (or we could create a shared key and do
> DNSSEC, but probably overkill for this testing.)
> 
>  - may allow laptops to come and go and simply run nsupdate to DTNbone
> DNS server to update address database
> 
>  - beginnings of late binding
> 
>  - forces some thought on naming as - for this system - names may have
> to be relative to some pre-configured domains (even if they are dummy
> domains). 
> 
>    This may be necessary in order to update the dns server
> 
>  - force some thought on when to try and re-resolve a name (because it
> change between the time you wanted to communicate and the time it
> reconnected to the network.
> 
>  - enables multiple physical addresses for a DTN entity unless you
> subtract old address when adding new.
> 
>  - forces thought on how to develop DNS name resolvers and handle late
> bindings
> 
>  
> 
> Test Plan generation 
> 
>  - Assign responsibilities to various individuals to create a test
> plan/procedure for each goal
> 
>    ** Include equipment, network topology, applications.
> 
>  
> 
>  
> 
>  
> 
> /Will
> 
>  
> 
>  
> 
> From: William Ivancic [mailto:[email-masked]] 
> Sent: Monday, July 13, 2009 3:58 PM
> To: Ivancic, William D. (GRC-RHN0)
> Subject: (Forward to attendees) Meeting rescheduled: DTN
> Disconnectaton
> 
> 
>  
> 
> **** You can forward this email invitation to attendees **** 
> 
> Hello , 
> 
> William Ivancic changed the time for this online meeting. 
> 
> Topic: DTN Disconnectaton 
> Date: Tuesday, July 14, 2009 
> Time: 10:00 am, Eastern Daylight Time (GMT -04:00, New York) 
> Meeting Number: 992 708 018 
> Meeting Password: DTN4all* 
> 
> Please click the link below to see more information, or to join the
> meeting. 
> 
> ------------------------------------------------------- 
> To join the online meeting 
> ------------------------------------------------------- 
> 1. Go to
> https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&PW=99cddb2f232b580d1f0841 
> 2. Enter your name and email address. 
> 3. Enter the meeting password: DTN4all* 
> 4. Click "Join Now". 
> 
> ------------------------------------------------------- 
> To join the teleconference only 
> ------------------------------------------------------- 
> 
> Toll Outside US 1-517-600-5252  
> Toll Free US Only 866-783-5733  
> pass code  1095920 
> 
> ------------------------------------------------------- 
> For assistance 
> ------------------------------------------------------- 
> 1. Go to https://nasa.webex.com/nasa/mc 
> 2. On the left navigation bar, click "Support". 
> 
> You can contact me at: 
> [email-masked] 
> 1-216-4333494 
> 
> To update this meeting to your calendar program (for example Microsoft
> Outlook), click this link: 
> https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=mNl0qJihMyGXOedMiHD1X816dXkQgLvPhDPxo6xE28I= 
> 
> 
> WebEx will automatically setup Meeting Manager for Windows the first
> time you join a meeting. To save time, you can setup prior to the
> meeting by clicking this link: 
> https://nasa.webex.com/nasa/meetingcenter/mcsetup.php 
> 
> 
> The playback of UCF (Universal Communications Format) rich media files
> requires appropriate players. To view this type of rich media files in
> the meeting, please check whether you have the players installed on
> your computer by going to
> https://nasa.webex.com/nasa/systemdiagnosis.php 
> 
> Sign up for a free trial of WebEx 
> http://www.webex.com/go/mcemfreetrial 
> 
> http://www.webex.com 
> We've got to start meeting like this(TM) 
> 
> IMPORTANT NOTICE: This WebEx service includes a feature that allows
> audio and any documents and other materials exchanged or viewed during
> the session to be recorded. By joining this session, you automatically
> consent to such recordings. If you do not consent to the recording, do
> not join the session. 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>,  Lloyd Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Jul 2009 07:18:31 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

DTN was originally conceived and designed for deep space and was designed with assumptions that hold fairly well for such the initial environment it was conceived to operate in.  One of those assumptions is that space systems have sufficient time synchronization to operate and that time synchronization comes from something other than using the bundling protocol. The problem is that we are now trying to expend the environment that DTN is to operate in and some of those initial assumptions may not be valid.

In other words, space is relatively easy for DTN, terrestrial is the hard case for DTN.  As conceived, space-base DTN bundle agents are synchronized and highly scheduled and you know what your bandwidths and delays are and who you are talking to.  Terrestrial DTN bundle agents may be disconnected, ad hoc, unpredictable, unknown bandwidth, unknown convergence layers, and may (probably) require discovery methods.  That is a much harder problem.  You may not be able to synchronize the terrestrial network so easily.  Yes, there is GPS on earth, but that also costs money to put into something like a simple sensor web.

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Burleigh,
>Scott C
>Sent: Tuesday, July 14, 2009 2:45 AM
>To: Lloyd Wood; [email-masked]
>Cc: [email-masked]
>Subject: Re: [dtn-interest] Time synchronization within DTNs
>
>Loath as I usually am to disagree with Vint Cerf, in this particular
>instance I do.  At least in the DTN context, where clock synchronization
>on the order of a second or two is more than sufficient, I would say
>there certainly is such a thing as "now".  If I have got a clock on a
>spacecraft that's 60 light seconds away, and I command it to send me a
>message at 1300 UTC, and its clock is synchronized to within 1 second of
>UTC as reported by an atomic clock on Earth, and I am holding a watch
>that is likewise set to within 1 second of UTC, and when my watch reads
>1300 I say "now", and when I do so my confederate starts a stopwatch
>which he stops when our co-worker says "Got it" upon detecting the
>arrival of the message, and the stopwatch thereupon reads 60 seconds
>(plus or minus one or two seconds), then I would contend that the
>spacecraft sent the message at the time I said "now".  Of course there's
>a "now".  If there weren't, we couldn't operate deep-space spacecraft at
>all.
>
>This is not to say that deep space communications doesn't open up
>endless opportunities for exchanging well-argued email on the subtle
>relativistic effects introduced by the motion of the spacecraft, the
>motion of Earth, the curvature of space, whatever.  It is to say that,
>for the purposes of DTN-based communication with spacecraft, none of
>that matters in the slightest.  It is simply not a problem.
>
>Scott
>________________________________________
>From: [email-masked] [dtn-interest-
>[email-masked]] On Behalf Of Lloyd Wood
>[[email-masked]]
>Sent: Monday, July 13, 2009 6:32 PM
>To: [email-masked]
>Cc: [email-masked]; Lloyd Wood
>Subject: Re: [dtn-interest] Time synchronization within DTNs
>
>The mailing list archive doesn't record attachments. Bob mentioned:
>http://dx.doi.org/10.1109/FREQ.2007.4319282
>Robert A. Nelson, Relativistic Time Transfer in the Solar System,
>Frequency Control Symposium, Joint with the 21st European Frequency
>and Time Forum, Geneva, June 2007, pp. 1278-1283.
>
>I wish we'd known of this paper before writing the section of our
>'Bundle of Problems' paper discussing time sync and relativity. Some
>relevant quotes:
>
>'"The problem with the interplanetary environment is that there ain't
>no such thing as 'now,' " Cerf says.'
>-- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, Aug 2005.
>
>'The DTN architecture depends on time synchronization among DTN nodes
>(supported by external, non-DTN protocols) for four primary purposes:
>bundle and fragment identification, routing with scheduled or
>predicted contacts, bundle expiration time computations, and
>application registration expiration.'
>-- RFC4938, section 3.12, V. Cerf et al., April 2007.
>
>Once one knows that there is no such thing as 'now' and that time is
>relative, not absolute, and once one realises that the environment one
>is designing for will keep bringing that awkward reality up (not to
>mention larger clock drifts in space due to temperature variations -
>keeping time under harsh conditions is not easy) - why would the
>reality be ignored by making clock synchronization critical to the
>design?
>
>L.
>
>'Only two things are infinite, the universe and human stupidity, and
>I'm not sure about the former.'
>-- Albert Einstein, discoverer of relativity.
>
>On 13 Jul 2009, at 22:29, [email-masked] wrote:
>
>> All,
>>
>> For precise time synchronization, relativistic effects need to be
>> considered.  These effects are not negligible.  Corrections
>> analogous to those
>> already implemented in the GPS are needed for solar system time
>> transfer.
>>
>> I attach a paper I presented at the EFTF/IEEE conference in Geneva
>> in 2007
>> for background.  The paper shows that for time transfer between Mars
>> and
>> Earth the periodic effects have amplitudes on the order of one to ten
>> milliseconds at the planetary orbital periods.
>>
>>
>> Bob  Nelson
>
>DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
><http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Lloyd Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 23:45:27 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Loath as I usually am to disagree with Vint Cerf, in this particular instance I do.  At least in the DTN context, where clock synchronization on the order of a second or two is more than sufficient, I would say there certainly is such a thing as "now".  If I have got a clock on a spacecraft that's 60 light seconds away, and I command it to send me a message at 1300 UTC, and its clock is synchronized to within 1 second of UTC as reported by an atomic clock on Earth, and I am holding a watch that is likewise set to within 1 second of UTC, and when my watch reads 1300 I say "now", and when I do so my confederate starts a stopwatch which he stops when our co-worker says "Got it" upon detecting the arrival of the message, and the stopwatch thereupon reads 60 seconds (plus or minus one or two seconds), then I would contend that the spacecraft sent the message at the time I said "now".  Of course there's a "now".  If there weren't, we couldn't operate deep-space spacecraft at all.

This is not to say that deep space communications doesn't open up endless opportunities for exchanging well-argued email on the subtle relativistic effects introduced by the motion of the spacecraft, the motion of Earth, the curvature of space, whatever.  It is to say that, for the purposes of DTN-based communication with spacecraft, none of that matters in the slightest.  It is simply not a problem.

Scott
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lloyd Wood [[email-masked]]
Sent: Monday, July 13, 2009 6:32 PM
To: [email-masked]
Cc: [email-masked]; Lloyd Wood
Subject: Re: [dtn-interest] Time synchronization within DTNs

The mailing list archive doesn't record attachments. Bob mentioned:
http://dx.doi.org/10.1109/FREQ.2007.4319282
Robert A. Nelson, Relativistic Time Transfer in the Solar System,
Frequency Control Symposium, Joint with the 21st European Frequency
and Time Forum, Geneva, June 2007, pp. 1278-1283.

I wish we'd known of this paper before writing the section of our
'Bundle of Problems' paper discussing time sync and relativity. Some
relevant quotes:

'"The problem with the interplanetary environment is that there ain't
no such thing as 'now,' " Cerf says.'
-- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, Aug 2005.

'The DTN architecture depends on time synchronization among DTN nodes
(supported by external, non-DTN protocols) for four primary purposes:
bundle and fragment identification, routing with scheduled or
predicted contacts, bundle expiration time computations, and
application registration expiration.'
-- RFC4938, section 3.12, V. Cerf et al., April 2007.

Once one knows that there is no such thing as 'now' and that time is
relative, not absolute, and once one realises that the environment one
is designing for will keep bringing that awkward reality up (not to
mention larger clock drifts in space due to temperature variations -
keeping time under harsh conditions is not easy) - why would the
reality be ignored by making clock synchronization critical to the
design?

L.

'Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former.'
-- Albert Einstein, discoverer of relativity.

On 13 Jul 2009, at 22:29, [email-masked] wrote:

> All,
>
> For precise time synchronization, relativistic effects need to be
> considered.  These effects are not negligible.  Corrections
> analogous to those
> already implemented in the GPS are needed for solar system time
> transfer.
>
> I attach a paper I presented at the EFTF/IEEE conference in Geneva
> in 2007
> for background.  The paper shows that for time transfer between Mars
> and
> Earth the periodic effects have amplitudes on the order of one to ten
> milliseconds at the planetary orbital periods.
>
>
> Bob  Nelson

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 13 Jul 2009 23:21:10 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

A couple of answers:

We found that quite rough clock synchronization, to within 8-10 seconds, was actually good enough.  If the time-to-live on a bundle is a week or so, as it was for DINET, then a 10-second clock error is in the noise in terms of bundle expiration timing.  Of course, the better synchronized the clocks were, the more fully we could use scheduled contacts (10 seconds of error might be 10 seconds worth of transmission that you're missing because you're not listening yet), so we did try to narrow the error on each pass.  The spacecraft clock was drifting about 1 second per day, I think, and as I recall we uploaded a new UTC delta at the end of each pass -- setting the delta to the value we expected to be correct on the *next* pass, 2-5 days later.

Although the clock was drifting at a rather high rate, the rate of drift was nowhere near high enough to impose any risk of premature bundle expiration when we uploaded these UTC delta corrections.  Again, we just used a fairly high time-to-live, probably at least five minutes (sorry, can't remember exactly).  So we never had to do anything fancy like spoof bundle creation times.

You're correct that a completely reset clock would have been another matter altogether.  But I think (for EPOXI, at least) a spacecraft clock reset would have been a dramatic enough anomaly to warrant a whole lot of special attention from the spacecraft team; bundle expiration would have been the furthest thing from anybody's thoughts, and I would expect they'd have used some sort of direct commanding to reset the clock to a reasonable current value.

I don't think anybody claims that DTN is anywhere near being ready to supplant low-level commanding altogether, and in fact I expect it never will do so -- much as in terrestrial internetworking we still sometimes have to give up and press ctrl^alt^del.  For routine operations on spacecraft equipped with the clocks they need for command sequence execution anyway, though, a DTN-based approach is not difficult.

Scott
________________________________________
From: Lloyd Wood [[email-masked]]
Sent: Monday, July 13, 2009 5:44 PM
To: Burleigh, Scott C
Cc: Lloyd Wood; Scott, Keith L.; [email-masked]
Subject: Re: [dtn-interest] Time synchronization within DTNs

Scott,

a couple of questions related to this.

didn't EPOXI's drifting-in-the-extremes-of-space clock have to be
reset to the correct time before every DINET experiment?

and, if you set the UTC delta value via bundling itself, did you have
to spoof the bundle creation time with the offset to make sure that
EPOXI wouldn't drop the bundle before processing it - as well as
making receipt of bundles from EPOXI containing time offsets very
tolerant of large offsets to avoid dropping any out-of-bounds bundles
created with a highly drifting clock?

In other words, how do you tolerate extreme deltas on an incorrect or
just plain reset clock?

thanks,

L.

On 13 Jul 2009, at 18:56, Burleigh, Scott C wrote:

> Actually we did this pretty successfully for DINET:
> �         Obviously the ability to set the bundle creation time on
> issuance and check the expiration time on reception depends on DTN�s
> ability to read the local system clock and know what the correct
> time is.  ION provides a getUTCTime() function for this purpose; the
> function reads the system clock value, adds to it a �UTC delta� (in
> seconds), and returns the sum.  Assuming your system clock is
> already reporting UTC time, the value of the UTC delta is the
> current clock error, i.e., the known difference between the UTC
> reported by the clock and the actual UTC as reported by a reference
> clock somewhere (e.g., GPS).  [If your system clock is reporting
> time for some local time zone rather than UTC, then the time-zone
> difference needs to be included in the UTC delta as well.]
> �         Aha! you respond, but how is this magical UTC delta
> �known�?  No problemo, at least for JPL missions: the spacecraft
> team for every spacecraft needs to know this clock error anyway, for
> loads of other purposes, so they are already collecting time
> correlation packets from the spacecraft and using them to construct
> sclk/scet correlation tables (where �sclk� is spacecraft clock time
> and �scet� is the corresponding actual spacecraft event time, both
> notionally in UTC).  The sclk/scet table tracks and predicts the
> drift of the spacecraft clock, so one can derive from it the
> difference between spacecraft clock time and the actual UTC at any
> time.  The EPOXI spacecraft team kindly extracted this information
> for us for each DINET tracking pass.
> �         Given the known UTC delta, we used the standard ION load/
> go system to set the UTC delta value on the spacecraft via DTN,
> ensuring that the values reported by getUTCTime() were correct (to
> within a few seconds) from that point on.
>
> This highly manual process wouldn�t scale up well beyond a small
> number of spacecraft, of course, but there�s nothing about it that
> is necessarily manual.  The system that computes the updated sclk/
> scet table for a spacecraft could certainly be modified to emit a
> load/go bundle to update that spacecraft�s UTC delta as well.
>
> Which is to say that, just as with contact graph routing, for DTN in
> space flight we have the advantage of being able to leverage off
> work that is already being done in order to fly the spacecraft; we
> don�t have to invent everything ourselves.  Not very helpful for
> terrestrial DTN environments, I know, and the eventual development
> of a full-up delay-tolerant NTP will be an attractive alternative
> for flight DTN as well, but in the meantime I think it�s worth
> suggesting that in some cases these problems are less daunting than
> they may seem.
>
> Scott
>
> From: [email-masked] [mailto:[email-masked]
> ] On Behalf Of Scott, Keith L.
> Sent: Monday, July 13, 2009 5:54 AM
> To: [email-masked]
> Subject: [dtn-interest] Time synchronization within DTNs
>
> The bundle protocol requires loose time synchronization to support
> the time-to-live parameter.  Does anyone have results from doing
> time synchronization using the bundle protocol itself (i.e. time
> synchronization over BP) and disrupted networks?
>
>                                 --keith
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Marshall Eubanks <[email-masked]>
To: "Manning, Robert M" <[email-masked]>
Date: Mon, 13 Jul 2009 23:58:29 -0400
Cc: [email-masked], Bruce Bills <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

On Jul 13, 2009, at 5:04 PM, Manning, Robert M wrote:

> FYI
>
> For our Mars rovers (before landing) we demand sub-millisecond time  
> correlation between the S/C clock (SCLK) and UTC � in fact there is  
> hardware support on both ends of the DFE (direct from earth) X-band  
> link to support this function. This time correlation is performed  
> every day prior to landing and about weekly on the surface.
>

Did you actually adjust the rover clock, or was this just a "paper  
clock" ?

If you did adjust the rover clock, is the Martian timing done with a  
proper relativistic transformation to barycentric time, or is the  
rover clock on an "adjusted terrestrial time" (which is perfectly  
adequate, as long as you don't have to worry about simultaneity issues  
- i.e., to compare Martian clocks with somewhere else besides the  
Earth) ?

> After landing we have a looser tolerance (< 10 seconds).

I hope you had better timing than that for the Phobos solar eclipse  
observations.

> It is possible that some Mars surface missions will require tighter  
> time correlation for coordinated observations.
>

Yes, any lander laser ranging mission like MLR likely would. Also,  
attempts to constrain Mars obliquity and rotation from Lander-Orbiter  
Doppler tracking would want better than a ms for both the orbiter and  
the lander. There are people who have their eyes on Spirit if it  
continues to be stuck...

Regards
Marshall

> -Rob Manning
>
>
> On 7/13/09 11:04 AM, "Peter Lovell" <[email-masked]> wrote:
>
> Hi Will,
>
> I think that would be essential.
>
> It's an interesting question, to be sure. Any time indication (for
> synchronization) in a bundle needs to be adjusted to account for  
> delays
> or retransmissions. Doing that will be hard since the bundle will
> probably be signed in order for the time number in it to be trusted.
> DNTP could become quite complicated.
>
> Cheers.....Peter
>
>
>
>
>
> On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)
> <[email-masked]> wrote:
>
> >To things that should be considered.  You probably need a multi-hop
> >system to truly test time synchronization - DTN network time protocol
> >(to be invented).
> >
> >Security Policy may state that if someone is trying to pass really  
> long
> >lived bundles relative to your operations, you may decide to silently
> >discard them as this may be considered a DOS attack to use up system
> >resources.
> >
> >/Will
> >
> >From: [email-masked] [mailto:dtn-
> >[email-masked]] On Behalf Of Scott,  
> Keith L.
> >Sent: Monday, July 13, 2009 8:54 AM
> >To: [email-masked]
> >Subject: [dtn-interest] Time synchronization within DTNs
> >
> >The bundle protocol requires loose time synchronization to support  
> the
> >time-to-live parameter.  Does anyone have results from doing time
> >synchronization using the bundle protocol itself (i.e. time
> >synchronization over BP) and disrupted networks?
> >
> >                                --keith
> >
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Marshall Eubanks <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 13 Jul 2009 23:57:30 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

On Jul 13, 2009, at 3:20 PM, Ivancic, William D. (GRC-RHN0) wrote:

> Marshall,
>
> From your comments below, are you just considering a space backbone  
> where everything is pretty much predicable.  DTN is also to be used  
> in a number of other unpredictable environments.
>

If you can do it, I think it should be supported. Even in cases where  
nodes are carried by mules and donkeys, it might be useful, especially  
if the traveling node itself has a clock.

Regards
Marshall

>
>
> /Will
>
>> From: Marshall Eubanks [mailto:[email-masked]]
>> Sent: Monday, July 13, 2009 2:48 PM
>> To: Peter Lovell
>> Cc: Ivancic, William D. (GRC-RHN0); Scott, Keith L. (JSC-ZF); dtn-
>> [email-masked]
>> Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>> In many cases, what is needed is not synchronization but  
>> syntonization
>> (aligning time rates, not time offset).
>> The DSN, for example, worries a lot more about syntonization than
>> synchronization. Syntonization is all you need, for
>> example, to predict when the next spacecraft transmission is coming.
>>
>> In a DTN perspective, I think that syntonization would
>> be much more straightforward, at least on a hop by hop basis. You
>> don't have to worry about delay, as long as there is an estimate for
>> the light travel time
>> and the other delays don't change very fast. A simple algorithm is
>>
>> - measure the time offset twice at two different clock epochs
>> - make sure that the path hasn't changed between the epochs. Apply  
>> any
>> known geometrical correction.
>> - the delta offset / delta epoch is the clock rate correction.
>>
>> Regards
>> Marshall
>
>

From: Marshall Eubanks <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Mon, 13 Jul 2009 23:30:19 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

Hello;

On Jul 13, 2009, at 2:04 PM, Peter Lovell wrote:

> Hi Will,
>
> I think that would be essential.
>
> It's an interesting question, to be sure. Any time indication (for
> synchronization) in a bundle needs to be adjusted to account for  
> delays
> or retransmissions. Doing that will be hard since the bundle will
> probably be signed in order for the time number in it to be trusted.
> DNTP could become quite complicated.
>
> Cheers.....Peter
>

Just because there are unknown delays doesn't mean that the clock  
adjustment might not be useful.

In many cases, what is needed is not synchronization but syntonization  
(aligning time rates, not time offset).
I believe that the DSN, for example, worries a lot more about  
syntonization than synchronization.

To put this another way, there are many cases where clock transfer is  
fairly repeatable, but with a
unknown bias. As long as the bias doesn't change much, in many cases  
it doesn't matter that much, but you still need
to have the clock drift controlled.

In a DTN perspective, I think that syntonization would
be pretty straightforward, at least on a hop by hop basis. In the  
spacecraft case of course you need an estimate for the light travel  
time, but you have to have that to point the antennas anyway.

Regards
Marshall
>
>
>
>
> On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)
> <[email-masked]> wrote:
>
>> To things that should be considered.  You probably need a multi-hop
>> system to truly test time synchronization - DTN network time protocol
>> (to be invented).
>>
>> Security Policy may state that if someone is trying to pass really  
>> long
>> lived bundles relative to your operations, you may decide to silently
>> discard them as this may be considered a DOS attack to use up system
>> resources.
>>
>> /Will
>>
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Scott,  
>> Keith L.
>> Sent: Monday, July 13, 2009 8:54 AM
>> To: [email-masked]
>> Subject: [dtn-interest] Time synchronization within DTNs
>>
>> The bundle protocol requires loose time synchronization to support  
>> the
>> time-to-live parameter.  Does anyone have results from doing time
>> synchronization using the bundle protocol itself (i.e. time
>> synchronization over BP) and disrupted networks?
>>
>>                                --keith
>>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Peter Lovell <[email-masked]>
To: Lloyd Wood <[email-masked]>, [email-masked]
Date: Mon, 13 Jul 2009 22:23:54 -0400
Cc: [email-masked]
Subject: [dtn-interest] Re(2):  Time synchronization within DTNs

On Tue, Jul 14, 2009, Lloyd Wood <[email-masked]> wrote:

>Once one knows that there is no such thing as 'now' and that time is
>relative, not absolute, and once one realises that the environment one
>is designing for will keep bringing that awkward reality up (not to
>mention larger clock drifts in space due to temperature variations -
>keeping time under harsh conditions is not easy) - why would the
>reality be ignored by making clock synchronization critical to the
>design?

I'll back away from the philosophy and relativistic mechanics.

This is a circular issue -- clock synchronization is a critical issue
only to the extent that implementations require it to be critical.

No gloom, no doom.

If you critically need clock synchronization then you have to provide it.

If you don't, then you do not.

Nothing in dtn requires a specific clock performance or tolerance. You
just have to design/build/provide the level you need. It might be hard,
but the concept is simple.

Move along, move along, nothing more to see here ...

Date: Mon, 13 Jul 2009 22:22:26 -0400
From: Eric Travis <[email-masked]>
To: "G. Clark" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

--00221532ca380e67bf046ea11cb9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gilbert,

You are correct on both points:  The strawman has lots of holes :o)
I didn't want to get into the engineering of the convergence protocols,
but merely point out that they can help satisfy the bundle-lifetime
requirement without requiring synchronized clocks.  If synchronized
clocks are available, they should be exploited.

Regarding the propagation time:
      If the convergence protocol reliably transfers bundles over a hop,
      you *could* get at least a round-trip propagation time.  I'm not
      saying you *do* get one, but if you want one, you can engineer
      the protocol to get it.  Absent any other information, assume
      the path is symmetric and add half to the observed reception
      duration.

For paths that are extremely high latency, I expect that the nodes already
have to know the propagation delay - so that information could readily be
factored by the convergence layer provider.  However, those same nodes
almost certainly also have fairly well correlated clocks, so it might not
matter.

Eric

On Mon, Jul 13, 2009 at 9:39 PM, G. Clark <[email-masked]> wrote:

> Wouldn't we need at least a rough idea of the propagation delay to be able
> to trust any kind of time limit / time elapsed field in a bundle?  Depending
> on a network's structure, I can think of cases where very strange things
> would happen if we didn't factor the time it takes to get from point A to
> point B into any kind of field that uses a time limit.  For example, say we
> have a bundle with a time limit of 300 seconds (and that we don't factor
> propagation delay into this time limit), there's a routing loop between
> three nodes that are each 15 minutes apart, and it takes 30 milliseconds to
> route a bundle. . . that'd mean the bundle would live for about 104 days
> (300 second lifetime / 30 milliseconds subtracted per trip * 15 minutes per
> trip) before it finally died.
>
> On a related note: I see synchronizing clocks as a simple way to keep track
> of propagation delay relatively accurately without actively querying other
> nodes to see how long it takes to get to them.  Then again, there may be
> better / easier ways to get this information.
>
> Just my two cents.
>
> Gilbert Clark
> Grad Student
> Ohio University
>
>
> Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>
>> I think I agree with the sentiment that there's no fundamental reason that
>> clock synchronization should have been required.  As I've understood the
>> lifetime & creation timestamp fields, they basically exist to meet three
>> distinct requirements:
>>  1) they allow bundle agents to prevent continuous looping of bundles
>> within routing loops (similar to IP TTL / hop limit)
>>  2) they allow bundle agents to optimize local storage by purging stale
>> data, no longer useful to the application/destination
>>  3) they allow unique identification of a bundle, necessary for reassembly
>> of fragmented bundles (similar to IP identification field)
>>  Other store-and-forward protocols have met similar requirements without
>> using absolute timestamps requiring coordinated clocks, so it can be done
>> for DTN.  Using the techniques developed in other store-and-forward
>> protocols is a good start.
>>
>>
>
>  I don't agree with Eric's proposal that this has to be done in the
>> convergence layer, or should be done there, as removing these fields from
>> the bundle protocol means we can't meet requirement 3 above.  However, we
>> could redefine the semantics of creation timestamp to be an arbitrary set of
>> "bundle id" bits that don't repeat within a flow between 2 EIDs, and the
>> lifetime field to be a TTL, hop limit, or time limit.  But that's just one
>> of many ways to meet the same requirements without requiring time
>> synchronization of any form.
>>   ------------------------------------------------------------------------
>> *From:* [email-masked] [
>> [email-masked]] On Behalf Of Eric
>> Travis [[email-masked]]
>> *Sent:* Monday, July 13, 2009 5:58 PM
>> *To:* [email-masked]
>> *Subject:* [dtn-interest] Time synchronization within DTNs
>>
>> | The bundle protocol requires loose time synchronization to support the
>> time-to-live parameter.
>> | Does anyone have results from doing time synchronization using the
>> bundle protocol itself
>> | (i.e. time synchronization over BP) and disrupted networks?
>> |
>> |                               --keith
>>
>>
>> Is system-wide time synchronization *really* necessary to support the
>> bundle lifetime field?
>>
>> I'm not discounting the value of a having a NTP-like service nor the fact
>> that some DTN
>> deployments are going to be built on infrastructure that provides
>> coordinated time - but
>> isn't what is required for aging a bundle obtainable via simple
>> cooperation between the
>> bundle agents and the hop-by-hop convergence layers....
>>
>> For example, consider a strawman:
>>
>> Once a bundle is created (and has its lifetime field populated) it is in
>> one of two states
>> (until successfully delivered or discard):
>>
>>      a) Being buffered for eventual transmission
>>               The local buffering duration for a bundle (Bd) can be
>> determined rather
>>                inexpensively during routine bundle handling [1]
>>
>>       b) Being transmitted to a next hop
>>                A suitably instrumented convergence layer implementation
>> would be
>>                able to provide a *rough* estimate [2] of the duration of a
>> reception event
>>                for incoming bundles  (Rd)
>>
>> If the cumulative sum of (Bd + Rd) were propagated with bundles, there is
>> a rough
>> estimate of the time elapsed since the creation of the bundle.   Said
>> estimate
>> would not include any latencies associated with the convergence layer
>> service
>> interface, but that seems OK in that ensures the estimate will be a
>> conservative one.
>>
>> Achieving this would require that a cumulative elapsed time be transferred
>> along
>> with bundles:
>>
>>        It can't be located within the bundle itself as it will change
>> per-hop
>>        It could be incorporated into a BAB, but the BAB isn't mandatory
>> (is it ?)
>>        It *can* be handled by the convergence layer protocol(s)
>>
>> The convergence layer service interface would have to be modified:
>>
>>        1) When delivering a bundle to the bundle protocol agent, the
>> convergence
>>            layer also provides the cumulative elapsed time (the received
>> value plus Rd)
>>
>>       2) When providing a bundle for transmission, the bundle protocol
>> agent
>>           provides the cumulative elapsed time (the value provided by the
>>           convergence layer plus Hd) to the convergence layer service
>> provider.           This will accompany the bundle to the next hop.
>>
>> The convergence layer implementations would need be augmented to provide
>> a rough estimate for the duration of a bundle reception (Rd).
>> Through the propagation the accretion of observed latencies, the bundle
>> agent
>> is provided a rough estimate of the time elapsed since a bundle's
>> creation. This
>> value can be compared directly with the value of the bundle lifetime as it
>> is also
>> represents time since bundle creation.
>>
>> No doubt the above has neglected some convergence layer latency factors,
>> such as if/when the convergence layer buffers bundles for an extended
>> period
>> prior to beginning transmission. These could be accounted for and handled
>> in
>> implementation - tweaking the cumulative latency just prior to
>> transmission, or not...
>>
>>
>> Regardless of the robustness of the above strawman, the question remains:
>>
>> Are (loosely) synchronized clocks considered necessary for core operations
>> - the
>> delivery of bundles, or are they something to be exploited when available.
>>
>> Eric
>>
>>
>>
>>   [1] Tag the local delivery of a bundle with the current time;  When
>> passing
>>         the bundle to the convergence layer, the delta between "now" and
>> the local
>>         delivery time is the holding time (Hd)
>>
>>   [2] Timestamp the start of a new incoming bundle transfer; Timestamp the
>>        termination of the bundle transfer.  Subtract the former from the
>> latter for
>>        the rough estimate.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>
>

--00221532ca380e67bf046ea11cb9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Gilbert,<br><br>You are correct on both points:=A0 The strawman has lots of=
 holes :o)<br>I didn&#39;t want to get into the engineering of the converge=
nce protocols, <br>but merely point out that they can help satisfy the bund=
le-lifetime <br>
requirement without requiring synchronized clocks.=A0 If synchronized <br>c=
locks are available, they should be exploited.<br><br>Regarding the propaga=
tion time:<br>=A0=A0=A0=A0=A0 If the convergence protocol reliably transfer=
s bundles over a hop, <br>
=A0=A0=A0=A0=A0 you *could* get at least a round-trip propagation time.=A0 =
I&#39;m not <br>=A0=A0=A0=A0=A0 saying you *do* get one, but if you want on=
e, you can engineer <br>=A0=A0=A0=A0=A0 the protocol to get it.=A0 Absent a=
ny other information, assume <br>
=A0=A0=A0=A0=A0 the path is symmetric and add half to the observed receptio=
n <br>=A0=A0=A0=A0=A0 duration. <br><br>For paths that are extremely high l=
atency, I expect that the nodes already <br>have to know the propagation de=
lay - so that information could readily be <br>
factored by the convergence layer provider.=A0 However, those same nodes <b=
r>almost certainly also have fairly well correlated clocks, so it might not=
 matter.<br><br>Eric<br><br><div class=3D"gmail_quote">On Mon, Jul 13, 2009=
 at 9:39 PM, G. Clark <span dir=3D"ltr">&lt;<a href=3D"mailto:gc355804@ohio=
.edu">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Wouldn&#39;t we n=
eed at least a rough idea of the propagation delay to be able to trust any =
kind of time limit / time elapsed field in a bundle? =A0Depending on a netw=
ork&#39;s structure, I can think of cases where very strange things would h=
appen if we didn&#39;t factor the time it takes to get from point A to poin=
t B into any kind of field that uses a time limit. =A0For example, say we h=
ave a bundle with a time limit of 300 seconds (and that we don&#39;t factor=
 propagation delay into this time limit), there&#39;s a routing loop betwee=
n three nodes that are each 15 minutes apart, and it takes 30 milliseconds =
to route a bundle. . . that&#39;d mean the bundle would live for about 104 =
days (300 second lifetime / 30 milliseconds subtracted per trip * 15 minute=
s per trip) before it finally died.<br>

<br>
On a related note: I see synchronizing clocks as a simple way to keep track=
 of propagation delay relatively accurately without actively querying other=
 nodes to see how long it takes to get to them. =A0Then again, there may be=
 better / easier ways to get this information.<br>

<br>
Just my two cents.<br>
<br>
Gilbert Clark<br>
Grad Student<br>
Ohio University<div><div></div><div class=3D"h5"><br>
<br>
Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think I agree with the sentiment that there&#39;s no fundamental reason t=
hat clock synchronization should have been required. =A0As I&#39;ve underst=
ood the lifetime &amp; creation timestamp fields, they basically exist to m=
eet three distinct requirements:<br>

=A01) they allow bundle agents to prevent continuous looping of bundles wit=
hin routing loops (similar to IP TTL / hop limit)<br>
=A02) they allow bundle agents to optimize local storage by purging stale d=
ata, no longer useful to the application/destination<br>
=A03) they allow unique identification of a bundle, necessary for reassembl=
y of fragmented bundles (similar to IP identification field)<br>
=A0Other store-and-forward protocols have met similar requirements without =
using absolute timestamps requiring coordinated clocks, so it can be done f=
or DTN. =A0Using the techniques developed in other store-and-forward protoc=
ols is a good start.<br>

=A0<br>
</blockquote>
<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px sol=
id rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>=
<div></div><div class=3D"h5">
I don&#39;t agree with Eric&#39;s proposal that this has to be done in the =
convergence layer, or should be done there, as removing these fields from t=
he bundle protocol means we can&#39;t meet requirement 3 above. =A0However,=
 we could redefine the semantics of creation timestamp to be an arbitrary s=
et of &quot;bundle id&quot; bits that don&#39;t repeat within a flow betwee=
n 2 EIDs, and the lifetime field to be a TTL, hop limit, or time limit. =A0=
But that&#39;s just one of many ways to meet the same requirements without =
requiring time synchronization of any form.<br>

=A0=A0---------------------------------------------------------------------=
---<br>
*From:* <a href=3D"mailto:[email-masked]=
" target=3D"_blank">[email-masked]</a> [=
<a href=3D"mailto:[email-masked]" target=
=3D"_blank">[email-masked]</a>] On Behal=
f Of Eric Travis [<a href=3D"mailto:[email-masked]" target=3D"_b=
lank">[email-masked]</a>]<br>

*Sent:* Monday, July 13, 2009 5:58 PM<br>
*To:* <a href=3D"mailto:[email-masked]" target=
=3D"_blank">[email-masked]</a><br>
*Subject:* [dtn-interest] Time synchronization within DTNs<br>
<br>
| The bundle protocol requires loose time synchronization to support the ti=
me-to-live parameter.<br>
| Does anyone have results from doing time synchronization using the bundle=
 protocol itself<br>
| (i.e. time synchronization over BP) and disrupted networks?<br>
|<br>
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --keith<br>
<br>
<br>
Is system-wide time synchronization *really* necessary to support the bundl=
e lifetime field?<br>
<br>
I&#39;m not discounting the value of a having a NTP-like service nor the fa=
ct that some DTN<br>
deployments are going to be built on infrastructure that provides coordinat=
ed time - but<br>
isn&#39;t what is required for aging a bundle obtainable via simple coopera=
tion between the<br>
bundle agents and the hop-by-hop convergence layers....<br>
<br>
For example, consider a strawman:<br>
<br>
Once a bundle is created (and has its lifetime field populated) it is in on=
e of two states<br>
(until successfully delivered or discard):<br>
<br>
 =A0 =A0 =A0a) Being buffered for eventual transmission<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The local buffering duration for a bundle (Bd)=
 can be determined rather<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0inexpensively during routine bundle handlin=
g [1]<br>
<br>
 =A0 =A0 =A0 b) Being transmitted to a next hop<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A suitably instrumented convergence layer i=
mplementation would be<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0able to provide a *rough* estimate [2] of t=
he duration of a reception event<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for incoming bundles =A0(Rd)<br>
<br>
If the cumulative sum of (Bd + Rd) were propagated with bundles, there is a=
 rough<br>
estimate of the time elapsed since the creation of the bundle. =A0 Said est=
imate<br>
would not include any latencies associated with the convergence layer servi=
ce<br>
interface, but that seems OK in that ensures the estimate will be a conserv=
ative one.<br>
<br>
Achieving this would require that a cumulative elapsed time be transferred =
along<br>
with bundles:<br>
<br>
 =A0 =A0 =A0 =A0It can&#39;t be located within the bundle itself as it will=
 change per-hop<br>
 =A0 =A0 =A0 =A0It could be incorporated into a BAB, but the BAB isn&#39;t =
mandatory (is it ?)<br>
 =A0 =A0 =A0 =A0It *can* be handled by the convergence layer protocol(s)<br=
>
<br>
The convergence layer service interface would have to be modified:<br>
<br>
 =A0 =A0 =A0 =A01) When delivering a bundle to the bundle protocol agent, t=
he convergence<br>
 =A0 =A0 =A0 =A0 =A0 =A0layer also provides the cumulative elapsed time (th=
e received value plus Rd)<br>
<br>
 =A0 =A0 =A0 2) When providing a bundle for transmission, the bundle protoc=
ol agent<br>
 =A0 =A0 =A0 =A0 =A0 provides the cumulative elapsed time (the value provid=
ed by the<br>
 =A0 =A0 =A0 =A0 =A0 convergence layer plus Hd) to the convergence layer se=
rvice provider.  =A0 =A0 =A0 =A0 =A0 This will accompany the bundle to the =
next hop.<br>
<br>
The convergence layer implementations would need be augmented to provide<br=
>
a rough estimate for the duration of a bundle reception (Rd). <br>
Through the propagation the accretion of observed latencies, the bundle age=
nt<br>
is provided a rough estimate of the time elapsed since a bundle&#39;s creat=
ion. This<br>
value can be compared directly with the value of the bundle lifetime as it =
is also<br>
represents time since bundle creation.<br>
<br>
No doubt the above has neglected some convergence layer latency factors,<br=
>
such as if/when the convergence layer buffers bundles for an extended perio=
d<br>
prior to beginning transmission. These could be accounted for and handled i=
n<br>
implementation - tweaking the cumulative latency just prior to transmission=
, or not...<br>
<br>
<br>
Regardless of the robustness of the above strawman, the question remains:<b=
r>
<br>
Are (loosely) synchronized clocks considered necessary for core operations =
- the<br>
delivery of bundles, or are they something to be exploited when available.<=
br>
<br>
Eric<br>
<br>
<br>
<br>
 =A0 [1] Tag the local delivery of a bundle with the current time; =A0When =
passing<br>
 =A0 =A0 =A0 =A0 the bundle to the convergence layer, the delta between &qu=
ot;now&quot; and the local<br>
 =A0 =A0 =A0 =A0 delivery time is the holding time (Hd)<br>
<br>
 =A0 [2] Timestamp the start of a new incoming bundle transfer; Timestamp t=
he<br>
 =A0 =A0 =A0 =A0termination of the bundle transfer. =A0Subtract the former =
from the latter for<br>
 =A0 =A0 =A0 =A0the rough estimate.<br>
<br></div></div>
------------------------------------------------------------------------<br=
>
<br>
_______________________________________________<br>
dtn-interest mailing list<div class=3D"im"><br>
<a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a><br>
</div><a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-i=
nterest" target=3D"_blank">http://maillists.intel-research.net/mailman/list=
info/dtn-interest</a><br>
 =A0<br>
</blockquote>
<br>
</blockquote></div><br>

--00221532ca380e67bf046ea11cb9--

Date: Mon, 13 Jul 2009 21:48:23 -0400
From: Eric Travis <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

--0003255750fe47fc00046ea0a23a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Wes,

On Mon, Jul 13, 2009 at 8:24 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] <
[email-masked]>  wrote:

I don't agree with Eric's proposal that this has to be done in the
> convergence layer, or should be done there, as removing these fields from
> the bundle protocol means we can't meet requirement 3 above.
>

Well, I didn't think that I was proposed moving the enforcement of the
bundle-lifetime
to the convergence layer nor altering anything related to the bundle header
or protocol
behavior);

If I did, thank you for pointing out the error  - I fully agree such an
approach doesn't
make any sense.

Rather, what I was suggesting was that the convergence layer protocols could

do two things for you that aren't currently being done:

   1 - Carry a cumulative measure of the latency introduced at each hop, as
there
        is no other way obvious to me to so within the existing protocol
framework.

   2 - Attempt to measure the time a bundle spends in transit, as this might
be
        non-trivial in some environments. This can't be done anywhere else
but
        within the convergence layer protocol implementation.

It remains the role of the bundle agent to take that cumulative latency and
deal with it.

>From my original message, the role of the bundle agent remains unchanged:

     >Through the propagation the accretion of observed latencies, the
bundle agent
     >is provided a rough estimate of the time elapsed since a bundle's
creation. This
     >value can be compared directly with the value of the bundle lifetime
as it is also
     >represents time since bundle creation.

All the bundle processing remains within the bundle agent. The convergence
layer
protocols merely passes along cumulative latency measurements that can't
otherwise
be stuck in the bundle header *and* can't be carried in a BAB unless the BAB
becomes
mandatory.

However, we could redefine the semantics of creation timestamp to be an
> arbitrary set of "bundle id" bits that don't repeat within a flow between 2
> EIDs, and the lifetime field to be a TTL, hop limit, or time limit.  But
> that's just one of many ways to meet the same requirements without requiring
> time synchronization of any form.
>

Isn't the lifetime field already a time limit?

As I interpret the spec, the bundle agent adds that value of the lifetime
field
and the creation timestamp in order to determine the acceptable lifespan of
the bundle.

If you have a rough measure of how long the bundle has been handled
(the summation of observed queue and transmission latencies) and compare
it to the value in the lifetime field... well the "bundle id" bits are
already irrelevant.

I don't see the need to change the existing semantics of the creation
timestamp.

Further, if as you suggest, the lifetime field were reinterpreted as a
hop-count or
TTL, then it would be necessary to either:

    - Decrement the lifetime field at every hop.
      If we can do this, we can also just decrement the lifetime field at
each hop
      by the observed latency.

    - Carry a cumulative hop count much like the cumulative delay.
      If not as part of the the convergence layer protocols, then via ...?

Eric

--0003255750fe47fc00046ea0a23a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Wes,<br><br><div class=3D"gmail_quote">On Mon, Jul 13, 2009 at 8:24 PM, Edd=
y, Wesley M. (GRC-MS00)[Verizon] <span dir=3D"ltr">&lt;<a href=3D"mailto:we=
[email-masked]">[email-masked]</a>&gt;</span>=A0 wrote:<br><b=
r><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204=
, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div dir=3D"ltr"><font face=3D"Arial" size=3D"2">I don&#39;t agree wit=
h Eric&#39;s proposal that this has to be done in the convergence layer, or=
 should be done there, as removing these fields from the bundle protocol me=
ans we can&#39;t meet requirement 3 above.=A0 </font></div>
</div></blockquote><div><br>Well, I didn&#39;t think that I was proposed mo=
ving the enforcement of the bundle-lifetime <br>to the convergence layer no=
r altering anything related to the bundle header or protocol <br>behavior);=
=A0 <br>
<br>If I did, thank you for pointing out the error=A0 - I fully agree such =
an approach doesn&#39;t<br>make any sense.<br><br>Rather, what I was sugges=
ting was that the convergence layer protocols could <br>do two things for y=
ou that aren&#39;t currently being done:<br>
<br>=A0=A0 1 - Carry a cumulative measure of the latency introduced at each=
 hop, as there <br>=A0=A0=A0=A0=A0=A0=A0 is no other way obvious to me to s=
o within the existing protocol framework.<br><br>=A0=A0 2 - Attempt to meas=
ure the time a bundle spends in transit, as this might be <br>
=A0=A0=A0=A0=A0=A0=A0 non-trivial in some environments. This can&#39;t be d=
one anywhere else but <br>=A0=A0=A0=A0=A0=A0=A0 within the convergence laye=
r protocol implementation.<br><br>It remains the role of the bundle agent t=
o take that cumulative latency and deal with it.<br>
=A0<br>From my original message, the role of the bundle agent remains uncha=
nged:<br><br>=A0=A0=A0=A0 &gt;Through the propagation the accretion of obse=
rved latencies, the bundle agent<br>=A0=A0=A0=A0
&gt;is provided a rough estimate of the time elapsed since a bundle&#39;s c=
reation. This <br>=A0=A0=A0=A0
&gt;value can be compared directly with the value of the bundle lifetime as=
 it is also
<br>=A0=A0=A0=A0
&gt;represents time since bundle creation.<br>
<br>All the bundle processing remains within the bundle agent. The converge=
nce layer <br>protocols merely passes along cumulative latency measurements=
 that can&#39;t otherwise <br>be stuck in the bundle header *and* can&#39;t=
 be carried in a BAB unless the BAB becomes <br>
mandatory.<br><br></div><blockquote class=3D"gmail_quote" style=3D"border-l=
eft: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:=
 1ex;"><div><div dir=3D"ltr"><font face=3D"Arial" size=3D"2">However, we
 could redefine the semantics of creation timestamp to be an arbitrary set =
of &quot;bundle id&quot; bits that don&#39;t repeat within a flow between 2=
 EIDs, and the lifetime field to be a TTL, hop limit, or time limit.=A0 But=
 that&#39;s just one of many ways to meet the same requirements
 without requiring time synchronization of any form.</font></div>
</div></blockquote><div><br>Isn&#39;t the lifetime field already a time lim=
it? <br><br>As I interpret the spec, the bundle agent adds that value of th=
e lifetime field<br>and the creation timestamp in order to determine the ac=
ceptable lifespan of <br>
the bundle.=A0 <br><br>If you have a rough measure of how long the bundle h=
as been handled <br>(the summation of observed queue and transmission laten=
cies) and compare <br>it to the value in the lifetime field... well the &qu=
ot;bundle id&quot; bits are already irrelevant.<br>
<br>I don&#39;t see the need to change the existing semantics of the creati=
on timestamp.<br><br>Further, if as you suggest, the lifetime field were re=
interpreted as a hop-count or<br>TTL, then it would be necessary to either:=
<br>
<br>=A0 =A0 - Decrement the lifetime field at every hop.=A0 <br>=A0=A0=A0=
=A0=A0 If we can do this, we can also just decrement the lifetime field at =
each hop <br>=A0=A0=A0=A0=A0 by the observed latency.<br><br>=A0 =A0 - Carr=
y a cumulative hop count much like the cumulative delay.=A0 <br>
=A0=A0=A0=A0=A0 If not as part of the the convergence layer protocols, then=
 via ...?<br><br>Eric<br><br></div></div>

--0003255750fe47fc00046ea0a23a--

From: Peter Lovell <[email-masked]>
To: "Manning, Robert M" <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>, Keith Scott <[email-masked]>, [email-masked]
Date: Mon, 13 Jul 2009 21:40:45 -0400
Subject: [dtn-interest] Re(2):  Re(2):  Time synchronization within DTNs

Hi Rob,

I think that the scenarios you envisage will have the resources to
provide "pretty good" to "very good" time correlation, or better.
Probably much better.

But some Earth-bound setups will have much longer delays and *much* less
precision. For snowmobile mail ferries in Lapland, for example, it might
be many seconds over the multi-day route. Hopefully the precision
required will be even less.

Fortunately there are ways for many terrestrial nodes to have
"reasonable" time even in the absence of frequent, reliable dtn-style
connections. GPS is widely available (most latitudes) and probably
provides the best timing signal. Of course, not all devices have GPS
receivers but the cost has decreased a lot and it's now a small expense.
We ought to consider non-DTN time solutions for those DTN systems that
have timing constraints tighter than their connections can reliably keep
synchronized.

Regards.....Peter

On Mon, Jul 13, 2009, Manning, Robert M <[email-masked]> wrote:

>FYI
>
>For our Mars rovers (before landing) we demand sub-millisecond time
>correlation between the S/C clock (SCLK) and UTC - in fact there is
>hardware support on both ends of the DFE (direct from earth) X-band link
>to support this function. This time correlation is performed every day
>prior to landing and about weekly on the surface.
>
>After landing we have a looser tolerance (< 10 seconds). It is possible
>that some Mars surface missions will require tighter time correlation
>for coordinated observations.
>
>-Rob Manning
>
>
>On 7/13/09 11:04 AM, "Peter Lovell" <[email-masked]> wrote:
>
>Hi Will,
>
>I think that would be essential.
>
>It's an interesting question, to be sure. Any time indication (for
>synchronization) in a bundle needs to be adjusted to account for delays
>or retransmissions. Doing that will be hard since the bundle will
>probably be signed in order for the time number in it to be trusted.
>DNTP could become quite complicated.
>
>Cheers.....Peter
>
>
>
>
>
>On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)
><[email-masked]> wrote:
>
>>To things that should be considered.  You probably need a multi-hop
>>system to truly test time synchronization - DTN network time protocol
>>(to be invented).
>>
>>Security Policy may state that if someone is trying to pass really long
>>lived bundles relative to your operations, you may decide to silently
>>discard them as this may be considered a DOS attack to use up system
>>resources.
>>
>>/Will
>>
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Scott, Keith L.
>>Sent: Monday, July 13, 2009 8:54 AM
>>To: [email-masked]
>>Subject: [dtn-interest] Time synchronization within DTNs
>>
>>The bundle protocol requires loose time synchronization to support the
>>time-to-live parameter.  Does anyone have results from doing time
>>synchronization using the bundle protocol itself (i.e. time
>>synchronization over BP) and disrupted networks?
>>
>>                                --keith
>>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Mon, 13 Jul 2009 21:39:00 -0400
From: "G. Clark" <[email-masked]>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Wouldn't we need at least a rough idea of the propagation delay to be 
able to trust any kind of time limit / time elapsed field in a bundle?  
Depending on a network's structure, I can think of cases where very 
strange things would happen if we didn't factor the time it takes to get 
from point A to point B into any kind of field that uses a time limit.  
For example, say we have a bundle with a time limit of 300 seconds (and 
that we don't factor propagation delay into this time limit), there's a 
routing loop between three nodes that are each 15 minutes apart, and it 
takes 30 milliseconds to route a bundle. . . that'd mean the bundle 
would live for about 104 days (300 second lifetime / 30 milliseconds 
subtracted per trip * 15 minutes per trip) before it finally died.

On a related note: I see synchronizing clocks as a simple way to keep 
track of propagation delay relatively accurately without actively 
querying other nodes to see how long it takes to get to them.  Then 
again, there may be better / easier ways to get this information.

Just my two cents.

Gilbert Clark
Grad Student
Ohio University

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> I think I agree with the sentiment that there's no fundamental reason 
> that clock synchronization should have been required.  As I've 
> understood the lifetime & creation timestamp fields, they basically 
> exist to meet three distinct requirements:
>  
> 1) they allow bundle agents to prevent continuous looping of bundles 
> within routing loops (similar to IP TTL / hop limit)
>  
> 2) they allow bundle agents to optimize local storage by purging stale 
> data, no longer useful to the application/destination
>  
> 3) they allow unique identification of a bundle, necessary for 
> reassembly of fragmented bundles (similar to IP identification field)
>  
> Other store-and-forward protocols have met similar requirements 
> without using absolute timestamps requiring coordinated clocks, so it 
> can be done for DTN.  Using the techniques developed in other 
> store-and-forward protocols is a good start.
>  

> I don't agree with Eric's proposal that this has to be done in the 
> convergence layer, or should be done there, as removing these fields 
> from the bundle protocol means we can't meet requirement 3 above.  
> However, we could redefine the semantics of creation timestamp to be 
> an arbitrary set of "bundle id" bits that don't repeat within a flow 
> between 2 EIDs, and the lifetime field to be a TTL, hop limit, or time 
> limit.  But that's just one of many ways to meet the same requirements 
> without requiring time synchronization of any form.
>  
>  
> ------------------------------------------------------------------------
> *From:* [email-masked] 
> [[email-masked]] On Behalf Of Eric 
> Travis [[email-masked]]
> *Sent:* Monday, July 13, 2009 5:58 PM
> *To:* [email-masked]
> *Subject:* [dtn-interest] Time synchronization within DTNs
>
> | The bundle protocol requires loose time synchronization to support 
> the time-to-live parameter.
> | Does anyone have results from doing time synchronization using the 
> bundle protocol itself
> | (i.e. time synchronization over BP) and disrupted networks?
> |
> |                               --keith
>
>
> Is system-wide time synchronization *really* necessary to support the 
> bundle lifetime field?
>
> I'm not discounting the value of a having a NTP-like service nor the 
> fact that some DTN
> deployments are going to be built on infrastructure that provides 
> coordinated time - but
> isn't what is required for aging a bundle obtainable via simple 
> cooperation between the
> bundle agents and the hop-by-hop convergence layers....
>
> For example, consider a strawman:
>
> Once a bundle is created (and has its lifetime field populated) it is 
> in one of two states
> (until successfully delivered or discard):
>
>       a) Being buffered for eventual transmission
>                The local buffering duration for a bundle (Bd) can be 
> determined rather
>                 inexpensively during routine bundle handling [1]
>
>        b) Being transmitted to a next hop
>                 A suitably instrumented convergence layer 
> implementation would be
>                 able to provide a *rough* estimate [2] of the duration 
> of a reception event
>                 for incoming bundles  (Rd)
>
> If the cumulative sum of (Bd + Rd) were propagated with bundles, there 
> is a rough
> estimate of the time elapsed since the creation of the bundle.   Said 
> estimate
> would not include any latencies associated with the convergence layer 
> service
> interface, but that seems OK in that ensures the estimate will be a 
> conservative one.
>
> Achieving this would require that a cumulative elapsed time be 
> transferred along
> with bundles:
>
>         It can't be located within the bundle itself as it will change 
> per-hop
>         It could be incorporated into a BAB, but the BAB isn't 
> mandatory (is it ?)
>         It *can* be handled by the convergence layer protocol(s)
>
> The convergence layer service interface would have to be modified:
>
>         1) When delivering a bundle to the bundle protocol agent, the 
> convergence
>             layer also provides the cumulative elapsed time (the 
> received value plus Rd)
>
>        2) When providing a bundle for transmission, the bundle 
> protocol agent
>            provides the cumulative elapsed time (the value provided by 
> the
>            convergence layer plus Hd) to the convergence layer service 
> provider. 
>            This will accompany the bundle to the next hop.
>
> The convergence layer implementations would need be augmented to provide
> a rough estimate for the duration of a bundle reception (Rd). 
>
> Through the propagation the accretion of observed latencies, the 
> bundle agent
> is provided a rough estimate of the time elapsed since a bundle's 
> creation. This
> value can be compared directly with the value of the bundle lifetime 
> as it is also
> represents time since bundle creation.
>
> No doubt the above has neglected some convergence layer latency factors,
> such as if/when the convergence layer buffers bundles for an extended 
> period
> prior to beginning transmission. These could be accounted for and 
> handled in
> implementation - tweaking the cumulative latency just prior to 
> transmission, or not...
>
>
> Regardless of the robustness of the above strawman, the question remains:
>
> Are (loosely) synchronized clocks considered necessary for core 
> operations - the
> delivery of bundles, or are they something to be exploited when available.
>
> Eric
>
>
>
>    [1] Tag the local delivery of a bundle with the current time;  When 
> passing
>          the bundle to the convergence layer, the delta between "now" 
> and the local
>          delivery time is the holding time (Hd)
>
>    [2] Timestamp the start of a new incoming bundle transfer; 
> Timestamp the
>         termination of the bundle transfer.  Subtract the former from 
> the latter for
>         the rough estimate.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

From: Lloyd Wood <[email-masked]>
To: [email-masked]
Date: Tue, 14 Jul 2009 02:32:11 +0100
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

The mailing list archive doesn't record attachments. Bob mentioned:
http://dx.doi.org/10.1109/FREQ.2007.4319282
Robert A. Nelson, Relativistic Time Transfer in the Solar System,  
Frequency Control Symposium, Joint with the 21st European Frequency  
and Time Forum, Geneva, June 2007, pp. 1278-1283.

I wish we'd known of this paper before writing the section of our  
'Bundle of Problems' paper discussing time sync and relativity. Some  
relevant quotes:

'"The problem with the interplanetary environment is that there ain't  
no such thing as 'now,' " Cerf says.'
-- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, Aug 2005.

'The DTN architecture depends on time synchronization among DTN nodes  
(supported by external, non-DTN protocols) for four primary purposes:  
bundle and fragment identification, routing with scheduled or  
predicted contacts, bundle expiration time computations, and  
application registration expiration.'
-- RFC4938, section 3.12, V. Cerf et al., April 2007.

Once one knows that there is no such thing as 'now' and that time is  
relative, not absolute, and once one realises that the environment one  
is designing for will keep bringing that awkward reality up (not to  
mention larger clock drifts in space due to temperature variations -  
keeping time under harsh conditions is not easy) - why would the  
reality be ignored by making clock synchronization critical to the  
design?

L.

'Only two things are infinite, the universe and human stupidity, and  
I'm not sure about the former.'
-- Albert Einstein, discoverer of relativity.

On 13 Jul 2009, at 22:29, [email-masked] wrote:

> All,
>
> For precise time synchronization, relativistic effects need to be
> considered.  These effects are not negligible.  Corrections  
> analogous to those
> already implemented in the GPS are needed for solar system time  
> transfer.
>
> I attach a paper I presented at the EFTF/IEEE conference in Geneva  
> in 2007
> for background.  The paper shows that for time transfer between Mars  
> and
> Earth the periodic effects have amplitudes on the order of one to ten
> milliseconds at the planetary orbital periods.
>
>
> Bob  Nelson

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: Lloyd Wood <[email-masked]>
To: "Burleigh, Scott C" <[email-masked]>
Date: Tue, 14 Jul 2009 01:44:15 +0100
Cc: Lloyd Wood <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Time synchronization within DTNs

Scott,

a couple of questions related to this.

didn't EPOXI's drifting-in-the-extremes-of-space clock have to be  
reset to the correct time before every DINET experiment?

and, if you set the UTC delta value via bundling itself, did you have  
to spoof the bundle creation time with the offset to make sure that  
EPOXI wouldn't drop the bundle before processing it - as well as  
making receipt of bundles from EPOXI containing time offsets very  
tolerant of large offsets to avoid dropping any out-of-bounds bundles  
created with a highly drifting clock?

In other words, how do you tolerate extreme deltas on an incorrect or  
just plain reset clock?

thanks,

L.

On 13 Jul 2009, at 18:56, Burleigh, Scott C wrote:

> Actually we did this pretty successfully for DINET:
> �         Obviously the ability to set the bundle creation time on  
> issuance and check the expiration time on reception depends on DTN�s  
> ability to read the local system clock and know what the correct  
> time is.  ION provides a getUTCTime() function for this purpose; the  
> function reads the system clock value, adds to it a �UTC delta� (in  
> seconds), and returns the sum.  Assuming your system clock is  
> already reporting UTC time, the value of the UTC delta is the  
> current clock error, i.e., the known difference between the UTC  
> reported by the clock and the actual UTC as reported by a reference  
> clock somewhere (e.g., GPS).  [If your system clock is reporting  
> time for some local time zone rather than UTC, then the time-zone  
> difference needs to be included in the UTC delta as well.]
> �         Aha! you respond, but how is this magical UTC delta  
> �known�?  No problemo, at least for JPL missions: the spacecraft  
> team for every spacecraft needs to know this clock error anyway, for  
> loads of other purposes, so they are already collecting time  
> correlation packets from the spacecraft and using them to construct  
> sclk/scet correlation tables (where �sclk� is spacecraft clock time  
> and �scet� is the corresponding actual spacecraft event time, both  
> notionally in UTC).  The sclk/scet table tracks and predicts the  
> drift of the spacecraft clock, so one can derive from it the  
> difference between spacecraft clock time and the actual UTC at any  
> time.  The EPOXI spacecraft team kindly extracted this information  
> for us for each DINET tracking pass.
> �         Given the known UTC delta, we used the standard ION load/ 
> go system to set the UTC delta value on the spacecraft via DTN,  
> ensuring that the values reported by getUTCTime() were correct (to  
> within a few seconds) from that point on.
>
> This highly manual process wouldn�t scale up well beyond a small  
> number of spacecraft, of course, but there�s nothing about it that  
> is necessarily manual.  The system that computes the updated sclk/ 
> scet table for a spacecraft could certainly be modified to emit a  
> load/go bundle to update that spacecraft�s UTC delta as well.
>
> Which is to say that, just as with contact graph routing, for DTN in  
> space flight we have the advantage of being able to leverage off  
> work that is already being done in order to fly the spacecraft; we  
> don�t have to invent everything ourselves.  Not very helpful for  
> terrestrial DTN environments, I know, and the eventual development  
> of a full-up delay-tolerant NTP will be an attractive alternative  
> for flight DTN as well, but in the meantime I think it�s worth  
> suggesting that in some cases these problems are less daunting than  
> they may seem.
>
> Scott
>
> From: [email-masked] [mailto:[email-masked] 
> ] On Behalf Of Scott, Keith L.
> Sent: Monday, July 13, 2009 5:54 AM
> To: [email-masked]
> Subject: [dtn-interest] Time synchronization within DTNs
>
> The bundle protocol requires loose time synchronization to support  
> the time-to-live parameter.  Does anyone have results from doing  
> time synchronization using the bundle protocol itself (i.e. time  
> synchronization over BP) and disrupted networks?
>
>                                 --keith
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
To: Eric Travis <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 19:24:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time synchronization within DTNs

--_000_C304DB494AC0C04C87C6A6E2FF5603DB225DFB8776NDJSSCC01ndcn_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think I agree with the sentiment that there's no fundamental reason that =
clock synchronization should have been required.  As I've understood the li=
fetime & creation timestamp fields, they basically exist to meet three dist=
inct requirements:

1) they allow bundle agents to prevent continuous looping of bundles within=
 routing loops (similar to IP TTL / hop limit)

2) they allow bundle agents to optimize local storage by purging stale data=
, no longer useful to the application/destination

3) they allow unique identification of a bundle, necessary for reassembly o=
f fragmented bundles (similar to IP identification field)

Other store-and-forward protocols have met similar requirements without usi=
ng absolute timestamps requiring coordinated clocks, so it can be done for =
DTN.  Using the techniques developed in other store-and-forward protocols i=
s a good start.

I don't agree with Eric's proposal that this has to be done in the converge=
nce layer, or should be done there, as removing these fields from the bundl=
e protocol means we can't meet requirement 3 above.  However, we could rede=
fine the semantics of creation timestamp to be an arbitrary set of "bundle =
id" bits that don't repeat within a flow between 2 EIDs, and the lifetime f=
ield to be a TTL, hop limit, or time limit.  But that's just one of many wa=
ys to meet the same requirements without requiring time synchronization of =
any form.

________________________________
From: [email-masked] [dtn-interest-bounc=
[email-masked]] On Behalf Of Eric Travis [eric.dot.travis@=
gmail.com]
Sent: Monday, July 13, 2009 5:58 PM
To: [email-masked]
Subject: [dtn-interest] Time synchronization within DTNs

| The bundle protocol requires loose time synchronization to support the ti=
me-to-live parameter.
| Does anyone have results from doing time synchronization using the bundle=
 protocol itself
| (i.e. time synchronization over BP) and disrupted networks?
|
|                               --keith

Is system-wide time synchronization *really* necessary to support the bundl=
e lifetime field?

I'm not discounting the value of a having a NTP-like service nor the fact t=
hat some DTN
deployments are going to be built on infrastructure that provides coordinat=
ed time - but
isn't what is required for aging a bundle obtainable via simple cooperation=
 between the
bundle agents and the hop-by-hop convergence layers....

For example, consider a strawman:

Once a bundle is created (and has its lifetime field populated) it is in on=
e of two states
(until successfully delivered or discard):

      a) Being buffered for eventual transmission
               The local buffering duration for a bundle (Bd) can be determ=
ined rather
                inexpensively during routine bundle handling [1]

       b) Being transmitted to a next hop
                A suitably instrumented convergence layer implementation wo=
uld be
                able to provide a *rough* estimate [2] of the duration of a=
 reception event
                for incoming bundles  (Rd)

If the cumulative sum of (Bd + Rd) were propagated with bundles, there is a=
 rough
estimate of the time elapsed since the creation of the bundle.   Said estim=
ate
would not include any latencies associated with the convergence layer servi=
ce
interface, but that seems OK in that ensures the estimate will be a conserv=
ative one.

Achieving this would require that a cumulative elapsed time be transferred =
along
with bundles:

        It can't be located within the bundle itself as it will change per-=
hop
        It could be incorporated into a BAB, but the BAB isn't mandatory (i=
s it ?)
        It *can* be handled by the convergence layer protocol(s)

The convergence layer service interface would have to be modified:

        1) When delivering a bundle to the bundle protocol agent, the conve=
rgence
            layer also provides the cumulative elapsed time (the received v=
alue plus Rd)

       2) When providing a bundle for transmission, the bundle protocol age=
nt
           provides the cumulative elapsed time (the value provided by the
           convergence layer plus Hd) to the convergence layer service prov=
ider.
           This will accompany the bundle to the next hop.

The convergence layer implementations would need be augmented to provide
a rough estimate for the duration of a bundle reception (Rd).

Through the propagation the accretion of observed latencies, the bundle age=
nt
is provided a rough estimate of the time elapsed since a bundle's creation.=
 This
value can be compared directly with the value of the bundle lifetime as it =
is also
represents time since bundle creation.

No doubt the above has neglected some convergence layer latency factors,
such as if/when the convergence layer buffers bundles for an extended perio=
d
prior to beginning transmission. These could be accounted for and handled i=
n
implementation - tweaking the cumulative latency just prior to transmission=
, or not...

Regardless of the robustness of the above strawman, the question remains:

Are (loosely) synchronized clocks considered necessary for core operations =
- the
delivery of bundles, or are they something to be exploited when available.

Eric

   [1] Tag the local delivery of a bundle with the current time;  When pass=
ing
         the bundle to the convergence layer, the delta between "now" and t=
he local
         delivery time is the holding time (Hd)

   [2] Timestamp the start of a new incoming bundle transfer; Timestamp the
        termination of the bundle transfer.  Subtract the former from the l=
atter for
        the rough estimate.

--_000_C304DB494AC0C04C87C6A6E2FF5603DB225DFB8776NDJSSCC01ndcn_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"GENERATOR" content=3D"MSHTML 8.00.6001.18783">
<style title=3D"owaParaStyle"><!--P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body ocsi=3D"x">
<div dir=3D"ltr"><font color=3D"#000000" size=3D"2" face=3D"Arial">I think =
I agree with the sentiment that there's no fundamental reason that clock sy=
nchronization should have been required.&nbsp; As I've understood the lifet=
ime &amp; creation timestamp fields, they basically
 exist to meet three distinct requirements:</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial">1) they allow bundle agent=
s to prevent continuous looping of bundles within routing loops (similar to=
 IP TTL / hop limit)</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial">2) they allow bundle agent=
s to optimize local storage by purging stale data, no longer useful to the =
application/destination</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial">3) they allow unique ident=
ification of a bundle, necessary for reassembly of fragmented bundles (simi=
lar to IP identification field)</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial">Other store-and-forward pr=
otocols have met similar requirements without using absolute timestamps req=
uiring coordinated clocks, so it can be done for DTN.&nbsp; Using the techn=
iques developed in other store-and-forward
 protocols is a good start.</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial">I don't agree with Eric's =
proposal that this has to be done in the convergence layer, or should be do=
ne there, as removing these fields from the bundle protocol means we can't =
meet requirement 3 above.&nbsp; However, we
 could redefine the semantics of creation timestamp to be an arbitrary set =
of &quot;bundle id&quot; bits that don't repeat within a flow between 2 EID=
s, and the lifetime field to be a TTL, hop limit, or time limit.&nbsp; But =
that's just one of many ways to meet the same requirements
 without requiring time synchronization of any form.</font></div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div dir=3D"ltr"><font size=3D"2" face=3D"Arial"></font>&nbsp;</div>
<div style=3D"DIRECTION: ltr" id=3D"divRpF200750">
<hr tabindex=3D"-1">
<font size=3D"2" face=3D"Tahoma"><b>From:</b> dtn-interest-bounces@maillist=
s.intel-research.net [[email-masked]] On=
 Behalf Of Eric Travis [[email-masked]]<br>
<b>Sent:</b> Monday, July 13, 2009 5:58 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] Time synchronization within DTNs<br>
</font><br>
</div>
<div></div>
<div>| The bundle protocol requires loose time synchronization to support t=
he time-to-live parameter.<br>
| Does anyone have results from doing time synchronization using the bundle=
 protocol itself<br>
| (i.e. time synchronization over BP) and disrupted networks?<br>
|<br>
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --keith<br>
<br>
<br>
Is system-wide time synchronization *really* necessary to support the bundl=
e lifetime field?
<br>
<br>
I'm not discounting the value of a having a NTP-like service nor the fact t=
hat some DTN<br>
deployments are going to be built on infrastructure that provides coordinat=
ed time - but
<br>
isn't what is required for aging a bundle obtainable via simple cooperation=
 between the
<br>
bundle agents and the hop-by-hop convergence layers....<br>
<br>
For example, consider a strawman:<br>
<br>
Once a bundle is created (and has its lifetime field populated) it is in on=
e of two states
<br>
(until successfully delivered or discard):<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) Being buffered for eventual transmission<=
br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; The local buffering duration for a bundle (Bd) can be determined =
rather
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; &nbsp; inexpensively during routine bundle handling [1]<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) Being transmitted to a next hop <br=
>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; A suitably instrumented convergence layer implementation wo=
uld be
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; able to provide a *rough* estimate [2] of the duration of a=
 reception event
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; for incoming bundles&nbsp; (Rd)<br>
<br>
If the cumulative sum of (Bd &#43; Rd) were propagated with bundles, there =
is a rough
<br>
estimate of the time elapsed since the creation of the bundle.&nbsp;&nbsp; =
Said estimate <br>
would not include any latencies associated with the convergence layer servi=
ce <br>
interface, but that seems OK in that ensures the estimate will be a conserv=
ative one.
<br>
<br>
Achieving this would require that a cumulative elapsed time be transferred =
along <br>
with bundles:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It can't be located within the b=
undle itself as it will change per-hop<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It could be incorporated into a =
BAB, but the BAB isn't mandatory (is it ?)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It *can* be handled by the conve=
rgence layer protocol(s)<br>
<br>
The convergence layer service interface would have to be modified:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) When delivering a bundle to t=
he bundle protocol agent, the convergence
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; layer also provide=
s the cumulative elapsed time (the received value plus Rd)<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) When providing a bundle for transmi=
ssion, the bundle protocol agent<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; provides the cumula=
tive elapsed time (the value provided by the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; convergence la=
yer plus Hd) to the convergence layer service provider.&nbsp;
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This will acco=
mpany the bundle to the next hop.<br>
<br>
The convergence layer implementations would need be augmented to provide <b=
r>
a rough estimate for the duration of a bundle reception (Rd).&nbsp; <br>
<br>
Through the propagation the accretion of observed latencies, the bundle age=
nt<br>
is provided a rough estimate of the time elapsed since a bundle's creation.=
 This <br>
value can be compared directly with the value of the bundle lifetime as it =
is also
<br>
represents time since bundle creation.<br>
<br>
No doubt the above has neglected some convergence layer latency factors,<br=
>
such as if/when the convergence layer buffers bundles for an extended perio=
d <br>
prior to beginning transmission. These could be accounted for and handled i=
n <br>
implementation - tweaking the cumulative latency just prior to transmission=
, or not...<br>
<br>
<br>
Regardless of the robustness of the above strawman, the question remains:<b=
r>
<br>
Are (loosely) synchronized clocks considered necessary for core operations =
- the <br>
delivery of bundles, or are they something to be exploited when available.<=
br>
<br>
Eric<br>
<br>
<br>
<br>
&nbsp;&nbsp; [1] Tag the local delivery of a bundle with the current time;&=
nbsp; When passing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the bundle to the converge=
nce layer, the delta between &quot;now&quot; and the local<br>
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; delivery time is the holding time (Hd)<br=
>
<br>
&nbsp;&nbsp; [2] Timestamp the start of a new incoming bundle transfer; Tim=
estamp the<br>
&nbsp;&nbsp; &nbsp; &nbsp;&nbsp; termination of the bundle transfer.&nbsp; =
Subtract the former from the latter for<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the rough estimate.<br>
<br>
</div>
</body>
</html>

--_000_C304DB494AC0C04C87C6A6E2FF5603DB225DFB8776NDJSSCC01ndcn_--

Date: Mon, 13 Jul 2009 17:58:20 -0400
From: Eric Travis <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Time synchronization within DTNs

--0003255765f692933e046e9d6b27
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

| The bundle protocol requires loose time synchronization to support the
time-to-live parameter.
| Does anyone have results from doing time synchronization using the bundle
protocol itself
| (i.e. time synchronization over BP) and disrupted networks?
|
|                               --keith

Is system-wide time synchronization *really* necessary to support the bundle
lifetime field?

I'm not discounting the value of a having a NTP-like service nor the fact
that some DTN
deployments are going to be built on infrastructure that provides
coordinated time - but
isn't what is required for aging a bundle obtainable via simple cooperation
between the
bundle agents and the hop-by-hop convergence layers....

For example, consider a strawman:

Once a bundle is created (and has its lifetime field populated) it is in one
of two states
(until successfully delivered or discard):

      a) Being buffered for eventual transmission
               The local buffering duration for a bundle (Bd) can be
determined rather
                inexpensively during routine bundle handling [1]

       b) Being transmitted to a next hop
                A suitably instrumented convergence layer implementation
would be
                able to provide a *rough* estimate [2] of the duration of a
reception event
                for incoming bundles  (Rd)

If the cumulative sum of (Bd + Rd) were propagated with bundles, there is a
rough
estimate of the time elapsed since the creation of the bundle.   Said
estimate
would not include any latencies associated with the convergence layer
service
interface, but that seems OK in that ensures the estimate will be a
conservative one.

Achieving this would require that a cumulative elapsed time be transferred
along
with bundles:

        It can't be located within the bundle itself as it will change
per-hop
        It could be incorporated into a BAB, but the BAB isn't mandatory (is
it ?)
        It *can* be handled by the convergence layer protocol(s)

The convergence layer service interface would have to be modified:

        1) When delivering a bundle to the bundle protocol agent, the
convergence
            layer also provides the cumulative elapsed time (the received
value plus Rd)

       2) When providing a bundle for transmission, the bundle protocol
agent
           provides the cumulative elapsed time (the value provided by the
           convergence layer plus Hd) to the convergence layer service
provider.
           This will accompany the bundle to the next hop.

The convergence layer implementations would need be augmented to provide
a rough estimate for the duration of a bundle reception (Rd).

Through the propagation the accretion of observed latencies, the bundle
agent
is provided a rough estimate of the time elapsed since a bundle's creation.
This
value can be compared directly with the value of the bundle lifetime as it
is also
represents time since bundle creation.

No doubt the above has neglected some convergence layer latency factors,
such as if/when the convergence layer buffers bundles for an extended period

prior to beginning transmission. These could be accounted for and handled in

implementation - tweaking the cumulative latency just prior to transmission,
or not...

Regardless of the robustness of the above strawman, the question remains:

Are (loosely) synchronized clocks considered necessary for core operations -
the
delivery of bundles, or are they something to be exploited when available.

Eric

   [1] Tag the local delivery of a bundle with the current time;  When
passing
         the bundle to the convergence layer, the delta between "now" and
the local
         delivery time is the holding time (Hd)

   [2] Timestamp the start of a new incoming bundle transfer; Timestamp the
        termination of the bundle transfer.  Subtract the former from the
latter for
        the rough estimate.

--0003255765f692933e046e9d6b27
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

| The bundle protocol requires loose time synchronization to support the ti=
me-to-live parameter.<br>| Does anyone have results from doing time synchro=
nization using the bundle protocol itself<br>| (i.e. time synchronization o=
ver BP) and disrupted networks?<br>
|<br>|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 --keith<br><br><br>Is system-wide time synchronizatio=
n *really* necessary to support the bundle lifetime field? <br><br>I&#39;m =
not discounting the value of a having a NTP-like service nor the fact that =
some DTN<br>
deployments are going to be built on infrastructure that provides coordinat=
ed time - but <br>isn&#39;t what is required for aging a bundle obtainable =
via simple cooperation between the <br>bundle agents and the hop-by-hop con=
vergence layers....<br>
<br>For example, consider a strawman:<br><br>Once a bundle is created (and =
has its lifetime field populated) it is in one of two states <br>(until suc=
cessfully delivered or discard):<br><br>=A0=A0=A0=A0=A0 a) Being buffered f=
or eventual transmission<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The local buffering duration for=
 a bundle (Bd) can be determined rather <br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 =A0 inexpensively during routine bundle handling [1]<br><br>=A0=
=A0=A0=A0=A0=A0 b) Being transmitted to a next hop <br>=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 A suitably instrumented convergence layer imple=
mentation would be <br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 able to provide a *rough* est=
imate [2] of the duration of a reception event <br>=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 for incoming bundles=A0 (Rd)<br><br>If the cumulative=
 sum of (Bd + Rd) were propagated with bundles, there is a rough <br>
estimate of the time elapsed since the creation of the bundle.=A0=A0 Said e=
stimate <br>would not include any latencies associated with the convergence=
 layer service <br>interface, but that seems OK in that ensures the estimat=
e will be a conservative one. <br>
<br>Achieving this would require that a cumulative elapsed time be transfer=
red along <br>with bundles:<br><br>=A0=A0=A0=A0=A0=A0=A0 It can&#39;t be lo=
cated within the bundle itself as it will change per-hop<br>=A0=A0=A0=A0=A0=
=A0=A0 It could be incorporated into a BAB, but the BAB isn&#39;t mandatory=
 (is it ?)<br>
=A0=A0=A0=A0=A0=A0=A0 It *can* be handled by the convergence layer protocol=
(s)<br><br>The convergence layer service interface would have to be modifie=
d:<br><br>=A0=A0=A0=A0=A0=A0=A0 1) When delivering a bundle to the bundle p=
rotocol agent, the convergence <br>
=A0=A0=A0=A0=A0 =A0 =A0=A0=A0 layer also provides the cumulative elapsed ti=
me (the received value plus Rd)<br><br>=A0=A0=A0=A0=A0=A0 2) When providing=
 a bundle for transmission, the bundle protocol agent<br>=A0=A0=A0=A0=A0=A0=
=A0 =A0=A0 provides the cumulative elapsed time (the value provided by the =
<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 convergence layer plus Hd) to the convergenc=
e layer service provider.=A0 <br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This will a=
ccompany the bundle to the next hop.<br><br>The convergence layer implement=
ations would need be augmented to provide <br>
a rough estimate for the duration of a bundle reception (Rd).=A0 <br><br>Th=
rough the propagation the accretion of observed latencies, the bundle agent=
<br>is provided a rough estimate of the time elapsed since a bundle&#39;s c=
reation. This <br>
value can be compared directly with the value of the bundle lifetime as it =
is also <br>represents time since bundle creation.<br><br>No doubt the abov=
e has neglected some convergence layer latency factors,<br>such as if/when =
the convergence layer buffers bundles for an extended period <br>
prior to beginning transmission. These could be accounted for and handled i=
n <br>implementation - tweaking the cumulative latency just prior to transm=
ission, or not...<br><br><br>Regardless of the robustness of the above stra=
wman, the question remains:<br>
<br>Are (loosely) synchronized clocks considered necessary for core operati=
ons - the <br>delivery of bundles, or are they something to be exploited wh=
en available.<br><br>Eric<br><br><br><br>=A0=A0 [1] Tag the local delivery =
of a bundle with the current time;=A0 When passing<br>
=A0=A0=A0=A0=A0=A0=A0=A0 the bundle to the convergence layer, the delta bet=
ween &quot;now&quot; and the local<br>=A0 =A0 =A0 =A0=A0 delivery time is t=
he holding time (Hd)<br><br>=A0=A0 [2] Timestamp the start of a new incomin=
g bundle transfer; Timestamp the<br>
=A0=A0 =A0 =A0=A0 termination of the bundle transfer.=A0 Subtract the forme=
r from the latter for<br>=A0=A0=A0=A0=A0=A0=A0 the rough estimate.<br><br>

--0003255765f692933e046e9d6b27--

From: [email-masked]
Date: Mon, 13 Jul 2009 17:29:48 EDT
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

--part1_c35.5f5f7b7f.378d014c_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><PRE><FONT FACE=arial,helvetica>All,

For precise time synchronization, relativistic effects need to be 
considered.  These effects are not negligible.  Corrections analogous to those 
already implemented in the GPS are needed for solar system time transfer.

I attach a paper I presented at the EFTF/IEEE conference in Geneva in 2007 
for background.  The paper shows that for time transfer between Mars and 
Earth the periodic effects have amplitudes on the order of one to ten 
milliseconds at the planetary orbital periods.

Bob  Nelson

<BR><BR><BR>**************<BR>Looking for love this summer? Find it now on AOL Personals. 
(http://personals.aol.com/?ncid=emlcntuslove00000003)</HTML></PRE></HTML>

--part1_c35.5f5f7b7f.378d014c_boundary
Content-Type: application/pdf; name="PAPER7~1.PDF"
Content-Transfer-Encoding: base64

--part1_c35.5f5f7b7f.378d014c_boundary--

From: "Manning, Robert M" <[email-masked]>
To: Peter Lovell <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, Kscott <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 14:04:03 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

--_000_C680EF537636RobertMManningjplnasagov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FYI

For our Mars rovers (before landing) we demand sub-millisecond time correla=
tion between the S/C clock (SCLK) and UTC - in fact there is hardware suppo=
rt on both ends of the DFE (direct from earth) X-band link to support this =
function. This time correlation is performed every day prior to landing and=
 about weekly on the surface.

After landing we have a looser tolerance (< 10 seconds). It is possible tha=
t some Mars surface missions will require tighter time correlation for coor=
dinated observations.

-Rob Manning

On 7/13/09 11:04 AM, "Peter Lovell" <[email-masked]> wrote:

Hi Will,

I think that would be essential.

It's an interesting question, to be sure. Any time indication (for
synchronization) in a bundle needs to be adjusted to account for delays
or retransmissions. Doing that will be hard since the bundle will
probably be signed in order for the time number in it to be trusted.
DNTP could become quite complicated.

Cheers.....Peter

On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>To things that should be considered.  You probably need a multi-hop
>system to truly test time synchronization - DTN network time protocol
>(to be invented).
>
>Security Policy may state that if someone is trying to pass really long
>lived bundles relative to your operations, you may decide to silently
>discard them as this may be considered a DOS attack to use up system
>resources.
>
>/Will
>
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Scott, Keith L=
.
>Sent: Monday, July 13, 2009 8:54 AM
>To: [email-masked]
>Subject: [dtn-interest] Time synchronization within DTNs
>
>The bundle protocol requires loose time synchronization to support the
>time-to-live parameter.  Does anyone have results from doing time
>synchronization using the bundle protocol itself (i.e. time
>synchronization over BP) and disrupted networks?
>
>                                --keith
>

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_C680EF537636RobertMManningjplnasagov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dtn-interest] Re(2): &nbsp;Time synchronization within DTNs</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>FYI<BR>
<BR>
For our Mars rovers (before landing) we demand sub-millisecond time correla=
tion between the S/C clock (SCLK) and UTC &#8211; in fact there is hardware=
 support on both ends of the DFE (direct from earth) X-band link to support=
 this function. This time correlation is performed every day prior to landi=
ng and about weekly on the surface.<BR>
<BR>
After landing we have a looser tolerance (&lt; 10 seconds). It is possible =
that some Mars surface missions will require tighter time correlation for c=
oordinated observations.<BR>
<BR>
-Rob Manning<BR>
<BR>
<BR>
On 7/13/09 11:04 AM, &quot;Peter Lovell&quot; &lt;<a href=3D"[email-masked]=
m">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Hi Will,<BR>
<BR>
I think that would be essential.<BR>
<BR>
It's an interesting question, to be sure. Any time indication (for<BR>
synchronization) in a bundle needs to be adjusted to account for delays<BR>
or retransmissions. Doing that will be hard since the bundle will<BR>
probably be signed in order for the time number in it to be trusted.<BR>
DNTP could become quite complicated.<BR>
<BR>
Cheers.....Peter<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)<BR>
&lt;<a href=3D"[email-masked]">[email-masked]</a>&g=
t; wrote:<BR>
<BR>
&gt;To things that should be considered.=A0 You probably need a multi-hop<B=
R>
&gt;system to truly test time synchronization - DTN network time protocol<B=
R>
&gt;(to be invented).<BR>
&gt;=A0<BR>
&gt;Security Policy may state that if someone is trying to pass really long=
<BR>
&gt;lived bundles relative to your operations, you may decide to silently<B=
R>
&gt;discard them as this may be considered a DOS attack to use up system<BR=
>
&gt;resources.<BR>
&gt;=A0<BR>
&gt;/Will<BR>
&gt;=A0<BR>
&gt;From: <a href=3D"[email-masked]">dtn=
[email-masked]</a> [<a href=3D"mailto:dtn-"=
>mailto:dtn-</a><BR>
&gt;<a href=3D"[email-masked]">interest-boun=
[email-masked]</a>] On Behalf Of Scott, Keith L.<BR>
&gt;Sent: Monday, July 13, 2009 8:54 AM<BR>
&gt;To: <a href=3D"[email-masked]">dtn-interest@=
maillists.intel-research.net</a><BR>
&gt;Subject: [dtn-interest] Time synchronization within DTNs<BR>
&gt;=A0<BR>
&gt;The bundle protocol requires loose time synchronization to support the<=
BR>
&gt;time-to-live parameter.=A0 Does anyone have results from doing time<BR>
&gt;synchronization using the bundle protocol itself (i.e. time<BR>
&gt;synchronization over BP) and disrupted networks?<BR>
&gt;=A0<BR>
&gt;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 --keith<BR>
&gt;=A0<BR>
<BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
<a href=3D"[email-masked]">dtn-interest@maillist=
s.intel-research.net</a><BR>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><BR=
>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--_000_C680EF537636RobertMManningjplnasagov_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 15:02:57 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Meeting time correction DTN Disconnectathon (14:00 UTC, 10:00 EDT)

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE93NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Meeting time is still 14:00 UTC.  I just corrected the East Coast time.

Agenda is:

DRAFT AGENDA (open for suggestions)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Primary Interoperability Tests

 - Ohio Univ and GRC

    ** TCP CL between IP and DTN2 (requires ION update and DTN2 patch)

    ** OU has a "socket-type" API that allows the same applications to run =
over ION and DTN2

 - DTN Bundle Security Specification Interoperability Tests ???

Testing Times

 - With DTNbone machines, some of this testing could be continuous.

Network configurations (other than point-to-point)

 - OU and GRC would like to see some multi-hop, intermittent connectivity, =
and limited bandwidth links

   ** should these be static route or routing protocols.

   ** One will quickly see that without some type of route (name) aggregati=
on, a multi-hop chain is pretty nasty to configure.

 - Are there some routing protocols that could be tested for interoperabili=
ty or just plain tested?

Post configurations on DTNRG wiki in real-time

 - NASA did this on an internal wiki for multi-center testing and it helped=
.

Thoughts on using unsecure dynamic DNS on DTNbone and nsupdate to update na=
mes to addresses (or we could create a shared key and do DNSSEC, but probab=
ly overkill for this testing.)

 - may allow laptops to come and go and simply run nsupdate to DTNbone DNS =
server to update address database

 - beginnings of late binding

 - forces some thought on naming as - for this system - names may have to b=
e relative to some pre-configured domains (even if they are dummy domains).

   This may be necessary in order to update the dns server

 - force some thought on when to try and re-resolve a name (because it chan=
ge between the time you wanted to communicate and the time it reconnected t=
o the network.

 - enables multiple physical addresses for a DTN entity unless you subtract=
 old address when adding new.

 - forces thought on how to develop DNS name resolvers and handle late bind=
ings

Test Plan generation

 - Assign responsibilities to various individuals to create a test plan/pro=
cedure for each goal

   ** Include equipment, network topology, applications.

/Will

From: William Ivancic [mailto:[email-masked]]
Sent: Monday, July 13, 2009 3:58 PM
To: Ivancic, William D. (GRC-RHN0)
Subject: (Forward to attendees) Meeting rescheduled: DTN Disconnectaton

**** You can forward this email invitation to attendees ****

Hello ,

William Ivancic changed the time for this online meeting.

Topic: DTN Disconnectaton
Date: Tuesday, July 14, 2009
Time: 10:00 am, Eastern Daylight Time (GMT -04:00, New York)
Meeting Number: 992 708 018
Meeting Password: DTN4all*

Please click the link below to see more information, or to join the meeting=
.

-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to https://nasa.webex.com/nasa/j.php?ED=3D123444722&UID=3D0&PW=3D99cd=
db2f232b580d1f0841
2. Enter your name and email address.
3. Enter the meeting password: DTN4all*
4. Click "Join Now".

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------

Toll Outside US 1-517-600-5252
Toll Free US Only 866-783-5733
pass code  1095920

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://nasa.webex.com/nasa/mc
2. On the left navigation bar, click "Support".

You can contact me at:
[email-masked]<mailto:[email-masked]>
1-216-4333494

To update this meeting to your calendar program (for example Microsoft Outl=
ook), click this link:
https://nasa.webex.com/nasa/j.php?ED=3D123444722&UID=3D0&ICS=3DMRS3&LD=3D1&=
RD=3D2&ST=3D1&SHA2=3DmNl0qJihMyGXOedMiHD1X816dXkQgLvPhDPxo6xE28I=3D

WebEx will automatically setup Meeting Manager for Windows the first time y=
ou join a meeting. To save time, you can setup prior to the meeting by clic=
king this link:
https://nasa.webex.com/nasa/meetingcenter/mcsetup.php

The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://nasa.webex.com/nasa/systemdiagnosis.php

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com
We've got to start meeting like this(TM)

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, do not join the sessio=
n.

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE93NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Meeting time is still 14:00 UTC.&nbsp; I just corrected the =
East
Coast time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'mso-element:para-border-div;border:none;border-bottom:double =
windowtext 2.25pt;
padding:0in 0in 1.0pt 0in'>

<p class=3DMsoNormal style=3D'border:none;padding:0in'><span style=3D'font-=
size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Agenda is:<o:p></o:p></sp=
an></p>

</div>

<p class=3DMsoPlainText>DRAFT AGENDA (open for suggestions)<o:p></o:p></p>

<p class=3DMsoPlainText>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p><=
/p>

<p class=3DMsoPlainText>Primary Interoperability Tests <o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- Ohio Univ and GRC<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp;&nbsp; ** TCP CL between IP and DTN2
(requires ION update and DTN2 patch)<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp;&nbsp; ** OU has a &quot;socket-type&qu=
ot;
API that allows the same applications to run over ION and DTN2<o:p></o:p></=
p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&nbsp;- DTN Bundle Security Specification
Interoperability Tests ???<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Testing Times<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- With DTNbone machines, some of this testing=
 could
be continuous.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Network configurations (other than point-to-point)<=
o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- OU and GRC would like to see some multi-hop=
,
intermittent connectivity, and limited bandwidth links<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp; ** should these be static route or rou=
ting
protocols.<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp; ** One will quickly see that without s=
ome
type of route (name) aggregation, a multi-hop chain is pretty nasty to
configure. <o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- Are there some routing protocols that could=
 be
tested for interoperability or just plain tested?<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Post configurations on DTNRG wiki in real-time<o:p>=
</o:p></p>

<p class=3DMsoPlainText>&nbsp;- NASA did this on an internal wiki for
multi-center testing and it helped.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Thoughts on using unsecure dynamic DNS on DTNbone a=
nd
nsupdate to update names to addresses (or we could create a shared key and =
do
DNSSEC, but probably overkill for this testing.)<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- may allow laptops to come and go and simply=
 run
nsupdate to DTNbone DNS server to update address database<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- beginnings of late binding<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- forces some thought on naming as - for this
system - names may have to be relative to some pre-configured domains (even=
 if
they are dummy domains). <o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp; This may be necessary in order to upda=
te the
dns server<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- force some thought on when to try and re-re=
solve
a name (because it change between the time you wanted to communicate and th=
e
time it reconnected to the network.<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- enables multiple physical addresses for a D=
TN
entity unless you subtract old address when adding new.<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- forces thought on how to develop DNS name
resolvers and handle late bindings<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Test Plan generation <o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;- Assign responsibilities to various individu=
als to
create a test plan/procedure for each goal<o:p></o:p></p>

<p class=3DMsoPlainText>&nbsp;&nbsp; ** Include equipment, network topology=
,
applications.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>/Will<o:p></o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> William Ivanc=
ic
[mailto:[email-masked]] <br>
<b>Sent:</b> Monday, July 13, 2009 3:58 PM<br>
<b>To:</b> Ivancic, William D. (GRC-RHN0)<br>
<b>Subject:</b> (Forward to attendees) Meeting rescheduled: DTN Disconnecta=
ton<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>****
You can forward this email invitation to attendees **** <br>
<br>
Hello , <br>
<br>
William Ivancic changed the time for this online meeting. <br>
<br>
Topic: DTN Disconnectaton <br>
Date: Tuesday, July 14, 2009 <br>
Time: 10:00 am, Eastern Daylight Time (GMT -04:00, New York) <br>
Meeting Number: 992 708 018 <br>
Meeting Password: DTN4all* <br>
<br>
Please click the link below to see more information, or to join the meeting=
. <br>
<br>
------------------------------------------------------- <br>
To join the online meeting <br>
------------------------------------------------------- <br>
1. Go to <a
href=3D"https://nasa.webex.com/nasa/j.php?ED=3D123444722&amp;UID=3D0&amp;PW=
=3D99cddb2f232b580d1f0841"
target=3D"_blank">https://nasa.webex.com/nasa/j.php?ED=3D123444722&amp;UID=
=3D0&amp;PW=3D99cddb2f232b580d1f0841</a>
<br>
2. Enter your name and email address. <br>
3. Enter the meeting password: DTN4all* <br>
4. Click &quot;Join Now&quot;. <br>
<br>
------------------------------------------------------- <br>
To join the teleconference only <br>
------------------------------------------------------- <br>
<br>
Toll&nbsp;Outside&nbsp;US&nbsp;1-517-600-5252&nbsp; <br>
Toll&nbsp;Free&nbsp;US&nbsp;Only&nbsp;866-783-5733&nbsp; <br>
pass&nbsp;code&nbsp;&nbsp;1095920 <br>
<br>
------------------------------------------------------- <br>
For assistance <br>
------------------------------------------------------- <br>
1. Go to <a href=3D"https://nasa.webex.com/nasa/mc" target=3D"_blank">https=
://nasa.webex.com/nasa/mc</a>
<br>
2. On the left navigation bar, click &quot;Support&quot;. <br>
<br>
You can contact me at: <br>
<a href=3D"mailto:[email-masked]">[email-masked]</a=
> <br>
1-216-4333494 <br>
<br>
To update this meeting to your calendar program (for example Microsoft
Outlook), click this link: <br>
<a
href=3D"https://nasa.webex.com/nasa/j.php?ED=3D123444722&amp;UID=3D0&amp;IC=
S=3DMRS3&amp;LD=3D1&amp;RD=3D2&amp;ST=3D1&amp;SHA2=3DmNl0qJihMyGXOedMiHD1X8=
16dXkQgLvPhDPxo6xE28I=3D"
target=3D"_blank">https://nasa.webex.com/nasa/j.php?ED=3D123444722&amp;UID=
=3D0&amp;ICS=3DMRS3&amp;LD=3D1&amp;RD=3D2&amp;ST=3D1&amp;SHA2=3DmNl0qJihMyG=
XOedMiHD1X816dXkQgLvPhDPxo6xE28I=3D</a>
<br>
<br>
<br>
WebEx will automatically setup Meeting Manager for Windows the first time y=
ou
join a meeting. To save time, you can setup prior to the meeting by clickin=
g
this link: <br>
<a href=3D"https://nasa.webex.com/nasa/meetingcenter/mcsetup.php" target=3D=
"_blank">https://nasa.webex.com/nasa/meetingcenter/mcsetup.php</a>
<br>
<br>
<br>
The playback of UCF (Universal Communications Format) rich media files requ=
ires
appropriate players. To view this type of rich media files in the meeting,
please check whether you have the players installed on your computer by goi=
ng
to <a href=3D"https://nasa.webex.com/nasa/systemdiagnosis.php" target=3D"_b=
lank">https://nasa.webex.com/nasa/systemdiagnosis.php</a>
<br>
<br>
Sign up for a free trial of WebEx <br>
<a href=3D"http://www.webex.com/go/mcemfreetrial" target=3D"_blank">http://=
www.webex.com/go/mcemfreetrial</a>
<br>
<br>
<a href=3D"http://www.webex.com" target=3D"_blank">http://www.webex.com</a>=
 <br>
We've got to start meeting like this(TM) <br>
<br>
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd
any documents and other materials exchanged or viewed during the session to=
 be
recorded. By joining this session, you automatically consent to such record=
ings.
If you do not consent to the recording, do not join the session. </span><o:=
p></o:p></p>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE93NDJSSCC03ndcn_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>,  "Scott, Keith L. (JSC-ZF)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 14:27:01 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time synchronization within DTNs

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE5CNDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with Scott in that space systems have timing handled as they need i=
t for many things.  But, today, all those system have some direct connectio=
n backchannel.

For the general, non-space case, timing synchronization is likely to be an =
issue.  You may not have a back channel and you may only be connected via a=
 multi-hop system.  That appears to be the general case.

Will

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Burleigh, Scott C
Sent: Monday, July 13, 2009 1:57 PM
To: Scott, Keith L. (JSC-ZF); [email-masked]
Subject: Re: [dtn-interest] Time synchronization within DTNs

Actually we did this pretty successfully for DINET:

*         Obviously the ability to set the bundle creation time on issuance=
 and check the expiration time on reception depends on DTN's ability to rea=
d the local system clock and know what the correct time is.  ION provides a=
 getUTCTime() function for this purpose; the function reads the system cloc=
k value, adds to it a "UTC delta" (in seconds), and returns the sum.  Assum=
ing your system clock is already reporting UTC time, the value of the UTC d=
elta is the current clock error, i.e., the known difference between the UTC=
 reported by the clock and the actual UTC as reported by a reference clock =
somewhere (e.g., GPS).  [If your system clock is reporting time for some lo=
cal time zone rather than UTC, then the time-zone difference needs to be in=
cluded in the UTC delta as well.]

*         Aha! you respond, but how is this magical UTC delta "known"?  No =
problemo, at least for JPL missions: the spacecraft team for every spacecra=
ft needs to know this clock error anyway, for loads of other purposes, so t=
hey are already collecting time correlation packets from the spacecraft and=
 using them to construct sclk/scet correlation tables (where "sclk" is spac=
ecraft clock time and "scet" is the corresponding actual spacecraft event t=
ime, both notionally in UTC).  The sclk/scet table tracks and predicts the =
drift of the spacecraft clock, so one can derive from it the difference bet=
ween spacecraft clock time and the actual UTC at any time.  The EPOXI space=
craft team kindly extracted this information for us for each DINET tracking=
 pass.

*         Given the known UTC delta, we used the standard ION load/go syste=
m to set the UTC delta value on the spacecraft via DTN, ensuring that the v=
alues reported by getUTCTime() were correct (to within a few seconds) from =
that point on.

This highly manual process wouldn't scale up well beyond a small number of =
spacecraft, of course, but there's nothing about it that is necessarily man=
ual.  The system that computes the updated sclk/scet table for a spacecraft=
 could certainly be modified to emit a load/go bundle to update that spacec=
raft's UTC delta as well.

Which is to say that, just as with contact graph routing, for DTN in space =
flight we have the advantage of being able to leverage off work that is alr=
eady being done in order to fly the spacecraft; we don't have to invent eve=
rything ourselves.  Not very helpful for terrestrial DTN environments, I kn=
ow, and the eventual development of a full-up delay-tolerant NTP will be an=
 attractive alternative for flight DTN as well, but in the meantime I think=
 it's worth suggesting that in some cases these problems are less daunting =
than they may seem.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Scott, Keith L.
Sent: Monday, July 13, 2009 5:54 AM
To: [email-masked]
Subject: [dtn-interest] Time synchronization within DTNs

The bundle protocol requires loose time synchronization to support the time=
-to-live parameter.  Does anyone have results from doing time synchronizati=
on using the bundle protocol itself (i.e. time synchronization over BP) and=
 disrupted networks?

                                --keith

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE5CNDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:603995168;
	mso-list-type:hybrid;
	mso-list-template-ids:-886388284 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>I agree with Scott in th=
at space
systems have timing handled as they need it for many things.&nbsp; But, tod=
ay,
all those system have some direct connection backchannel.<o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>For the general, non-spa=
ce case,
timing synchronization is likely to be an issue.&nbsp; You may not have a b=
ack
channel and you may only be connected via a multi-hop system.&nbsp; That
appears to be the general case.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Will<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Burleigh,
Scott C<br>
<b>Sent:</b> Monday, July 13, 2009 1:57 PM<br>
<b>To:</b> Scott, Keith L. (JSC-ZF); [email-masked].=
net<br>
<b>Subject:</b> Re: [dtn-interest] Time synchronization within DTNs<o:p></o=
:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Actually we did this pre=
tty
successfully for DINET:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Obviously the
ability to set the bundle creation time on issuance and check the expiratio=
n
time on reception depends on DTN&#8217;s ability to read the local system c=
lock
and know what the correct time is.&nbsp; ION provides a getUTCTime() functi=
on
for this purpose; the function reads the system clock value, adds to it a
&#8220;UTC delta&#8221; (in seconds), and returns the sum.&nbsp; Assuming y=
our
system clock is already reporting UTC time, the value of the UTC delta is t=
he
current clock error, i.e., the known difference between the UTC reported by=
 the
clock and the actual UTC as reported by a reference clock somewhere (e.g.,
GPS).&nbsp; [If your system clock is reporting time for some local time zon=
e
rather than UTC, then the time-zone difference needs to be included in the =
UTC
delta as well.]<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Aha! you respo=
nd,
but how is this magical UTC delta &#8220;known&#8221;?&nbsp; No problemo, a=
t
least for JPL missions: the spacecraft team for every spacecraft needs to k=
now
this clock error anyway, for loads of other purposes, so they are already
collecting time correlation packets from the spacecraft and using them to
construct sclk/scet correlation tables (where &#8220;sclk&#8221; is spacecr=
aft
clock time and &#8220;scet&#8221; is the corresponding actual spacecraft ev=
ent
time, both notionally in UTC).&nbsp; The sclk/scet table tracks and predict=
s
the drift of the spacecraft clock, so one can derive from it the difference
between spacecraft clock time and the actual UTC at any time.&nbsp; The EPO=
XI
spacecraft team kindly extracted this information for us for each DINET
tracking pass.<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo2'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Given the know=
n UTC
delta, we used the standard ION load/go system to set the UTC delta value o=
n
the spacecraft via DTN, ensuring that the values reported by getUTCTime() w=
ere correct
(to within a few seconds) from that point on.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This highly manual proce=
ss
wouldn&#8217;t scale up well beyond a small number of spacecraft, of course=
,
but there&#8217;s nothing about it that is necessarily manual.&nbsp; The sy=
stem
that computes the updated sclk/scet table for a spacecraft could certainly =
be
modified to emit a load/go bundle to update that spacecraft&#8217;s UTC del=
ta
as well.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Which is to say that, ju=
st as
with contact graph routing, for DTN in space flight we have the advantage o=
f
being able to leverage off work that is already being done in order to fly =
the
spacecraft; we don&#8217;t have to invent everything ourselves.&nbsp; Not v=
ery
helpful for terrestrial DTN environments, I know, and the eventual developm=
ent
of a full-up delay-tolerant NTP will be an attractive alternative for fligh=
t
DTN as well, but in the meantime I think it&#8217;s worth suggesting that i=
n
some cases these problems are less daunting than they may seem.<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Scott<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Scott,
Keith L.<br>
<b>Sent:</b> Monday, July 13, 2009 5:54 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] Time synchronization within DTNs<o:p></o:p><=
/span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The bundle protocol requires loose time synchronizatio=
n to
support the time-to-live parameter.&nbsp; Does anyone have results from doi=
ng
time synchronization using the bundle protocol itself (i.e. time
synchronization over BP) and disrupted networks?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--keith<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFE5CNDJSSCC03ndcn_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Marshall Eubanks <[email-masked]>, Peter Lovell <[email-masked]>
Date: Mon, 13 Jul 2009 14:20:12 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Time synchronization within DTNs

Marshall,

>From your comments below, are you just considering a space backbone where everything is pretty much predicable.  DTN is also to be used in a number of other unpredictable environments.

/Will

>From: Marshall Eubanks [mailto:[email-masked]]
>Sent: Monday, July 13, 2009 2:48 PM
>To: Peter Lovell
>Cc: Ivancic, William D. (GRC-RHN0); Scott, Keith L. (JSC-ZF); dtn-
>[email-masked]
>Subject: Re: [dtn-interest] Re(2): Time synchronization within DTNs
>In many cases, what is needed is not synchronization but syntonization
>(aligning time rates, not time offset).
>The DSN, for example, worries a lot more about syntonization than
>synchronization. Syntonization is all you need, for
>example, to predict when the next spacecraft transmission is coming.
>
>In a DTN perspective, I think that syntonization would
>be much more straightforward, at least on a hop by hop basis. You
>don't have to worry about delay, as long as there is an estimate for
>the light travel time
>and the other delays don't change very fast. A simple algorithm is
>
>- measure the time offset twice at two different clock epochs
>- make sure that the path hasn't changed between the epochs. Apply any
>known geometrical correction.
>- the delta offset / delta epoch is the clock rate correction.
>
>Regards
>Marshall

From: Peter Lovell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, Kscott <[email-masked]>, [email-masked]
Date: Mon, 13 Jul 2009 14:04:22 -0400
Subject: [dtn-interest] Re(2):  Time synchronization within DTNs

Hi Will,

I think that would be essential. 

It's an interesting question, to be sure. Any time indication (for
synchronization) in a bundle needs to be adjusted to account for delays
or retransmissions. Doing that will be hard since the bundle will
probably be signed in order for the time number in it to be trusted.
DNTP could become quite complicated.

Cheers.....Peter

On Mon, Jul 13, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>To things that should be considered.� You probably need a multi-hop
>system to truly test time synchronization - DTN network time protocol
>(to be invented).
>�
>Security Policy may state that if someone is trying to pass really long
>lived bundles relative to your operations, you may decide to silently
>discard them as this may be considered a DOS attack to use up system
>resources.
>�
>/Will
>�
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Scott, Keith L.
>Sent: Monday, July 13, 2009 8:54 AM
>To: [email-masked]
>Subject: [dtn-interest] Time synchronization within DTNs
>�
>The bundle protocol requires loose time synchronization to support the
>time-to-live parameter.� Does anyone have results from doing time
>synchronization using the bundle protocol itself (i.e. time
>synchronization over BP) and disrupted networks?
>�
>������������������������������� --keith
>�

From: "Burleigh, Scott C" <[email-masked]>
To: "Scott, Keith L." <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 10:56:48 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time synchronization within DTNs

--_000_FD514C8A5155C64C9B145B48D674EF54499FFFD9FAALTPHYEMBEVSP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Actually we did this pretty successfully for DINET:

*         Obviously the ability to set the bundle creation time on issuance=
 and check the expiration time on reception depends on DTN's ability to rea=
d the local system clock and know what the correct time is.  ION provides a=
 getUTCTime() function for this purpose; the function reads the system cloc=
k value, adds to it a "UTC delta" (in seconds), and returns the sum.  Assum=
ing your system clock is already reporting UTC time, the value of the UTC d=
elta is the current clock error, i.e., the known difference between the UTC=
 reported by the clock and the actual UTC as reported by a reference clock =
somewhere (e.g., GPS).  [If your system clock is reporting time for some lo=
cal time zone rather than UTC, then the time-zone difference needs to be in=
cluded in the UTC delta as well.]

*         Aha! you respond, but how is this magical UTC delta "known"?  No =
problemo, at least for JPL missions: the spacecraft team for every spacecra=
ft needs to know this clock error anyway, for loads of other purposes, so t=
hey are already collecting time correlation packets from the spacecraft and=
 using them to construct sclk/scet correlation tables (where "sclk" is spac=
ecraft clock time and "scet" is the corresponding actual spacecraft event t=
ime, both notionally in UTC).  The sclk/scet table tracks and predicts the =
drift of the spacecraft clock, so one can derive from it the difference bet=
ween spacecraft clock time and the actual UTC at any time.  The EPOXI space=
craft team kindly extracted this information for us for each DINET tracking=
 pass.

*         Given the known UTC delta, we used the standard ION load/go syste=
m to set the UTC delta value on the spacecraft via DTN, ensuring that the v=
alues reported by getUTCTime() were correct (to within a few seconds) from =
that point on.

This highly manual process wouldn't scale up well beyond a small number of =
spacecraft, of course, but there's nothing about it that is necessarily man=
ual.  The system that computes the updated sclk/scet table for a spacecraft=
 could certainly be modified to emit a load/go bundle to update that spacec=
raft's UTC delta as well.

Which is to say that, just as with contact graph routing, for DTN in space =
flight we have the advantage of being able to leverage off work that is alr=
eady being done in order to fly the spacecraft; we don't have to invent eve=
rything ourselves.  Not very helpful for terrestrial DTN environments, I kn=
ow, and the eventual development of a full-up delay-tolerant NTP will be an=
 attractive alternative for flight DTN as well, but in the meantime I think=
 it's worth suggesting that in some cases these problems are less daunting =
than they may seem.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Scott, Keith L.
Sent: Monday, July 13, 2009 5:54 AM
To: [email-masked]
Subject: [dtn-interest] Time synchronization within DTNs

The bundle protocol requires loose time synchronization to support the time=
-to-live parameter.  Does anyone have results from doing time synchronizati=
on using the bundle protocol itself (i.e. time synchronization over BP) and=
 disrupted networks?

                                --keith

--_000_FD514C8A5155C64C9B145B48D674EF54499FFFD9FAALTPHYEMBEVSP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:603995168;
	mso-list-type:hybrid;
	mso-list-template-ids:-886388284 67698689 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Actually we did this pre=
tty
successfully for DINET:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Obviously the
ability to set the bundle creation time on issuance and check the expiratio=
n
time on reception depends on DTN&#8217;s ability to read the local system c=
lock
and know what the correct time is.&nbsp; ION provides a getUTCTime() functi=
on for
this purpose; the function reads the system clock value, adds to it a &#822=
0;UTC
delta&#8221; (in seconds), and returns the sum.&nbsp; Assuming your system
clock is already reporting UTC time, the value of the UTC delta is the curr=
ent clock
error, i.e., the known difference between the UTC reported by the clock and=
 the
actual UTC as reported by a reference clock somewhere (e.g., GPS).&nbsp; [I=
f
your system clock is reporting time for some local time zone rather than UT=
C,
then the time-zone difference needs to be included in the UTC delta as well=
.]<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Aha! you respo=
nd,
but how is this magical UTC delta &#8220;known&#8221;?&nbsp; No problemo, a=
t
least for JPL missions: the spacecraft team for every spacecraft needs to k=
now
this clock error anyway, for loads of other purposes, so they are already c=
ollecting
time correlation packets from the spacecraft and using them to construct
sclk/scet correlation tables (where &#8220;sclk&#8221; is spacecraft clock =
time
and &#8220;scet&#8221; is the corresponding actual spacecraft event time, b=
oth
notionally in UTC).&nbsp; The sclk/scet table tracks and predicts the drift=
 of
the spacecraft clock, so one can derive from it the difference between
spacecraft clock time and the actual UTC at any time.&nbsp; The EPOXI space=
craft
team kindly extracted this information for us for each DINET tracking pass.=
<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'font-family:Symbol;color:#1F497D'><span style=3D'mso-list:Ignore'>=
&middot;<span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'color:#1F497D'>Given the know=
n UTC
delta, we used the standard ION load/go system to set the UTC delta value o=
n
the spacecraft via DTN, ensuring that the values reported by getUTCTime() w=
ere
correct (to within a few seconds) from that point on.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>This highly manual proce=
ss
wouldn&#8217;t scale up well beyond a small number of spacecraft, of course=
,
but there&#8217;s nothing about it that is necessarily manual.&nbsp; The sy=
stem
that computes the updated sclk/scet table for a spacecraft could certainly =
be
modified to emit a load/go bundle to update that spacecraft&#8217;s UTC del=
ta
as well.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Which is to say that, ju=
st as
with contact graph routing, for DTN in space flight we have the advantage o=
f
being able to leverage off work that is already being done in order to fly =
the
spacecraft; we don&#8217;t have to invent everything ourselves.&nbsp; Not v=
ery
helpful for terrestrial DTN environments, I know, and the eventual developm=
ent
of a full-up delay-tolerant NTP will be an attractive alternative for fligh=
t
DTN as well, but in the meantime I think it&#8217;s worth suggesting that i=
n
some cases these problems are less daunting than they may seem.<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Scott<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:dtn-interest-boun=
[email-masked]]
<b>On Behalf Of </b>Scott, Keith L.<br>
<b>Sent:</b> Monday, July 13, 2009 5:54 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] Time synchronization within DTNs<o:p></o:p><=
/span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The bundle protocol requires loose time synchronizatio=
n to
support the time-to-live parameter.&nbsp; Does anyone have results from doi=
ng
time synchronization using the bundle protocol itself (i.e. time
synchronization over BP) and disrupted networks?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--keith<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF54499FFFD9FAALTPHYEMBEVSP_--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 08:33:51 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Meeting invitation: DTN Disconnectathon - Planning Teleconference (updated Agenda)

I added security as a topic to the agenda.  I would like to know if anyone plans to test BSP or any portions of this?  If so, if we know the algorithms people wish to test, we can probably pre-generate some key types and a mini-certificate authority chain and place that on the wiki for people to use.

/Will
========================

I setup a teleconference and webex meeting for DTN Disconnectathon - Planning Teleconference

Tuesday, July 14
14:00 UTC  (10:00 EDT)  I think this is 4:00 for most of Europe

I suspect this will mainly be a teleconference, but I setup a Webex in case we want to use it.  

I think we can get done in an hour if we are well organized in advance.

Goal - Determine what we want out of the Disconnectathon and how to accomplish that

In preparation, those wishing to participate in the Disconnectathon, if you could send you primary Goals to the list, that would be useful.  I can compile them and we can go through those first.

For example do you want to test a particular routing protocol, applications, network management functions, etcetera?

DRAFT AGENDA (open for suggestions)
======================================
Primary Interoperability Tests 
 - Ohio Univ and GRC
    ** TCP CL between IP and DTN2 (requires ION update and DTN2 patch)
    ** OU has a "socket-type" API that allows the same applications to run over ION and DTN2

 - DTN Bundle Security Specification Interoperability Tests ???

Testing Times
 - With DTNbone machines, some of this testing could be continuous.

Network configurations (other than point-to-point)
 - OU and GRC would like to see some multi-hop, intermittent connectivity, and limited bandwidth links
   ** should these be static route or routing protocols.
   ** One will quickly see that without some type of route (name) aggregation, a multi-hop chain is pretty nasty to configure. 
 - Are there some routing protocols that could be tested for interoperability or just plain tested?

Post configurations on DTNRG wiki in real-time
 - NASA did this on an internal wiki for multi-center testing and it helped.

Thoughts on using unsecure dynamic DNS on DTNbone and nsupdate to update names to addresses (or we could create a shared key and do DNSSEC, but probably overkill for this testing.)
 - may allow laptops to come and go and simply run nsupdate to DTNbone DNS server to update address database
 - beginnings of late binding
 - forces some thought on naming as - for this system - names may have to be relative to some pre-configured domains (even if they are dummy domains). 
   This may be necessary in order to update the dns server
 - force some thought on when to try and re-resolve a name (because it change between the time you wanted to communicate and the time it reconnected to the network.
 - enables multiple physical addresses for a DTN entity unless you subtract old address when adding new.
 - forces thought on how to develop DNS name resolvers and handle late bindings

Test Plan generation 
 - Assign responsibilities to various individuals to create a test plan/procedure for each goal
   ** Include equipment, network topology, applications.

/Will

******************************

From: William Ivancic [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 2:53 PM
To: Ivancic, William D. (GRC-RHN0)
Subject: (Forward to attendees) Meeting invitation: DTN Disconnectathon

**** You can forward this email invitation to attendees **** 

Hello , 

William Ivancic invites you to attend this online meeting. 

Topic: DTN Disconnectathon 
Date: Tuesday, July 14, 2009 
Time: 2:00 pm, Eastern Daylight Time (GMT -04:00, New York) 
Meeting Number: 992 708 018 
Meeting Password: DTN4all* 

Please click the link below to see more information, or to join the meeting. 

------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&PW=c9a9442018057e272d5512
 
2. Enter your name and email address. 
3. Enter the meeting password: DTN4all* 
4. Click "Join Now". 

------------------------------------------------------- 
To join the teleconference only 
------------------------------------------------------- 

Toll�Outside�US�1-517-600-5252� 
Toll�Free�US�Only�866-783-5733� 
pass�code��1095920 

------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://nasa.webex.com/nasa/mc 
2. On the left navigation bar, click "Support". 

You can contact me at: 
[email-masked] 
1-216-4333494 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=mNl0qJihMyGXOedMiHD1X816dXkQgLvPhDPxo6xE28I= 

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://nasa.webex.com/nasa/systemdiagnosis.php 

Sign up for a free trial of WebEx 
http://www.webex.com/go/mcemfreetrial 

http://www.webex.com 
We've got to start meeting like this(TM) 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Scott, Keith L. (JSC-ZF)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 08:17:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time synchronization within DTNs

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFBD2NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To things that should be considered.  You probably need a multi-hop system =
to truly test time synchronization - DTN network time protocol (to be inven=
ted).

Security Policy may state that if someone is trying to pass really long liv=
ed bundles relative to your operations, you may decide to silently discard =
them as this may be considered a DOS attack to use up system resources.

/Will

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Scott, Keith L.
Sent: Monday, July 13, 2009 8:54 AM
To: [email-masked]
Subject: [dtn-interest] Time synchronization within DTNs

The bundle protocol requires loose time synchronization to support the time=
-to-live parameter.  Does anyone have results from doing time synchronizati=
on using the bundle protocol itself (i.e. time synchronization over BP) and=
 disrupted networks?

                                --keith

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFBD2NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>To things that should be
considered.&nbsp; You probably need a multi-hop system to truly test time
synchronization &#8211; DTN network time protocol (to be invented).<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Security Policy may stat=
e that
if someone is trying to pass really long lived bundles relative to your
operations, you may decide to silently discard them as this may be consider=
ed a
DOS attack to use up system resources.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>/Will<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Scott,
Keith L.<br>
<b>Sent:</b> Monday, July 13, 2009 8:54 AM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] Time synchronization within DTNs<o:p></o:p><=
/span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The bundle protocol requires loose time synchronizatio=
n to
support the time-to-live parameter.&nbsp; Does anyone have results from doi=
ng
time synchronization using the bundle protocol itself (i.e. time synchroniz=
ation
over BP) and disrupted networks?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--keith<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856137E50CFBD2NDJSSCC03ndcn_--

From: "Scott, Keith L." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Jul 2009 08:53:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Time synchronization within DTNs

--_000_0111C34BD897FD41841D60396F2AD3D3018A8B42FBIMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The bundle protocol requires loose time synchronization to support the time=
-to-live parameter.  Does anyone have results from doing time synchronizati=
on using the bundle protocol itself (i.e. time synchronization over BP) and=
 disrupted networks?

                                --keith

--_000_0111C34BD897FD41841D60396F2AD3D3018A8B42FBIMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>The bundle protocol requires loose time synchronizatio=
n to
support the time-to-live parameter.&nbsp; Does anyone have results from doi=
ng
time synchronization using the bundle protocol itself (i.e. time
synchronization over BP) and disrupted networks?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --keith<o:p></o:p=
></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_0111C34BD897FD41841D60396F2AD3D3018A8B42FBIMCMBX2MITREO_--

From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Sat, 11 Jul 2009 09:35:46 +0100
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] bundle transfer questions

I hope Lloyd won't mind (too much) if I point out that those documents  
contain contentious material and do not represent a concensus of the  
research group. Well worth reading but being aware of that part of the  
background is important,
Stephen.

On 11 Jul 2009, at 05:08, Lloyd Wood <[email-masked]> wrote:

>
> On 10 Jul 2009, at 20:42, Victor lyamtsev wrote:
>> I had a question if error detection if supported in current DTN
>> implementation. The answer was as following:
>> "Not originally.  The current approach is to use the Security
>> mechanism as error checking, but this means you have to implement the
>> security mechanisms (or at least the portion you need)"
>
> Read:
> Wesley M. Eddy, Lloyd Wood and Will Ivancic, Reliability-only
> Ciphersuites for the Bundle Protocol, work in progress as an internet-
> draft, May 2009.
> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum
>
>
> Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',
> IEEE Aerospace Conference, Big Sky, Montana, March 2009.
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems
>
>> OK, error detection is implemented as a part of BSP and from the
>> recent discussion on "dtn-interest" I surmised  that DTN2 already
>> supports BSP with implementations for BA1, PI2, PC3 ciphersuites. If
>> support is already there, what would I have to implement?
>>
>> Thank you and regards,
>> -V
>> On Thu, May 28, 2009 at 2:03 PM, Ivancic, William D.
>> (GRC-RHN0)<[email-masked]> wrote:
>>>> -----Original Message-----
>>>> From: [email-masked]  
>>>> [mailto:dtn-
>>>> [email-masked]] On Behalf Of Victor
>>>> lyamtsev
>>>> Sent: Thursday, May 28, 2009 10:15 AM
>>>> To: [email-masked]
>>>> Subject: [dtn-interest] bundle transfer questions
>>>>
>>>> Hello,
>>>> After reading of RFC and some tutorials it's still not quite clear
>>>> to
>>>> me how bundle transfer is accomplished...
>>>> The tutorial remarks that transport layer is terminated on the
>>>> bundle
>>>> layer...
>>>> Suppose node A sends the bundle to node B. Does that mean bandle
>>>> layer
>>>> of "B" has to provide ACK message to "A" to mark successful bundle
>>>> transfer, regardless of ACK's in the transport layer ?
>>>
>>> Yes, if custody transfer is required.
>>>
>>> No, if custody transfer is NOT required, an acknowledgement is
>>> not.   However acknowledgements are useful.
>>>
>>>> Is there error
>>>> checking mechanism in the bundle layer independent of transport,
>>>> link
>>>> layers ?
>>>
>>> Not originally.  The current approach is to use the Security
>>> mechanism as error checking, but this means you have to implement
>>> the security mechanisms (or at least the portion you need).
>>> Sometimes you don't need error checking for some data, but for
>>> custody transfer it is really useful.  There has been LOTS of
>>> discussion on the list regarding this.  I suggest reading http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-04
>>> as it give some background regarding CRC and the current design
>>> decisions to implement a part of the Security piece.
>>>
>>>> If that's not the case how's the conclusion made in bundle layer of
>>>> "A" about success/ failure of bundle transfer?
>>>> Suppose, there's link failure in the middle of bundle transfer.  
>>>> Does
>>>> that mean the whole bundle has to be sent from the beginning? Or,
>>>> does
>>>> node "B" have temporary storage for new bundle and node "A" just  
>>>> can
>>>> resume transfer after finding new route?
>>>
>>> Sort of an overloaded question.  Some transport protocols like LTP
>>> can handle some of this.  Reactive Fragmentation - particularly
>>> with security is a problem with, I believe to date, no known
>>> solution - particularly if there is a reroute between fragments.
>>>
>
>
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Lloyd Wood <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Date: Sat, 11 Jul 2009 05:08:43 +0100
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] bundle transfer questions

On 10 Jul 2009, at 20:42, Victor lyamtsev wrote:
> I had a question if error detection if supported in current DTN
> implementation. The answer was as following:
> "Not originally.  The current approach is to use the Security
> mechanism as error checking, but this means you have to implement the
> security mechanisms (or at least the portion you need)"

Read:
Wesley M. Eddy, Lloyd Wood and Will Ivancic, Reliability-only  
Ciphersuites for the Bundle Protocol, work in progress as an internet- 
draft, May 2009.
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum

Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems',  
IEEE Aerospace Conference, Big Sky, Montana, March 2009.
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems

> OK, error detection is implemented as a part of BSP and from the
> recent discussion on "dtn-interest" I surmised  that DTN2 already
> supports BSP with implementations for BA1, PI2, PC3 ciphersuites. If
> support is already there, what would I have to implement?
>
> Thank you and regards,
> -V
> On Thu, May 28, 2009 at 2:03 PM, Ivancic, William D.
> (GRC-RHN0)<[email-masked]> wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Victor
>>> lyamtsev
>>> Sent: Thursday, May 28, 2009 10:15 AM
>>> To: [email-masked]
>>> Subject: [dtn-interest] bundle transfer questions
>>>
>>> Hello,
>>> After reading of RFC and some tutorials it's still not quite clear  
>>> to
>>> me how bundle transfer is accomplished...
>>> The tutorial remarks that transport layer is terminated on the  
>>> bundle
>>> layer...
>>> Suppose node A sends the bundle to node B. Does that mean bandle  
>>> layer
>>> of "B" has to provide ACK message to "A" to mark successful bundle
>>> transfer, regardless of ACK's in the transport layer ?
>>
>> Yes, if custody transfer is required.
>>
>> No, if custody transfer is NOT required, an acknowledgement is  
>> not.   However acknowledgements are useful.
>>
>>> Is there error
>>> checking mechanism in the bundle layer independent of transport,  
>>> link
>>> layers ?
>>
>> Not originally.  The current approach is to use the Security  
>> mechanism as error checking, but this means you have to implement  
>> the security mechanisms (or at least the portion you need).   
>> Sometimes you don't need error checking for some data, but for  
>> custody transfer it is really useful.  There has been LOTS of  
>> discussion on the list regarding this.  I suggest reading http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-04 
>>  as it give some background regarding CRC and the current design  
>> decisions to implement a part of the Security piece.
>>
>>> If that's not the case how's the conclusion made in bundle layer of
>>> "A" about success/ failure of bundle transfer?
>>> Suppose, there's link failure in the middle of bundle transfer. Does
>>> that mean the whole bundle has to be sent from the beginning? Or,  
>>> does
>>> node "B" have temporary storage for new bundle and node "A" just can
>>> resume transfer after finding new route?
>>
>> Sort of an overloaded question.  Some transport protocols like LTP  
>> can handle some of this.  Reactive Fragmentation - particularly  
>> with security is a problem with, I believe to date, no known  
>> solution - particularly if there is a reroute between fragments.
>>

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

From: "Burleigh, Scott C" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 10 Jul 2009 17:01:38 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Bundle Security Protocol follow up questions

We've now got a simple security policy database management facility built into ION, to support the use of BABs in DINET 2.  So far it just manages keys and BAB transmission and reception rules, but the structure is easily extensible to handle rules for PIBs, PCBs, and ESBs (and even the LTP security extensions) whenever we get around to implementing them.

I'm hoping the upgraded ION will become available from Ohio U. sometime in the next couple of weeks, as soon as we get migration to Mercurial coordinated between JPL and Ohio U.  But we've been fixated on getting ready for our Critical Design Review, which just ended half an hour ago, so progress on that migration hasn't had high priority until now.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Friday, July 10, 2009 10:38 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [dtn-interest] Bundle Security Protocol follow up questions
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:dtn-
> >[email-masked]] On Behalf Of
> >[email-masked]
> >Sent: Friday, July 10, 2009 11:34 AM
> >To: [email-masked]
> >Subject: [dtn-interest] Bundle Sucurity Protocol folloup questions
> >
> >Thanks for the replies.
> >
> >But again I encounterd some more questions,as follows:
> >
> >The decision whether or not to check is determined by the node's policy
> >
> >1. So, where’s the node policy is defined? In .conf file? How’s the
> >particular ciphersuite is selected?
> 
> 
> I don't know if any of the currently openly available code have gotten that
> far.  Perhaps BBN Spindle III has it.
> 
> If you look at a Router, it is in the configurations.  Likewise, think of
> IP in Linux and you find security policy in a number of places.  IP-Tables
> is firewall policy.  If you run IPsec Tools and SETKEY can create a
> configuration file there or just run command line.  If you download some of
> the IKEv2 implementations like Strongswan, they have Policy configuration
> files.  Fun stuff!
> 
> http://linux.die.net/man/8/setkey
> 
> http://www.strongswan.org/uml/testresults43/ikev2/net2net-route/
> here, the ipsec.conf files have the security policy
> 
> 
> /Will
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Peter Lovell <[email-masked]>
To: Victor lyamtsev <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>
Date: Fri, 10 Jul 2009 17:58:08 -0400
Cc: [email-masked]
Subject: [dtn-interest] Re(2):  bundle transfer questions

Hi Victor,

first let me clarify a bit ...

BAB will detect errors for a single hop. If all the hops support BAB,
and don't introduce errors themselves, then errors should be detected as
soon as they occur.

If some hops do not implement BAB then you may have undetected errors.
That can happen also if a node internally has errors, as Lloyd has said.
For that circumstance the PIB solution is needed. If you need that then
you have to implement the ciphersuite as suggested in the bundle-
checksum draft. That's not part of the RI.

Regards.....Peter

On Fri, Jul 10, 2009, Victor lyamtsev <[email-masked]> wrote:

>Hi,
>I had a question if error detection if supported in current DTN
>implementation. The answer was as following:
>"Not originally.  The current approach is to use the Security
>mechanism as error checking, but this means you have to implement the
>security mechanisms (or at least the portion you need)"
>OK, error detection is implemented as a part of BSP and from the
>recent discussion on "dtn-interest" I surmised  that DTN2 already
>supports BSP with implementations for BA1, PI2, PC3 ciphersuites. If
>support is already there, what would I have to implement?
>
>Thank you and regards,
>-V
>On Thu, May 28, 2009 at 2:03 PM, Ivancic, William D.
>(GRC-RHN0)<[email-masked]> wrote:
>>>-----Original Message-----
>>>From: [email-masked] [mailto:dtn-
>>>[email-masked]] On Behalf Of Victor
>>>lyamtsev
>>>Sent: Thursday, May 28, 2009 10:15 AM
>>>To: [email-masked]
>>>Subject: [dtn-interest] bundle transfer questions
>>>
>>>Hello,
>>>After reading of RFC and some tutorials it's still not quite clear to
>>>me how bundle transfer is accomplished...
>>>The tutorial remarks that transport layer is terminated on the bundle
>>>layer...
>>>Suppose node A sends the bundle to node B. Does that mean bandle layer
>>>of "B" has to provide ACK message to "A" to mark successful bundle
>>>transfer, regardless of ACK's in the transport layer ?
>>
>> Yes, if custody transfer is required.
>>
>> No, if custody transfer is NOT required, an acknowledgement is not. �
>However acknowledgements are useful.
>>
>>>Is there error
>>>checking mechanism in the bundle layer independent of transport, link
>>>layers ?
>>
>> Not originally. �The current approach is to use the Security mechanism
>as error checking, but this means you have to implement the security
>mechanisms (or at least the portion you need). �Sometimes you don't need
>error checking for some data, but for custody transfer it is really
>useful. �There has been LOTS of discussion on the list regarding this.
>�I suggest reading http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-
>checksum-04 as it give some background regarding CRC and the current
>design decisions to implement a part of the Security piece.
>>
>>>If that's not the case how's the conclusion made in bundle layer of
>>>"A" about success/ failure of bundle transfer?
>>>Suppose, there's link failure in the middle of bundle transfer. Does
>>>that mean the whole bundle has to be sent from the beginning? Or, does
>>>node "B" have temporary storage for new bundle and node "A" just can
>>>resume transfer after finding new route?
>>
>> Sort of an overloaded question. �Some transport protocols like LTP can
>handle some of this. �Reactive Fragmentation - particularly with
>security is a problem with, I believe to date, no known solution -
>particularly if there is a reroute between fragments.
>>
>>
>>
>>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 10 Jul 2009 15:42:31 -0400
From: Victor lyamtsev <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] bundle transfer questions

Hi,
I had a question if error detection if supported in current DTN
implementation. The answer was as following:
"Not originally.  The current approach is to use the Security
mechanism as error checking, but this means you have to implement the
security mechanisms (or at least the portion you need)"
OK, error detection is implemented as a part of BSP and from the
recent discussion on "dtn-interest" I surmised  that DTN2 already
supports BSP with implementations for BA1, PI2, PC3 ciphersuites. If
support is already there, what would I have to implement?

Thank you and regards,
-V
On Thu, May 28, 2009 at 2:03 PM, Ivancic, William D.
(GRC-RHN0)<[email-masked]> wrote:
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of Victor
>>lyamtsev
>>Sent: Thursday, May 28, 2009 10:15 AM
>>To: [email-masked]
>>Subject: [dtn-interest] bundle transfer questions
>>
>>Hello,
>>After reading of RFC and some tutorials it's still not quite clear to
>>me how bundle transfer is accomplished...
>>The tutorial remarks that transport layer is terminated on the bundle
>>layer...
>>Suppose node A sends the bundle to node B. Does that mean bandle layer
>>of "B" has to provide ACK message to "A" to mark successful bundle
>>transfer, regardless of ACK's in the transport layer ?
>
> Yes, if custody transfer is required.
>
> No, if custody transfer is NOT required, an acknowledgement is not. � However acknowledgements are useful.
>
>>Is there error
>>checking mechanism in the bundle layer independent of transport, link
>>layers ?
>
> Not originally. �The current approach is to use the Security mechanism as error checking, but this means you have to implement the security mechanisms (or at least the portion you need). �Sometimes you don't need error checking for some data, but for custody transfer it is really useful. �There has been LOTS of discussion on the list regarding this. �I suggest reading http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-04 as it give some background regarding CRC and the current design decisions to implement a part of the Security piece.
>
>>If that's not the case how's the conclusion made in bundle layer of
>>"A" about success/ failure of bundle transfer?
>>Suppose, there's link failure in the middle of bundle transfer. Does
>>that mean the whole bundle has to be sent from the beginning? Or, does
>>node "B" have temporary storage for new bundle and node "A" just can
>>resume transfer after finding new route?
>
> Sort of an overloaded question. �Some transport protocols like LTP can handle some of this. �Reactive Fragmentation - particularly with security is a problem with, I believe to date, no known solution - particularly if there is a reroute between fragments.
>
>
>
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 10 Jul 2009 14:31:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Meeting invitation: DTN Disconnectathon - Planning Teleconference

I setup a teleconference and webex meeting for DTN Disconnectaton - Planning Teleconference

Tuesday, July 14
14:00 UTC  (10:00 EDT)  I think this is 4:00 for most of Europe

I suspect this will mainly be a teleconference, but I setup a Webex in case we want to use it.  

I think we can get done in an hour if we are well organized in advance.

Goal - Determine what we want out of the Disconnectathon and how to accomplish that

In preparation, those wishing to participate in the disconnectathon, if you could send you primary Goals to the list, that would be useful.  I can compile them and we can go through those first.

For example do you want to test a particular routing protocol, applications, network management functions, etcetera?

DRAFT AGENDA (open for suggestions)
======================================
Primary Interoperability Tests 
 - Ohio Univ and GRC
    ** TCP CL between IP and DTN2 (requires ION update and DTN2 patch)
    ** OU has a "socket-type" API that allows the same applications to run over ION and DTN2

Testing Times
 - With DTNbone machines, some of this testing could be continuous.

Network configurations (other than point-to-point)
 - OU and GRC would like to see some multi-hop, intermittent connectivity, and limited bandwidth links
   ** should these be static route or routing protocols.
   ** One will quickly see that without some type of route (name) aggregation, a multi-hop chain is pretty nasty to configure. 
 - Are there some routing protocols that could be tested for interoperability or just plain tested?

Post configurations on DTNRG wiki in real-time
 - NASA did this on an internal wiki for multi-center testing and it helped.

Thoughts on using unsecure dynamic DNS on DTNbone and nsupdate to update names to addresses (or we could create a shared key and do DNSSEC, but probably overkill for this testing.)
 - may allow laptops to come and go and simply run nsupdate to DTNbone DNS server to update address database
 - beginnings of late binding
 - forces some thought on naming as - for this system - names may have to be relative to some pre-configured domains (even if they are dummy domains). 
   This may be necessary in order to update the dns server
 - force some thought on when to try and re-resolve a name (because it change between the time you wanted to communicate and the time it reconnected to the network.
 - enables multiple physical addresses for a DTN entity unless you subtract old address when adding new.
 - forces thought on how to develop DNS name resolvers and handle late bindings

Test Plan generation 
 - Assign responsibilities to various individuals to create a test plan/procedure for each goal
   ** Include equipment, network topology, applications.

/Will

******************************

From: William Ivancic [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 2:53 PM
To: Ivancic, William D. (GRC-RHN0)
Subject: (Forward to attendees) Meeting invitation: DTN Disconnectaton

**** You can forward this email invitation to attendees **** 

Hello , 

William Ivancic invites you to attend this online meeting. 

Topic: DTN Disconnectaton 
Date: Tuesday, July 14, 2009 
Time: 2:00 pm, Eastern Daylight Time (GMT -04:00, New York) 
Meeting Number: 992 708 018 
Meeting Password: DTN4all* 

Please click the link below to see more information, or to join the meeting. 

------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&PW=c9a9442018057e272d5512
 
2. Enter your name and email address. 
3. Enter the meeting password: DTN4all* 
4. Click "Join Now". 

------------------------------------------------------- 
To join the teleconference only 
------------------------------------------------------- 

Toll�Outside�US�1-517-600-5252� 
Toll�Free�US�Only�866-783-5733� 
pass�code��1095920 

------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://nasa.webex.com/nasa/mc 
2. On the left navigation bar, click "Support". 

You can contact me at: 
[email-masked] 
1-216-4333494 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://nasa.webex.com/nasa/j.php?ED=123444722&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=mNl0qJihMyGXOedMiHD1X816dXkQgLvPhDPxo6xE28I= 

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://nasa.webex.com/nasa/systemdiagnosis.php 

Sign up for a free trial of WebEx 
http://www.webex.com/go/mcemfreetrial 

http://www.webex.com 
We've got to start meeting like this(TM) 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. 

Date: Fri, 10 Jul 2009 14:02:33 -0400
From: Victor lyamtsev <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Bundle Security Protocol follow up questions

I think the real question was "is it possible to configure BSP options
in dtnd config files", like specific ciphersuite selection.

On Fri, Jul 10, 2009 at 1:38 PM, Ivancic, William D.
(GRC-RHN0)<[email-masked]> wrote:
>>-----Original Message-----
>>From: [email-masked] [mailto:dtn-
>>[email-masked]] On Behalf Of
>>[email-masked]
>>Sent: Friday, July 10, 2009 11:34 AM
>>To: [email-masked]
>>Subject: [dtn-interest] Bundle Sucurity Protocol folloup questions
>>
>>Thanks for the replies.
>>
>>But again I encounterd some more questions,as follows:
>>
>>The decision whether or not to check is determined by the node's policy
>>
>>1. So, where�s the node policy is defined? In .conf file? How�s the
>>particular ciphersuite is selected?
>
>
> I don't know if any of the currently openly available code have gotten that far. �Perhaps BBN Spindle III has it.
>
> If you look at a Router, it is in the configurations. �Likewise, think of IP in Linux and you find security policy in a number of places. �IP-Tables is firewall policy. �If you run IPsec Tools and SETKEY can create a configuration file there or just run command line. �If you download some of the IKEv2 implementations like Strongswan, they have Policy configuration files. �Fun stuff!
>
> http://linux.die.net/man/8/setkey
>
> http://www.strongswan.org/uml/testresults43/ikev2/net2net-route/
> here, the ipsec.conf files have the security policy
>
>
> /Will
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Peter Lovell <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 10 Jul 2009 13:39:22 -0400
Subject: Re: [dtn-interest] Bundle Sucurity Protocol folloup questions

>>The DTN2 Reference Implementation contains generic BSP support and
>>implementations of BA1, PI2 and PC3 ciphersuites.
>
>5. What is not supported in generic support?

The "generic" part is support for the plug-in ciphersuites. The
"specific" part is the implementation for three of them.

Regards.....Peter

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 10 Jul 2009 12:38:20 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Bundle Security Protocol follow up questions

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of
>[email-masked]
>Sent: Friday, July 10, 2009 11:34 AM
>To: [email-masked]
>Subject: [dtn-interest] Bundle Sucurity Protocol folloup questions
>
>Thanks for the replies.
>
>But again I encounterd some more questions,as follows:
>
>The decision whether or not to check is determined by the node's policy
>
>1. So, where’s the node policy is defined? In .conf file? How’s the
>particular ciphersuite is selected?

I don't know if any of the currently openly available code have gotten that far.  Perhaps BBN Spindle III has it.

If you look at a Router, it is in the configurations.  Likewise, think of IP in Linux and you find security policy in a number of places.  IP-Tables is firewall policy.  If you run IPsec Tools and SETKEY can create a configuration file there or just run command line.  If you download some of the IKEv2 implementations like Strongswan, they have Policy configuration files.  Fun stuff!

http://linux.die.net/man/8/setkey

http://www.strongswan.org/uml/testresults43/ikev2/net2net-route/
here, the ipsec.conf files have the security policy

/Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, Peter Lovell <[email-masked]>
Date: Fri, 10 Jul 2009 12:18:20 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Bundle Security Protocol

Lloyd, I don't think we should read to much into Peter's use of "policy" here.  I read this as good practice - something that is wise to do.

Regarding the use of the term "policy" in security, I have started using to terms:

"Rules of Engagement" to mean "How is one permitted to operate".

I try to leave the term  "policy" to apply to things like the security policy database in IP.

There is sort of an implied equivalent in DTN and it seems to have appeared in the later Bundle Security Specification and currently reside in 
"3.1. Nodes as policy enforcement points"

For example, the "Rules of Engagement" may say Platoon A can communicate with Platoon B.

And the "policy" is the detailed implementation:

Network A bidirectional with Network B using IPsec tunnel mode key 5 SPI 1234 Algorithm Z

For DTN a "Rule of Engagement" might be to only accept store or pass traffic from organizations A and C because they are the only ones who have service agreements with us.

Policy is:

PID not validated to originate from organization A or C, Drop silently

Or 
 
PID not validated to originate from organization A or C, Drop and send administrative message "No Indentified Service Agreement"

/Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Lloyd Wood
>Sent: Friday, July 10, 2009 12:40 PM
>To: Peter Lovell
>Cc: [email-masked]; [email-masked];
>Lloyd Wood
>Subject: Re: [dtn-interest] Re(2): Bundle Security Protocol
>
>
>On 9 Jul 2009, at 20:42, Peter Lovell wrote:
>>> or is it performed for the whole bundle at the custody transfer
>>> stage?
>>
>> BP and BSP do not *require* an integrity check upon custody
>> transfer, as
>> some members have commented. That would be good policy, though.
>
>It's not really a security policy question. Putting a reliability-only
>ciphersuite check around an encrypted payload and then checking that
>the bundle is correct before accepting custody is an engineering/
>performance/efficient network utilization matter that does not have
>security implications and does not affect policy.
>
>(or were you using the word 'policy' casually in a non-security
>context? For shame; this has been first and foremost a security list.)
>Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems,'
>IEEE Aerospace Conference, Big Sky, Montana, March 2009.
>DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
><http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Lloyd Wood <[email-masked]>
To: Peter Lovell <[email-masked]>
Date: Fri, 10 Jul 2009 17:39:41 +0100
Cc: [email-masked], [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Re(2):  Bundle Security Protocol

On 9 Jul 2009, at 20:42, Peter Lovell wrote:
>> or is it performed for the whole bundle at the custody transfer  
>> stage?
>
> BP and BSP do not *require* an integrity check upon custody  
> transfer, as
> some members have commented. That would be good policy, though.

It's not really a security policy question. Putting a reliability-only  
ciphersuite check around an encrypted payload and then checking that  
the bundle is correct before accepting custody is an engineering/ 
performance/efficient network utilization matter that does not have  
security implications and does not affect policy.

(or were you using the word 'policy' casually in a non-security  
context? For shame; this has been first and foremost a security list.)
Lloyd Wood, Wesley M. Eddy and Peter Holliday, 'A Bundle of Problems,'  
IEEE Aerospace Conference, Big Sky, Montana, March 2009.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

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

Date: Fri, 10 Jul 2009 15:34:00 +0000
From: [email-masked]
To: [email-masked]
Subject: [dtn-interest] Bundle Sucurity Protocol folloup questions

Thanks for the replies.

But again I encounterd some more questions,as follows:

The decision whether or not to check is determined by the node's policy

1. So, where’s the node policy is defined? In .conf file? How’s the particular ciphersuite is selected?

BP and BSP do not *require* an integrity check upon custody transfer, as some members have commented. That would be good policy, though.

2. Again, where would be the place to define that policy?

3. Is there some standard test scenario for data integrity check?

We tried to introduce data corruption % for transmission node with ‘tc netem’ and compared the received file on receiver node vs. original.

4. Is that sufficient?

The DTN2 Reference Implementation contains generic BSP support and
implementations of BA1, PI2 and PC3 ciphersuites.

5 .What is not supported in generic support?

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Joerg Ott <[email-masked]>, Andrew Sullivan <[email-masked]>
Date: Thu, 9 Jul 2009 15:57:53 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Disconnectathon Planning Teleconference Update

Disconnectathon Planning Teleconference Update

I spoke with Hans Kruse regarding an agenda.  I will put that together tomorrow and send it out.

The teleconference will be Tuesday, July 14 at 14:00 - 15:00 UTC.

I'll send call in number and perhaps Webex information tomorrow.

Think about what your primary goal is that you wish to accomplish.  

Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Peter Lovell <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 9 Jul 2009 15:48:24 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Re(2):  Bundle Security Protocol

>>3.Does the BSP have any place for the FEC codes, or is the
>>retransmission is the only correction method?
>
>FEC is not part of any of the defined ciphersuites. As an implementor,
>you can certainly create a suite that offers FEC capability and
>incorporate that into the BSP overall structure.

Hmmm. It seems to me that FEC would be wrapped around and contain the BSP the all Payload and such.  I think FEC, if implemented would be done as bundle-in-bundle.  You might even do bundle-in-bundle followed by proactive fragmenting followed by FEC.  Perhaps the FEC would be another extension block.

Regardless, I think FEC is independent of BSP with the exception that if one is applying FEC it must be done in a manner that does not break BSP.

/Will

From: Peter Lovell <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 09 Jul 2009 15:42:26 -0400
Subject: [dtn-interest] Re(2):  Bundle Security Protocol

On Thu, Jul 9, 2009, [email-masked] <[email-masked]> wrote:

>Hi,
>Can anybody help me in the following doubts:

Sure.

>1. Does the PIB is generated for the bundle, or for the bundle
>transmission fragment?

PIB is generated for the bundle, subject to the specific rules for the
ciphersuite. For the PI2 ciphersuite, it's the whole bundle as described
in "mutable canonicalization".

>2. The bundle is usually transmitted in few different fragments.

I wouldn't say "usually", but the bundle can be fragmented and the
pieces sent separately.

>Is the process of error checking performed for the every fragment,

For BundleAuthentication (BA) ciphersuites, the checking is always
performed since these are hop-by-hop. Since it's one hop, a bundle is a
bundle is a bundle and there are no fragments.

For PayloadIntergrity (PI) suites, checking is governed by policy.
Remember that a fragmented bundle becomes several new, separate bundles.
Each of the new bundles is independent so a checksum for the original,
full bundle can't be checked if that has been fragmented. A checksum
calculated for the new, smaller fragment-bundle can be checked if the
appropriate keys are available. For PI2 ciphersuite, this would be an
RSA public key so it might be well-known.

The decision whether or not to check is determined by the node's policy.

>or is it performed for the whole bundle at the custody transfer stage?

BP and BSP do not *require* an integrity check upon custody transfer, as
some members have commented. That would be good policy, though.

>3.Does the BSP have any place for the FEC codes, or is the
>retransmission is the only correction method?

FEC is not part of any of the defined ciphersuites. As an implementor,
you can certainly create a suite that offers FEC capability and
incorporate that into the BSP overall structure.

>4. What is the mechanism for BSP to request bundle/ fragment
>retransmission (if errors detected) from bundle protocol agent?

BSP itself does not request retransmission. Various implementations
might make that decision in different ways and I'm not sure what
mechanisms are in used now.

>5. Are there any existing implementations for BSP, or is it only at the
>draft stage?

The DTN2 Reference Implementation contains generic BSP support and
implementations of BA1, PI2 and PC3 ciphersuites.

Regards.....Peter

Date: Thu, 09 Jul 2009 22:20:07 +0300
From: Joerg Ott <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Disconnectathon plans

I'd prefer next week.

Joerg

Andrew Sullivan wrote:
> On Wed, Jul 08, 2009 at 12:45:01PM -0400, Daniel Ellard wrote:
>> Thanks, that sounds like a great idea.
>>
>> Are people available this week or early next week?
> 
> I'm not available this week, alas, but early next week I am.
> 
> A
> 

Date: Thu, 9 Jul 2009 19:01:23 +0000
From: [email-masked]
To: [email-masked]
Subject: Re: [dtn-interest] Bundle Security Protocol

Hi,
Can anybody help me in the following doubts:

1. Does the PIB is generated for the bundle, or for the bundle transmission fragment?

2. The bundle is usually transmitted in few different fragments. Is the process of error checking performed for the every fragment, or is it performed for the whole bundle at the custody transfer stage?

3.Does the BSP have any place for the FEC codes, or is the retransmission is the only correction method?

4. What is the mechanism for BSP to request bundle/ fragment retransmission (if errors detected) from bundle protocol agent?

5. Are there any existing implementations for BSP, or is it only at the draft stage?  

Thank you.

Date: Thu, 9 Jul 2009 19:00:21 +0000
From: [email-masked]
To: [email-masked]
Subject: Re: [dtn-interest] Bundle Security Protocol

Hi,
Can anybody help me in the following doubts:

1. Does the PIB is generated for the bundle, or for the bundle transmission fragment?

2. The bundle is usually transmitted in few different fragments. Is the process of error checking performed for the every fragment, or is it performed for the whole bundle at the custody transfer stage?

3.Does the BSP have any place for the FEC codes, or is the retransmission is the only correction method?

4. What is the mechanism for BSP to request bundle/ fragment retransmission (if errors detected) from bundle protocol agent?

5. Are there any existing implementations for BSP, or is it only at the draft stage?  

Thank you.

Date: Thu, 9 Jul 2009 14:41:37 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Disconnectathon plans

On Wed, Jul 08, 2009 at 12:45:01PM -0400, Daniel Ellard wrote:
> Thanks, that sounds like a great idea.
> 
> Are people available this week or early next week?

I'm not available this week, alas, but early next week I am.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From: Hans Kruse <[email-masked]>
To: Teemu <[email-masked]>
Date: Thu, 9 Jul 2009 11:43:25 -0400
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

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

I am available 1400 UTC tomorrow and all of next week.

On Jul 9, 2009, at 7:29 AM, Teemu wrote:

> Hi,
>
> I am available and 14:00 UTC sounds good. I would like to finalize  
> the exact
> dates soon so I can book my travel, as I will not be attending IETF  
> and
> would like to minimize my days out of office.
>
> Cheers,
> -Teemu
>
>
> On 8.7.2009 19.45, "Daniel Ellard" <[email-masked]> wrote:
>
>> Thanks, that sounds like a great idea.
>>
>> Are people available this week or early next week?
>>
>> -Dan
>>
>>
>> Ivancic, William D. (GRC-RHN0) wrote:
>>> Dan,
>>>
>>> I think we (the participants) need to take some time and do some  
>>> real
>>> planning if we want to get much out of this.  We really need a  
>>> test plan and
>>> procedures to get much out of this.
>>>
>>> I can setup a teleconference and webex.  The only issue there is the
>>> telephone number will be a toll call from outside US.
>>>
>>> A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe.  I  
>>> think that
>>> would work for a large group, but put Asian countries in the  
>>> middle of the
>>> night.
>>>
>>> It would be good to know any machine names, addresses and  
>>> convergence layers
>>> that we can beforehand.  The DTNbone machines have that  
>>> information.  We need
>>> it for BBN and the other test systems.
>>> http://www.dtnrg.org/wiki/DtnBone
>>>
>>> If we have most of the information, we can perhaps create a host  
>>> file once we
>>> know the actual addresses of machines at IETF that can be used by  
>>> all.
>>>
>>>
>>> Will
>>>
>>>
>>>
>>>
>>>
>>>
>>> ******************************
>>>
>>>> -----Original Message-----
>>>> From: [email-masked]  
>>>> [mailto:dtn-
>>>> [email-masked]] On Behalf Of Daniel
>>>> Ellard
>>>> Sent: Monday, July 06, 2009 2:13 PM
>>>> To: [email-masked]
>>>> Subject: [dtn-interest] Disconnectathon plans
>>>>
>>>>
>>>> Based on the responses that I received to my last message, I
>>>> am planning to cancel the BBN on-site portion of the
>>>> Disconectathon, and focus all energies on the Stockholm-site
>>>> and remote portions.  (only one person outside of BBN
>>>> expressed current interest in attending at BBN rather than
>>>> either Stockholm or remotely)
>>>>
>>>> Based on the schedule posted for the IETF WG meetings, it
>>>> looks like we should plan to set things up Wednesday morning
>>>> and then do testing and interaction Wednesday afternoon and
>>>> Thursday.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>> -Dan
>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Ellard, Ph.D.
>>>> Senior Scientist, Network Research
>>>> BBN Technologies
>>>> 10 Moulton Street
>>>> Cambridge, MA 02138
>>>> [email-masked]
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/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-411549479
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I am available 1400 UTC =
tomorrow and all of next week.<div><br><div><div>On Jul 9, 2009, at 7:29 =
AM, Teemu wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Hi,<br><br>I am available and 14:00 UTC sounds good. =
I would like to finalize the exact<br>dates soon so I can book my =
travel, as I will not be attending IETF and<br>would like to minimize my =
days out of office.<br><br>Cheers,<br>-Teemu<br><br><br>On 8.7.2009 =
19.45, "Daniel Ellard" &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">Thanks, that sounds like a great =
idea.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Are people =
available this week or early next week?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-Dan<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Ivancic, =
William D. (GRC-RHN0) wrote:<br></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Dan,<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I think we (the participants) =
need to take some time and do some =
real<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">planning if we want to get much out of this. &nbsp;We =
really need a test plan and<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">procedures to get much out of =
this.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">I can setup a teleconference and =
webex. &nbsp;The only issue there is =
the<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">telephone number will be a toll call from outside =
US.<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">A 14:00 UTC is 10:00am Eastern =
US and 3:00 or 4:00pm Europe. &nbsp;I think =
that<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">would work for a large group, but put Asian countries in =
the middle of the<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">night. =
&nbsp;<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">It would be good to know any =
machine names, addresses and convergence =
layers<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">that we can beforehand. &nbsp;The DTNbone machines have =
that information. &nbsp;We need<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">it for BBN and the other test =
systems.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"http://www.dtnrg.org/wiki/DtnBone">http://www.dtnrg.org/wiki/DtnBo=
ne</a><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">If we have most of the =
information, we can perhaps create a host file once =
we<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">know the actual addresses of machines at IETF that can be =
used by all.<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">Will<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">******************************<br></blockquote></blockquote>=
<blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-----Original =
Message-----<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">From: =
[email-masked] [<a =
href=3D"mailto:dtn-">mailto:dtn-</a><br></blockquote></blockquote></blockq=
uote><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"mailto:[email-masked]">interest-bou=
[email-masked]</a>] On Behalf Of =
Daniel<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Ellard<br></blockquote></blockquote></blockquote><blockquote=
 type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Sent: =
Monday, July 06, 2009 2:13 =
PM<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Subject:=
 [dtn-interest] Disconnectathon =
plans<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Based =
on the responses that I received to my last message, =
I<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">am =
planning to cancel the BBN on-site portion of =
the<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Disconectathon, and focus all energies on the =
Stockholm-site<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">and =
remote portions. &nbsp;(only one person outside of =
BBN<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">expressed current interest in attending at BBN rather =
than<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">either =
Stockholm or =
remotely)<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Based =
on the schedule posted for the IETF WG meetings, =
it<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">looks =
like we should plan to set things up Wednesday =
morning<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">and =
then do testing and interaction Wednesday afternoon =
and<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Thursday.<br></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Thoughts?<br></blockquote></blockquote></blockquote><blockqu=
ote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Thanks,<br></blockquote></blockquote></blockquote><blockquot=
e type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">-Dan<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">--<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Daniel =
Ellard, Ph.D.<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">Senior =
Scientist, Network =
Research<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">BBN =
Technologies<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">10 =
Moulton Street<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite">Cambridge, MA =
02138<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br></blockquote></bloc=
kquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><br><br>___________________________________=
____________<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-2-411549479--

Date: Thu, 09 Jul 2009 14:29:20 +0300
From: Teemu <[email-masked]>
To: Daniel Ellard <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

Hi,

I am available and 14:00 UTC sounds good. I would like to finalize the exact
dates soon so I can book my travel, as I will not be attending IETF and
would like to minimize my days out of office.

Cheers,
-Teemu

On 8.7.2009 19.45, "Daniel Ellard" <[email-masked]> wrote:

> Thanks, that sounds like a great idea.
> 
> Are people available this week or early next week?
> 
> -Dan
> 
> 
> Ivancic, William D. (GRC-RHN0) wrote:
>> Dan,
>> 
>> I think we (the participants) need to take some time and do some real
>> planning if we want to get much out of this.  We really need a test plan and
>> procedures to get much out of this.
>> 
>> I can setup a teleconference and webex.  The only issue there is the
>> telephone number will be a toll call from outside US.
>> 
>> A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe.  I think that
>> would work for a large group, but put Asian countries in the middle of the
>> night.  
>> 
>> It would be good to know any machine names, addresses and convergence layers
>> that we can beforehand.  The DTNbone machines have that information.  We need
>> it for BBN and the other test systems.
>> http://www.dtnrg.org/wiki/DtnBone
>> 
>> If we have most of the information, we can perhaps create a host file once we
>> know the actual addresses of machines at IETF that can be used by all.
>> 
>> 
>> Will
>> 
>> 
>> 
>> 
>> 
>> 
>> ******************************
>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Daniel
>>> Ellard
>>> Sent: Monday, July 06, 2009 2:13 PM
>>> To: [email-masked]
>>> Subject: [dtn-interest] Disconnectathon plans
>>> 
>>> 
>>> Based on the responses that I received to my last message, I
>>> am planning to cancel the BBN on-site portion of the
>>> Disconectathon, and focus all energies on the Stockholm-site
>>> and remote portions.  (only one person outside of BBN
>>> expressed current interest in attending at BBN rather than
>>> either Stockholm or remotely)
>>> 
>>> Based on the schedule posted for the IETF WG meetings, it
>>> looks like we should plan to set things up Wednesday morning
>>> and then do testing and interaction Wednesday afternoon and
>>> Thursday.
>>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> -Dan
>>> 
>>> 
>>> 
>>> --
>>> Daniel Ellard, Ph.D.
>>> Senior Scientist, Network Research
>>> BBN Technologies
>>> 10 Moulton Street
>>> Cambridge, MA 02138
>>> [email-masked]
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Hans Kruse <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 8 Jul 2009 14:42:02 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

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

Before I forget -- I checked on the IETF jabber rooms, and they are  
indeed available year-round 24/7.  So outside the actual dtnrg  
meeting, the dtnrg jabber room would be a convenient real-time channel  
for participants to interact with each other.

On Jul 8, 2009, at 11:59 AM, Ivancic, William D. (GRC-RHN0) wrote:

> Dan,
>
> I think we (the participants) need to take some time and do some  
> real planning if we want to get much out of this.  We really need a  
> test plan and procedures to get much out of this.
>
> I can setup a teleconference and webex.  The only issue there is the  
> telephone number will be a toll call from outside US.
>
> A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe.  I  
> think that would work for a large group, but put Asian countries in  
> the middle of the night.
>
> It would be good to know any machine names, addresses and  
> convergence layers that we can beforehand.  The DTNbone machines  
> have that information.  We need it for BBN and the other test systems.
> http://www.dtnrg.org/wiki/DtnBone
>
> If we have most of the information, we can perhaps create a host  
> file once we know the actual addresses of machines at IETF that can  
> be used by all.
>
>
> Will
>
>
>
>
>
>
> ******************************
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Daniel
>> Ellard
>> Sent: Monday, July 06, 2009 2:13 PM
>> To: [email-masked]
>> Subject: [dtn-interest] Disconnectathon plans
>>
>>
>> Based on the responses that I received to my last message, I
>> am planning to cancel the BBN on-site portion of the
>> Disconectathon, and focus all energies on the Stockholm-site
>> and remote portions.  (only one person outside of BBN
>> expressed current interest in attending at BBN rather than
>> either Stockholm or remotely)
>>
>> Based on the schedule posted for the IETF WG meetings, it
>> looks like we should plan to set things up Wednesday morning
>> and then do testing and interaction Wednesday afternoon and
>> Thursday.
>>
>> Thoughts?
>>
>> Thanks,
>> 	-Dan
>>
>>
>>
>> --
>> Daniel Ellard, Ph.D.
>> Senior Scientist, Network Research
>> BBN Technologies
>> 10 Moulton Street
>> Cambridge, MA 02138
>> [email-masked]
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/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-335866852
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Before I forget -- I checked on =
the IETF jabber rooms, and they are indeed available year-round 24/7. =
&nbsp;So outside the actual dtnrg meeting, the dtnrg jabber room would =
be a convenient real-time channel for participants to interact with each =
other.<div><br><div><div>On Jul 8, 2009, at 11:59 AM, Ivancic, William =
D. (GRC-RHN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Dan,<br><br>I think we (the participants) need to =
take some time and do some real planning if we want to get much out of =
this. &nbsp;We really need a test plan and procedures to get much out of =
this.<br><br>I can setup a teleconference and webex. &nbsp;The only =
issue there is the telephone number will be a toll call from outside =
US.<br><br>A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe. =
&nbsp;I think that would work for a large group, but put Asian countries =
in the middle of the night. &nbsp;<br><br>It would be good to know any =
machine names, addresses and convergence layers that we can beforehand. =
&nbsp;The DTNbone machines have that information. &nbsp;We need it for =
BBN and the other test systems. &nbsp;<br><a =
href=3D"http://www.dtnrg.org/wiki/DtnBone">http://www.dtnrg.org/wiki/DtnBo=
ne</a><br><br>If we have most of the information, we can perhaps create =
a host file once we know the actual addresses of machines at IETF that =
can be used by =
all.<br><br><br>Will<br><br><br><br><br><br><br>**************************=
****<br><br><blockquote type=3D"cite">-----Original =
Message-----<br></blockquote><blockquote type=3D"cite">From: =
[email-masked] =
[mailto:dtn-<br></blockquote><blockquote =
type=3D"cite">[email-masked]] On Behalf =
Of Daniel<br></blockquote><blockquote =
type=3D"cite">Ellard<br></blockquote><blockquote type=3D"cite">Sent: =
Monday, July 06, 2009 2:13 PM<br></blockquote><blockquote =
type=3D"cite">To: =
[email-masked]<br></blockquote><blockquote =
type=3D"cite">Subject: [dtn-interest] Disconnectathon =
plans<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Based on the =
responses that I received to my last message, =
I<br></blockquote><blockquote type=3D"cite">am planning to cancel the =
BBN on-site portion of the<br></blockquote><blockquote =
type=3D"cite">Disconectathon, and focus all energies on the =
Stockholm-site<br></blockquote><blockquote type=3D"cite">and remote =
portions. &nbsp;(only one person outside of =
BBN<br></blockquote><blockquote type=3D"cite">expressed current interest =
in attending at BBN rather than<br></blockquote><blockquote =
type=3D"cite">either Stockholm or remotely)<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Based on the =
schedule posted for the IETF WG meetings, it<br></blockquote><blockquote =
type=3D"cite">looks like we should plan to set things up Wednesday =
morning<br></blockquote><blockquote type=3D"cite">and then do testing =
and interaction Wednesday afternoon and<br></blockquote><blockquote =
type=3D"cite">Thursday.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Thoughts?<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">Thanks,<br></blockquote><blockquote type=3D"cite"><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>-Dan<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">--<br></blockquote><blockquote type=3D"cite">Daniel =
Ellard, Ph.D.<br></blockquote><blockquote type=3D"cite">Senior =
Scientist, Network Research<br></blockquote><blockquote type=3D"cite">BBN =
Technologies<br></blockquote><blockquote type=3D"cite">10 Moulton =
Street<br></blockquote><blockquote type=3D"cite">Cambridge, MA =
02138<br></blockquote><blockquote =
type=3D"cite">[email-masked]<br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote =
type=3D"cite">[email-masked]<br></blockquote><b=
lockquote =
type=3D"cite">http://maillists.intel-research.net/mailman/listinfo/dtn-int=
erest<br></blockquote><br>_______________________________________________<=
br>dtn-interest mailing =
list<br>[email-masked]<br>http://maillists.inte=
l-research.net/mailman/listinfo/dtn-interest<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-2-335866852--

Date: Wed, 08 Jul 2009 12:45:01 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

Thanks, that sounds like a great idea.

Are people available this week or early next week?

-Dan

Ivancic, William D. (GRC-RHN0) wrote:
> Dan,
> 
> I think we (the participants) need to take some time and do some real planning if we want to get much out of this.  We really need a test plan and procedures to get much out of this.
> 
> I can setup a teleconference and webex.  The only issue there is the telephone number will be a toll call from outside US.
> 
> A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe.  I think that would work for a large group, but put Asian countries in the middle of the night.  
> 
> It would be good to know any machine names, addresses and convergence layers that we can beforehand.  The DTNbone machines have that information.  We need it for BBN and the other test systems.  
> http://www.dtnrg.org/wiki/DtnBone
> 
> If we have most of the information, we can perhaps create a host file once we know the actual addresses of machines at IETF that can be used by all.
> 
> 
> Will
> 
> 
> 
> 
> 
> 
> ******************************
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Daniel
>> Ellard
>> Sent: Monday, July 06, 2009 2:13 PM
>> To: [email-masked]
>> Subject: [dtn-interest] Disconnectathon plans
>>
>>
>> Based on the responses that I received to my last message, I
>> am planning to cancel the BBN on-site portion of the
>> Disconectathon, and focus all energies on the Stockholm-site
>> and remote portions.  (only one person outside of BBN
>> expressed current interest in attending at BBN rather than
>> either Stockholm or remotely)
>>
>> Based on the schedule posted for the IETF WG meetings, it
>> looks like we should plan to set things up Wednesday morning
>> and then do testing and interaction Wednesday afternoon and
>> Thursday.
>>
>> Thoughts?
>>
>> Thanks,
>> 	-Dan
>>
>>
>>
>> --
>> Daniel Ellard, Ph.D.
>> Senior Scientist, Network Research
>> BBN Technologies
>> 10 Moulton Street
>> Cambridge, MA 02138
>> [email-masked]
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Daniel Ellard <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 8 Jul 2009 10:59:16 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Disconnectathon plans

Dan,

I think we (the participants) need to take some time and do some real planning if we want to get much out of this.  We really need a test plan and procedures to get much out of this.

I can setup a teleconference and webex.  The only issue there is the telephone number will be a toll call from outside US.

A 14:00 UTC is 10:00am Eastern US and 3:00 or 4:00pm Europe.  I think that would work for a large group, but put Asian countries in the middle of the night.  

It would be good to know any machine names, addresses and convergence layers that we can beforehand.  The DTNbone machines have that information.  We need it for BBN and the other test systems.  
http://www.dtnrg.org/wiki/DtnBone

If we have most of the information, we can perhaps create a host file once we know the actual addresses of machines at IETF that can be used by all.

Will

******************************

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Daniel
>Ellard
>Sent: Monday, July 06, 2009 2:13 PM
>To: [email-masked]
>Subject: [dtn-interest] Disconnectathon plans
>
>
>Based on the responses that I received to my last message, I
>am planning to cancel the BBN on-site portion of the
>Disconectathon, and focus all energies on the Stockholm-site
>and remote portions.  (only one person outside of BBN
>expressed current interest in attending at BBN rather than
>either Stockholm or remotely)
>
>Based on the schedule posted for the IETF WG meetings, it
>looks like we should plan to set things up Wednesday morning
>and then do testing and interaction Wednesday afternoon and
>Thursday.
>
>Thoughts?
>
>Thanks,
>	-Dan
>
>
>
>--
>Daniel Ellard, Ph.D.
>Senior Scientist, Network Research
>BBN Technologies
>10 Moulton Street
>Cambridge, MA 02138
>[email-masked]
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Jamey Hicks <[email-masked]>
To: "ext Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 8 Jul 2009 09:28:03 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] link simulation tools

If you want to simulate IP links with different characteristics, you  
can use Linux Advanced Routing and Traffic Control, described at http://lartc.org/ 
  -- this is a standard capability in the Linux kernel, including the  
ability to add latency to links via the netem queuing discipline and  
to throttle bandwidth with the TBF token bucket filter. I do not know  
if it has a facility for adding burst errors, though.

Jamey

On Jul 8, 2009, at 8:48 AM, ext Ivancic, William D. (GRC-RHN0) wrote:

> Do you want to simulate that or emulate the link?  It sounds like  
> you have two DTN2 physical or virtual nodes, not software models.   
> It appears you want to emulate a link with reduced bandwidth, delay,  
> and perhaps bit errors.  If that is the case, dummynet and other  
> tools are available.  NASA has a channel emulator.
>
> Note, this software is currently not available to everyone, but is  
> available to many many people.  Other similar emulation is available  
> elsewhere.
>
> http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator
>
>
> Will
>
> ******************************
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Victor
>> lyamtsev
>> Sent: Wednesday, July 08, 2009 8:21 AM
>> To: [email-masked]
>> Subject: [dtn-interest] link simulation tools
>>
>> Hi All,
>>
>> We need to test file transfer between DTN2 nodes  over the unreliable
>> link with limited bandwidth and higher rate of burst errors. I wonder
>> what we could use to simulate properties of such link... Does anybody
>> used dtn2 tools with Ns2 to run the scenarios like that? Other sim
>> tools, specifically for DTN? Any pointers to tutorials, howtos, etc
>> would be also great.
>>
>> Thank you,
>>
>> -V
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Victor lyamtsev <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 8 Jul 2009 07:48:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] link simulation tools

Do you want to simulate that or emulate the link?  It sounds like you have two DTN2 physical or virtual nodes, not software models.  It appears you want to emulate a link with reduced bandwidth, delay, and perhaps bit errors.  If that is the case, dummynet and other tools are available.  NASA has a channel emulator.

Note, this software is currently not available to everyone, but is available to many many people.  Other similar emulation is available elsewhere.

http://channel-emulator.grc.nasa.gov/wiki/index.php?ChannelEmulator

Will

******************************
>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Victor
>lyamtsev
>Sent: Wednesday, July 08, 2009 8:21 AM
>To: [email-masked]
>Subject: [dtn-interest] link simulation tools
>
>Hi All,
>
>We need to test file transfer between DTN2 nodes  over the unreliable
>link with limited bandwidth and higher rate of burst errors. I wonder
>what we could use to simulate properties of such link... Does anybody
>used dtn2 tools with Ns2 to run the scenarios like that? Other sim
>tools, specifically for DTN? Any pointers to tutorials, howtos, etc
>would be also great.
>
>Thank you,
>
>-V
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 8 Jul 2009 08:20:31 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] link simulation tools

Hi All,

We need to test file transfer between DTN2 nodes  over the unreliable
link with limited bandwidth and higher rate of burst errors. I wonder
what we could use to simulate properties of such link... Does anybody
used dtn2 tools with Ns2 to run the scenarios like that? Other sim
tools, specifically for DTN? Any pointers to tutorials, howtos, etc
would be also great.

Thank you,

-V

Date: Tue, 7 Jul 2009 17:22:02 +0000
From: [email-masked]
To: [email-masked]
Subject: Re: [dtn-interest] Simulator

Hi,<br /><br />I have following doubts:<br />1. Which will be the better way to simulate/emulate DTN on a bandwidth constraint link. Is it DTN simulator or NS?<br />2. If its DTN, can anybody me the guidelines about how to use the DTN simulator?<br /> <br />Thanks.

Date: Tue, 7 Jul 2009 18:16:49 +0200
From: Anders Lindgren <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] DTN I-Ds in last call

Hi,

Similarly to what Susan said a while back, we also have a draft
(PRoPHET) in last call, and have not received any comments on it so
far.

It can be found at:
http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-02

If anyone have read the draft recently or is willing to have another
look at it before the Stockholm meeting, comments would be
appreciated, either via mail or in person (I will be at the Stockholm
meeting, at least for the meeting on Friday, but if I'm in town, I
might be around earlier in the week as well).

/Anders

On Thu, Jun 4, 2009 at 5:50 PM, Symington, Susan F. <[email-masked]> wrote:
> Folks,
>
>
>
> In response to comments that I received at our last DTNRG meeting in March,
> I revised three drafts that are in last call:
>
>
>
> draft-irtf-dtnrg-bundle-metadata-block-03 [draft]
>
> draft-irtf-dtnrg-bundle-previous-hop-block-06 [draft]
>
> draft-irtf-dtnrg-bundle-retrans-block-05 [draft]
>
>
>
> The only comments I�ve received were from Scott and Wesley regarding
> terminology that has to be cleaned up in the Previous Hop Block draft, which
> I am happy to do. This is not controversial.
>
>
>
> Does anyone else have any comments on these drafts? Now that they have been
> revised per the directions I received at the March meeting, are they to your
> liking?� Two months have passed since I posted the revised drafts. Is your
> silence to be interpreted as consent?
>
>
>
> If these docs are okay with you, then saying so would be helpful for the
> rest of us to know.
>
>
>
> Thanks.
>
>
>
> -susan
>
>
>
> *****************************************************************
>
> Susan Symington
>
> The MITRE Corporation
>
> [email-masked]
>
> 703-983-7209 (voice)
>
> 703-983-7142 (fax)
>
> ******************************************************************
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: David Young <[email-masked]>
Date: Tue, 7 Jul 2009 08:38:29 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTN URI scheme - expired

Thanks,

Yes, I was reading the creation date.  My mistake.

Thanks

Will

>-----Original Message-----
>From: David Young [mailto:[email-masked]]
>Sent: Tuesday, July 07, 2009 9:19 AM
>To: Ivancic, William D. (GRC-RHN0)
>Subject: Re: [dtn-interest] DTN URI scheme - expired
>
>Will,
>
>Forgive me for my confusion, but the document itself says "Expires:
>September 29, 2009."
>I thought drafts last 6 months, and I believe this document was put
>together in March during the google event.
>
>On Tue, Jul 7, 2009 at 8:22 AM, Ivancic, William D.
>(GRC-RHN0)<[email-masked]> wrote:
>> The following document has expired. �Just curious, will it be updated?
>>
>> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-dtn-uri-scheme-
>00.txt
>>
>>
>> Will
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>
>
>
>--
>David Young

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 7 Jul 2009 07:22:07 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTN URI scheme - expired

The following document has expired.  Just curious, will it be updated?

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-dtn-uri-scheme-00.txt

Will

From: Peter Lovell <[email-masked]>
To: dtn interest <[email-masked]>
Date: Tue, 07 Jul 2009 07:17:46 -0400
Subject: [dtn-interest] DTN at ISS

DTN in the news, from the space station ...

<http://www.theregister.co.uk/2009/07/07/dtn_node/>

<http://www.nasa.gov/mission_pages/station/science/experiments/DTN.html>

Date: Mon, 06 Jul 2009 15:31:52 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Hans Kruse <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

Hans Kruse wrote:
> As far as sites -- that makes sense.    Could you clarify your intent as
> far as times?   Stockholm is at GMT+2, the US east cost at GMT-4.   So
> the US afternoons are not too useful unless the Stockholm crowd is game
> for very late nights?

To clarify: the times are "local" to Stockholm.

A lot of the people traveling to Stockholm are going to be
coming from the west, so they might already consider the
local morning to be very, very early.  I suspect we'll split
the difference: folks stateside will be getting up early on
those days, and folks in Stockholm might be working a little
bit late.

> 
> Also, I have agreed to set up pages in the dtnrg wiki to support the
> test, e.g. supply a place to post IP addresses, config files, routes, etc.

Splendid,
	-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: Hans Kruse <[email-masked]>
To: Daniel Ellard <[email-masked]>
Date: Mon, 6 Jul 2009 14:39:03 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Disconnectathon plans

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

As far as sites -- that makes sense.    Could you clarify your intent  
as far as times?   Stockholm is at GMT+2, the US east cost at GMT-4.    
So the US afternoons are not too useful unless the Stockholm crowd is  
game for very late nights?

On the technical side, we are hoping to test some applications built  
with a socket-type API that allows the same app to work over both ION  
and DTN2.  We'll send out more information on that soon.  Also, the  
next release of ION should be available by that time, allowing better  
routing support between and ION and DTN2, as well as TCP between ION  
and DTN2;  however, for that to work, DTN2 users will need a patch we  
committed into the DTN2 Mercurial source repository.

Also, I have agreed to set up pages in the dtnrg wiki to support the  
test, e.g. supply a place to post IP addresses, config files, routes,  
etc.

On Jul 6, 2009, at 2:12 PM, Daniel Ellard wrote:

>
> Based on the responses that I received to my last message, I
> am planning to cancel the BBN on-site portion of the
> Disconectathon, and focus all energies on the Stockholm-site
> and remote portions.  (only one person outside of BBN
> expressed current interest in attending at BBN rather than
> either Stockholm or remotely)
>
> Based on the schedule posted for the IETF WG meetings, it
> looks like we should plan to set things up Wednesday morning
> and then do testing and interaction Wednesday afternoon and
> Thursday.
>
> Thoughts?
>
> Thanks,
> 	-Dan
>
>
>
> -- 
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/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-5-162887168
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">As far as sites -- that makes =
sense. &nbsp; &nbsp;Could you clarify your intent as far as times? =
&nbsp; Stockholm is at GMT+2, the US east cost at GMT-4. &nbsp; So the =
US afternoons are not too useful unless the Stockholm crowd is game for =
very late nights?<div><br></div><div>On the technical side, we are =
hoping to test some applications built with a socket-type API that =
allows the same app to work over both ION and DTN2. &nbsp;We'll send out =
more information on that soon. &nbsp;Also, the next release of ION =
should be available by that time, allowing better routing support =
between and ION and DTN2, as well as TCP between ION and DTN2; =
&nbsp;however, for that to work, DTN2 users will need a patch we =
committed into the DTN2 Mercurial source =
repository.</div><div><br></div><div>Also, I have agreed to set up pages =
in the dtnrg wiki to support the test, e.g. supply a place to post IP =
addresses, config files, routes, etc.</div><div><br><div><div>On Jul 6, =
2009, at 2:12 PM, Daniel Ellard wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br>Based on the responses that I received to my last =
message, I<br>am planning to cancel the BBN on-site portion of =
the<br>Disconectathon, and focus all energies on the =
Stockholm-site<br>and remote portions. &nbsp;(only one person outside of =
BBN<br>expressed current interest in attending at BBN rather =
than<br>either Stockholm or remotely)<br><br>Based on the schedule =
posted for the IETF WG meetings, it<br>looks like we should plan to set =
things up Wednesday morning<br>and then do testing and interaction =
Wednesday afternoon =
and<br>Thursday.<br><br>Thoughts?<br><br>Thanks,<br><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>-Dan<br><br><br><br>-- <br>Daniel Ellard, Ph.D.<br>Senior =
Scientist, Network Research<br>BBN Technologies<br>10 Moulton =
Street<br>Cambridge, MA 02138<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>___________________=
____________________________<br>dtn-interest mailing =
list<br>[email-masked]<br>http://maillists.inte=
l-research.net/mailman/listinfo/dtn-interest<br></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; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><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></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-5-162887168--

Date: Mon, 06 Jul 2009 14:12:43 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Disconnectathon plans

Based on the responses that I received to my last message, I
am planning to cancel the BBN on-site portion of the
Disconectathon, and focus all energies on the Stockholm-site
and remote portions.  (only one person outside of BBN
expressed current interest in attending at BBN rather than
either Stockholm or remotely)

Based on the schedule posted for the IETF WG meetings, it
looks like we should plan to set things up Wednesday morning
and then do testing and interaction Wednesday afternoon and
Thursday.

Thoughts?

Thanks,
	-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Mon, 06 Jul 2009 11:43:11 +0100
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Stockholm Meeting Topics

Thanks Will,

I'll send out a draft agenda tomorrow. If anyone else wants
a slot please mail Kevin and I.

Cheers,
Stephen.

Ivancic, William D. (GRC-RHN0) wrote:
> Assuming my travel gets approved, I can take a few minutes to discuss the DTN Network Management Requirements Draft
> 
> I could also discuss briefly NASA's internal multi-center network configuration and current test to date.
> 
> Regardless, I think we should discuss the need for a common API for DTN-2, ION and whatever else comes along (Spindle-3, etc...) so we can write common applications like dtn-ping, dtn-traceroute, dth-perf, etcetera.
> 
> Naming and Binding (early, late, partial, complete) - continued discussions on this (not just the syntax, but actual concepts of operations and how this stuff would really be deployed and work).
> Of course, a great start for such discussions is:
> http://tools.ietf.org/html/draft-pbasu-dtnrg-naming-00
> 
> 
> /Will
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Fri, 03 Jul 2009 18:01:09 +0100
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Bundle Authentication

Hi Will,

(Been travelling, hence the slooow response)

Ivancic, William D. (GRC-RHN0) wrote:
> I'm taking yet another look at the DTN security specification and I have the following question.
> 
> The bundle authentication block is for hop-by-hop authentication.  The specification indicates that "The BAB ciphersuite is based on shared secrets using HMAC."  And later indicates "The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]."
> 
> So this requires that a shared secret get distributed somehow to those two bundle agents.  

Right. There is an as-yet unmet need for key management.

>
One would hope this shared secret is only between two unique systems if
one wants to identify the previous hop source, otherwise, what good is it.

That depends. There could be group keying scenarios that'd make sense,
e.g. if all the BAB verifier wanted to know was that the bundle came
from one of a number of previous hops. Typically however, one would
expect unique keys per pair.

> 
>  *  Is the reason for using a symmetric key for processing?

I guess symmetric crypto is quicker, but given that its hop by
hop, its also usually easier to setup shared secrets rather than
require a full blown PKI.

>  *  Is the thought process here more along the lines of IPsec session keys negotiated via IKE or IKEv2?  (I would think negotiation of session keys in a disconnected network is extremely DTN network specific where it might work if you know disconnection is more of the form of disruption for short periods of time.)

As I said, DTN key mgmt isn't done, so we don't know how best to do
that. But in the meantime I'm sure there are lots of environments where
they can successfully setup BAB keys.

> 
> Also, one is  likely to be using asymmetric keys to wrap symmetric keys for key distribution.  If so, why not have the ability to authenticate using asymmetric keys such as is done with email?  It seems to me that his should be a viable option for hop-by-hop authentication for many instances and may simply the amount of keying material that has to be managed.  

One might be using D-H key agreement rather than key transport. There's
nothing to stop someone defining a ciphersuite for an asymmetric BAB
equivalent of course, we just didn't see the immediate need.
> 
> On the other hand, I think operationally one may not care what the previous hop source unique identity is.  Rather, I would like to know if the bundle originate from a trusted community - in which case I may decide to believe the routing protocols or simply be willing to store and forward bundles from various communities, but not from others.  Or course, this is sort of a naming and aggregation issue - (how does one aggregate naming?).  Anyway, it seems like one may find the Bundle Integrity Block more useful than the Bundle Authentication Block even to validate routing.  It may be easier to manage with something more along the lines of a shared group keys.  
> 
> 
> These thought come from contemplating how one might manage the following space scenario.  Lunar rover is US owned as is the Operations Center for the Lunar Rover.  The rover communicates to a relay satellite owned by India and India dumps the transmission through a Japanese ground station.  It seems like one may have an easier time validating certificates via some multi-organizational cross validation agreement than distributing shared secret keys. 

Right. That's why the default PIB is asymmetric and is what you'd
want in that scenario.

Stephen.

> 
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Fri, 03 Jul 2009 09:12:25 +0300
From: Joerg Ott <[email-masked]>
To: Sushil Chaudhari <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Reg: DTN daemons

(this is rather a question for the dtn-users list)

I suppose you mena on the same machine?

Make the path names for directories relative and
run the daemons from different directories.

Joerg

Sushil Chaudhari wrote:
> Hi,
> 
>  
> 
> Can anybody tell me how is it possible to run two daemons by using same 
> configuration file.
> 
>  
> 
> Thanks.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Sushil Chaudhari" <[email-masked]>
To: <[email-masked]>
Date: Thu, 2 Jul 2009 17:23:47 -0400
Subject: [dtn-interest] Reg: DTN daemons

This is a multipart message in MIME format.

------=_NextPart_000_0001_01C9FB39.DBD3AC80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

Can anybody tell me how is it possible to run two daemons by using same
configuration file.

Thanks.

------=_NextPart_000_0001_01C9FB39.DBD3AC80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Hi,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Can anybody tell me how is it possible to run two =
daemons by
using same configuration file.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks.<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C9FB39.DBD3AC80--