Subject: [dtn-interest] DEADLINE EXTENSION: 1st IEEE Int. Workshop on Network Sci. For Comm. Networks (NetSciCom'09)
From: Katia Obraczka <[email-masked]>
To: [email-masked]
Cc: Katia Obraczka <[email-masked]>
Date: Wed, 28 Jan 2009 10:40:01 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

We apologize if you receive multiple copies of this message. Due to 
the tight timeframe for this workshop, we extended the deadline 
to 

** February 15 **

 Please see updated cfp below.

=====================================================================
                     FINAL CALL FOR PAPERS
   
                        NetSciCom 2009
        First IEEE International Workshop on Network Science
                  For Communication Networks
   
              April 24, 2009 - Rio de Janeiro, Brazil
                 http://netscicom2009.asu.edu/
   
               In conjunction with IEEE Infocom 2009
=====================================================================
   
SCOPE: 
   
Network Science is a newly emerging discipline with applications in a
variety of domains, such as, Communication Networks, Power Grid
Networks, Transportation Networks, Social Networks, Biological Networks
and Economics. Designing complex communication networks of the future
needs a deep understanding of the interplay between the physical-, the
communication- and the social networks involved. An understanding of
such interdependency can only be achieved by closer interaction between
Network Scientists, Communication Network Designers, and Social and
Behavioral Scientists. The goal of this workshop is to a provide a forum
where this diverse group of researchers can meet and exchange ideas that
will lead to deeper insights into the design of robust, efficient and
complex communication networks of the future.
   
TOPICS OF INTEREST: 
   
The topics of this workshop lie at the intersection of Network Science
and Communication Network Design - including Topology Design and
Analysis, Traffic Modeling, Traffic Routing, Social Media Analysis:
blogs and friendship networks, Bio-inspired networks, Internet scale
measurement and analysis of online communities, Social network analysis
with mobile phone data, Interdependency between power grid,
communication and transportation networks.

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

PAPER SUBMISSION:

Papers should contain original material, i.e., that has not been
previously published or currently submitted elsewhere. Manuscripts
must be limited to 6 pages in IEEE 8.5x11 conference format, and
formatted in strict accordance with the IEEE Communications Society
author guidelines. All submissions will be handled
electronically. Accepted papers will be published by the IEEE INFOCOM
2009 workshop proceedings and will be available through IEEE Xplore.

For paper formatting instructions, please check 

http://www.ieee-infocom.org/paper-layout.htm 

Prospective authors should submit their papers through EDAS. EDAS is
now accepting NetSciCom2009 submissions at

http://edas.info/newPaper.php?c=7339&

or by follwoing the respective links through the workshop webpage.
   
====================================================================
   
IMPORTANT DATES: 

Workshop date: April 24, 2009
   
***EXTENDED SUBMISSION DEADLINE: February 15, 2009***
 
Notification of acceptance: March 22, 2009 
Camera-ready version submission deadline: April 5, 2009
   
====================================================================
   
PROGRAM CO-CHAIRS:
   
Arun Sen, Arizona State U.
Andrea Richa, Arizona State U.
Katia Obraczka, UC Santa Cruz
   
PROGRAM COMMITTEE:
   
J. Altmann, Int. Univ. Germany
M. Boguna, Univ. of Barcelona, Spain
R. Bonneau, AFOSR
J. M. Coyle, ARO
J. J. Garcia-Luna-Aceves, UCSC
G. Konjevod, ASU
D. Krioukov, CAIDA, UC San Diego
M. Latapy, CNRS, France
C. Magnien, CNRS, France
R. Mateus, UFMG, Brazil
M. Mitzenmacher, Harvard Univ.
C. Qiao, Univ. Buffalo (SUNY)
K. Ramchandran, U.C. Berkeley
H. Sadjadpour, UCSC
C. Scheideler, T.U. Munich
E. Silva, UFRJ, Brazil
B. Ulman, ARO
P. Varaiya, U.C. Berkeley
J. Walrand, U.C. Berkeley
G. Xue, ASU
E. Zegura, Georgia Tech
T. Znati, NSF

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

Date: Sat, 24 Jan 2009 03:28:13 -0500
From: "Omar Y. Tahboub" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] The First International Workshop on Concurrent Communication (ConCom 2009) Announcement

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

Call for Papers of SAINT2009 Workshop(6) - ConCom 2009

The First International Workshop on Concurrent Communication (ConCom 2009)
		    In Conjunction with SAINT 2009
			     Seattle, USA
			  July 20 - 24, 2009
	    http://infonet.cse.kyutech.ac.jp/conf/saint09/

CALL FOR PAPER

* THEME OF THE WORKSHOP

Communication pathways of the next generation networks will whiteness
two prevalent relaxations of singularity and persistence. The
relaxation of pathway singularity is related to the parallelism, which
allows data flows to be streamed concurrently. Through concurrency,
the performance contemporary file sharing systems, automatic backup
systems and content distribution networks will achieve exponential
growth. Moreover, concurrency will play a key role in future
bandwidth-intensive applications that involve the transfer of massive
data posing capacity demands reaching Gigabytes and yet Terabytes per
day. Such bandwidth-intensive applications include scientific
experimentations, High-Definition (HD) media distribution,real-time
distance learning, and telemedicine.

Pathway persistence is a fundamental principle, which mandates all
node/link hops to be active and available concurrently during the data
flow transfer.On the other hand, pathway intermittency is relaxation
of this principle,which does not mandate such concurrency. However,
data flow reachability must be guaranteed. Link and Hop intermittency
is now frequently appearing in a number of emergent communication
domains. Link intermittency is a physical characteristic of space
communication networks due to orbital rotation and occlusions. Hop
intermittency is also appearing to be intrinsic to vehicular and
aero-networks. It is believed that it is becoming an important issue
in emerging personal area networks (PAN) well. Intermittency is also
present in peer-to-peer domains. A fundamental feature of P2P is that
bulk of the clients are not logically connected 24/7. Thus, systems
need to provision for online/offline communication. In large volume
content distribution at the macroscopic level, pathways are logically
intermittent, but physically persistent. Such macroscopic
intermittency has been encountered in content distribution networks
(CDN). Large scale media distribution, cooperative backup and large
scale physics/science data distribution applications face such logical
intermittency.

Efficient route scheduling under concurrency and intermittency forms
an interesting research challenge. Classically, route can be computed
with various levels of knowledge. Interestingly, there is a strong
trend towards routing with knowledge about network resources and
circuit demand- especially in high performance and scientific
experimentation network domain. Internet2's Dynamic Circuit Network
(DCN) is one example where large volume connections can be planned
even at optical layer for scheduled massive data
transfers. Furthermore, space communication network and science
networks (such as ESNet) are experimenting with advance scheduling for
efficient and quality assured data transfer. This workshop will
address the key research issues related to architectural and protocol
design of concurrent computation exploiting pathway concurrency and
intermittency at the physical and logical levels. Furthermore, this
works also has special interest in on-demand scheduling-based
communication in this type of networks.

Topics of Interest:

Concurrent Communication Network Architectures

* Distributed Parallel Communication Networks
* Multi-stream transport Networks

