Subject: Re: [dtn-interest] what about connectivity in DTN
From: Lloyd Wood <[email-masked]>
To: xlwujunying <[email-masked]>
Cc: dtn-interest <[email-masked]>, Lloyd Wood <[email-masked]>
Date: Thu, 31 Dec 2009 10:36:52 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

On 31 Dec 2009, at 09:30, xlwujunying wrote:

> how can we measur connectivity in DTN,

You can try graphing range of individual link or path delay (y) vs range of persistence of links or paths (x).

Bottom right is core of the Internet - very reliable, long persistence, short delay.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/

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

Date: Thu, 31 Dec 2009 10:54:21 +0100
From: Xiaoming Fu <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IWQoS 2010 Call for Papers

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<pre wrap="">Apologies if you receive multiple copies.<strong><span
 style="font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"></span></strong> 
</pre>
<p class="MsoNormal"><b><span
 style="font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"><span
 class="headline1">--------------------------------------------------------------------------------------------------------</span><br>
<span class="headline1">18th IEEE International Workshop on Quality of
Service (IWQoS
2010)<br>
</span></span></b><b><span
 style="font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"><span
 class="headline1">--------------------------------------------------------------------------------------------------------</span></span></b><br>
<span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);">June
16-18, 2010, Tsinghua University, Beijing, China<br>
</span><a href="http://www.ieee-iwqos.org/2010/cfp.html"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(204, 51, 0);">http://www.ieee-iwqos.org/2010/cfp.html</span></a><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);">
<br>
<br>
Improving quality of service ( QoS ) in both networks and end systems
has been
a long lasting research focus worldwide. The seventeen-year-long
success of
IWQoS has established it as a highly reputable forum to present novel
ideas on
all research subjects related to QoS. While QoS research for future
generations
of wired and wireless networks continues to captivate much interest,
recent
exploration of data centers, virtualization, cloud computing,
industrial
communication, and &#8220;green&#8221; computing has motivated a new wave of
research
interest in QoS and its related metrics such as Quality of Experience
(QoE) and
Quality of Protection (QoP) . The scope of IWQoS 2010 covers both
theoretical
and experimental research on QoS related issues such as survivability,
availability, reliability, security, privacy, pricing, resource
provisioning
and management, user experience, and system performance guarantees.
Topics of
interest include QoS issues in (but not limited to) the following areas:<o:p></o:p></span></p>
<ul type="disc">
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Data
centers, virtualization and cloud computing <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Energy
saving in networks and end systems; IT technologies to reduce energy
consumption in applications <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Protection,
experience, security and privacy <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">System
dependability, availability; resilience and robustness to faults and
DoS attacks <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Scheduling,
resource management, queue management, admission control; traffic
engineering approaches and tools for provisioning and evaluation <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Quality
evaluation metrics and methodologies; application-aware QoS parsing,
identification and control <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Measurement,
evaluation, adaptation and verification <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Network
operations, pricing and billing, network and service management <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Architectures
and protocols for IP and WDM networks, overlay and peer-to-peer
networks; wireless ad hoc, mesh, and sensor networks <o:p></o:p></span></li>
  <li class="MsoNormal"
 style="color: rgb(79, 65, 70); text-align: left;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Design for
the future Internet<o:p></o:p></span></li>
</ul>
<p><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);">Paper
Submission Guidelines: IWQoS invites submission of manuscripts with
original
research results that have not been previously published or that are
not
currently under review by another conference or journal. Submissions
will be
judged based on originality, significance, interest, clarity,
relevance, and
correctness. Paper submissions should be no longer than 9
single-spaced,
double-column pages with font-size of 10. Papers must be submitted
electronically as PDF files through the EDAS system
(<a class="moz-txt-link-freetext" href="http://edas.info/N8541">http://edas.info/N8541</a>).
All submitted papers will be subject to peer reviews by Technical
Program
Committee members and other experts in the field. IWQoS aims at rapid
dissemination of research results. For fast turnaround in the review
process, a
short review and publication cycle is designed, with the submission
deadline as
close to the workshop as the publisher allows.<o:p></o:p></span></p>
<p><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);">The
proceedings will be published in IEEE Xplore and EI indexed.&nbsp; However,
IEEE reserves the right to exclude a paper from distribution after the
conference (e.g., removal from IEEE Xplore) if the paper is not
presented at
the conference.<br>
&nbsp;<o:p></o:p></span></p>
<p class="MsoNormal"><strong><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);">IMPORTANT
DATES</span></strong><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"><br>
---------------------------<br>
Paper submission deadline: <strong><span
 style="font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Feb.
8, 2010</span></strong><br>
Notification of accept: April 5, 2010<br>
Camera-ready papers: April 23, 2010 <br>
<br>
<strong><span style="font-family: &quot;Arial&quot;,&quot;sans-serif&quot;;">Technical
Program
Committee</span></strong><br>
-------------------------------------------<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent: 0pt;"><span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"><o:p></o:p>Abhishek
Chandra, University of Minnesota, USA<br>
Amund Kvalbein, Simula Research Laboratory, Norway<br>
Baochun Li, University of Toronto, Canada<br>
Burkhard Stiller, University of Zurich, Switzerland<br>
Byrav Ramamurthy, University of Nebraska-Lincoln, USA<br>
Cheng-Zhong Xu, Wayne State University, USA<br>
Carlos Calafate, Technical University of Valencia, Spain<br>
Gang Feng, University of Electronic Science and Technology of China,
China<br>
David Yau, Purdue University, USA<br>
Dan Marinescu, University of Central Florida, USA<br>
Edmundo Monteiro, University of Coimbra, Portugal<br>
Georgios Karagiannis, University of Twente, The Netherlands<br>
Haining Wang, College of William and Mary, USA<br>
Himabindu Pucha, IBM ARC, USA<br>
Iordanis Koutsopoulos, UTH, Greece<br>
Jiangchuan Liu, Simon Fraser University, Canada<br>
Joel Rodrigues IT, University of Beira Interior, Portugal<br>
John Chi Shing Lui, The Chinese University of Hong Kong, Hong Kong<br>
Martin Reisslein, Arizona State University, USA<br>
Matthew Caesar, University of Illinois at Urbana-Champaign, USA<br>
Narasimha Reddy, Texas A &amp; M University, USA<br>
Oliver Hohlfeld, TU Berlin, Germany<br>
Pascal Lorenz, University of Haute Alsace, France<br>
Patrick Pak-Ching Lee, The Chinese University of Hong Kong, Hong Kong<br>
Qun Li, College
of William and Mary, USA<br>
Rade Stanojevic, Telefonica Research, Spain<br>
Sridhar Machiraju, Google, USA<br>
Srihari Nelakuditi, University of South Carolina, USA<br>
Steve Uhlig, TU Berlin/T-labs, Germany<br>
Torsten Braun, University of Bern, Switzerland<br>
Vasilios Siris, ICS-FORTH / Athens University of Economics and
Business, Greece<br>
Weiyi Zhang, North Dakota State University, USA<br>
Xiuzhen Cheng, George Washington Univ., USA<br>
Xue Liu, McGill University, Canada<br>
Yan Chen, Northwestern University, USA<o:p></o:p></span></p>
<span
 style="font-size: 9pt; font-family: &quot;Arial&quot;,&quot;sans-serif&quot;; color: rgb(79, 65, 70);"><o:p></o:p></span>--
<br>
<pre class="moz-signature" cols="72">Xiaoming Fu, <a
 class="moz-txt-link-freetext"
 href="http://user.informatik.uni-goettingen.de/%7Efu">http://user.informatik.uni-goettingen.de/~fu</a></pre>
</body>
</html>

Date: Thu, 31 Dec 2009 17:30:27 +0800 (CST)
From: xlwujunying <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] what about connectivity in DTN

------=_Part_86403_6067457.1262251827036
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: base64

SGkgYWxsIQpob3cgY2FuIHdlIG1lYXN1ciBjb25uZWN0aXZpdHkgaW4gRFROLG9yIHRoZXJlIGlz
IG5vIGNvbm5lY3Rpdml0eSBhdCBhbGw/CmhvdyB0byBkZWZpbmUgdGhpczogIEkgY2FuIHNlbmQg
YW55IG1lc3NhZ2UgYmV0d2VlbiBhbnkgdHdvIG5vZGVzIGluIGEgZGVmaW5lZCB0aW1lIGluIERU
Ti4gCklzIHRoaXMgbmV0d29yayBjb25uZWN0ZWQ/Ci0tCgrO4r7806oKMTg5MTE1Njc4ODkKCgo=
------=_Part_86403_6067457.1262251827036
Content-Type: text/html; charset=gbk
Content-Transfer-Encoding: base64