On-Demands Scheduling-based Communication in Concurrent Communication
Networks
* On-demand Scheduling-based Communication Networks Architectures
* On-demand Scheduling-based Communication Protocol Architectures
* On-demand Scheduling-based Routing Algorithms
* On-demand Scheduling-based Routing Protocols
* On-demand Scheduling-based Data Transport Algorithms
* On-demand Scheduling-based Data Transport Protocols
* On-demand Scheduling-based Application Protocols

Intermittent Communication Network Architectures
* Space Communication Networks
* Disruption/Delay Tolerant Networks (DTNs)
* Intermittently Connected Mobile Ad Hoc Networks (ICMAN)
* Vehicular Networks (VNets)
* Aerospace Networks (AeroNets)
* Personal Area Networks (PANs)
* Wireless Sensor Forwarding Networks
* Peer-to-Peer Content Distribution Networks CDN's
* Dynamic Circuit Networks (DCNs)

On-Demand Scheduling-based Communication in Intermittent Networks
* On-demand Scheduling-based Communication Networks Architectures
* On-demand Scheduling-based Communication Protocol Architectures
* On-demand Scheduling-based Routing Algorithms
* On-demand Scheduling-based Routing Protocols
* On-demand Scheduling-based Data Transport Algorithms
* On-demand Scheduling-based Data Transport Protocols
* On-demand Scheduling-based Application Protocols

* PAPERS AND AUTHOR'S KIT

Workshop papers should be within 4 pages, no extra page is allowed.The
Proceedings of the Symposium and the Workshops will be published, in
separated volumes, by the IEEE Computer Society Press. Please follow
the instruction on the web below where authors can find Page Form and
appropriate pointers for LaTeX Macros. Please visit SAINT 2009 Website
(http://infonet.cse.kyutech.ac.jp/conf/saint09/) and select >
Information for Authors

* PAPER SUBMISSION

Papers should be submitted on-line through my e-mail address
otahboub[atmark]cs.kent.edu or otahboub[atmark]kent.edu no later than
February 28, 2009. After a review process by Organizers and Program
Committeeof the Workshop, authors of accepted papers will be requested
to send its final manuscript to IEEE-CS press no later than April 30,
2009. So, authors are kindly requested to submit papers as early as
possible to facilitate a review process.

* IMPORTANT DATES

Workshop Paper Submission: Feburary 28, 2009

Workshop Paper Notification: March 31, 2009

Workshop Final Manuscript: April 30, 2009

Author registration due: TBD

Workshop: July 20 - 24, 2009 (exact date is TBD)

* REGISTRATION

It is the IEEE policy that accepted papers can be published only when
IEEE recognized that at least ONE author has completed FULL
registration for presentation. So, authors will be requested to
register along with the final manuscript. SAINT Conference
Registration fees include a copy of the Conference proceedings, a copy
of the Workshop proceedings, and admission to the Conference/Workshop
sessions.

* NOTE

The date and length (a full or half day) of the Workshop will be
decided by SAINT2009 Organizing Committee taking account of the number
submitted of papers, and be notified on the SAINT2009 web. Please also
note that, according to the SAINT2009 Organizing Committee, the
Workshop is subject to cancellation when the number submitted of
papers will not be enough.

* ORGANIZER

* Omar Y. Tahboub, Kent State University <otahboub[atmark]cs.kent.edu>

* PROGRAM COMMITTEE FOR PAPER REVIEW

* Ala Al-Fuqaha, West Michigan University Kalamazoo, USA
* Ali Abu-EI Humos, Jackson State University, USA
* Graciela Perera, Youngstown State University, USA
* Javed I. Khan, Kent State University, Kent, OH, USA
* Jinhua Guo, University of Michigan - Dearborn
* Kathy J. Liszka, University of Akron, OH, USA
* Dr. Muhammad Anan, Purdue University Calumet, USA,
* Min Sik Kim, Washington State University, USA
* Paolo Giaccone, Politecnico di Torino, Italy

--------------040701080205000909090604
Content-Type: application/pdf;
 name="ws-cfp-6.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ws-cfp-6.pdf"

--------------040701080205000909090604--

Date: Fri, 23 Jan 2009 15:11:29 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] call for updated project information

Its been pointed out to me that the "projects" info
(scroll down on [1]) on the DTNRG site is a bit outdated.

Can you update your stuff if you've an account or else
mail me details (*) and I'll get around to it sometime
soonish. If you keep the above subject line, there's a
smaller (but still non-zero;-) chance that I'll not
miss your message,

Cheers,
Stephen.

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

Details I'd like:

0. Name
1. One sentence description (a short sentence:-)
2. URL that'll lead to technical info (papers, HOWTOs, service
   links etc.)
3. Using BP [y/n] LTP [y/n]
4. Specify if using any of the known DTN codebases (DTN2, ION,...)
5. Duration (e.g. start/end year&month)

From: Peter TB Brett <[email-masked]>
Organization: Integral Informatics Ltd
To: [email-masked]
Date: Thu, 22 Jan 2009 22:11:02 +0000
Cc: "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <[email-masked]>
Subject: Re: [dtn-interest] sdnv draft update

--nextPart1850938.zTJVhkAdxl
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 22 January 2009 21:32:36 Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> As requested, I posted an update to the SDNV draft that
> had expired.  It's an update to the date only, I believe.
> All the comments that were raised on prior versions had
> been addressed, and I think it's ready for RG consensus
> call or whatever is required to wrap up and send forth.
>
> See:
> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sdnv-01.txt

I spotted a couple of possible grammatical errors:

Section 4:

    32,767 in 2 bytes.  Both formats could encode values requiring up to
=2D   N bytes in N+2 bytes, where N<127.  The two major difference between
+   N bytes in N+2 bytes, where N<127.  The two major differences between
    this old SDNV format and the currently-used SDNV format is that the

=2E..

=2D   The advantage in ease of parsing that the old format manifests itself
+   The advantage in ease of parsing the old format manifests itself
    in two aspects: (1) the size of the value is determinable ahead of
    time, in a way equivalent to parsing a TLV, and (2) the actual value

Regards,

                                      Peter

=2D-=20
Peter Brett

Electronic Systems Engineer
Integral Informatics Ltd

--nextPart1850938.zTJVhkAdxl
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1850938.zTJVhkAdxl--

Content-class: urn:content-classes:message
Date: Thu, 22 Jan 2009 15:32:36 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] sdnv draft update

As requested, I posted an update to the SDNV draft that
had expired.  It's an update to the date only, I believe.
All the comments that were raised on prior versions had
been addressed, and I think it's ready for RG consensus
call or whatever is required to wrap up and send forth.

See:
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sdnv-01.txt

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

Date: Thu, 22 Jan 2009 22:15:33 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] [Fwd: [theONE] The ONE v.1.3 available]

Just FYI: we have a new version of the ONE simulator released.
Details below.

Joerg

Hi all,

We released a new version of the ONE (1.3.0) and it's available for
download at the homepage: http://www.netlab.tkk.fi/tutkimus/dtn/theone/

Here's what's new since the last version:

- New Features
    - ModuleCommunicationBus for sharing information between different
      (types of) modules
    - EnergyAwareRouter demonstrating energy awareness possibilities
      and use of the ModuleCommunicationBus
      - EnergyLevelReport for reporting the energy levels
    - ConnectivityONEReport class for generating connectivity traces
      that can be read using the StandardEventsReader
- Enhancements
    - Any number of input config files supported
    - Batch mode supports run index ranges (can start from any index)
      - small change in the command line syntax; see README for details
    - MessageEventGenerator supports message creation time and
      destination
      host ranges
    - NetworkLayer has configurable scanning intervals
    - ExternalEventsQueue can be configured like all the other event
      generators (though the old way is still supported too)
    - ccdfPlotter script has better help and can now also create CDFs
- New toolkit scripts
    - messageLocationAnimator for creating GIF animations out of
      MessageLocation reports
    - dieselNetConverter for converting DieselNet traces into ONE
      mobility traces
    - getAverages for counting averages out of different time-stamped
      reports
    - splotEnergy for creating 3D plots from EnergyLevel reports
- Fixed bugs in
    - handling of incoming messages with expired TTL
    - report directory creation; thanks to STARpio
    - BusTravellerMovement incState; thanks to Mehedi Bakht
    - MaxProp calcTreshold; thanks to Vasco Soares and STARpio

Cheers,
Ari

Date: Thu, 22 Jan 2009 00:20:41 +0100
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To: [email-masked]
Subject: [dtn-interest] Call for papers: ICNP 2009

[Sincere apologies if you receive multiple copies of this CFP.]

                          CALL FOR PAPERS
                             ICNP 2009
        17th IEEE International Conference on Network Protocols
                       October 13-16, 2009
                    Princeton, New Jersey, USA
                  http://www.ieee-icnp.org/2009

ICNP, the IEEE International Conference on Network Protocols is the
premier conference covering all aspects of network protocols. ICNP will
be held in its seventeenth year at Princeton, New Jersey from October
13-16th, 2009. Papers with significant research contributions on network
protocols are solicited for submission. Papers related to all aspects of
network protocols including design, implementation, analysis,
performance and specification are relevant. Papers must not be
previously published nor under review in any other conference or
journal. Only original papers that have not been published previously or
submitted for publication and under review by another conference or
journal elsewhere can be submitted. Papers containing plagiarized
material will be subject to the IEEE Plagiarism policy and will be
rejected without review. Topics of interest include, but are not limited to:
� Protocol design, implementation, testing and analysis.
� Measurement studies of protocol performance.
� Protocols for wireless ad hoc and sensor networks.
� Protocols for peer-to-peer networks.
� Protocols for specific functions such as routing, flow/congestion
control, network management.
� Protocols for security, survivability and fault-tolerance.

Papers must be directly relevant to protocols. Papers on general
networking where protocols are only a secondary focus will be considered
only if they are of exceptionally high quality.

Papers will be subject to a double-blind review process. The identity of
authors and referees will not be revealed to each other. To ensure blind
reviewing, the authors' names and affiliations should not appear in the
paper. Bibliographic references should protect the authors' anonymity.
Papers should adhere to the IEEE format and should not be more than 10
pages. The font size should not be smaller than 10pt.  Further
instructions will be posted on the ICNP website
(http://www.ieee-icnp.org/2009).

Authors of accepted papers will be expected to register for the
conference and the paper must be presented at the conference in order
for the paper to appear in the conference proceedings.

Important Dates:
Abstract Submission:        April 10, 2009 8:59 P.M. EDT
Paper Submission:           April 17, 2009 8:59 P.M. EDT (Hard Deadline)
Notification of Acceptance: July  28, 2009
Camera Ready Version Due:   September 4, 2009

Organizing Committee:

Executive Committee:
David Lee                   Ohio State University, USA (Chair)
Mostafa Ammar               Georgia Tech. USA
Ken Calvert                 University of Kentucky, USA
Teruo Higashino             Osaka University, Japan
Raymond Miller              University of Maryland, USA

General Chairs:
K.K. Ramakrishnan           AT & T Labs Research, USA
Henning Schulzrinne         Columbia University, USA

Program Chairs:
Timothy Griffin             University of Cambridge, U.K.
Srikanth V. Krishnamurthy   University of California, Riverside, USA

For more details, visit the conference webpage:
http://www.ieee-icnp.org/2009

Regards,
Xiaoming Fu
IEEE ICNP'09 Publicity Chair

Date: Wed, 21 Jan 2009 17:54:28 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Meeting in March - RSVP required

Hi All,

As we mentioned at the last IETF we're planning a two-day meeting
for March 19/20 which will be hosted by Google in Mountain View.

Since the room capacity is limited and there are a few related
events (IETF meeting, an IPv6 conference) on around the same time
and place, we might get some (welcome) new folks, but we need to
make sure we're not overflowing the facilities.

So, if you intend coming can you send Kevin and I a mail before
the end of this month.

In the unlikely event that too many folks want to attend we'll
first prioritise people who've been active in the DTNRG, after
which it'll be first-come-first-served.

I'll send out a mail early next month with detailed logistics
and the list of those planning to attend. We'll also start
planning the agenda at that point.

Thanks again to Vint Cerf from Google for hosting us, and also
to Adrian Hooke of NASA for helping to organise that,
Regards,
Stephen.

PS: I've also asked for a short 1-hour slot at the IETF meeting
itself if we want to do an update. I'd be interested if folks do
or don't want that session at the IETF, so let me know.

Date: Thu, 15 Jan 2009 12:30:09 +0000
From: Tristan Henderson <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Mobiquitous 2009 - Call For Workshops

Hi,

If anyone is interested in organising a DTN workshop at Mobiquitous, a
proposal would be most welcome.

Cheers,
Tristan

MOBIQUITOUS 2009 - Call for Workshops

The Mobiquitous 2009 Workshop Chairs and the Mobiquitous Organizing
Committee invite proposals for workshops to be held with the Sixth
Annual International Conference on Mobile and Ubiquitous Systems:
Computing, Networking and Services.

Mobiquitous 2009 will be held in Toronto from (tentatively) July 13th
– July 16th 2009. Workshops provide a forum for discussion among
researchers and practitioners of areas of special interest within
Mobiquitous --- from underlying technologies to applications, theory
to practice, and data management and services all with the special
focus on mobility and ubiquitous computing. The aim is to provide a
forum for novel ideas and specific research questions. Workshops may
be organized by invitation or via an open call for participation.
Organizers may ask participants to give talks, submit short position
papers, or full papers, and organize peer-review process for all the
papers.

Workshop organizers are expected to be active in the field where they
propose a workshop. To foster interaction, the workshops are one-day
events limited to 30-50 participants. Workshops are expected to be one
day. A typical number of papers for a workshop is 10-12 but this may
differ, depending on the chosen format. As a reference, Web pages of
previous Mobiquitous conference sites (and links to various workshop
sites) are accessible from the "History" section at
http://www.mobiquitous.org.

TOPICS

We expect workshops to complement the topics of Mobiquitous 2009. Areas
of interest include: efficient context sensing on mobile platform,
ubiquitous healthcare, reliability and security in disconnection
tolerant networks, security and privacy in P2P embedded systems, social
networking design and usability, service discovery and data query in
participatory sensing etc.

Please contact the workshop chairs (see contact information below) to
propose workshop or to discuss ideas. A formal workshop proposal should
be at most five pages and include the following information:

    * Name of the workshop
    * Theme of the workshop and topics of interest, and how these relate
      to the overall conference
    * Names, affiliations, and research interest of the workshop organizers
    * Tentative list of program committee
    * What is the expected attendance of the workshop
    * How do you plan to attract submissions and/or participants
    * How do you plan to organize the workshop? Provide an estimate time
      line for the major milestones

Proposals should be sent to the workshops co-chairs:

    * Iqbal Mohomed <mailto:[email-masked]>, Microsoft Research, USA
    * Milena Radenkovic <mailto:[email-masked]>, University of
      Nottingham, UK

IMPORTANT DATES

Workshop proposals: January 20, 2009
Notification of acceptance: January 30, 2009
Workshop calls online (by organizers): February 15, 2009
Final Manuscript due (for common proceedings): April 10, 2009
Workshops: June 5, 2009

-- 
Tristan Henderson | School of Computer Science | University of St Andrews
www: http://www.cs.st-andrews.ac.uk/~tristan/  | tel: +44 1334 461637
The University of St Andrews is a charity registered in Scotland: No SC013532

Date: Tue, 13 Jan 2009 17:21:33 +0000
From: Stephen Farrell <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Simon Perreault <[email-masked]>
Subject: Re: [dtn-interest] [dtnbone] A new service on the DTNbone: DTN News

Nice!

Stephen.

Marc Blanchet wrote:
> Hello,
> 
> We are proud to announce a new service on the DTNbone: DTN news.
> 
> The service enables you to receive any RSS/Atom feed available on the
> Internet (currently on Earth) delivered through the DTNbone. Any feed
> such as slashdot, cnn or any your liking.
> 
> The concept is simple. You register to the service with your dtnbone
> node information and the feeds you want to receive. We continually poll
> RSS and Atom feeds. At the frequency of your choosing, we will package a
> news bundle and deliver it reliably over bundle protocol to your dtnbone
> node.
> 
> For example, a node which is intermittently connected may receive his
> preferred news feed as it connects to the dtnbone, then disconnects and
> reads them offline.
> 
> See http://reeves.viagenie.ca for details and how to sign up.
> 
> Marc and Simon(who implemented it).

Date: Tue, 13 Jan 2009 12:13:01 -0500
From: Marc Blanchet <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], Simon Perreault <[email-masked]>
Subject: [dtn-interest] A new service on the DTNbone: DTN News