PERJVj5IaSBhbGwhPC9ESVY+CjxESVY+aG93IGNhbiB3ZSBtZWFzdXIgY29ubmVjdGl2aXR5IGlu
IERUTixvciB0aGVyZSBpcyBubyBjb25uZWN0aXZpdHkgYXQgYWxsPzwvRElWPgo8RElWPmhvdyB0
byBkZWZpbmUgdGhpczombmJzcDsgSSBjYW4gc2VuZCBhbnkgbWVzc2FnZSBiZXR3ZWVuIGFueSB0
d28gbm9kZXMgaW4gYSBkZWZpbmVkIHRpbWUgaW4gRFROLiA8L0RJVj4KPERJVj5JcyB0aGlzIG5l
dHdvcmsgY29ubmVjdGVkPzxCUj4tLTxCUj48L0RJVj4KPERJVj4KPERJVj7O4r7806o8L0RJVj4K
PERJVj4xODkxMTU2Nzg4OTwvRElWPjwvRElWPjxCUj48QlI+PFNQQU4gdGl0bGU9Im5ldGVhc2Vm
b290ZXIiPjwvU1BBTj48YnI+PGJyPjxzcGFuIHRpdGxlPSJuZXRlYXNlZm9vdGVyIi8+PC9zcGFu
Pg==
------=_Part_86403_6067457.1262251827036--

Date: Wed, 30 Dec 2009 17:10:07 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>, DTN <[email-masked]>
Subject: [dtn-interest] LTP CL

Hi Scott,

Just noticed you've published draft-burleigh-dtnrg-ltpcl-00, which
is good.

I'll probably have more comments later, but this part of the spec
just seems wrong:

   The requirement that green segment service data be self-identifying
   to the client service -- in this case, the Bundle Protocol -- implies
   that the service data of each green segment must be a single complete
   bundle, even if possibly a BP "fragment."

Firstly, where's that "self-identifying" requirement come from? I
don't recall it in the LTP RFCs. (But I didn't look, maybe its there.)

Secondly that requires the BP agent to know the segment sizing used
within the LTP CL (to use green segments). I don't think any other CL
has a similar requirement does it? Perhaps just limiting this to one
bundle per LTP session (or all-red or all-green) would be better and
a good bit simpler?

S.

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Tue, 22 Dec 2009 11:57:58 -0500
Subject: Re: [dtn-interest] DTNRG slot at IETF 77

On Tue, Dec 22, 2009, Stephen Farrell <[email-masked]> wrote:

>Folks,
>
>IETF 77 [1] is in Anaheim next March and scheduling has
>started. (Registration is also open.)
>
>We're planning to request a slot for DTNRG. We'll do
>agenda stuff etc closer to the time.
>
>Regards,
>Stephen.

I will have to miss this one, unfortunately, as my daughter's wedding is
that week.

Cheers.....Peter

Date: Tue, 22 Dec 2009 16:49:49 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] DTNRG slot at IETF 77

Folks,

IETF 77 [1] is in Anaheim next March and scheduling has
started. (Registration is also open.)

We're planning to request a slot for DTNRG. We'll do
agenda stuff etc closer to the time.

Regards,
Stephen.

[1] http://www.ietf.org/meeting/77/index.html

From: Kevin Fall <[email-masked]>
Date: Fri, 18 Dec 2009 23:31:11 -0800
To: Lloyd Wood <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Hiroshima DTNRG minutes

fixed.
- K

On Dec 18, 2009, at Dec 18 10:40 AMPST, Lloyd Wood wrote:

> All the links to presentations cited in the minutes are broken.
> 
> You've uploaded ppt, which get sort-of-converted to html (on a Mac, with attendant Mac files and directory structure) a random time after they're uploaded.
> 
> If you'd uploaded pdf, the links given in the minutes would still be valid, and no conversion effort need be expended. Or, if you'd left off the .ppt filename extension, http content negotiation would have avoided breakage, since the core filename is unchanged after munging (though there are still a few extra clicks to get through the Mac-induced directory layout).
> 
> See the presentations at
> http://www.ietf.org/proceedings/09nov/slides/DTNRG-0/
> http://www.ietf.org/proceedings/09nov/slides/DTNRG-1/
> http://www.ietf.org/proceedings/09nov/slides/DTNRG-2/
> http://www.ietf.org/proceedings/09nov/slides/DTNRG-3/
> http://www.ietf.org/proceedings/09nov/slides/DTNRG-4/
> 
> 
> On 18 Dec 2009, at 14:10, Stephen Farrell wrote:
> 
>> 
>> Hi all,
>> 
>> I finally got around to getting the minutes [1] from Hiroshima done.
>> Thanks to Elwyn Davies and Peter Lovell for taking notes and to
>> Peter St. Andre for jabber scribing.
>> 
>> If there are any changes/additions needed let me and/or the list
>> know before Jan 6 please.
>> 
>> Thanks,
>> Stephen.
>> 
>> [1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html
>> 
>> 
>> _______________________________________________
>> 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/dtn/
> 
> <http://info.ee.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]>
Date: Fri, 18 Dec 2009 18:40:42 +0000
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Hiroshima DTNRG minutes

All the links to presentations cited in the minutes are broken.

You've uploaded ppt, which get sort-of-converted to html (on a Mac, with attendant Mac files and directory structure) a random time after they're uploaded.

If you'd uploaded pdf, the links given in the minutes would still be valid, and no conversion effort need be expended. Or, if you'd left off the .ppt filename extension, http content negotiation would have avoided breakage, since the core filename is unchanged after munging (though there are still a few extra clicks to get through the Mac-induced directory layout).

See the presentations at
http://www.ietf.org/proceedings/09nov/slides/DTNRG-0/
http://www.ietf.org/proceedings/09nov/slides/DTNRG-1/
http://www.ietf.org/proceedings/09nov/slides/DTNRG-2/
http://www.ietf.org/proceedings/09nov/slides/DTNRG-3/
http://www.ietf.org/proceedings/09nov/slides/DTNRG-4/

On 18 Dec 2009, at 14:10, Stephen Farrell wrote:

> 
> Hi all,
> 
> I finally got around to getting the minutes [1] from Hiroshima done.
> Thanks to Elwyn Davies and Peter Lovell for taking notes and to
> Peter St. Andre for jabber scribing.
> 
> If there are any changes/additions needed let me and/or the list
> know before Jan 6 please.
> 
> Thanks,
> Stephen.
> 
> [1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html
> 
> 
> _______________________________________________
> 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/dtn/

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

Date: Fri, 18 Dec 2009 14:10:23 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Hiroshima DTNRG minutes

Hi all,

I finally got around to getting the minutes [1] from Hiroshima done.
Thanks to Elwyn Davies and Peter Lovell for taking notes and to
Peter St. Andre for jabber scribing.

If there are any changes/additions needed let me and/or the list
know before Jan 6 please.

Thanks,
Stephen.

[1] http://www.ietf.org/proceedings/09nov/minutes/DTNRG.html

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 10 Dec 2009 22:09:56 -0800
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] fragmentation fields in administrative records
Reply-To: [email-masked]

My query was only concerned with gaining a better understanding of
administrative records. Specifically with establishing whether a bundle
with bit 1 set indicating the bundle's ADU is an administrative record
explicitly meant that the administrative record ADU must be contained in
the payload block, establishing the distinction between an
administrative record ADU and payload that is an administrative record
ADU, whether the only application of fragment fields in an
administrative record was when and administrative record was requested
for each fragment bundle of a bundle and whether the administrative
record depicted in RFC 5050 which depicts fragmentation fields (Fragment
offset & Fragment length) was correct. All of which you have answered.

In the context of my query when I said "primary block of an
administrative record", I am aware of my error. What I had meant and
what I should have said properly was "primary block of a bundle with a
payload that is an administrative record". By saying "bundle that is an
administrative record" in this context I meant "bundle with a payload
that is an administrative record" and am aware of this error too. Had I
known the answers to my questions (and i probably should have) prior to
asking them I would have phrased them properly. My references to RFC
5050 were only intended to provide context to my query in which by
'indicates' I meant 'suggests to me' and not intended to be taken to
claim or to state to be true that RFC 5050 says an administrative record
ADU has a primary block, says an administrative record is a bundle, or
say anything other. I have said previously on this thread "There is
nothing in 5050 (that I know of) that states that an administrative
record is a bundle". 

Thanks,

Alex

On Thu, 2009-12-10 at 15:57 -0800, Burleigh, Scott C (313B) wrote:
> > -----Original Message-----
> > From: Alex McMahon [mailto:[email-masked]] On Behalf Of Alex McMahon
> > Sent: Thursday, December 10, 2009 2:38 PM
> > To: Burleigh, Scott C (313B)
> > Cc: DTN
> > Subject: Re: [dtn-interest] fragmentation fields in administrative records
> > 
> > 
> > On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote:
> > > Alex McMahon wrote:
> > > > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
> > > > 5050 depicts an administrative record that includes the fragmentation
> > > > fields (Fragment offset & Fragment length).
> > > Correct.
> > > > However, as RFC 5050 also
> > > > indicates that the processing control flag of the primary block of an
> > > > administrative record is set to indicate the ADU is an administrative
> > > > record.
> > > Actually I'm pretty sure it never says this anywhere.
> > It says at the start of 4.2. that bit 1 characterizes the bundle as
> > "Application data unit is an administrative record".
> Right, bit 1 of the processing control flags in the primary block OF A BUNDLE has exactly this significance.  But "the processing control flag of the primary block of an administrative record" is meaningless, because an administrative record has no primary block, because it is not a bundle.  RFC 5050 does not say, anywhere, what you claim it says.
> > >  I think it says
> > > that bit 1 of the bundle processing control flags in the primary block
> > > of a bundle that contains an administrative record is set to indicate
> > > that the bundle's ADU is an administrative record.
> > 
> > Although it does say 'Bundle's ADU is an administrative record' in the
> > later text it does not (that i am aware of) say 'bundle that contains an
> > administrative record'.
> 
> That particular phrase happens not to have been required anywhere in the RFC, but step 2 of 6.2 certainly makes the relationship clear.  Do a text search on "administrative record" in RFC 5050; if you can find any text that says an administrative record is a bundle rather than an ADU that may form the payload of a bundle, please point it out.
> > These would seem to have different meanings.
> > 'Bundle's ADU "is" an administrative record' could indicate that a
> > payload block of that Bundle "is" an administrative record while 'bundle
> > that contains an administrative record' indicates that a payload block
> > of that bundle must contain an administrative record.
> 
> No, a payload block cannot "be" an administrative record; it's a block, not an ADU.  The payload block has some flags (which are entirely distinct from the bundle processing control flags in the primary block) and it also has some content, an ADU, which we refer to as "the payload of the bundle".  "Bundle's application data unit" and "bundle's payload" are synonymous.  
> 
> > So.. if a bundle has bit 1 set indicating the bundle's ADU is an
> > administrative record, this means that the administrative record ADU
> > must be contained in the payload block....right ?
> 
> Yes.
> 
> > > An administrative record has no primary block. It can't, because it's
> > > not a bundle; it's an application data unit, in standard form, that may
> > > be the payload of a bundle.
> > > > This implies that an administrative record has a primary block
> > > > that includes the fragmentation fields (Fragment offset & Fragment
> > > > length) if fragmented.
> > > No, it doesn't, for the reason explained above. An administrative record
> > > has no primary block (containing fragmentation fields or otherwise),
> > > because it's not a bundle.
> > 
> > > > Is there a scenario in which fragmentation offsets would be included in
> > > > an administrative record ?
> > > Yes: the scenario in which the bundle to which the administrative record
> > > pertains (the one that is partially identified by the admin record's
> > > "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's
> > > Creation Timestamp sequence number", and source endpoint ID; e.g., the
> > > bundle for which custody has been taken) is a fragment.
> > >  In that case, the source endpoint ID and creation timestamp are
> > insufficient to
> > > identify fully the bundle to which the admin record pertains: that
> > > bundle's fragment offset and length are needed as well.
> > 
> > Is the only scenario in which fragmentation offsets would be included in
> > an administrative record, one in which an administrative record is
> > requested for each fragment bundle of a bundle?
> 
> I think it comes to that.  I don't know of any administrative records that would be generated for only a subset of the fragments of a fragmented bundle.
> 
> > As a requested administrative record would already be transmitted for a
> > a set of fragmented bundles upon reassembly it seems like the main
> > reason requesting reports per fragment is for transmission or
> > retransmission of all fragment bundles of that bundle which might not
> > have been received by the destination yet - right?
> 
> I don't think so.  If you're requesting status reports on bundle reception (for example) for a given bundle, then I think fragmentation of that bundle will cause status reports to be individually generated upon reception of each of the fragments at each router along the end-to-end path.
> 
> > Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an
> > administrative record refer to a copy of bundle X's fragments and
> > perhaps Figure 10 and Figure 13 should indicate  'Copy of bundle X's
> > Fragment offset' & 'Copy of bundle X's Fragment length' if this is the
> > case.
> 
> Sure, we could change those labels when we submit the replacement I-D for RFC 5050.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: DTN <[email-masked]>
Date: Thu, 10 Dec 2009 15:57:34 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] fragmentation fields in administrative records

> -----Original Message-----
> From: Alex McMahon [mailto:[email-masked]] On Behalf Of Alex McMahon
> Sent: Thursday, December 10, 2009 2:38 PM
> To: Burleigh, Scott C (313B)
> Cc: DTN
> Subject: Re: [dtn-interest] fragmentation fields in administrative records
> 
> 
> On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote:
> > Alex McMahon wrote:
> > > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
> > > 5050 depicts an administrative record that includes the fragmentation
> > > fields (Fragment offset & Fragment length).
> > Correct.
> > > However, as RFC 5050 also
> > > indicates that the processing control flag of the primary block of an
> > > administrative record is set to indicate the ADU is an administrative
> > > record.
> > Actually I'm pretty sure it never says this anywhere.
> It says at the start of 4.2. that bit 1 characterizes the bundle as
> "Application data unit is an administrative record".

Right, bit 1 of the processing control flags in the primary block OF A BUNDLE has exactly this significance.  But "the processing control flag of the primary block of an administrative record" is meaningless, because an administrative record has no primary block, because it is not a bundle.  RFC 5050 does not say, anywhere, what you claim it says.

> >  I think it says
> > that bit 1 of the bundle processing control flags in the primary block
> > of a bundle that contains an administrative record is set to indicate
> > that the bundle's ADU is an administrative record.
> 
> Although it does say 'Bundle's ADU is an administrative record' in the
> later text it does not (that i am aware of) say 'bundle that contains an
> administrative record'.

That particular phrase happens not to have been required anywhere in the RFC, but step 2 of 6.2 certainly makes the relationship clear.  Do a text search on "administrative record" in RFC 5050; if you can find any text that says an administrative record is a bundle rather than an ADU that may form the payload of a bundle, please point it out.

> These would seem to have different meanings.
> 'Bundle's ADU "is" an administrative record' could indicate that a
> payload block of that Bundle "is" an administrative record while 'bundle
> that contains an administrative record' indicates that a payload block
> of that bundle must contain an administrative record.

No, a payload block cannot "be" an administrative record; it's a block, not an ADU.  The payload block has some flags (which are entirely distinct from the bundle processing control flags in the primary block) and it also has some content, an ADU, which we refer to as "the payload of the bundle".  "Bundle's application data unit" and "bundle's payload" are synonymous.  

> So.. if a bundle has bit 1 set indicating the bundle's ADU is an
> administrative record, this means that the administrative record ADU
> must be contained in the payload block....right ?

Yes.

> > An administrative record has no primary block. It can't, because it's
> > not a bundle; it's an application data unit, in standard form, that may
> > be the payload of a bundle.
> > > This implies that an administrative record has a primary block
> > > that includes the fragmentation fields (Fragment offset & Fragment
> > > length) if fragmented.
> > No, it doesn't, for the reason explained above. An administrative record
> > has no primary block (containing fragmentation fields or otherwise),
> > because it's not a bundle.
> 
> > > Is there a scenario in which fragmentation offsets would be included in
> > > an administrative record ?
> > Yes: the scenario in which the bundle to which the administrative record
> > pertains (the one that is partially identified by the admin record's
> > "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's
> > Creation Timestamp sequence number", and source endpoint ID; e.g., the
> > bundle for which custody has been taken) is a fragment.
> >  In that case, the source endpoint ID and creation timestamp are
> insufficient to
> > identify fully the bundle to which the admin record pertains: that
> > bundle's fragment offset and length are needed as well.
> 
> Is the only scenario in which fragmentation offsets would be included in
> an administrative record, one in which an administrative record is
> requested for each fragment bundle of a bundle?

I think it comes to that.  I don't know of any administrative records that would be generated for only a subset of the fragments of a fragmented bundle.

> As a requested administrative record would already be transmitted for a
> a set of fragmented bundles upon reassembly it seems like the main
> reason requesting reports per fragment is for transmission or
> retransmission of all fragment bundles of that bundle which might not
> have been received by the destination yet - right?