Hello,

We are proud to announce a new service on the DTNbone: DTN news.

The service enables you to receive any RSS/Atom feed available on the
Internet (currently on Earth) delivered through the DTNbone. Any feed
such as slashdot, cnn or any your liking.

The concept is simple. You register to the service with your dtnbone
node information and the feeds you want to receive. We continually poll
RSS and Atom feeds. At the frequency of your choosing, we will package a
news bundle and deliver it reliably over bundle protocol to your dtnbone
node.

For example, a node which is intermittently connected may receive his
preferred news feed as it connects to the dtnbone, then disconnects and
reads them offline.

See http://reeves.viagenie.ca for details and how to sign up.

Marc and Simon(who implemented it).
-- 
=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca

Date: Mon, 12 Jan 2009 11:52:52 +0100
From: Emilio Ancillotti <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [AOC 2009]: Call for Papers

[Our apologies for possible duplicates]
---------------------------------------------------------------

CALL FOR PAPERS
Third IEEE WoWMoM Workshop on
Autonomic and Opportunistic Communications (AOC 2009)
June 15, 2009 - Island of Kos (Greece)
http://cnd.iit.cnr.it/aoc2009/

jointly organized by the

SOCIALNETS project
funded by the FET-IST Programme under the
FET proactive initiative on Pervisive Adaptation (PerAda)
http://www.social-nets.eu

ANA project
funded by the FET-SAC Programme in the area
Situated and Autonomic Communications (SAC)
http://www.ana-project.org/

Fast Track on Computer Communications Journal
http://www.elsevier.com/locate/comcom

**** Submission Deadline --- 5 February 2008 ****
---------------------------------------------------------------

The goal of this workshop is to provide a forum between
the autonomic and opportunistic communication communities
to exchange ideas, discuss solutions, and share experiences among
researchers, professionals, and application developers both from industry 
and academia.
The synergies between autonomic and opportunistic communications &
social networks studies and technologies are one of the primary interests
of this year’s edition.
Original papers addressing both theoretical and practical aspects of
autonomic and opportunistic communications and are solicited.
Papers describing prototype implementations and deployments are welcome.

Topics of interest include but are not limited to:

* Architecture and models for autonomic and opportunistic communications
* Economic, biological and social models used for
  autonomic and opportunistic communications
* Social networking technologies applied to autonomic and
  opportunistic communications
* Tools and techniques for designing, analysing and building
  autonomic and opportunistic networks
* Adaptive security for self protection of networks
* Mobility models for opportunistic networking
* Novel management techniques for autonomic and
  opportunistic communications
* Sensing, monitoring and measurements for self-managing networks
* Advanced technologies for enabling autonomic and
  opportunistic communications
* Autonomic and opportunistic communication testbeds and measurements
* Algorithmic aspects associated with
  autonomic communications environments and problems

PAPER SUBMISSION AND PUBLICATION
--------------------------------
Papers should neither have been published elsewhere nor currently under
review by another conference or journal. 
Guidelines on paper submission and formatting are available at
http://cnd.iit.cnr.it/aoc2009/.
Accepted papers will appear in the symposium proceedings published by IEEE. 
At least one author of each accepted paper is required to register and 
present their work at the workshop.
Extended versions of workshop selected papers will be considered for
possible fast track publication on the
Computer Communications Journal (Elsevier).

IMPORTANT DATES
---------------
Full papers due:      5 February, 2009
Notification:         23 March, 2009

ORGANIZING COMMITTEE
--------------------

WORKSHOP Chairs
  Andrea Passarella, IIT-CNR, Italy
  Konstantinos Oikonomou, Ionian University, Greece
  
STEERING Committee
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Co-Chairs
  Emilio Ancillotti, IIT-CNR, Italy
  Nikolaos Laoutaris, Telefonica Research, Spain

PROGRAM COMMITTEE (confirmed)
-----------------------------

Mostafa Ammar, Georgia Institute of Technology, USA
Giuseppe Anastasi, University of Pisa, Italy
Eleonora Borgia, IIT-CNR, Italy
Levente Buttyan, BUTE, Hungary
Vania Conan, Thales, France
Franca Delmastro, IIT-CNR, Italy
Falko Dressler, University of Erlangen-Nuremberg, Germany
Serge Fdida, UPCM Paris VI, France
Philip Ginzboorg, Nokia, Finland
Mohan Kumar, University of Texas at Arlington, USA
Emmanouil V. Magkos, Ionian University, Greece
Cecilia Mascolo, University of Cambridge, UK
Daniele Miorandi, Create-net, Italy
Refik Molva, Eurécom, France
Joerg Ott, HUT, Finland
Antonios Panagakis, University of Athens, Greece
Symeon Papavassiliou, NTUA, Greece
Giovanni Pau, UCLA, USA
Calicrates Policroniades, Telenor, Norway
George Polyzos, AUEB, Greece
Konstantinos Psounis, University of Southern California, USA
Christian Rohner, Uppsala University, Sweden
Fabrizio Sestini, EU Commission
Thrasyvoulos Spyropoulos, ETH Zurich, Switzerland
Pablo Vidales, Deutsche Telekom Laboratories, Germany
Roger Whitaker, Cardiff University, UK
Christos Xenakis, University of Piraeous, Greece
Eiko Yoneki, University of Cambridge, UK
Franco Zambonelli, University of Modena-Reggio, Italy