I don't think so.  If you're requesting status reports on bundle reception (for example) for a given bundle, then I think fragmentation of that bundle will cause status reports to be individually generated upon reception of each of the fragments at each router along the end-to-end path.

> Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an
> administrative record refer to a copy of bundle X's fragments and
> perhaps Figure 10 and Figure 13 should indicate  'Copy of bundle X's
> Fragment offset' & 'Copy of bundle X's Fragment length' if this is the
> case.

Sure, we could change those labels when we submit the replacement I-D for RFC 5050.

Scott

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Peter Lovell <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 10 Dec 2009 14:57:44 -0800
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2): fragmentation fields in administrative records
Reply-To: [email-masked]

Thanks Peter

On Thu, 2009-12-10 at 04:55 -0500, Peter Lovell wrote:
> On Wed, Dec 9, 2009, Alex McMahon <[email-masked]> wrote:
> 
> >> Every bundle must have a primary.
> >> If a bundle is fragmented, each
> >> fragment becomes a new bundle ("fragment-bundle") and has a primary
> >> block.
> >Right, every bundle, but what if an administrative record was not a
> >bundle.
> >> So I don't understand your question here.
> >There is nothing in 5050 (that I know of) that states that an
> >administrative record is a bundle, it is only stated that it is a
> >standard ADU that is used in providing some of the features of the
> >Bundle Protocol. Also the example shown in figure 13 depicts an
> >administrative record is not in the Canonical Bundle Block Format.
> >
> >It is stated in 5050 that if a bundle is an administrative record then
> >it will indicate this in the primary block.
> >
> >>From this I gather that while an administrative record can be a bundle,
> >it does not have to be. It could, for example, be an ADU, not
> >transformed by BP into a bundle, that provides only some of the features
> >of the Bundle Protocol and as such might not have a primary block..
> 
> 
> Hi Alex,
> 
> I think we're getting at cross-purposes here. Perhaps I was being too
> brief in my response.
> 
> An admin record is not a bundle, in and of itself. It doesn't have its
> own primary block. But any admin record going between nodes must be
> conveyed in a bundle.
> 
> Section 5.1 says ...
> 
>    When
>    required to "generate" an administrative record (a bundle status
>    report or a custody signal), the bundle protocol agent itself is
>    responsible for causing a new bundle to be transmitted, conveying
>    that record.
> 
> This says (to me, at least) that you can't have an admin record going
> naked on the wire -- it has to be contained in a "bundle" wrapper. So an
> admin record on-the-fly will always have a primary block associated with
> it. After all, primary is the only place that source and destination are
> specified, so it has to be there.
> 
> That said, when it comes off the wire and goes to the BPA, the primary
> might well be gone. That all depends upon how one writes a BPA (and I've
> not thought very hard about that specific issue).
> 
> But the lower levels of the protocol have to tell BPA about the content.
> That is, BPA has to know whether to handle the payload as user-data or
> admin-record, at the very least.
> 
> >Is there a scenario in which fragmentation offsets would be included in
> >an administrative record ?
> 
> Yes. The fragment-offset-and-length fields in an admin record refer to
> original bundle for which this admin record was generated. For example,
> if you're accepting custody and you receive a bundle-fragment, you send
> a custody acknowledgement for the fragment you received. You can't (must
> not) send one for the whole, original bundle because you don't have it.
> So the fragment fields in the admin record refer to the original bundle,
> the fields in your own primary will deal with the case that the admin
> record itself is fragmented (ugh).
> 
> >Also the example shown in figure 13 depicts an
> >administrative record is not in the Canonical Bundle Block Format.
> 
> What that figure shows is the content of the record. The record will be
> the payload of a bundle and will therefore have the payload header (Fig
> 6) prepended when being packaged into a real bundle.
> 
> Cheers.....Peter
> 

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: "Scott C. Burleigh" <[email-masked]>
Organization: Trinity College Dublin
Date: Thu, 10 Dec 2009 14:37:52 -0800
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] fragmentation fields in administrative records
Reply-To: [email-masked]

On Wed, 2009-12-09 at 21:46 -0800, Scott C. Burleigh wrote:
> Alex McMahon wrote:
> > The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
> > 5050 depicts an administrative record that includes the fragmentation
> > fields (Fragment offset & Fragment length).
> Correct.
> > However, as RFC 5050 also
> > indicates that the processing control flag of the primary block of an
> > administrative record is set to indicate the ADU is an administrative
> > record.
> Actually I'm pretty sure it never says this anywhere.
It says at the start of 4.2. that bit 1 characterizes the bundle as
"Application data unit is an administrative record". 

>  I think it says 
> that bit 1 of the bundle processing control flags in the primary block 
> of a bundle that contains an administrative record is set to indicate 
> that the bundle's ADU is an administrative record.

Although it does say 'Bundle's ADU is an administrative record' in the
later text it does not (that i am aware of) say 'bundle that contains an
administrative record'. These would seem to have different meanings.
'Bundle's ADU "is" an administrative record' could indicate that a
payload block of that Bundle "is" an administrative record while 'bundle
that contains an administrative record' indicates that a payload block
of that bundle must contain an administrative record. 

So.. if a bundle has bit 1 set indicating the bundle's ADU is an
administrative record, this means that the administrative record ADU
must be contained in the payload block....right ?
> An administrative record has no primary block. It can't, because it's 
> not a bundle; it's an application data unit, in standard form, that may 
> be the payload of a bundle.
> > This implies that an administrative record has a primary block
> > that includes the fragmentation fields (Fragment offset & Fragment
> > length) if fragmented.   
> No, it doesn't, for the reason explained above. An administrative record 
> has no primary block (containing fragmentation fields or otherwise), 
> because it's not a bundle.

> > Is there a scenario in which fragmentation offsets would be included in
> > an administrative record ?
> Yes: the scenario in which the bundle to which the administrative record 
> pertains (the one that is partially identified by the admin record's 
> "Copy of bundle X's Creation Timestamp time", "Copy of bundle X's 
> Creation Timestamp sequence number", and source endpoint ID; e.g., the 
> bundle for which custody has been taken) is a fragment.
>  In that case, the source endpoint ID and creation timestamp are insufficient to 
> identify fully the bundle to which the admin record pertains: that 
> bundle's fragment offset and length are needed as well.

Is the only scenario in which fragmentation offsets would be included in
an administrative record, one in which an administrative record is
requested for each fragment bundle of a bundle?

As a requested administrative record would already be transmitted for a
a set of fragmented bundles upon reassembly it seems like the main
reason requesting reports per fragment is for transmission or
retransmission of all fragment bundles of that bundle which might not
have been received by the destination yet - right?

Therefore, it seems that the 'Fragment offset' & 'Fragment length' of an
administrative record refer to a copy of bundle X's fragments and
perhaps Figure 10 and Figure 13 should indicate  'Copy of bundle X's
Fragment offset' & 'Copy of bundle X's Fragment length' if this is the
case.         

> > Does this imply that a BPA should be capable of processing an
> > administrative record without a primary block as well as a bundle that
> > is an administrative record ?
> >   
> Almost. A BPA should be capable of processing an administrative record 
> without a primary block, because all administrative records lack primary 
> blocks, because they are not bundles. And a BPA should be capable of 
> processing a bundle that contains an administrative record (because 
> that's the only way it's going to receive an administrative record), but 
> it will never need to process a bundle that is an administrative record 
> because none are.
> 
Thanks,

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

From: Peter Lovell <[email-masked]>
To: [email-masked]
Date: Thu, 10 Dec 2009 04:55:49 -0500
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] Re(2): fragmentation fields in administrative records

On Wed, Dec 9, 2009, Alex McMahon <[email-masked]> wrote:

>> Every bundle must have a primary.
>> If a bundle is fragmented, each
>> fragment becomes a new bundle ("fragment-bundle") and has a primary
>> block.
>Right, every bundle, but what if an administrative record was not a
>bundle.
>> So I don't understand your question here.
>There is nothing in 5050 (that I know of) that states that an
>administrative record is a bundle, it is only stated that it is a
>standard ADU that is used in providing some of the features of the
>Bundle Protocol. Also the example shown in figure 13 depicts an
>administrative record is not in the Canonical Bundle Block Format.
>
>It is stated in 5050 that if a bundle is an administrative record then
>it will indicate this in the primary block.
>
>>From this I gather that while an administrative record can be a bundle,
>it does not have to be. It could, for example, be an ADU, not
>transformed by BP into a bundle, that provides only some of the features
>of the Bundle Protocol and as such might not have a primary block..

Hi Alex,

I think we're getting at cross-purposes here. Perhaps I was being too
brief in my response.

An admin record is not a bundle, in and of itself. It doesn't have its
own primary block. But any admin record going between nodes must be
conveyed in a bundle.

Section 5.1 says ...

   When
   required to "generate" an administrative record (a bundle status
   report or a custody signal), the bundle protocol agent itself is
   responsible for causing a new bundle to be transmitted, conveying
   that record.

This says (to me, at least) that you can't have an admin record going
naked on the wire -- it has to be contained in a "bundle" wrapper. So an
admin record on-the-fly will always have a primary block associated with
it. After all, primary is the only place that source and destination are
specified, so it has to be there.

That said, when it comes off the wire and goes to the BPA, the primary
might well be gone. That all depends upon how one writes a BPA (and I've
not thought very hard about that specific issue).

But the lower levels of the protocol have to tell BPA about the content.
That is, BPA has to know whether to handle the payload as user-data or
admin-record, at the very least.

>Is there a scenario in which fragmentation offsets would be included in
>an administrative record ?

Yes. The fragment-offset-and-length fields in an admin record refer to
original bundle for which this admin record was generated. For example,
if you're accepting custody and you receive a bundle-fragment, you send
a custody acknowledgement for the fragment you received. You can't (must
not) send one for the whole, original bundle because you don't have it.
So the fragment fields in the admin record refer to the original bundle,
the fields in your own primary will deal with the case that the admin
record itself is fragmented (ugh).

>Also the example shown in figure 13 depicts an
>administrative record is not in the Canonical Bundle Block Format.

What that figure shows is the content of the record. The record will be
the payload of a bundle and will therefore have the payload header (Fig
6) prepended when being packaged into a real bundle.

Cheers.....Peter

Date: Wed, 09 Dec 2009 21:46:38 -0800
From: "Scott C. Burleigh" <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] fragmentation fields in administrative records

Alex McMahon wrote:
> The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
> 5050 depicts an administrative record that includes the fragmentation
> fields (Fragment offset & Fragment length).
Correct.
> However, as RFC 5050 also
> indicates that the processing control flag of the primary block of an
> administrative record is set to indicate the ADU is an administrative
> record.
Actually I'm pretty sure it never says this anywhere. I think it says 
that bit 1 of the bundle processing control flags in the primary block 
of a bundle that contains an administrative record is set to indicate 
that the bundle's ADU is an administrative record.

An administrative record has no primary block. It can't, because it's 
not a bundle; it's an application data unit, in standard form, that may 
be the payload of a bundle.
> This implies that an administrative record has a primary block
> that includes the fragmentation fields (Fragment offset & Fragment
> length) if fragmented.
>   
No, it doesn't, for the reason explained above. An administrative record 
has no primary block (containing fragmentation fields or otherwise), 
because it's not a bundle.
> Is there a scenario in which fragmentation offsets would be included in
> an administrative record ?
Yes: the scenario in which the bundle to which the administrative record 
pertains (the one that is partially identified by the admin record's 
"Copy of bundle X's Creation Timestamp time", "Copy of bundle X's 
Creation Timestamp sequence number", and source endpoint ID; e.g., the 
bundle for which custody has been taken) is a fragment. In that case, 
the source endpoint ID and creation timestamp are insufficient to 
identify fully the bundle to which the admin record pertains: that 
bundle's fragment offset and length are needed as well.
> Does this imply that a BPA should be capable of processing an
> administrative record without a primary block as well as a bundle that
> is an administrative record ?
>   
Almost. A BPA should be capable of processing an administrative record 
without a primary block, because all administrative records lack primary 
blocks, because they are not bundles. And a BPA should be capable of 
processing a bundle that contains an administrative record (because 
that's the only way it's going to receive an administrative record), but 
it will never need to process a bundle that is an administrative record 
because none are.

Scott

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Peter Lovell <[email-masked]>
Organization: Trinity College Dublin
Date: Wed, 09 Dec 2009 20:27:12 -0800
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] fragmentation fields in administrative records
Reply-To: [email-masked]

Hi Peter,

>  but I believe that it's there.
I don't think it is (but it might be that I just can't find it), perhaps
the part you are referring to is at the end of 4.2. which indicates the
processing control flags setting if the record is administrative.
However in this paragraph the part which refers to the "Bundle must not
be fragmented" flag relates to when a bundle's source endpoint ID is
"dtn:none" 
> 
> I can't imagine any scenario where fragmentation would make sense for a
> custody signal. 
I agree, however a custody signal is only one type of administrative
record. There might be a need to fragment other type of administrative
records that have not yet been defined.

> So although the field might be depicted, I don't think
> that there's a way for it to actually be used.
I agree, but even if it was fragmented these field would be in the
primary block and not where depicted. The only reason I can see
(assuming there is one) for fragmentation fields to exist as depicted in
both Figure 10 and 13 is if the administrative record does not have a
primary block.. 
> 
> Every bundle must have a primary. 
> If a bundle is fragmented, each
> fragment becomes a new bundle ("fragment-bundle") and has a primary
> block. 
Right, every bundle, but what if an administrative record was not a
bundle.
> So I don't understand your question here.
There is nothing in 5050 (that I know of) that states that an
administrative record is a bundle, it is only stated that it is a
standard ADU that is used in providing some of the features of the
Bundle Protocol. Also the example shown in figure 13 depicts an
administrative record is not in the Canonical Bundle Block Format.

It is stated in 5050 that if a bundle is an administrative record then
it will indicate this in the primary block. 

>From this I gather that while an administrative record can be a bundle,
it does not have to be. It could, for example, be an ADU, not
transformed by BP into a bundle, that provides only some of the features
of the Bundle Protocol and as such might not have a primary block..

Thanks

Alex

On Wed, 2009-12-09 at 20:30 -0500, Peter Lovell wrote:
> On Wed, Dec 9, 2009, Alex McMahon <[email-masked]> wrote:
> 
> >The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
> >5050 depicts an administrative record that includes the fragmentation
> >fields (Fragment offset & Fragment length). However, as RFC 5050 also
> >indicates that the processing control flag of the primary block of an
> >administrative record is set to indicate the ADU is an administrative
> >record.  This implies that an administrative record has a primary block
> >that includes the fragmentation fields (Fragment offset & Fragment
> >length) if fragmented.
> >
> >Is there a scenario in which fragmentation offsets would be included in
> >an administrative record ?
> >
> >Does this imply that a BPA should be capable of processing an
> >administrative record without a primary block as well as a bundle that
> >is an administrative record ?
> >
> >Thanks
> >
> >Alex
> >
> 
> Hi Alex,
> 
> I think that there's a statement somewhere that says that an
> administrative record can't be fragmented. I don't see it right now, but
> I believe that it's there.
> 
> I can't imagine any scenario where fragmentation would make sense for a
> custody signal. So although the field might be depicted, I don't think
> that there's a way for it to actually be used.
> 
> >administrative record without a primary block
> Every bundle must have a primary. If a bundle is fragmented, each
> fragment becomes a new bundle ("fragment-bundle") and has a primary
> block. So I don't understand your question here.
> 
> Cheers.....Peter
> 

From: Peter Lovell <[email-masked]>
To: [email-masked], dtn interest <[email-masked]>
Date: Wed, 09 Dec 2009 20:30:28 -0500
Subject: Re: [dtn-interest] fragmentation fields in administrative records

On Wed, Dec 9, 2009, Alex McMahon <[email-masked]> wrote:

>The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
>5050 depicts an administrative record that includes the fragmentation
>fields (Fragment offset & Fragment length). However, as RFC 5050 also
>indicates that the processing control flag of the primary block of an
>administrative record is set to indicate the ADU is an administrative
>record.  This implies that an administrative record has a primary block
>that includes the fragmentation fields (Fragment offset & Fragment
>length) if fragmented.
>
>Is there a scenario in which fragmentation offsets would be included in
>an administrative record ?
>
>Does this imply that a BPA should be capable of processing an
>administrative record without a primary block as well as a bundle that
>is an administrative record ?
>
>Thanks
>
>Alex
>

Hi Alex,

I think that there's a statement somewhere that says that an
administrative record can't be fragmented. I don't see it right now, but
I believe that it's there.

I can't imagine any scenario where fragmentation would make sense for a
custody signal. So although the field might be depicted, I don't think
that there's a way for it to actually be used.

>administrative record without a primary block
Every bundle must have a primary. If a bundle is fragmented, each
fragment becomes a new bundle ("fragment-bundle") and has a primary
block. So I don't understand your question here.

Cheers.....Peter

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: DTN <[email-masked]>
Organization: Trinity College Dublin
Date: Wed, 09 Dec 2009 16:33:06 -0800
Subject: [dtn-interest] fragmentation fields in administrative records
Reply-To: [email-masked]