-- 
============================================================
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
============================================================

From: "Parikh, Salil" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Wed, 7 Jan 2009 19:50:45 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Thanks for the prompt review, Stephen.  This draft is currently not fortified against the wily and wicked.

Most of the applications we had in mind would use a constant retention count.  

In the vehicle tracking example, the application might drop the retention count from greater-than-one down to one, and then not send any future matching (SBEB-wise) bundles.  It might do this to send a final bundle for a particular vehicle that announces its deletion, which would flush the previous updates that are still migrating through agents.  

The application might alternatively have sent all the updates with a retention count of zero, causing agents to deliver them all until the final bundle purged them.

Or (even more hypothetically and notionally) an application might send differential updates with a retention count of zero, and periodically send "checkpoint" bundles with the count set to one, followed by more differential updates (like frames in video encoders?). 

Are there cases (hypothetical, notional, or worse) that would use a time-varying retention count?

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2009 11:13 AM
To: Parikh, Salil
Cc: [email-masked]
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Hi Salil,

Interesting draft. My immediate reaction (as a security type:-)
is that this is a nice new attack vector, so I'd argue that that
needs more discussion in the document.

E.g. without a cookie, the source, dest and timestamps could
be fairly easily guessable, which seems like a very easy attack
that could be launched off-path resulting in some or all of your
payloads being replaced by mine. (In your example, I could
replace a traffic camera image with something less desirable;-)

I'd say the cookie should at least be mandatory, (and of
reasonable length & randomness) so that at least off-path
attacks are hard.

I guess I could also argue that it ought be possible to
authenticate the SBEB as well, so that a policy requiring
the that the original source be the source of the replacement
can be implemented, or so that the source of the replacement
can be held accountable. There're probably a few ways this
could be done - have you thought about that?

Separately, I'd need to think about how this plays with
custody, e.g. setting a high retention count is sort-of
like a form of custody.

It also wasn't clear to me how varying retention count
values would be work out - if the most recent one is
less that a previous one that seems to assume that the
source knows where the bundles might be in the end-to-end
path, which is a bit odd. Raising the retention count
will be somewhat pointless until a number of bundles
have been sent etc. So maybe a bit more explanation
is needed there.

And lastly a nit: "Cookies only have meaning to the
application." seems odd & could be deleted.

Cheers,
Stephen.

Parikh, Salil wrote:
> Hello,
> 
>  
> 
> We have submitted an Internet-Draft titled "Delay-Tolerant Networking
> Superseding Bundle Extension Block".  We welcome review and comment from
> the DTNRG community.
> 
>  
> 
> http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt
> 
>  
> 
> Abstract:
> 
>  
> 
> This document defines an optional Bundle Protocol block called the
> Superseding Bundle Extension Block (SBEB) for use with the Bundle
> Protocol in the context of the Delay-Tolerant Networking Architecture. 
> Applications use this block to call for the removal of previously sent
> bundles that are rendered obsolete by more recent bundles. Upon
> receiving a bundle with an SBEB, a node will search its bundle store
> (and outbound queues) for bundles that are obsoleted by other related
> bundles according to their source and destination EID, and the SBEB
> cookie (if present), and may delete some or all of them. Discarding
> obsolete bundles helps conserve storage space and prevents expending
> resources in further forwarding bundles that are no longer relevant. 
> The bundle protocol already uses expiration times to remove bundles that
> are no longer useful to applications.  The SBEB is a way for
> applications to mark bundles that a node may delete prior to their
> expiration times.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 07 Jan 2009 23:35:31 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] Standalone meeting in San Francisco

Hi Elwyn,

To be honest I've not looked yet. DTRNG is meeting in
Mountain View & the IETF's wherever it is, so I'm not
sure that one hotel will do. But I'll get info out
early next month as I said,

S.

Davies wrote:
> Hi.
> 
> Are there any further details available about the meeting?  I'd like to coordinate hotel bookings etc. for this meeting and IETF fairly shortly.
> 
> 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]>
Date: Wed, 07 Jan 2009 22:31:48 +0000
Subject: [dtn-interest] Standalone meeting in San Francisco
Reply-To: Elwyn Davies <[email-masked]>

Hi.

Are there any further details available about the meeting?  I'd like to coordinate hotel bookings etc. for this meeting and IETF fairly shortly.

Regards,
Elwyn.

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Jan 2009 16:05:37 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

As Stephen pointed out -- yes, you could misuse the SBEB that way.  That's a flaw (surely one of many) I had not considered.  

You should propose a Bundle Chelation Extension Block...  

-----Original Message-----
From: Rajesh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2009 2:34 PM
To: Parikh, Salil
Cc: [email-masked]
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Looks like I may have misunderstood the purpose --  new version obsoleting old.

Can I use the SBEB to implement purging of arbitrary bundles?   Will
read the whole draft before I post any more. :)

Best Regards,
Rajesh

On Wed, Jan 7, 2009 at 2:12 PM, Rajesh Krishnan <[email-masked]> wrote:
> Hi Salil,
>
> From the abstract this sounds like a useful purge mechanism when
> applied in conjunction
> with replication-oriented (Epidemic-like) DTN routing approaches.
>
> Having a well-specified way to do that is a good thing.
>
> Best Regards,
> Rajesh
>
>
> On Wed, Jan 7, 2009 at 10:29 AM, Parikh, Salil <[email-masked]> wrote:
>> Hello,
>>
>>
>>
>> We have submitted an Internet-Draft titled "Delay-Tolerant Networking
>> Superseding Bundle Extension Block".  We welcome review and comment from the
>> DTNRG community.
>>
>>
>>
>> http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt
>>
>>
>>
>> Abstract:
>>
>>
>>
>> This document defines an optional Bundle Protocol block called the
>> Superseding Bundle Extension Block (SBEB) for use with the Bundle Protocol
>> in the context of the Delay-Tolerant Networking Architecture.  Applications
>> use this block to call for the removal of previously sent bundles that are
>> rendered obsolete by more recent bundles. Upon receiving a bundle with an
>> SBEB, a node will search its bundle store (and outbound queues) for bundles
>> that are obsoleted by other related bundles according to their source and
>> destination EID, and the SBEB cookie (if present), and may delete some or
>> all of them. Discarding obsolete bundles helps conserve storage space and
>> prevents expending resources in further forwarding bundles that are no
>> longer relevant.  The bundle protocol already uses expiration times to
>> remove bundles that are no longer useful to applications.  The SBEB is a way
>> for applications to mark bundles that a node may delete prior to their
>> expiration times.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Jan 2009 15:19:38 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Thanks for the review, Wes.  

Yes, your wording is exactly right.  The SBEB is just advisory.  The intention is for  applications to give the agents hints to help manage storage and reduce unnecessary bundle transmissions, but it doesn't guarantee that they will do so.  It's for the benefit of the agents and the network, not the applications.  

-----Original Message-----
From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[email-masked]] 
Sent: Wednesday, January 07, 2009 12:17 PM
To: Parikh, Salil; [email-masked]
Subject: RE: [dtn-interest] I-D: Delay-Tolerant Networking Superseding BundleExtension Block

Interesting.  It sounds like this is just advisory
information, since it says "may discard the other matching
bundles" in 4.3, so it's not trying to guarantee that only
a fixed number are kept, but just provide helpful hints
from apps to bundle agents in managing their storage.  Do
you agree?

You can get a similar effect through having local policy
configured in a bundle agent, such that a limit applies to
storage used per-flow (per EID-pair).  This would likely
be accounted in bytes rather than numbers of bundles.  A
bundle agent probably needs this anyways, just like an OS
has limits to the length of socket buffers, and it happens
without any traffic on the network or protocol effort.  I
guess the interactions with custody transfer are a bit
different with local resource control policy versus SBEB
though.

It should be pretty clear that this draft isn't aiming to
be a distrubuted cache management mechanism since it has
no control over whether the more-recent bundles with SBEB
follow the same path through the network as the prior ones,
and would be at the mercy of the routing and forwarding
mechanisms for that.

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

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Parikh, Salil
>Sent: Wednesday, January 07, 2009 10:30 AM
>To: [email-masked]
>Subject: [dtn-interest] I-D: Delay-Tolerant Networking 
>Superseding BundleExtension Block
>
>Hello,
>
> 
>
>We have submitted an Internet-Draft titled "Delay-Tolerant 
>Networking Superseding Bundle Extension Block".  We welcome 
>review and comment from the DTNRG community.
>
> 
>
>http://www.ietf.org/internet-drafts/draft-parikh-bundle-superse
>ding-extension-block-00.txt
>
> 
>
>Abstract:
>
> 
>
>This document defines an optional Bundle Protocol block called 
>the Superseding Bundle Extension Block (SBEB) for use with the 
>Bundle Protocol in the context of the Delay-Tolerant 
>Networking Architecture.  Applications use this block to call 
>for the removal of previously sent bundles that are rendered 
>obsolete by more recent bundles. Upon receiving a bundle with 
>an SBEB, a node will search its bundle store (and outbound 
>queues) for bundles that are obsoleted by other related 
>bundles according to their source and destination EID, and the 
>SBEB cookie (if present), and may delete some or all of them. 
>Discarding obsolete bundles helps conserve storage space and 
>prevents expending resources in further forwarding bundles 
>that are no longer relevant.  The bundle protocol already uses 
>expiration times to remove bundles that are no longer useful 
>to applications.  The SBEB is a way for applications to mark 
>bundles that a node may delete prior to their expiration times.
>
>

Date: Wed, 7 Jan 2009 14:34:15 -0500
From: "Rajesh Krishnan" <[email-masked]>
To: "Parikh, Salil" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Looks like I may have misunderstood the purpose --  new version obsoleting old.

Can I use the SBEB to implement purging of arbitrary bundles?   Will
read the whole draft before I post any more. :)

Best Regards,
Rajesh

On Wed, Jan 7, 2009 at 2:12 PM, Rajesh Krishnan <[email-masked]> wrote:
> Hi Salil,
>
> From the abstract this sounds like a useful purge mechanism when
> applied in conjunction
> with replication-oriented (Epidemic-like) DTN routing approaches.
>
> Having a well-specified way to do that is a good thing.
>
> Best Regards,
> Rajesh
>
>
> On Wed, Jan 7, 2009 at 10:29 AM, Parikh, Salil <[email-masked]> wrote:
>> Hello,
>>
>>
>>
>> We have submitted an Internet-Draft titled "Delay-Tolerant Networking
>> Superseding Bundle Extension Block".  We welcome review and comment from the
>> DTNRG community.
>>
>>
>>
>> http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt
>>
>>
>>
>> Abstract:
>>
>>
>>
>> This document defines an optional Bundle Protocol block called the
>> Superseding Bundle Extension Block (SBEB) for use with the Bundle Protocol
>> in the context of the Delay-Tolerant Networking Architecture.  Applications
>> use this block to call for the removal of previously sent bundles that are
>> rendered obsolete by more recent bundles. Upon receiving a bundle with an
>> SBEB, a node will search its bundle store (and outbound queues) for bundles
>> that are obsoleted by other related bundles according to their source and
>> destination EID, and the SBEB cookie (if present), and may delete some or
>> all of them. Discarding obsolete bundles helps conserve storage space and
>> prevents expending resources in further forwarding bundles that are no
>> longer relevant.  The bundle protocol already uses expiration times to
>> remove bundles that are no longer useful to applications.  The SBEB is a way
>> for applications to mark bundles that a node may delete prior to their
>> expiration times.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>

Date: Wed, 7 Jan 2009 14:12:51 -0500
From: "Rajesh Krishnan" <[email-masked]>
To: "Parikh, Salil" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Hi Salil,

>From the abstract this sounds like a useful purge mechanism when
applied in conjunction
with replication-oriented (Epidemic-like) DTN routing approaches.

Having a well-specified way to do that is a good thing.

Best Regards,
Rajesh

On Wed, Jan 7, 2009 at 10:29 AM, Parikh, Salil <[email-masked]> wrote:
> Hello,
>
>
>
> We have submitted an Internet-Draft titled "Delay-Tolerant Networking
> Superseding Bundle Extension Block".  We welcome review and comment from the
> DTNRG community.
>
>
>
> http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt
>
>
>
> Abstract:
>
>
>
> This document defines an optional Bundle Protocol block called the
> Superseding Bundle Extension Block (SBEB) for use with the Bundle Protocol
> in the context of the Delay-Tolerant Networking Architecture.  Applications
> use this block to call for the removal of previously sent bundles that are
> rendered obsolete by more recent bundles. Upon receiving a bundle with an
> SBEB, a node will search its bundle store (and outbound queues) for bundles
> that are obsoleted by other related bundles according to their source and
> destination EID, and the SBEB cookie (if present), and may delete some or
> all of them. Discarding obsolete bundles helps conserve storage space and
> prevents expending resources in further forwarding bundles that are no
> longer relevant.  The bundle protocol already uses expiration times to
> remove bundles that are no longer useful to applications.  The SBEB is a way
> for applications to mark bundles that a node may delete prior to their
> expiration times.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

Content-class: urn:content-classes:message
Date: Wed, 7 Jan 2009 11:16:43 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Parikh, Salil" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding BundleExtension Block

Interesting.  It sounds like this is just advisory
information, since it says "may discard the other matching
bundles" in 4.3, so it's not trying to guarantee that only
a fixed number are kept, but just provide helpful hints
from apps to bundle agents in managing their storage.  Do
you agree?

You can get a similar effect through having local policy
configured in a bundle agent, such that a limit applies to
storage used per-flow (per EID-pair).  This would likely
be accounted in bytes rather than numbers of bundles.  A
bundle agent probably needs this anyways, just like an OS
has limits to the length of socket buffers, and it happens
without any traffic on the network or protocol effort.  I
guess the interactions with custody transfer are a bit
different with local resource control policy versus SBEB
though.