The Custody Signal Format depicted in Figure 13, section 6.1.2. of RFC
5050 depicts an administrative record that includes the fragmentation
fields (Fragment offset & Fragment length). However, as RFC 5050 also
indicates that the processing control flag of the primary block of an
administrative record is set to indicate the ADU is an administrative
record.  This implies that an administrative record has a primary block
that includes the fragmentation fields (Fragment offset & Fragment
length) if fragmented.

Is there a scenario in which fragmentation offsets would be included in
an administrative record ? 

Does this imply that a BPA should be capable of processing an
administrative record without a primary block as well as a bundle that
is an administrative record ?

Thanks

Alex

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, DTN <[email-masked]>
Date: Wed, 9 Dec 2009 15:13:01 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Network Synchronization Requirements - some thoughts

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Ivancic,
> William D. (GRC-RHN0)
> Sent: Monday, December 07, 2009 1:32 PM
> To: DTN
> Subject: [dtn-interest] Network Synchronization Requirements - some
> thoughts
> 
> I believe some of the discussion and disagreement on network
> synchronization requirements may be due to the vast environments DTN may be
> applied to.
> 
> Once a system reaches steady state (and how that done is not addressed in
> this email), I believe that the network probably has to be synchronized to
> within some percentage of the shortest bundle lifetime that network will
> have to handle.  Whether that is 1%, 10% or 500% probably depends on the
> network, the amount and length of disconnection and applications.
> 
> Consider operating as the N4C group was in this summer's field exercise.
> If the bundle lifetimes are many hours or days, the network probably only
> requires synchronization to a hour or so (Assuming you will accept bundles
> from the an hour or two into the future).
> 
> Consider military environment where DTN is providing the network layer
> rather than an overlay.  DTN is being used to handle short-term fades and
> disconnection as well as near-real time communications.  In such an
> environment, some bundles may have very short lifetimes - perhaps a few to
> tens of seconds.   If so, the network will have to be synchronized to
> within a some fraction of this.

This is an interesting point.  The intent of the bundle lifetime is to clear undelivered bundles out of the network when they get "stuck" at some node for such a long time that the utility of delivering them to the final destination drops to zero.  Bundles that do get delivered need not be purged.  Bundles that have not yet gotten delivered but still have potential value to their intended recipients should not be purged.  Bundles that are not "stuck" -- that is, they have been transmitted via some convergence-layer protocol (and possibly not received, depending on the reliability of that CL protocol) and are not retained for possible custodial retransmission -- cannot be purged.  There may not be much left, and in fact during DINET we saw only a handful of bundles deleted due to lifetime expiration over a 4-week period.

The only bundles for which the absence of highly accurate clock synchronization might marginally degrade DTN performance (by unnecessary occupation of non-volatile storage) would be those that lose all their value to users and applications in a matter of seconds -- the only reason for a short lifetime -- and are (a) stuck in a transmission queue longer than expected due to a routing failure or (b) transmitted, and important enough to merit custody transfer handling, but not yet acknowledged due to a convergence-layer protocol failure or routing failure.  If your routing and/or CL protocols are flaky enough to make this sort of anomaly commonplace, you've probably got lots bigger fish to fry than sub-optimal non-volatile storage space utilization. 

Scott

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 8 Dec 2009 09:57:05 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Network Synchronization Requirements - some thoughts

I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to.

Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle.  Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications.

Consider operating as the N4C group was in this summer's field exercise.  If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future).

Consider military environment where DTN is providing the network layer rather than an overlay.  DTN is being used to handle short-term fades and disconnection as well as near-real time communications.  In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds.   If so, the network will have to be synchronized to within a some fraction of this.  

Networks with scheduled  connectivity have to have some sort of clock.  Deep Space networks are one such example.  In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions.  

If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle.  However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements.

--Will

From: Kevin Fall <[email-masked]>
Date: Tue, 8 Dec 2009 07:50:46 -0800
To: DTN Interest List <[email-masked]>
Subject: [dtn-interest] test e-mail -- please ignore

we have been having some mailing list server issues...

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 8 Dec 2009 09:36:29 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Test Message

This is a test message as test the mail list server as it appears to have been down.

-- Will

Date: Tue, 8 Dec 2009 14:57:52 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] test ignore

see the subject line

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Tue, 8 Dec 2009 08:28:54 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Network Synchronization Requirements - some thoughts

I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to.

Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle.  Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications.

Consider operating as the N4C group was in this summer's field exercise.  If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future).

Consider military environment where DTN is providing the network layer rather than an overlay.  DTN is being used to handle short-term fades and disconnection as well as near-real time communications.  In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds.   If so, the network will have to be synchronized to within a some fraction of this.  

Networks with scheduled  connectivity have to have some sort of clock.  Deep Space networks are one such example.  In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions.  

If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle.  However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements.

--Will

(This is a resend.  I did not see it show up after I sent it yesterday.)

Date: Tue,  8 Dec 2009 15:08:13 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN2 on Maemo

The research team of Prof. Carlo Caini (DEIS, University of Bologna, Italy) have
successfully installed DTN2 on a Nokia N900 with Maemo 5.

A first set of transfers has been carried out with the new DTNPerf 2.5 and other
tests will follow in the next days.

More details will be available soon on the DEIS website.

Kind regards,
Piero Cornice

Date: Tue, 08 Dec 2009 08:01:12 +0000
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN2 on Maemo

The research team of Prof. Carlo Caini (DEIS, University of Bologna, Italy) have
successfully installed DTN2 on a Nokia N900 with Maemo 5.

A first set of transfers has been carried out with the new DTNPerf 2.5 and other
tests will follow in the next days.

More details will be available soon on the DEIS website.

Kind regards,
Piero Cornice

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Mon, 7 Dec 2009 15:31:56 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Network Synchronization Requirements - some thoughts

I believe some of the discussion and disagreement on network synchronization requirements may be due to the vast environments DTN may be applied to.

Once a system reaches steady state (and how that done is not addressed in this email), I believe that the network probably has to be synchronized to within some percentage of the shortest bundle lifetime that network will have to handle.  Whether that is 1%, 10% or 500% probably depends on the network, the amount and length of disconnection and applications.

Consider operating as the N4C group was in this summer's field exercise.  If the bundle lifetimes are many hours or days, the network probably only requires synchronization to a hour or so (Assuming you will accept bundles from the an hour or two into the future).

Consider military environment where DTN is providing the network layer rather than an overlay.  DTN is being used to handle short-term fades and disconnection as well as near-real time communications.  In such an environment, some bundles may have very short lifetimes - perhaps a few to tens of seconds.   If so, the network will have to be synchronized to within a some fraction of this.  

Networks with scheduled  connectivity have to have some sort of clock.  Deep Space networks are one such example.  In this case bundle lifetimes are probably much longer than the synchronization requirements for pointing antennas, turning on transmitters and other such lower layer functions.  

If one has a closed network, one probably has some reasonable idea of the expected minimum lifetime of a bundle.  However, if the DTN is open, estimating the expected minimum lifetime of a bundle is problematic and thus, so are the network synchronization requirements.

--Will

Date: Fri, 04 Dec 2009 14:49:30 +0100
From: Emilio Ancillotti <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Call for Extended Abstracts PhD Forum ACM/SIGMOBILE MobiOpp 2010

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

*******************************************************************************
Our Sincere apologies if you receive multiple copies of this Call
 
     The Second International Workshop on Mobile Opportunistic Networking
          ACM/SIGMOBILE MobiOpp 2010, February 22-23, 2010, PISA ITALY
                      http://cnd.iit.cnr.it/mobiopp2010/
                         *Call for Extended Abstracts*
                                  *PhD Forum*

The first PhD Forum on Opportunistic Networking will be hosted at Second
International Workshop on Mobile Opportunistic Networking (MobiOpp2010). 
Doctoral students working in areas related to opportunistic networking and
computing are solicited to submit an extended abstract comprising a 
summary of
their research findings, work in progress and planned research. The 
forum will
be a platform for PhD students to interact both with their peers as well as
experienced researchers from industry. The forum will be organized as a 
poster
session preceded by a '1-minute madness' introduction by each student.