It should be pretty clear that this draft isn't aiming to
be a distrubuted cache management mechanism since it has
no control over whether the more-recent bundles with SBEB
follow the same path through the network as the prior ones,
and would be at the mercy of the routing and forwarding
mechanisms for that.

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

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Parikh, Salil
>Sent: Wednesday, January 07, 2009 10:30 AM
>To: [email-masked]
>Subject: [dtn-interest] I-D: Delay-Tolerant Networking 
>Superseding BundleExtension Block
>
>Hello,
>
> 
>
>We have submitted an Internet-Draft titled "Delay-Tolerant 
>Networking Superseding Bundle Extension Block".  We welcome 
>review and comment from the DTNRG community.
>
> 
>
>http://www.ietf.org/internet-drafts/draft-parikh-bundle-superse
>ding-extension-block-00.txt
>
> 
>
>Abstract:
>
> 
>
>This document defines an optional Bundle Protocol block called 
>the Superseding Bundle Extension Block (SBEB) for use with the 
>Bundle Protocol in the context of the Delay-Tolerant 
>Networking Architecture.  Applications use this block to call 
>for the removal of previously sent bundles that are rendered 
>obsolete by more recent bundles. Upon receiving a bundle with 
>an SBEB, a node will search its bundle store (and outbound 
>queues) for bundles that are obsoleted by other related 
>bundles according to their source and destination EID, and the 
>SBEB cookie (if present), and may delete some or all of them. 
>Discarding obsolete bundles helps conserve storage space and 
>prevents expending resources in further forwarding bundles 
>that are no longer relevant.  The bundle protocol already uses 
>expiration times to remove bundles that are no longer useful 
>to applications.  The SBEB is a way for applications to mark 
>bundles that a node may delete prior to their expiration times.
>
>

Date: Wed, 07 Jan 2009 16:12:35 +0000
From: Stephen Farrell <[email-masked]>
To: "Parikh, Salil" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

Hi Salil,

Interesting draft. My immediate reaction (as a security type:-)
is that this is a nice new attack vector, so I'd argue that that
needs more discussion in the document.

E.g. without a cookie, the source, dest and timestamps could
be fairly easily guessable, which seems like a very easy attack
that could be launched off-path resulting in some or all of your
payloads being replaced by mine. (In your example, I could
replace a traffic camera image with something less desirable;-)

I'd say the cookie should at least be mandatory, (and of
reasonable length & randomness) so that at least off-path
attacks are hard.

I guess I could also argue that it ought be possible to
authenticate the SBEB as well, so that a policy requiring
the that the original source be the source of the replacement
can be implemented, or so that the source of the replacement
can be held accountable. There're probably a few ways this
could be done - have you thought about that?

Separately, I'd need to think about how this plays with
custody, e.g. setting a high retention count is sort-of
like a form of custody.

It also wasn't clear to me how varying retention count
values would be work out - if the most recent one is
less that a previous one that seems to assume that the
source knows where the bundles might be in the end-to-end
path, which is a bit odd. Raising the retention count
will be somewhat pointless until a number of bundles
have been sent etc. So maybe a bit more explanation
is needed there.

And lastly a nit: "Cookies only have meaning to the
application." seems odd & could be deleted.

Cheers,
Stephen.

Parikh, Salil wrote:
> Hello,
> 
>  
> 
> We have submitted an Internet-Draft titled �Delay-Tolerant Networking
> Superseding Bundle Extension Block�.  We welcome review and comment from
> the DTNRG community.
> 
>  
> 
> http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extension-block-00.txt
> 
>  
> 
> Abstract:
> 
>  
> 
> This document defines an optional Bundle Protocol block called the
> Superseding Bundle Extension Block (SBEB) for use with the Bundle
> Protocol in the context of the Delay-Tolerant Networking Architecture. 
> Applications use this block to call for the removal of previously sent
> bundles that are rendered obsolete by more recent bundles. Upon
> receiving a bundle with an SBEB, a node will search its bundle store
> (and outbound queues) for bundles that are obsoleted by other related
> bundles according to their source and destination EID, and the SBEB
> cookie (if present), and may delete some or all of them. Discarding
> obsolete bundles helps conserve storage space and prevents expending
> resources in further forwarding bundles that are no longer relevant. 
> The bundle protocol already uses expiration times to remove bundles that
> are no longer useful to applications.  The SBEB is a way for
> applications to mark bundles that a node may delete prior to their
> expiration times.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Parikh, Salil" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Jan 2009 10:29:47 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] I-D: Delay-Tolerant Networking Superseding Bundle Extension Block

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

Hello,

We have submitted an Internet-Draft titled "Delay-Tolerant Networking Super=
seding Bundle Extension Block".  We welcome review and comment from the DTN=
RG community.

http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding-extensi=
on-block-00.txt

Abstract:

This document defines an optional Bundle Protocol block called the Supersed=
ing Bundle Extension Block (SBEB) for use with the Bundle Protocol in the c=
ontext of the Delay-Tolerant Networking Architecture.  Applications use thi=
s block to call for the removal of previously sent bundles that are rendere=
d obsolete by more recent bundles. Upon receiving a bundle with an SBEB, a =
node will search its bundle store (and outbound queues) for bundles that ar=
e obsoleted by other related bundles according to their source and destinat=
ion EID, and the SBEB cookie (if present), and may delete some or all of th=
em. Discarding obsolete bundles helps conserve storage space and prevents e=
xpending resources in further forwarding bundles that are no longer relevan=
t.  The bundle protocol already uses expiration times to remove bundles tha=
t are no longer useful to applications.  The SBEB is a way for applications=
 to mark bundles that a node may delete prior to their expiration times.

--_000_06CBA47B9C3FA7409BF459DAA035248902611AB5EFIMCMBX3MITREO_
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:D=3D"DAV:" xmln=
s:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"ht=
tp://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schema=
s.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2=
000/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/sharepoin=
t/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://schema=
s.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSc=
hema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xm=
lns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D=
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schem=
as.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.mi=
crosoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsof=
t.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/=
package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats=
.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/off=
ice/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/=
2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpa=
ges" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/typ=
es" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/mess=
ages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibr=
ary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer=
/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: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;
	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>Hello,<o:p></o:p></p>

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

<p class=3DMsoNormal>We have submitted an Internet-Draft titled
&#8220;Delay-Tolerant Networking Superseding Bundle Extension
Block&#8221;.&nbsp; We welcome review and comment from the DTNRG community.=
<o:p></o:p></p>

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

<p class=3DMsoNormal><a
href=3D"http://www.ietf.org/internet-drafts/draft-parikh-bundle-superseding=
-extension-block-00.txt">http://www.ietf.org/internet-drafts/draft-parikh-b=
undle-superseding-extension-block-00.txt</a><o:p></o:p></p>

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

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

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

<p class=3DMsoNormal>This document defines an optional Bundle Protocol bloc=
k
called the Superseding Bundle Extension Block (SBEB) for use with the Bundl=
e
Protocol in the context of the Delay-Tolerant Networking Architecture.&nbsp=
;
Applications use this block to call for the removal of previously sent bund=
les
that are rendered obsolete by more recent bundles. Upon receiving a bundle =
with
an SBEB, a node will search its bundle store (and outbound queues) for bund=
les
that are obsoleted by other related bundles according to their source and
destination EID, and the SBEB cookie (if present), and may delete some or a=
ll
of them. Discarding obsolete bundles helps conserve storage space and preve=
nts
expending resources in further forwarding bundles that are no longer
relevant.&nbsp; The bundle protocol already uses expiration times to remove
bundles that are no longer useful to applications.&nbsp; The SBEB is a way =
for
applications to mark bundles that a node may delete prior to their expirati=
on
times.<o:p></o:p></p>