Current Ph.D. students, as well as researchers who have completed their 
Ph.D.
dissertations since May 2009, are encouraged to submit extended 
abstracts. The
Ph.D. student should be the sole author, although contributions of the 
advisor
and others may be acknowledged in the extended abstract. Submissions will be
reviewed to ensure quality and relevance. Authors of accepted 
submissions are
expected to travel to MobiOpp 2010 to present their poster at the PhD Forum.
The best presentation at the Forum, will receive an award sponsored by 
Elsevier
Publications and there is likely to be travel assistance for some students.
Accepted extended abstracts will appear in conference proceedings.
*
Extended Abstract Submission*: Ph.D. students are invited to submit two-page
extended abstracts that describe current research and potential 
contributions
to theory and innovation in pervasive computing and communications. 
Submissions
must be received by no later than December 7, 2009. Extended abstracts 
should
include the author's name, affiliation, and email address. Submissions 
must be
PDF files and be written in English. Submissions should adhere to the ACM
format and be no more than two pages in length (all inclusive).
Papers must be submitted via email to [email-masked].

*Important Dates*
Extended abstract submission deadline: December 7, 2009
Notification of acceptance: January 10, 2010
Camera-ready paper due: January 22, 2010
MobiOpp: February 22-23, 2010

*PhD Forum Co-Chairs*
Silvia Giordano, SUPSI, Switzerland
Mohan Kumar, The University of Texas at Arlington
*Corporate Sponsor    TBD*

-- 
============================================================
Ing. Emilio Ancillotti, PhD
   Pervasive Computing & Networking Lab. (PerLab)
   Institute for Informatics and Telematics (IIT)
   National Research Council (CNR)
      Via G. Moruzzi, 1    ||    voice:    +39 050 315 2437
      56124 Pisa, Italy    ||    fax:    +39 050 315 2113
                           ||    mobile:    +39 328 2963760
============================================================

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>*******************************************************************************<br>
Our Sincere apologies if you receive multiple copies of this Call<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp; The Second International Workshop on Mobile Opportunistic
Networking<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACM/SIGMOBILE MobiOpp 2010, February 22-23, 2010, PISA ITALY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext"
 href="http://cnd.iit.cnr.it/mobiopp2010/">http://cnd.iit.cnr.it/mobiopp2010/</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <b>Call for Extended Abstracts</b><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <b>PhD Forum</b><br>
<br>
The first PhD Forum on Opportunistic Networking will be hosted at
Second <br>
International Workshop on Mobile Opportunistic Networking
(MobiOpp2010).&nbsp; <br>
Doctoral students working in areas related to opportunistic networking
and <br>
computing are solicited to submit an extended abstract comprising a
summary of<br>
their research findings, work in progress and planned research. The
forum will<br>
be a platform for PhD students to interact both with their peers as
well as <br>
experienced researchers from industry. The forum will be organized as a
poster <br>
session preceded by a '1-minute madness' introduction by each student.<br>
<br>
Current Ph.D. students, as well as researchers who have completed their
Ph.D. <br>
dissertations since May 2009, are encouraged to submit extended
abstracts. The<br>
Ph.D. student should be the sole author, although contributions of the
advisor<br>
and others may be acknowledged in the extended abstract. Submissions
will be<br>
reviewed to ensure quality and relevance. Authors of accepted
submissions are<br>
expected to travel to MobiOpp 2010 to present their poster at the PhD
Forum.<br>
The best presentation at the Forum, will receive an award sponsored by
Elsevier<br>
Publications and there is likely to be travel assistance for some
students.<br>
Accepted extended abstracts will appear in conference proceedings.<br>
<b><br>
Extended Abstract Submission</b>: Ph.D. students are invited to submit
two-page<br>
extended abstracts that describe current research and potential
contributions<br>
to theory and innovation in pervasive computing and communications.
Submissions<br>
must be received by no later than December 7, 2009. Extended abstracts
should<br>
include the author's name, affiliation, and email address. Submissions
must be<br>
PDF files and be written in English. Submissions should adhere to the
ACM <br>
format and be no more than two pages in length (all inclusive).<br>
Papers must be submitted via email to <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.<br>
<br>
<b>Important Dates</b><br>
Extended abstract submission deadline: December 7, 2009<br>
Notification of acceptance: January 10, 2010<br>
Camera-ready paper due: January 22, 2010<br>
MobiOpp: February 22-23, 2010<br>
<br>
<b>PhD Forum Co-Chairs</b><br>
Silvia Giordano, SUPSI, Switzerland<br>
Mohan Kumar, The University of Texas at Arlington<br>
<b>Corporate Sponsor&nbsp;&nbsp;&nbsp; TBD</b><br>
</tt><br>
<pre class="moz-signature" cols="72">-- 
============================================================
Ing. Emilio Ancillotti, PhD
   Pervasive Computing &amp; Networking Lab. (PerLab)
   Institute for Informatics and Telematics (IIT)
   National Research Council (CNR)
      Via G. Moruzzi, 1    ||    voice:    +39 050 315 2437
      56124 Pisa, Italy    ||    fax:    +39 050 315 2113
                           ||    mobile:    +39 328 2963760
============================================================

</pre>
</body>
</html>

--------------050600000700060403040701--

Sender: [email-masked]
From: Pablo Serrano <[email-masked]>
Date: Thu, 3 Dec 2009 18:17:14 +0100
To: [email-masked]
Subject: [dtn-interest] CFP: 2nd IEEE WoWMoM Workshop on Hot Topics in Mesh Networking (HotMESH 2010)

[Please accept our apologies if you receive multiple copies of this CFP.]

----------------------------------------------------------------------
The Second IEEE WoWMoM Workshop on Hot Topics in  Mesh Networking (HotMESH 2010)

http://cnd.iit.cnr.it/mesh2010/

Montreal, Canada June 14, 2010

In conjunction with the 11th IEEE International Symposium on a "World
of Wireless, Mobile and Multimedia Networks" (WoWMoM’10)

http://wowmom2010.netgroup.uniroma2.it/
----------------------------------------------------------------------

THEME AND SCOPE
The huge advances of wireless broadband technologies lay the
foundation of a future where ubiquitous wireless network access will
be anywhere at anytime. Wireless mesh networks are expected to be a
key element of this future by providing a highly scalable, reliable
and cost-effective wireless backbone to mobile devices a multi-hop
wireless communication system. However, there are still a lot of
technical challenges that need to be solved in order to reach the full
potentialities of this innovative technology.

This workshop aims to bring together the technologist and researchers
who share interest in the area of wireless mesh networks. The main
purpose is to promote discussions on recent advances in the analysis
design and implementation of systems, protocols and services for next
generation mobile mesh networks. It also aims at increasing the
synergy between academic and industry professionals working in this
area. We plan to seek papers that address theoretical, experimental,
and work in-progress at all layers of mesh networks, from application
to physical layer.

Topics of interest include, but are not limited to:

       Cross layer design and optimizations
       Capacity analysis
       Greening the Internet
       Multi-radio and multi-channel wireless mesh networking
       Medium access control protocols
       Self-configuration and self-management procedures
       Routing, scheduling, and channel assignment protocols
       Mesh networks measurement
       QoS provisioning
       Mobility management
       Topology construction and maintenance
       Security architectures, functions and protocols
       Privacy enhancing technologies for mesh networks
       Testbed, prototype, and practical systems

PAPER SUBMISSIONS
Authors should prepare a PDF file following the IEEE 8.5x11 conference
format in accordance with the IEEE Computer Society author guidelines
(http://www.computer.org/portal/web/cscps/formatting). Manuscripts
should not exceed six (6) pages in size including all text, figures,
tables, and references. Papers significantly exceeding this limit will
be automatically rejected. Attendance to the workshop will require a
Full Registration to the main conference. Accepted papers will be
published by the IEEE Computer Society Press in the combined WoWMoM
2010 workshop proceedings. Accepted papers not presented at the
workshop will not be included in the IEEE Digital Library.

IMPORTANT DATES
Submission due:                  February 5, 2010
Acceptance notification:           March 25, 2010
Final manuscript due:              April 10, 2010
Workshop:                           June 14, 2010

WORKSHOP CO-CHAIRS
Albert Banchs, Univ. Carlos III de Madrid, Spain
Raffaele Bruno, IIT-CNR, Italy

PUBLICITY CHAIR
Pablo Serrano, Univ. Carlos III de Madrid, Spain

PROGRAM COMMITTEE
TBA

Date: Tue, 1 Dec 2009 13:52:28 -0800 (PST)
From: Scott Fowler <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP:Symposium on Smart Homes (SH-10)

--0-775492143-1259704348=:15350
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

SH 2010 Call for Papers=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=0A=0AThe Fifth International Symposium on Sm=
art Home=0AIn Conjunction with FutureTech 2010. May 21-23, 2010. Busan, Kor=
ea=0Ahttp://www.ftrg.org/sh2010/index.php=0A=0A=0ASmart Home Environments (=
SHEs) are emerging rapidly as an exciting new paradigm including ubiquitous=
, grid, and peer-to-peer computing to provide computing and communication s=
ervices any time and anywhere. To full realize the advantages of the paradi=
gm, we require a host of suitable security services and their applications.=
 They will offer the user remote access to all information about appliances=
 in the workplace as well as at home, and help easily and conveniently use =