</div>

</body>

</html>

--_000_06CBA47B9C3FA7409BF459DAA035248902611AB5EFIMCMBX3MITREO_--

Content-class: urn:content-classes:message
Date: Tue, 6 Jan 2009 15:47:37 -0600
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN Network Management Teleconference meeting notes.

DTN Network Management - Collaborators
Meeting Notes for
Monday, January 5, 2009
1:00 - 2:00 EST (18:00 - 19:00 UTC)

A teleconference was held on Monday, January 5th.  The following
teleconference will be, Wednesday, January 21, 2009 due to Martin Luther
King Day and the Inauguration.

Participants:
*	BBN - Cambridge
*	Hans Kruse, Shawn Oysterman  - Ohio University
*	Will Ivancic and Joseph Ishac - NASA Glenn
*	Scott Burleigh - NASA JPL
*	Robert Cole (and others?) - Applied Physics Lab
*	Keith Scott ( and others?) - MITRE
Agenda:
==========

Discussions on the Requirements Document work in progress.

A very draft unofficial draft that changes often - nearly daily.  
http://roland.grc.nasa.gov/~ivancic/shared/DTN/draft-ivancic-dtnrg-netwo
rk-management-reqs-00.txt

Results:

* Scott Burleigh provided insight on the operations of DTN in the DINET
experiment (DTN using the Deep Impact spacecraft).  For the most part,
management was via out-of-DTN-band as would be expected for early
deployments of new technology.  Scott will provide a write up of
parameters and items that they found useful to track.  Mainly there were
of the category of statistical (logs), diagnostics (traps),
informational (i.e. available storage) and bundle reports.  The deep
impact spacecraft clock was also corrected for drift as it appeared to
be drifting at about 1 second per day. 

* The outline number needs to be corrected.  There is a misplaced
"section" termination.  This will be fixed in the next revision.

* Discussion on the Scenarios was mainly concerned with simple sensors
and the need to add a scenario for a multi-homed network.  

--- For simple sensor networks there may be cases were DTN makes sense
such as if these simple sensor are asleep often, but synchronized to the
extent that they can wake up a nearly the same time to communicate some
information.  These simple nodes would probably have limited network
management capability.  

--- A scenario whereby a DTN node may have multiple links with varying
capability was suggested.  Something like high rate satellite link that
may not always be available and very low rate link that might only be
used for meta-data to inform the end systems on what data may be
available to send down as bundles when the high-capacity link becomes
available.  Fortunately, Will Ivancic is working such a problem with
UAVs and will write this scenario up.

* There is a need to add a section in the document for items that need
to be monitored related to bundle processing.  This will be put up front
in the next revision.

* It would probably be useful to have the DTN aware applications be able
to pull the local DTN network management in order to determine actions.
Sort of like layer-2 triggers.  DTN triggers to a application to
indicate it can send data over a particular link.  DTN as a
store-and-forward technology probably needs to be much more system aware
(and visa versa) than highly connected networks.

* Stick to general requirements.  Remove section on specifics
requirements.
 
* The characteristics section should be short descriptions and
references (links) to needed documents.  We don't want to write MIB type
details here of everything that may get monitored.  It is to early to
know what we really want/need to monitor.

Mgmt over DTN Requirements
-----------------------
(Note: Fundamentally, need a model for the data pushing and pulling of
different types of data  to the management station.  Need to understand
the reliability of the data movement, e.g.,  traps versus informs.  What
are the operational requirements, e.g., storage, network, etc. )

Functional Requirements:

        + State Monitoring - Notifications (traps or informs)

        + Fault Monitoring - Notifications (traps or informs)

        + Configuration Mgmt - Load, validate and install, then
Notification of the change

        + Accounting and Performance Mgmt - off line, batch reporting
(pulled versus pushed)

        + Security Mgmt - who has accessed, e.g., are their multiple
managers?  Attempts  failed (authentication or encryption or integrity),
rejections, types of keys, types of algorithms supported, etc.

Architecture/Environmental Requirement:

        + Local and Remote mgmt?  Are these requirements for mgmt over
DTN networks (I think  they should focus on these requirements).

        + System and Network Characteristics/Constraints?

        + Security requirements? What level of secure access is
required?

******************************
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 

Date: Mon, 5 Jan 2009 11:36:48 -0800
From: Katia Obraczka <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], Katia Obraczka <[email-masked]>
Subject: [dtn-interest] CFP 1st IEEE Int. Workshop on Network Sci. For Comm. Networks (NetSciCom'09)

==============================================================
      PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS
   
                   NetSciCom 2009
   First IEEE International Workshop on Network Science
             For Communication Networks
   
         April 24, 2009 - Rio de Janeiro, Brazil
            http://www.asu.edu//NetSciCom2009
   
          In conjunction with IEEE Infocom 2009
===============================================================
   
SCOPE: 
   
Network Science is a newly emerging discipline with applications in a
variety of domains, such as, Communication Networks, Power Grid
Networks, Transportation Networks, Social Networks, Biological Networks
and Economics. Designing complex communication networks of the future
needs a deep understanding of the interplay between the physical-, the
communication- and the social networks involved. An understanding of
such interdependency can only be achieved by closer interaction between
Network Scientists, Communication Network Designers, and Social and
Behavioral Scientists. The goal of this workshop is to a provide a forum
where this diverse group of researchers can meet and exchange ideas that
will lead to deeper insights into the design of robust, efficient and
complex communication networks of the future.
   
TOPICS OF INTEREST: 
   
The topics of this workshop lie at the intersection of Network Science
and Communication Network Design - including Topology Design and
Analysis, Traffic Modeling, Traffic Routing, Social Media Analysis:
blogs and friendship networks, Bio-inspired networks, Internet scale
measurement and analysis of online communities, Social network analysis
with mobile phone data, Interdependency between power grid,
communication and transportation networks,
   
==================================================================
   
IMPORTANT DATES: 

Workshop date: April 24, 2009
   
Paper submission deadline: January 31, 2009 
Notification of acceptance: March 22, 2009 
Camera-ready version submission deadline: April 5, 2009
   
==================================================================
   
PROGRAM CO-CHAIRS:
   
Arun Sen, Arizona State U.
Andrea Richa, Arizona State U.
Katia Obraczka, UC Santa Cruz
   
PROGRAM COMMITTEE (partial list):
   
P. Varaiya, U.C. Berkeley
M. Mitzenmacher, Harvard Univ.
C. Scheideler, T.U. Munich
E. Silva, UFRJ, Brazil
R. Mateus, UFMG, Brazil
R. Bonneau, AFOSR
J. M. Coyle, ARO
J. J. Garcia-Luna-Aceves, UCSC
G. Konjevod, ASU
G. Xue, ASU
J. Walrand, U.C. Berkeley
K. Ramchandran, U.C. Berkeley
C. Qiao, Univ. Buffalo (SUNY)
M. Latapy, CNRS, France
C. Magnien, CNRS, France
J. Altmann, Int. Univ Germany
   
===================================================================