various services to enable working from home, and facilitate remote educati=
on, remote diagnosis, virtual shopping, network gaming, and portal & high q=
uality VOD with no limitations on space and time. SH-2010 is intended to fo=
ster the dissemination of state-of-the-art research in the area of SHE incl=
uding business models, security services, and novel applications associated=
 with its utilization. As a follow-up of the symposium, we plan to publish =
high quality papers, covering the various
 theories and practical applications related to smart home. The published p=
apers are expected to present the high level results to solve the applicati=
on services and various problems in the various SH fields. In addition, we =
expect they will trigger further related research and technological improve=
ments of the SH. The goal of the SH-2010 is to bring together the researche=
rs from academia and industry as well as practitioners to share ideas, prob=
lems and solutions relating to the multifaceted aspects of Information Tech=
nology. =0A=0AWe invite new and original submissions addressing theoretical=
 and practical topics in information technology and intelligent computing f=
ields including (but not limited to these topics): =0A=0ASH Applications=0A=
=0A- Smart home (Building) applications and services=0A- Smart home network=
 middleware and protocols Mobile / Wearable intelligence=0A- Commercial and=
 industrial application for SH=0A- Mobile / Wearable intelligence=0A- Frame=
works for integrating AI and data mining=0A- Context awareness model for sm=
art home services=0A- Wireless sensor networks (WSN) / RFID application for=
 SH=0A=0A=0ASH Security=0A=0A- Multimedia Security and Services in SH=0A- S=
mart home security issues and model=0A- Access control and privacy protecti=
on in SH=0A- Forensics and Security Policy in SH=0A- WSN/ RFID Security in =
SH=0A- Security Protocol for smart home service=0A=0A SH Embedded Hardware =
and Software=0A=0A- Embedded Hardware Support for SH=0A- Embedded Software =
for SH=0A- Embedded System Architecture for SH=0A- Real-time OS for SH=0A- =
Smart and Personal Devices for SH=0A- Power-Aware Computing for SH=0A- Midd=
leware for SH=0A- Specification, Validation and Verification of Embedded So=
ftware=0A- Computational Models=0A=0A=0ASubmission Guidelines=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=0A=0A=
Submitted papers must be unpublished and not considered elsewhere for publi=
cation.Only electronic submissions in PDF format will be considered. Papers=
 must be 8 pages or less in size, including references, figures and tables =
(at least 10pt font, 2-column format). The IEEE LaTeX and Microsoft Word te=
mplates, as well as information for formatting the manuscript can be found =
at http://www2.computer.org/portal/web/cscps/formatting. Papers will be rig=
orously reviewed by the international technical program committee. All acce=
pted papers will be included in the FutureTech-10  Workshop Proceeding publ=
ished by IEEE. (The proceeding will be included in EI and other index). Fin=
al author manuscripts will be 8.5" x 11" (two columns IEEE format), not exc=
eeding 8 pages; ( 2 extra pages will be allowed at additional cost only for=
 camera ready papers).  =0A=0AAll paper submissions will be handled electro=
nically. The submission process is described on the Submission Page at http=
://www.editorialsystem.net/sh2010/=0A=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=0ASpecial Issue Internatio=
nal Journal Publication=0A=0AExtended versions of best papers of the Sympos=
ium will be considered for publication in a Special issue of an Internation=
al journal planned shortly after the event.=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=0A=0A=0AImportant Da=
tes=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=0APaper Submission: January 31, 2010 =0AAcceptance Notification: =
March 5, 2010 =0ACamera-Ready Version: March 15, 2010  =0ASymposium Date: M=
ay 21-23, 2010 =0A=0A=0A      
--0-775492143-1259704348=:15350
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>SH 2010 Call for Papers<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<br><br>The Fifth Internati=
onal Symposium on Smart Home<br>In Conjunction with FutureTech 2010. May 21=
-23, 2010. Busan, Korea<br><span><a target=3D"_blank" href=3D"http://www.ft=
rg.org/sh2010/index.php">http://www.ftrg.org/sh2010/index.php</a></span><br=
><br><br>Smart Home Environments (SHEs) are emerging rapidly as an exciting=
 new paradigm including ubiquitous, grid, and peer-to-peer computing to pro=
vide computing and communication services any time and anywhere. To full re=
alize the advantages of the paradigm, we require a host of suitable securit=
y services and their applications. They will offer the user remote access t=
o all information about appliances in the workplace as well as at home, and=
 help easily and conveniently use various services to
 enable working from home, and facilitate remote education, remote diagnosi=
s, virtual shopping, network gaming, and portal &amp; high quality VOD with=
 no limitations on space and time. SH-2010 is intended to foster the dissem=
ination of state-of-the-art research in the area of SHE including business =
models, security services, and novel applications associated with its utili=
zation. As a follow-up of the symposium, we plan to publish high quality pa=
pers, covering the various theories and practical applications related to s=
mart home. The published papers are expected to present the high level resu=
lts to solve the application services and various problems in the various S=
H fields. In addition, we expect they will trigger further related research=
 and technological improvements of the SH. The goal of the SH-2010 is to br=
ing together the researchers from academia and industry as well as practiti=
oners to share ideas, problems and solutions relating to the
 multifaceted aspects of Information Technology. <br><br>We invite new and =
original submissions addressing theoretical and practical topics in informa=
tion technology and intelligent computing fields including (but not limited=
 to these topics): <br><br>SH Applications<br><br>- Smart home (Building) a=
pplications and services<br>- Smart home network middleware and protocols M=
obile / Wearable intelligence<br>- Commercial and industrial application fo=
r SH<br>- Mobile / Wearable intelligence<br>- Frameworks for integrating AI=
 and data mining<br>- Context awareness model for smart home services<br>- =
Wireless sensor networks (WSN) / RFID application for SH<br><br><br>SH Secu=
rity<br><br>- Multimedia Security and Services in SH<br>- Smart home securi=
ty issues and model<br>- Access control and privacy protection in SH<br>- F=
orensics and Security Policy in SH<br>- WSN/ RFID Security in SH<br>- Secur=
ity Protocol for smart home service<br><br>&nbsp;SH Embedded
 Hardware and Software<br><br>- Embedded Hardware Support for SH<br>- Embed=
ded Software for SH<br>- Embedded System Architecture for SH<br>- Real-time=
 OS for SH<br>- Smart and Personal Devices for SH<br>- Power-Aware Computin=
g for SH<br>- Middleware for SH<br>- Specification, Validation and Verifica=
tion of Embedded Software<br>- Computational Models<br><br><br>Submission G=
uidelines<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<br><br><span>Submitted papers must be unpublished and no=
t considered elsewhere for publication.Only electronic submissions in PDF f=
ormat will be considered. Papers must be 8 pages or less in size, including=
 references, figures and tables (at least 10pt font, 2-column format). The =
IEEE LaTeX and Microsoft Word templates, as well as information for formatt=
ing the manuscript can be found at <a target=3D"_blank" href=3D"http://www2=
.computer.org/portal/web/cscps/formatting">http://www2.computer.org/portal/=
web/cscps/formatting</a>. Papers will be rigorously
 reviewed by the international technical program committee. All accepted pa=
pers will be included in the FutureTech-10&nbsp; Workshop Proceeding publis=
hed by IEEE. (The proceeding will be included in EI and other index). Final=
 author manuscripts will be 8.5" x 11" (two columns IEEE format), not excee=
ding 8 pages; ( 2 extra pages will be allowed at additional cost only for c=
amera ready papers).&nbsp; </span><br><br><span>All paper submissions will =
be handled electronically. The submission process is described on the Submi=
ssion Page at <a target=3D"_blank" href=3D"http://www.editorialsystem.net/s=
h2010/">http://www.editorialsystem.net/sh2010/</a></span><br><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<br=
>Special Issue International Journal Publication<br><br>Extended versions o=
f best papers of the Symposium will be considered for publication in a Spec=
ial issue of an International journal planned shortly after the
 event.<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<br><br><br>Important Dates<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<br>Paper Submission:=
 January 31, 2010 <br>Acceptance Notification: March 5, 2010 <br>Camera-Rea=
dy Version: March 15, 2010&nbsp; <br>Symposium Date: May 21-23, 2010 <br><b=
r><br></div>=0A<!-- cg24.c41.mail.ird.yahoo.com compressed/chunked Sat Nov =
28 14:14:07 PST 2009 -->=0A</div><br>=0A=0A=0A=0A      </body></html>
--0-775492143-1259704348=:15350--