From aline.viana@inria.fr Wed May 2 05:20:15 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826B121F89C0 for ; Wed, 2 May 2012 05:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.759 X-Spam-Level: X-Spam-Status: No, score=-10.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERbhmV4U53sl for ; Wed, 2 May 2012 05:20:14 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9947521F89BA for ; Wed, 2 May 2012 05:20:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,516,1330902000"; d="scan'208,217";a="156389083" Received: from sphinx.lix.polytechnique.fr (HELO [192.168.112.171]) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 02 May 2012 14:20:11 +0200 Message-ID: <4FA1267A.4070608@inria.fr> Date: Wed, 02 May 2012 14:20:10 +0200 From: Aline Carneiro Viana User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary="------------090702080006080902050804" Subject: [dtn-interest] IEEE SECON 2012 Student Travel Grant X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 12:20:15 -0000 This is a multi-part message in MIME format. --------------090702080006080902050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (We apologize if you receive multiple copies of this announcement) ========== IEEE SECON 2012 Student Travel Grant Opportunities ========== SECON 2012 is pleased to provide a limited number of student travel grants to graduate students to participate in our conference, workshops, poster, and demo sessions. Travel support will provide funds to help defray, but not necessarily to cover entirely, the costs of student's travel, lodging, meals, and conference registration fees. We encourage participation from women and underrepresented minorities. Student Travel Grant Support The support is intended to partially cover the costs of student's travel, lodging, meals, conference registration, etc. The award will be handled via reimbursements. Each legitimate expense must be documented with an original official receipt (e.g., air ticket and hotel receipt). The reimbursement will be sent as a check via postal mail six to eight weeks after submitting the reimbursement forms and supporting receipts. Further details of the reimbursement procedure will be communicated to the award recipients. Eligibility for Student Travel Grants The eligibility criteria for student travel grants to attend SECON 2012 are as follows. Applicants must be full-time, currently registered students in engineering or related fields in a college or university at the time of application. Priority will be given to student authors with accepted papers, posters, or demos at SECON 2012 who would not otherwise be able to attend due to budgetary constraints. Priority is also given to students who are volunteers with SECON events. Special efforts will be made to recruit student participants who are underrepresented in STEM disciplines, and who are coming from diverse institutions Application Process and Notification The applicant should send an application containing: - A resume or CV of the applicant - A letter that (1) summarizes the applicant's current research interests / accomplishments and (2) describes how SECON will benefit his/her professional development. The student's advisor should send a supporting letter that (1) confirms that the student is in good academic standing in their graduate program, (2) explains why the student is in need of a travel grant, and (3) describes how SECON will benefit the student's research progress. Applications should be submitted by April 30 via email to the Travel Awards Chair (Patrick Tague, tague [at] cmu [dot] edu). Please use "SECON Student Travel Grant" in the subject line. PDF format is strongly recommended, and applications using unsupported formats may cause delay notification. The Student Travel Grant Committee will review all travel grant applications and notify applicants about award decisions by May 11. Important Dates Application Deadline: April 30, 2012 Decision: May 11, 2012 ** --------------090702080006080902050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

(We apologize if you receive multiple copies of this announcement)

==========
IEEE SECON 2012 Student Travel Grant Opportunities
==========


SECON 2012 is pleased to provide a limited number of student travel grants to graduate students to participate in our conference, workshops, poster, and demo sessions. Travel support will provide funds to help defray, but not necessarily to cover entirely, the costs of student's travel, lodging, meals, and conference registration fees. We encourage participation from women and underrepresented minorities.

Student Travel Grant Support

The support is intended to partially cover the costs of student's travel, lodging, meals, conference registration, etc. The award will be handled via reimbursements. Each legitimate expense must be documented with an original official receipt (e.g., air ticket and hotel receipt). The reimbursement will be sent as a check via postal mail six to eight weeks after submitting the reimbursement forms and supporting receipts. Further details of the reimbursement procedure will be communicated to the award recipients.

Eligibility for Student Travel Grants

The eligibility criteria for student travel grants to attend SECON 2012 are as follows.  Applicants must be full-time, currently registered students in engineering or related fields in a college or university at the time of application.  Priority will be given to student authors with accepted papers, posters, or demos at SECON 2012 who would not otherwise be able to attend due to budgetary constraints. Priority is also given to students who are volunteers with SECON events. Special efforts will be made to recruit student participants who are underrepresented in STEM disciplines, and who are coming from diverse institutions

Application Process and Notification

The applicant should send an application containing:
- A resume or CV of the applicant
- A letter that (1) summarizes the applicant's current research interests / accomplishments and (2) describes how SECON will benefit his/her professional development.

The student's advisor should send a supporting letter that (1) confirms that the student is in good academic standing in their graduate program, (2) explains why the student is in need of a travel grant, and (3) describes how SECON will benefit the student's research progress.
Applications should be submitted by April 30 via email to the Travel Awards Chair (Patrick Tague, tague [at] cmu [dot] edu). Please use "SECON Student Travel Grant" in the subject line. PDF format is strongly recommended, and applications using unsupported formats may cause delay notification. The Student Travel Grant Committee will review all travel grant applications and notify applicants about award decisions by May 11.

Important Dates

Application Deadline: April 30, 2012
Decision: May 11, 2012

 
--------------090702080006080902050804-- From aline.viana@inria.fr Mon May 7 02:59:40 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA821F859A for ; Mon, 7 May 2012 02:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.153 X-Spam-Level: X-Spam-Status: No, score=-8.153 tagged_above=-999 required=5 tests=[AWL=-2.606, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-kcyPNpesSS for ; Mon, 7 May 2012 02:59:38 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id A47D821F8593 for ; Mon, 7 May 2012 02:59:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,543,1330902000"; d="scan'208,217";a="157027877" Received: from sphinx.lix.polytechnique.fr (HELO [192.168.112.171]) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 May 2012 11:59:34 +0200 Message-ID: <4FA79D07.40103@inria.fr> Date: Mon, 07 May 2012 11:59:35 +0200 From: Aline Carneiro Viana User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary="------------030708080608030708000006" Subject: [dtn-interest] =?windows-1252?q?Call_for_participation_=96_IEEE_S?= =?windows-1252?q?ECON_2012_-_Early_registration_deadline_May_29?= X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:59:40 -0000 This is a multi-part message in MIME format. --------------030708080608030708000006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit *********************************************************************************** [Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).] *********************************************************************************** CALL FOR PARTICIPATION IEEE SECON 2012 9th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/ June 18-21, 2012 - Seoul, Korea *********************************************************************************** * IMPORTANT DATES Discounted hotel reservation deadline29 May 2012 Early registration deadline29 May 2012 Conference dates 18-21 June 2012 Workshops (ETSIoT’12 and VCSC’12) date18 June 2012 * SCOPE: Building on the success of previous years, IEEESECON2012provides a unique forum to exchange innovative research ideas, recent results, and share experiences among researchers and practitioners in the field of sensor, mesh, and ad hoc networks and systems.IEEE SECON grew out of the IEEE INFOCOM conference in 2004, in order to create an event that focused on the important and exciting topics of Sensor, Mesh and Ad Hoc Communications Networks. In addition to the traditional topics published in SECON, this year the conference especially brings papers in emerging applications and services, involving sensor, mesh and ad-hoc communications, such as green technologies, smart grids, urban sensing systems, the Internet of Things, social networking, etc. * KEYNOTE SPEAKERS:Dr. Kang G. Shin (Professor at the University of Michigan) and Dr. Yoonchae Cheong (Senior Vice President at the Samsung Advanced Institute of Technology, Samsung Electronics Co. Ltd.). * TECHNICAL PROGRAM:67papershavebeenacceptedfor presentationandforpublicationintheconference proceedings. The complete list of accepted papers can be found on-line at the conference web page: http://www.ieee-secon.org/program.html * PANEL:The panel will provide discussion on “M2M/D2D toward Beyond 4G Wireless”. * Workshops: IEEE SECON 2012 features two workshops to be held on June 18, 2012: 1. The IEEE Workshop on Enabling Technologies for Smartphone and Internet of Things (ETSIoT) 2012 aims to provide a forum for academic researchers and industrial experts possessing the vision of IoT with smartphones. 2. The IEEE Workshop on Vehicular Communications, Sensing, and Computing (VCSC) 2012 aims to cover all related topics of intra/inter-vehicular communications, sensing on the road, and computing to support safer and more efficient driving. * POSTERS/DEMOS: IEEE SECON 2012 includes poster and demostration sessions providing a forum to present and discuss works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. This year IEEE SECON is also running a best poster and best demo award competition. Awards will be based on the novelty and the potentials of the poster/demo to drive further research. * STUDENTTRAVELGRANTS: TheIEEESECON 2012organizing committee is pleased to provide a limited number of Student Travel Grantsto graduate students to participate in our conference, workshops, poster, and demo sessions. See more information at http://www.ieee-secon.org/sttravel.html. * SPONSORS: IEEE SECON 2012 organizing committee is pleased to announce it has 3 Gold patrons (ETRI, HP Laboratories, and Samsung Electronics) and 3 Silver patrons (IBM Research, INRIA, and KEPCO). See more information at http://www.ieee-secon.org/patrons.html. ** * VENUE: IEEE SECON 2012 will take place at the Millennium Seoul Hilton at395, 5-ga, Namdaemun-ro, Jung-gu, Seoul, South Korea 100-802. A block of rooms have been reserved for June 15, 2012 - June 23, 2012. The special room rate will be available until May 29th or until the group block is sold-out, whichever comes first.Pleasemakeyourhotel arrangements early in order toinsure getting a room at the special conferencerate price. Reservations can be made on-line http://www.hilton.com/en/hi/groups/personalized/S/SELHITW-GIEE06-20120615/index.jhtml?WT.mc_id=POG. --------------030708080608030708000006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

***********************************************************************************

 

[Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).]

 

***********************************************************************************

                               CALL FOR PARTICIPATION

 

                                    IEEE SECON 2012

                   9th Annual IEEE Communications Society Conference on

                  Sensor, Mesh and Ad Hoc Communications and Networks

                             http://www.ieee-secon.org/

 

                          June 18-21, 2012 - Seoul, Korea

***********************************************************************************

 

* IMPORTANT DATES

  Discounted hotel reservation deadline       29 May 2012

  Early registration deadline                 29 May 2012

  Conference dates                           18-21 June 2012

  Workshops (ETSIoT’12 and VCSC’12) date      18 June 2012

 

 

* SCOPE: Building on the success of previous years, IEEE  SECON  2012  provides a unique forum to exchange innovative research ideas, recent results, and share experiences among researchers and practitioners in the field of sensor, mesh, and ad hoc networks and systems.  IEEE SECON grew out of the IEEE INFOCOM conference in 2004, in order to create an event that focused on the important and exciting topics of Sensor, Mesh and Ad Hoc Communications Networks. In addition to the traditional topics published in SECON, this year the conference especially brings papers in emerging applications and services, involving sensor, mesh and ad-hoc communications, such as green technologies, smart grids, urban sensing systems, the Internet of Things, social networking, etc.

 

* KEYNOTE SPEAKERS:  Dr. Kang G. Shin (Professor at the University of Michigan) and Dr. Yoonchae Cheong (Senior Vice President at the Samsung Advanced Institute of Technology, Samsung Electronics Co. Ltd.).

 

* TECHNICAL PROGRAM:  67  papers  have  been  accepted  for presentation   and  for   publication   in  the   conference proceedings. The complete list of accepted papers can be found on-line at the conference web page: http://www.ieee-secon.org/program.html

 

* PANEL:  The panel will provide discussion on “M2M/D2D toward Beyond 4G Wireless”.

 

* Workshops: IEEE SECON 2012 features two workshops to be held on June 18, 2012:

1. The IEEE Workshop on Enabling Technologies for Smartphone and Internet of Things (ETSIoT) 2012 aims to provide a forum for academic researchers and industrial experts possessing the vision of IoT with smartphones.

 

2. The IEEE Workshop on Vehicular Communications, Sensing, and Computing (VCSC) 2012 aims to cover all related topics of intra/inter-vehicular communications, sensing on the road, and computing to support safer and more efficient driving.

 

* POSTERS/DEMOS: IEEE SECON 2012 includes poster and demostration sessions providing a forum to present and discuss works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. This year IEEE SECON is also running a best poster and best demo award competition. Awards will be based on the novelty and the potentials of the poster/demo to drive further research. 

 

* STUDENT  TRAVEL  GRANTS: The  IEEE  SECON 2012  organizing committee is pleased to provide a limited number of Student Travel Grants  to graduate students to participate in our conference, workshops, poster, and demo sessions. See more information at http://www.ieee-secon.org/sttravel.html.

 

* SPONSORS: IEEE SECON 2012 organizing committee is pleased to announce it has 3 Gold patrons (ETRI, HP Laboratories, and Samsung Electronics) and 3 Silver patrons (IBM Research, INRIA, and KEPCO). See more information at http://www.ieee-secon.org/patrons.html.

 

 

* VENUE: IEEE SECON 2012 will take place at the Millennium Seoul Hilton at  395, 5-ga, Namdaemun-ro, Jung-gu, Seoul, South Korea 100-802. A block of rooms have been reserved for June 15, 2012 - June 23, 2012. The special room rate will be available until May 29th or until the group block is sold-out, whichever comes first.  Please  make   your  hotel arrangements early in order to  insure getting a room at the special conference  rate price. Reservations can be made on-line http://www.hilton.com/en/hi/groups/personalized/S/SELHITW-GIEE06-20120615/index.jhtml?WT.mc_id=POG.


--------------030708080608030708000006-- From RAFFAELE.BRUNO@IIT.CNR.IT Tue May 8 09:11:06 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6ED21F8608 for ; Tue, 8 May 2012 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk0gm1kscSam for ; Tue, 8 May 2012 09:10:59 -0700 (PDT) Received: from smtp.iit.cnr.it (mx7.iit.cnr.it [146.48.98.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDD621F85C3 for ; Tue, 8 May 2012 09:10:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 3E5E812EEB9 for ; Tue, 8 May 2012 18:10:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx7.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx7.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tXh6fiNRbu7 for ; Tue, 8 May 2012 18:09:28 +0200 (CEST) Received: from bruno.iit.cnr.it (bruno.iit.cnr.it [146.48.98.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id EC32012EE8D for ; Tue, 8 May 2012 18:09:27 +0200 (CEST) From: Raffaele Bruno Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2012 18:09:30 +0200 Message-Id: <33881B3C-1DFB-4EBD-9911-76213C0A4D3D@IIT.CNR.IT> To: dtn-interest@irtf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dtn-interest] ACM Q2SWinet 2012: Call for Papers X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:11:06 -0000 Please accept our apologies if you receive multiple copies of this CFP. ---------------------------------------------------------------------- CALL FOR PAPERS The 8th ACM* Symposium on QoS and Security for Wireless Mobile Networks (ACM Q2SWinet 2012) October 21st-25th, 2012 Paphos, Cyprus=20 http://cnd.iit.cnr.it/q2swinet2012 Jointly held with the 15th ACM MSWiM 2012 Conference. * ACM Pending upon Approval **** Paper Registration Deadline --- May 30th, 2012 **** = =20 ---------------------------------------------------------------------- SCOPE AND OVERVIEW -------------------------------- In recent years, wireless and mobile communication systems have become = increasingly popular as an inexpensive and promising means for = ubiquitous communications. In this scenario, the QoS provisioning and = the management of network security have become crucial tasks to = determine the success of future generation wireless mobile networks.This = symposium calls for cutting-edge research achievements on the = provisioning of QoS and Security in wireless and mobile networks. It = also aims at increasing the synergy between academic and industry = professionals working in this area.=09 Authors are encouraged to submit full papers presenting new research = related to theory or practice of all aspects of Quality of Service and = Security issues in mobile and wireless systems.=20 Topics of interest for ACM Q2SWinet 2012 include, but are not limited = to: + Security in Wireless MANETs, VANETs, Sensor, Mesh and PCS Networks + Secure PHY, MAC and Routing Protocols =09 + Secure Cooperation-Based Systems and Services + Security for Cognitive Radio Networks + Intrusion Detection in Wireless Ad hoc and Sensor Networks + Privacy, anonymity and authentication + Trust Establishment + Cooperation and Prevention of Non-cooperative Behavior=20 + Incentive Aware Secure Protocol Design + QoS/QoE for Wireless Multimedia Networks and Systems + QoS/QoE for Wireless/Wired Hybrid Systems + QoS/QoE support and Mobility Management in Wireless Internet=20 + QoS/QoE-Aware Routing for Wireless Networks + QoS/QoE Metrics + Wireless Network Survivability + Wireless Systems Reliability + Field operating tests, Performance Modeling and Simulation Techniques + Real-time and QoS-aware Wireless Networks=20 PAPER SUBMISSION AND PUBLICATION -------------------------------- Papers should neither have been published elsewhere nor being currently = under review by another conference or journal. Manuscripts are limited = to 10 pages, single spacing, double column, and must strictly adhere to = the ACM template format. Guidelines on paper submission and = formatting are availableathttp://cnd.iit.cnr.it/q2swinet2012/.=20 Submission is managed electronically through EDAS: = http://edas.info/N12037 At least one author of each accepted paper must be registered for the = symposium, in order for that paper to appear in the ACM proceedings and = to be scheduled for presentation. Furthermore, authors of accepted = papers must guarantee that their paper will be presented at the = Symposium.=20 IMPORTANT DATES --------------- Paper registration: May 30th, 2012 Paper submission: June 5th, 2012 Notification: July 15th, 2012 Symposium: October 21st-25th, 2012 ORGANIZING COMMITTEE -------------------- General Chair Peter Mueller, IBM Zurich Research Laboratory, Switzerland =20 Program Committee Chairs Jalel Ben-Othman, University of Paris 13, France Raffaele Bruno, IIT, CNR, Italy Program Committee (tentative) Nael Abu-Ghazaleh, State University of New York at Binghamton, USA Gergely Acs, INRIA, Rhone-Alpes, France Emilio Ancillotti, IIT-CNR, Italy Regina Araujo, Federal University of Sao Carlos, Brazil Jalel Ben-othman, University of Versailles, France Boldizsar Bencsath, Budapest University of Tech. and Economics, Hungary Luciano Bononi, University of Bologna, Italy Azzedine Boukerche, University of Ottawa, Canada Roberto Cascella, INRIA, France Lloren=E7 Cerdra-Alabern, Universitat Politecnica de Catalunya, Spain Matteo Cesana, Politecnico di Milano, Italy Bruno Crispo, University of Trento, Italy Roberto Di Pietro, Universita' di Roma Tre, Italy Falko Dressler, University of Erlangen Rosario Garroppo, University of Pisa, Italy Fabrizio Granelli, University of Trento, Italy Stefanos Gritzalis, University of the Aegean, Greece Dimitrios Koutsonikolas, University at Buffalo, SUNY, USA Albert Levi, Sabanci University, Turkey Lynda Mokdad, Universit=E9 de Paris 12, France Peter Mueller, IBM Zurich Research Laboratory, Switzerland Stefano Paris, University of Bergamo, Italy Mahalingam Ramkumar, Mississippi State University, USA Peter Reiher, UCLA, USA Simon Pietro Romano, University of Napoli Federico II, Italy Susana Sargento, University of Aveiro, Portugal Ahmed Serhrouchni, ENST, France Sabrina Sicari, University of Insubria, Italy Vasilios Siris, Athens University of Economics and Business, Greece Avinash Srinivasan, George Mason University, USA Damla Turgut, University of Central Florida, USA Giacomo Verticale, Politecnico di Milano, Italy Andr=E9 Zuquete, University of Aveiro, Portugal Albert Zomaya, The University of Sydney, Australia Publicity Co-chairs=20 Victor Govindaswamy, University of Texas at Arlington, USA Maddalena Nurchis, IIT, CNR, Italy _______________________________________________ Ukubinet-announce mailing list Ukubinet-announce@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/ukubinet-announce --------------------------------------------------------------------- To unsubscribe, e-mail: infq-unsubscribe@infq.it For additional commands, e-mail: infq-help@infq.it From zhd5408@gmail.com Wed May 9 01:56:04 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7626021F854E for ; Wed, 9 May 2012 01:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF22w0VOcqtn for ; Wed, 9 May 2012 01:56:03 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 95E5421F855A for ; Wed, 9 May 2012 01:56:00 -0700 (PDT) Received: by dadv36 with SMTP id v36so57437dad.13 for ; Wed, 09 May 2012 01:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=7N9lazfvVlpVYY0ibz1l1Ll6pArUf2b7fxk01tRiAT8=; b=oRwVTXME+3APLAgQgzWRUhwmPXgCxQjQj1yORKImNAxkpC8dwbJ79kEjVFiaVTe8Ll v9Uz33BcOUl2UM8bR/mTeP4aIbXOHB6ByKDXRoF/mMqpdAu435NaqoR+I78Zb6bF2md1 AieMgK3CSPPKsA/FVCsCp8tigLke+cOl5uWkvq0blkSjogktAuDZ9w2jiPoI8KYDMRf3 d5hCrmkvRvxyVGymBs7kMy5BhzNfTF98rqkCBw/3UeSkeI4pmhAFR3L1sy0ivMQ5kheh 9HsqNZeI4giHGtu52SRKwiinOidJ/CYBxKrxLvxDGr0jvd1prykt3cD2EvxMo0gd/vcz du+A== Received: by 10.68.190.5 with SMTP id gm5mr6880376pbc.21.1336553758798; Wed, 09 May 2012 01:55:58 -0700 (PDT) Received: from WIN-6HKLPKIT3IE ([113.219.19.66]) by mx.google.com with ESMTPS id rs3sm3732946pbc.47.2012.05.09.01.55.54 (version=SSLv3 cipher=OTHER); Wed, 09 May 2012 01:55:57 -0700 (PDT) Date: Wed, 9 May 2012 16:56:07 +0800 From: zhd5408 To: dtn-interest X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201205091656034891078@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart587137817104_=----" Subject: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhd5408 List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 08:56:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart587137817104_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Tm93IGFsbW9zdCBhbGwgdGhlIERUTiBpbXBsZW1lbnQgd2l0aCBBZGRpbmcgYnVuZGxlIGxheWVy IGJldHdlZW4gYXBwbGljYXRpb24gYW5kIHRyYW5zcG9ydCBsYXllci4gDQoNClRoZXNlIERUTiBh cmUgc2VwYXJhdGVkIHdpdGggTUFORVQgY29tcGxldGVseSwgYWxsIHRoZSBkYXRhIGZyb20gTUFO RVQgc2hvdWxkIGJlIHRyYW5zbGF0ZWQgdGhyb3VnaCB0aGUgRFROIGdhdGV3YXkgYW5kIGFsbCB0 aGUgYXBwbGljYXRpb25zIHVzZWQgaW4gRFROIG11c3QgYmUgcmVkZXNpZ25lZC5CdXQgTUFORVQg YW5kIERUTiBjYW4gY29leGlzdCBpbiBzb21lIGNhc2VzLg0KDQpJIHdvbmRlciB0aGF0IHdoZXRo ZXIgY2FuIHdlIGRlc2lnbiBEVE4gdmlhIG1vZGlmeWluZyB0aGUgbmV0d29yayBsYXllciwgbm90 IHVzaW5nIEJQLiBUaHVzIHRoZSBNQU5FVCBhbmQgRFROIGNhbiBjb2V4aXN0IGFuZCBpdCBpcyB0 cmFuc3BhcmVudCBmb3IgdXBwZXIgbGF5ZXJzLiAgQWxsIHRoZSBhcHBsaWNhdGlvbnMgZG9uJ3Qg bmVlZCB0byBtb2RpZnkuDQoNCklmIHRvIGRvIHNvLiBXaGF0IHByb2JsZW1zIHdpbGwgZW5jb3Vu dGVyPyBvciBpcyBpdCBwb3NzaWJsZT8NCg0KDQoNCg0KaGV5ZWFzdA== ------=_001_NextPart587137817104_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Now almost all the DTN implement with Adding bundle layer betwee= n=20 application and transport layer.
 
These DTN are separated with MANET completely, all the data from= MANET=20 should be translated through the DTN gateway and all the applications= used=20 in DTN must be redesigned.But MANET and DTN can coexist in some=20 cases.
 
I wonder that whether can we design DTN via modifying the n= etwork=20 layer, not using BP. Thus the MANET and DTN can coexist and it i= s=20 transparent for upper layers.  All the applications don't n= eed to=20 modify.
 
If to do so. What problems will encounter? or is it possible?
 

heyeast
------=_001_NextPart587137817104_=------ From kscott@mitre.org Wed May 9 05:26:36 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503B121F8603 for ; Wed, 9 May 2012 05:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUEwsiQamgrK for ; Wed, 9 May 2012 05:26:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD75D21F8533 for ; Wed, 9 May 2012 05:26:33 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 669FF21B139C; Wed, 9 May 2012 08:26:29 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4545321B0B18; Wed, 9 May 2012 08:26:29 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Wed, 9 May 2012 08:26:28 -0400 From: "Scott, Keith L." To: zhd5408 , dtn-interest Thread-Topic: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? Thread-Index: AQHNLcGTCp5Svdpp4UGYfJmNPA85XpbBXpBA Date: Wed, 9 May 2012 12:26:27 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG> References: <201205091656034891078@gmail.com> In-Reply-To: <201205091656034891078@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5IMCMBX01MITREORG_" MIME-Version: 1.0 Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 12:26:36 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5IMCMBX01MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you mean 'can DTN be implemented underneath the sockets API'? And, if y= ou want this to be completely transparent to applications, presumably 'hidi= ng underneath SOCK_STREAM or SOCK_DGRAM'? In a sense, there's nothing in IP that prevents you from storing IP datagra= ms while waiting for a forward path to become available; the issues in impl= ementing IP this way all have to do with the things around IP, e.g.: * Routing implementations that drop datagrams when no next hop is a= vailable * ARP (which has timeouts) * DNS queries (which have timeouts) * Routing protocols like OSPF (which have timeouts and which typica= lly do not deal well with either scheduled connectivity or temporary partit= ions) * Applications that expect either 1) real-time connectivity from IP= -or- 2) no connectivity (but not a possibly-delayed store-and-forward serv= ice) Routing's probably NOT an issue here if we're talking about MANETs since we= could tweak the MANET routing protocols, but some of the others (esp. appl= ication expectations) are a bit problematic. You'd also need to worry abou= t how/if you want to implement things like custody transfer, the various bu= ndle notifications, etc. That said, there are implementations of BP that live underneath IP (BBN has= an implementation that does this). The chances are that the class of appl= ications that would be amenable to 'transparent' transplantation to use BP = services are UDP-based, and for these (if the applications don't have timer= s that would preclude it) you might consider using the DTN Tunnel that's in= the DTN2 reference implementation or an equivalent. That is, if the appli= cation can handle it, just tunnel UDP over BP. If the application can't ha= ndle it, then hiding BP underneath the sockets API wouldn't work (without m= odifying the application) anyway. Another approach would be to ask: what's the MANET getting you that DTN/BP = can't (or doesn't)? --keith From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of zhd5408 Sent: Wednesday, May 09, 2012 4:56 AM To: dtn-interest Subject: [dtn-interest] Can we implement DTN in Network layer of protocol s= tack ? Now almost all the DTN implement with Adding bundle layer between applicati= on and transport layer. These DTN are separated with MANET completely, all the data from MANET shou= ld be translated through the DTN gateway and all the applications used in D= TN must be redesigned.But MANET and DTN can coexist in some cases. I wonder that whether can we design DTN via modifying the network layer, no= t using BP. Thus the MANET and DTN can coexist and it is transparent for up= per layers. All the applications don't need to modify. If to do so. What problems will encounter? or is it possible? ________________________________ heyeast --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5IMCMBX01MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do you mean ‘can DT= N be implemented underneath the sockets API’?  And, if you want = this to be completely transparent to applications, presumably ‘hiding= underneath SOCK_STREAM or SOCK_DGRAM’?

In a sense, there’s= nothing in IP that prevents you from storing IP datagrams while waiting fo= r a forward path to become available; the issues in implementing IP this way all have to do with the things around IP, e.g.:

·       &= nbsp; Routing implement= ations that drop datagrams when no next hop is available<= /p>

·       &= nbsp; ARP (which has ti= meouts)

·       &= nbsp; DNS queries (whic= h have timeouts)

·       &= nbsp; Routing protocols= like OSPF (which have timeouts and which typically do not deal well with e= ither scheduled connectivity or temporary partitions)

·       &= nbsp; Applications that= expect either 1) real-time connectivity from IP –or- 2) no connectiv= ity (but not a possibly-delayed store-and-forward service)

Routing’s probably NOT an issue here if we’re talking abou= t MANETs since we could tweak the MANET routing protocols, but some of the others (esp. application expectations) are a bit problematic.  Yo= u’d also need to worry about how/if you want to implement things like= custody transfer, the various bundle notifications, etc.=

That said, there are implementations of BP that live underneath IP (BB= N has an implementation that does this).  The chances are that the class of applications that would be amenable to ‘transparen= t’ transplantation to use BP services are UDP-based, and for these (i= f the applications don’t have timers that would preclude it) you migh= t consider using the DTN Tunnel that’s in the DTN2 reference implementation or an equivalent.  That is, if the applicati= on can handle it, just tunnel UDP over BP.  If the application canR= 17;t handle it, then hiding BP underneath the sockets API wouldn’t wo= rk (without modifying the application) anyway.

Another approach would be to ask: what’s the MANET getting you t= hat DTN/BP can’t (or doesn’t)?

           &nbs= p;            &= nbsp;    --keith

From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of zhd5408
Sent: Wednesday, May 09, 2012 4:56 AM
To: dtn-interest
Subject: [dtn-interest] Can we implement DTN in Network layer of pro= tocol stack ?

 

Now almost all the DTN impleme= nt with Adding bundle layer between application and transport layer.

 

These DTN are separated w= ith MANET completely, all the data from MANET should be translated thr= ough the DTN gateway and all the applications used in DTN must be redesigne= d.But MANET and DTN can coexist in some cases.

 

I wonder that whether can we d= esign DTN via modifying the network layer, not using BP. Thu= s the MANET and DTN can coexist and it is transparent for upper l= ayers.  All the applications don't need to modify.

 

If to do so. What problems wil= l encounter? or is it possible?

 


heyeast

--_000_5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5IMCMBX01MITREORG_-- From jeremiah.scholl@ki.se Thu May 10 02:02:06 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6117F21F8517 for ; Thu, 10 May 2012 02:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWOVX7Lq4lnp for ; Thu, 10 May 2012 02:02:04 -0700 (PDT) Received: from smtp5.ki.se (smtp5.ki.se [130.237.99.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD4F21F851C for ; Thu, 10 May 2012 02:02:02 -0700 (PDT) Received: from KIMSX11.user.ki.se (kimsx11.user.ki.se [130.229.20.28]) by smtp5.ki.se (Postfix) with ESMTP id 4225629605B; Thu, 10 May 2012 11:02:01 +0200 (CEST) Received: from KIMSX02.user.ki.se ([fe80::1cf5:a8ad:9211:9e02]) by KIMSX11.user.ki.se ([::1]) with mapi id 14.01.0355.002; Thu, 10 May 2012 11:02:00 +0200 From: Jeremiah Scholl To: "dtn-interest@irtf.org" Thread-Topic: DTN enabled printer or fax machine? Thread-Index: Ac0uipkLzKF363IpRaSCk7foLxEDJg== Date: Thu, 10 May 2012 09:01:59 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.10.141.24] Content-Type: multipart/alternative; boundary="_000_C346AC0B17BB2742B5B622D35D08A56E31D0FCC1KIMSX02userkise_" MIME-Version: 1.0 Cc: Shabbir Subject: [dtn-interest] DTN enabled printer or fax machine? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 09:02:06 -0000 --_000_C346AC0B17BB2742B5B622D35D08A56E31D0FCC1KIMSX02userkise_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello DTN people. Just now I was looking the presentation slides at the li= nk below, specifically slide 10. It shows an "sms printer" that is used fo= r printing out results from laboratory tests so they can be returned to a c= linic via SMS, instead of requiring the physical transport of paper records= . http://www.teampata.org/downloads/presentations/2011/2%20Shaffiq%20Essajee%= 20Fast%20tracking%20infants.pdf The idea is being applied to reduce the time from when tests are taken of i= nfants that might have HIV, to when they can put them on Anti Retroviral Tr= eatment. It made me wonder if anyone has implemented a "dtn printer" or "dtn fax mac= hine". It could be used as a substitute for paper mail, where SMS is not th= e best alternative. It could provide several advantages. For example, some studies that transmit health information to mobile phones= run into problems because the phones get stolen. The printer hardware wou= ld not be so useful for general purposes however, like a mobile phone is, s= o the incentive to steal one would not be as great. Also in situations wher= e you want a paper copy of the information that a DTN network is transmitti= ng, then the usability would be much better than having a general computer-= printer combo. This is usually the case in a healthcare setting since the = remote clinics that would use a system like this use paper records and it i= s quite difficult to get them to change over to completely use electronic r= ecords. Also potentially you could transmit much nicer documents than the SMS versi= on. So I have two questions.... a) Has anyone ever implemented a DTN-enabled fax machine or printer? b) If not would anyone be interested in creating an open source hardwa= re/software implementation of one? I think that it could be useful in the h= ealthcare domain. Jeremiah ---------------------------------------------- Jeremiah Scholl, Ph.D. Senior Researcher Health Informatics Centre Karolinska Institutet +46852483926 --_000_C346AC0B17BB2742B5B622D35D08A56E31D0FCC1KIMSX02userkise_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello DTN people.  Just no= w I was looking the presentation slides at the link below, specifically sli= de 10.  It shows an “sms printer” that is used for printin= g out results from laboratory tests so they can be returned to a clinic via SMS, instead of requiring the physical transport of paper = records. 

 

http://www.teampata.org/downloads/presentations/2011/2%20Shaff= iq%20Essajee%20Fast%20tracking%20infants.pdf

 

The idea is being applied to re= duce the time from when tests are taken of infants that might have HIV, to = when they can put them on Anti Retroviral Treatment.

 

It made me wonder if anyone has= implemented a ”dtn printer” or “dtn fax machine”. = It could be used as a substitute for paper mail, where SMS is not the best = alternative. It could provide several advantages.

 

For example, some studies that = transmit health information to mobile phones run into problems because the = phones get stolen.  The printer hardware would not be so useful for ge= neral purposes however, like a mobile phone is, so the incentive to steal one would not be as great. Also in situation= s where you want a paper copy of the information that a DTN network is tran= smitting, then the usability would be much better than having a general com= puter-printer combo. This is usually the case in  a healthcare setting since the remote clinics that would= use a system like this use paper records and it is quite difficult to get = them to change over to completely use electronic records.=

 

Also potentially you could tran= smit much nicer documents than the SMS version. 

 

So I have two questions….=

 

a) &nbs= p;    Has anyone ever impleme= nted a DTN-enabled fax machine or printer?

b) &nbs= p;    If not would anyone be = interested in creating an open source hardware/software implementation of o= ne? I think that it could be useful in the healthcare domain.

 

Jeremiah

 

--= --------------------------------------------

Je= remiah Scholl, Ph.D.

Se= nior ResearcherHe= alth Informatics Centre

Karolinska Instit= utet

+46852483926<= /span>

--_000_C346AC0B17BB2742B5B622D35D08A56E31D0FCC1KIMSX02userkise_-- From aline.viana@inria.fr Thu May 10 07:47:30 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EBC21F860F for ; Thu, 10 May 2012 07:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keRbwdOe47S4 for ; Thu, 10 May 2012 07:47:29 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 03E4D21F8604 for ; Thu, 10 May 2012 07:47:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,565,1330902000"; d="scan'208,217";a="157869400" Received: from sphinx.lix.polytechnique.fr (HELO [192.168.112.171]) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 May 2012 16:47:26 +0200 Message-ID: <4FABD4FF.5070201@inria.fr> Date: Thu, 10 May 2012 16:47:27 +0200 From: Aline Carneiro Viana User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary="------------030207010201030903060006" Subject: [dtn-interest] =?windows-1252?q?Call_for_Participation_=96_ACM_Ho?= =?windows-1252?q?tPlanet_2012_-_Early_registration_deadline_May_24?= X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:47:31 -0000 This is a multi-part message in MIME format. --------------030207010201030903060006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit *********************************************************************************** [Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).] *********************************************************************************** CALL FOR PARTICIPATION ACM HotPlanet 2012 - The 4th ACM International Workshop on Hot Topics in Planet-Scale Measurement June 25, Low Wood Bay, Lake District, UK http://www.hotplanetconf.net *********************************************************************************** * IMPORTANT DATES Early registration deadlineMay 24, 2012 Workshop dateJune 25, 2012 * SCOPE: It is well-known that successfully researching, designing and building new mobile, ad-hoc, mesh and opportunistic networking systems and algorithms requires access to large-scale data on human mobility, encounter, and social network patterns. Building on the success of previous years, this 4th ACM HotPlanet workshop will challenge the community to collect large-scale human mobility traces as well as to propose novel mobility data processing and knowledge discovery techniques, also showcasing demonstrations of innovative realworld technology. This year the full-day workshop brings papers in: emerging applications involving large-scale human mobility data collection, human dynamics characterization and modelling, knowledge discovery from mobility data, methods for choosing and collecting large-scale human mobility datasets, etc. * KEYNOTE SPEAKERS:Prof. Jon Crowcroft (University of Cambridge) will give a talk entitled “Through a Graph, Darkly”. See http://www.hotplanetconf.net/ for more information. * TECHNICAL PROGRAM:7 papers have been accepted for presentation and forpublication in the conference proceedings. The complete list of papers are now available at http://www.hotplanetconf.net/ ** * VENUE: The ACM HotPlanet 2012 will be held in conjunction with the ACM MobiSys 2012 conference at Low Wood Bay by Lake Windermere (Low Wood, Ambleside Rd indermere, Cumbria LA23 1LP). You are strongly encouraged to book your hotel room as soon as possible. There are limited rooms available and other hotels are some distance away and may be expensive at this time of year. Please, note that all bookings must be made via the Group Sales Office (****and not the website****). See the following link for more information:http://www.sigmobile.org/mobisys/2012/venue.php --------------030207010201030903060006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

***********************************************************************************

 

[Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).]

 

***********************************************************************************

                               CALL FOR PARTICIPATION

 

             ACM HotPlanet 2012 - The 4th ACM International Workshop on

                     Hot Topics in Planet-Scale Measurement

 

                       June 25, Low Wood Bay, Lake District, UK

                           http://www.hotplanetconf.net

***********************************************************************************

 

* IMPORTANT DATES

  Early registration deadline                 May 24, 2012

  Workshop date                               June 25, 2012

 

* SCOPE: It is well-known that successfully researching, designing and building new mobile, ad-hoc, mesh and opportunistic networking systems and algorithms requires access to large-scale data on human mobility, encounter, and social network patterns. Building on the success of previous years, this 4th ACM HotPlanet workshop will challenge the community to collect large-scale human mobility traces as well as to propose novel mobility data processing and knowledge discovery techniques, also showcasing demonstrations of innovative realworld technology. This year the full-day workshop brings papers in: emerging applications involving large-scale human mobility data collection, human dynamics characterization and modelling, knowledge discovery from mobility data, methods for choosing and collecting large-scale human mobility datasets, etc.

 

* KEYNOTE SPEAKERS:  Prof. Jon Crowcroft (University of Cambridge) will give a talk entitled “Through a Graph, Darkly”. See http://www.hotplanetconf.net/ for more information.

 

* TECHNICAL PROGRAM:  7 papers have been accepted for presentation and for   publication in the conference proceedings. The complete list of papers are now available at http://www.hotplanetconf.net/

 

* VENUE: The ACM HotPlanet 2012 will be held in conjunction with the ACM MobiSys 2012 conference at Low Wood Bay by Lake Windermere (Low Wood, Ambleside Rd indermere, Cumbria LA23 1LP). You are strongly encouraged to book your hotel room as soon as possible. There are limited rooms available and other hotels are some distance away and may be expensive at this time of year. Please, note that all bookings must be made via the Group Sales Office (****and not the website****). See the following link for more information:  http://www.sigmobile.org/mobisys/2012/venue.php


--------------030207010201030903060006-- From kissel@cis.udel.edu Thu May 10 09:32:04 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74A321F8713 for ; Thu, 10 May 2012 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RH-mEx5Z+L1 for ; Thu, 10 May 2012 09:32:04 -0700 (PDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0185221F8714 for ; Thu, 10 May 2012 09:32:03 -0700 (PDT) Received: from [192.168.1.50] (207-172-183-122.c3-0.tlg-ubr3.atw-tlg.pa.cable.rcn.com [207.172.183.122]) (Authenticated sender: kissel@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id B52A71A60; Thu, 10 May 2012 12:32:02 -0400 (EDT) Message-ID: <4FABED86.8000301@cis.udel.edu> Date: Thu, 10 May 2012 12:32:06 -0400 From: Ezra Kissel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Scott, Keith L." References: <201205091656034891078@gmail.com> <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: zhd5408 , dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:32:05 -0000 This list might be interested in our work on the eXtensible Session Protocol and our notion of a session-enabled buffer-and-burst model for data movement. While our focus has been on high-performance, bulk data transfers, I believe our model could in many ways address what the original poster had in mind. (PFLDNet 2010) http://damsl.cis.udel.edu/projects/phoebus/phoebus_slabs.pdf It has occurred to us on more than one occasion that we could apply our store-and-forward approach for managing the interaction between MANETs and DTNs, as well as optimizing WAN transfers for frequently disconnected endpoints where the latency of individual PDUs is less of a concern. We would also very much welcome exploring the commonalities of BP with our notion of a Session-PDU within the DTNRG. Regards, - ezra On 5/9/2012 8:26 AM, Scott, Keith L. wrote: > Do you mean ‘can DTN be implemented underneath the sockets API’? And, if > you want this to be completely transparent to applications, presumably > ‘hiding underneath SOCK_STREAM or SOCK_DGRAM’? > > In a sense, there’s nothing in IP that prevents you from storing IP > datagrams while waiting for a forward path to become available; the > issues in implementing IP this way all have to do with the things around > IP, e.g.: > > ·Routing implementations that drop datagrams when no next hop is available > > ·ARP (which has timeouts) > > ·DNS queries (which have timeouts) > > ·Routing protocols like OSPF (which have timeouts and which typically do > not deal well with either scheduled connectivity or temporary partitions) > > ·Applications that expect either 1) real-time connectivity from IP –or- > 2) no connectivity (but not a possibly-delayed store-and-forward service) > > Routing’s probably NOT an issue here if we’re talking about MANETs since > we could tweak the MANET routing protocols, but some of the others (esp. > application expectations) are a bit problematic. You’d also need to > worry about how/if you want to implement things like custody transfer, > the various bundle notifications, etc. > > That said, there are implementations of BP that live underneath IP (BBN > has an implementation that does this). The chances are that the class of > applications that would be amenable to ‘transparent’ transplantation to > use BP services are UDP-based, and for these (if the applications don’t > have timers that would preclude it) you might consider using the DTN > Tunnel that’s in the DTN2 reference implementation or an equivalent. > That is, if the application can handle it, just tunnel UDP over BP. If > the application can’t handle it, then hiding BP underneath the sockets > API wouldn’t work (without modifying the application) anyway. > > Another approach would be to ask: what’s the MANET getting you that > DTN/BP can’t (or doesn’t)? > > --keith > > *From:*dtn-interest-bounces@irtf.org > [mailto:dtn-interest-bounces@irtf.org] *On Behalf Of *zhd5408 > *Sent:* Wednesday, May 09, 2012 4:56 AM > *To:* dtn-interest > *Subject:* [dtn-interest] Can we implement DTN in Network layer of > protocol stack ? > > Now almost all the DTN implement with Adding bundle layer between > application and transport layer. > > These DTN are separated with MANET completely, all the data from MANET > should be translated through the DTN gateway and all the applications > used in DTN must be redesigned.But MANET and DTN can coexist in some cases. > > I wonder that whether can we design DTN via modifying the network layer, > not using BP. Thus the MANET and DTN can coexist and it is transparent > for upper layers. All the applications don't need to modify. > > If to do so. What problems will encounter? or is it possible? > > ------------------------------------------------------------------------ > > heyeast > From scott.c.burleigh@jpl.nasa.gov Thu May 10 16:43:00 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929EC21F85E3 for ; Thu, 10 May 2012 16:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MehfRIveKKtv for ; Thu, 10 May 2012 16:42:58 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47F21F85AD for ; Thu, 10 May 2012 16:42:58 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4ANerqc006207 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for ; Thu, 10 May 2012 16:42:56 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.245]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.02.0298.004; Thu, 10 May 2012 16:42:37 -0700 From: "Burleigh, Scott C (313B)" To: "dtn-interest@irtf.org" Thread-Topic: DTN enabled printer or fax machine? Thread-Index: Ac0uipkLzKF363IpRaSCk7foLxEDJgAe8ssQ Date: Thu, 10 May 2012 23:42:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B055A04apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-interest] DTN enabled printer or fax machine? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 23:43:00 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B055A04apembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This sounds like a great idea to me; I don't know of anybody who's working = on anything similar, and it does sound like something that could be very us= eful. Scott From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Jeremiah Scholl Sent: Thursday, May 10, 2012 2:02 AM To: dtn-interest@irtf.org Cc: Shabbir Subject: [dtn-interest] DTN enabled printer or fax machine? Hello DTN people. Just now I was looking the presentation slides at the li= nk below, specifically slide 10. It shows an "sms printer" that is used fo= r printing out results from laboratory tests so they can be returned to a c= linic via SMS, instead of requiring the physical transport of paper records= . http://www.teampata.org/downloads/presentations/2011/2%20Shaffiq%20Essajee%= 20Fast%20tracking%20infants.pdf The idea is being applied to reduce the time from when tests are taken of i= nfants that might have HIV, to when they can put them on Anti Retroviral Tr= eatment. It made me wonder if anyone has implemented a "dtn printer" or "dtn fax mac= hine". It could be used as a substitute for paper mail, where SMS is not th= e best alternative. It could provide several advantages. For example, some studies that transmit health information to mobile phones= run into problems because the phones get stolen. The printer hardware wou= ld not be so useful for general purposes however, like a mobile phone is, s= o the incentive to steal one would not be as great. Also in situations wher= e you want a paper copy of the information that a DTN network is transmitti= ng, then the usability would be much better than having a general computer-= printer combo. This is usually the case in a healthcare setting since the = remote clinics that would use a system like this use paper records and it i= s quite difficult to get them to change over to completely use electronic r= ecords. Also potentially you could transmit much nicer documents than the SMS versi= on. So I have two questions.... a) Has anyone ever implemented a DTN-enabled fax machine or printer? b) If not would anyone be interested in creating an open source hardwa= re/software implementation of one? I think that it could be useful in the h= ealthcare domain. Jeremiah ---------------------------------------------- Jeremiah Scholl, Ph.D. Senior Researcher Health Informatics Centre Karolinska Institutet +46852483926 --_000_A5BEAD028815CB40A32A5669CF737C3B055A04apembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This sounds like a gre= at idea to me; I don’t know of anybody who’s working on anythin= g similar, and it does sound like something that could be very useful.=

 

Scott

 

From: dtn-inte= rest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Jeremiah Scholl
Sent: Thursday, May 10, 2012 2:02 AM
To: dtn-interest@irtf.org
Cc: Shabbir
Subject: [dtn-interest] DTN enabled printer or fax machine?

 

Hello DTN people.  Just now I was looking the p= resentation slides at the link below, specifically slide 10.  It shows= an “sms printer” that is used for printing out results from la= boratory tests so they can be returned to a clinic via SMS, instead of requiring the physical transport of paper records.  <= /o:p>

 

http://www.teampata.org/downloads/presentati= ons/2011/2%20Shaffiq%20Essajee%20Fast%20tracking%20infants.pdf

 

The idea is being applied to reduce the time from wh= en tests are taken of infants that might have HIV, to when they can put the= m on Anti Retroviral Treatment.

 

It made me wonder if anyone has implemented a ”= ;dtn printer” or “dtn fax machine”. It could be used as a= substitute for paper mail, where SMS is not the best alternative. It could= provide several advantages.

 

For example, some studies that transmit health infor= mation to mobile phones run into problems because the phones get stolen. &n= bsp;The printer hardware would not be so useful for general purposes howeve= r, like a mobile phone is, so the incentive to steal one would not be as great. Also in situations where you want a pa= per copy of the information that a DTN network is transmitting, then the us= ability would be much better than having a general computer-printer combo. = This is usually the case in  a healthcare setting since the remote clinics that would use a system like this use pap= er records and it is quite difficult to get them to change over to complete= ly use electronic records.

 

Also potentially you could transmit much nicer docum= ents than the SMS version. 

 

So I have two questions….

 

a)      Has anyone ever implemented a DTN-enabled fax machi= ne or printer?

b)      If not would anyone be interested in creating an op= en source hardware/software implementation of one? I think that it could be= useful in the healthcare domain.

 

Jeremiah

 

-----------------= -----------------------------

Jeremiah Scholl, = Ph.D.

Senior Researcher=

Health Informatic= s Centre

Karol= inska Institutet=

+= 46852483926

--_000_A5BEAD028815CB40A32A5669CF737C3B055A04apembxsp40RESADJP_-- From zhd5408@gmail.com Fri May 11 01:18:54 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE321F862A for ; Fri, 11 May 2012 01:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xpH0Rf5EIVq for ; Fri, 11 May 2012 01:18:53 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0818E21F85A8 for ; Fri, 11 May 2012 01:18:52 -0700 (PDT) Received: by dadv36 with SMTP id v36so3228533dad.13 for ; Fri, 11 May 2012 01:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=2X3jGtUfF3ysoljJWqxs4b1Bx6ML6Nu2SzFrodd+r2U=; b=G2f2oxzCGFDWqgWXg+BXQIFqyDOw74zvsQbs/pmkxX48dvhrx2vFEOHsXliL7gI1y4 wS+cQPrqX0XRw4eZnz4bql+/9hXfdDX636/srRuMrjyoFzElf+epoH38wuafNQc8ZT90 yO83VzpM03r1grch1D9Ucc/JlOXdD8ulsjdAgpPwVpJp06kFWKZhP6HtieJt8YhwHIt6 nWu5yLTtepV9LPrOz1W3eUp/a+eGzMatoMCL6vVddpGDmz1Uvunhyvq8W8xz497Cjk7T d2c//mIwNV8s6alcoZYVcJj2YSFWegeAHuGP7jlSqB+t8rtfnAfjWGM6XwjVXCSISHWg AjoQ== Received: by 10.68.217.37 with SMTP id ov5mr29331183pbc.25.1336724331823; Fri, 11 May 2012 01:18:51 -0700 (PDT) Received: from WIN-6HKLPKIT3IE ([113.221.136.141]) by mx.google.com with ESMTPS id d4sm12118787pbr.32.2012.05.11.01.18.44 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 01:18:48 -0700 (PDT) Date: Fri, 11 May 2012 16:18:54 +0800 From: heyeast To: "Vint Cerf" , dtn-interest References: <201205091656034891078@gmail.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201205111618505003564@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart470215821362_=----" Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhd5408 List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:18:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart470215821362_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGkgVmludCBDZXJmOg0KSW4gaGlnaCBsb3NzL2xhdGVuY3kgZW52aXJvbm1lbnQsIERUTiBpcyBp bXBsaWNpdCB0aGUgYmVzdCBjaG9pY2UgZm9yIHVzLiBIb3dldmVyLCB3ZSBmb2N1cyBvbiB0aGUg d2lyZWxlc3MgZW52aXJvbm1lbnQgd2l0aCBsb3cgbGF0ZW5jeSBidXQgc29tZXRpbWUgdGhlIGxp bmsgd2lsbCBkaXNjb25uZWN0IGZvciBhIGZldyB0aW1lLiBJbiBvdGhlciB3b3Jkcywgd2Ugd2lz aCB1c2luZyBEVE4gdG8gZW5oYW5jZSB0aGUgTUFORVQncyByZWxpYWJsZSBhbmQgcm9idXN0Lg0K DQpBcyBrZWl0aCByZWZlciwgbm93IEJCTiB0ZWNobm9sb2d5IGhhcyBpbXBsZW1lbnQgV05hTiB3 aXRoIGhhbmRsaW5nIEJQIHVuZGVyIElQIHN0YWNrIGFuZCB0cmFuc3BhcmVudCBmb3IgdXBwZXIg bGF5ZXJzLg0KDQoNCg0KDQpoZXllYXN0DQoNCkZyb206IFZpbnQgQ2VyZg0KRGF0ZTogMjAxMi0w NS0wOSAxODoyMQ0KVG86IHpoZDU0MDgNClN1YmplY3Q6IFJlOiBbZHRuLWludGVyZXN0XSBDYW4g d2UgaW1wbGVtZW50IERUTiBpbiBOZXR3b3JrIGxheWVyIG9mIHByb3RvY29sIHN0YWNrID8NCkkg dGhpbmsgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgbG9naWMgYW5kIGJlaGF2aW9yIG9mIERUTiBp cyBkaWZmZXJlbnQNCmZyb20gSVAuIE1vc3Qgb2YgdGhlIElQLWJhc2VkIHByb3RvY29scyBhc3N1 bWUgbG93IGxhdGVuY3kgd2hpbGUgRFRODQphc3N1bWUgaGlnaCBsYXRlbmN5IGFuZCBsb3NzLiBU aGUgcmVzdWx0IGlzIHRoYXQgaGlkaW5nIHRoZSBCUCAob3IgRFRODQpmdW5jdGlvbmFsaXR5KSBp biB0aGUgbmV0d29yayBsYXllciBsZWFkcyB0byBhcHBsaWNhdGlvbnMgdGhhdCB3aWxsIGJlDQpj b25mdXNlZCBvciBqdXN0IGZhaWwgd2hlbiBvcGVyYXRpbmcgaW4gYSBoaWdoIGxvc3MvbGF0ZW5j eQ0KZW52aXJvbm1lbnQuIFVEUCBhcHBsaWNhdGlvbnMgZG9uJ3QgbmVjZXNzYXJpbHkgd29yayBl aXRoZXIgaWYgdGhleQ0KYXNzdW1lIGltcGxpY2l0IGxvdyBsYXRlbmN5Lg0KDQp2DQoNCg0KT24g V2VkLCBNYXkgOSwgMjAxMiBhdCA0OjU2IEFNLCB6aGQ1NDA4IDx6aGQ1NDA4QGdtYWlsLmNvbT4g d3JvdGU6DQo+IE5vdyBhbG1vc3QgYWxsIHRoZSBEVE4gaW1wbGVtZW50IHdpdGggQWRkaW5nIGJ1 bmRsZSBsYXllciBiZXR3ZWVuDQo+IGFwcGxpY2F0aW9uIGFuZCB0cmFuc3BvcnQgbGF5ZXIuDQo+ DQo+IFRoZXNlIERUTiBhcmUgc2VwYXJhdGVkIHdpdGggTUFORVQgY29tcGxldGVseSwgYWxsIHRo ZSBkYXRhIGZyb20gTUFORVQNCj4gc2hvdWxkIGJlIHRyYW5zbGF0ZWQgdGhyb3VnaCB0aGUgRFRO IGdhdGV3YXkgYW5kIGFsbCB0aGUgYXBwbGljYXRpb25zIHVzZWQNCj4gaW4gRFROIG11c3QgYmUg cmVkZXNpZ25lZC5CdXQgTUFORVQgYW5kIERUTiBjYW4gY29leGlzdCBpbiBzb21lIGNhc2VzLg0K Pg0KPiBJIHdvbmRlciB0aGF0IHdoZXRoZXIgY2FuIHdlIGRlc2lnbiBEVE4gdmlhIG1vZGlmeWlu ZyB0aGUgbmV0d29yayBsYXllciwgbm90DQo+IHVzaW5nIEJQLiBUaHVzIHRoZSBNQU5FVCBhbmQg RFROIGNhbiBjb2V4aXN0IGFuZCBpdCBpcyB0cmFuc3BhcmVudCBmb3IgdXBwZXINCj4gbGF5ZXJz LiAgQWxsIHRoZSBhcHBsaWNhdGlvbnMgZG9uJ3QgbmVlZCB0byBtb2RpZnkuDQo+DQo+IElmIHRv IGRvIHNvLiBXaGF0IHByb2JsZW1zIHdpbGwgZW5jb3VudGVyPyBvciBpcyBpdCBwb3NzaWJsZT8N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaGV5ZWFzdA0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkdG4taW50 ZXJlc3QgbWFpbGluZyBsaXN0DQo+IGR0bi1pbnRlcmVzdEBpcnRmLm9yZw0KPiBodHRwczovL3d3 dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2R0bi1pbnRlcmVzdA0KPg== ------=_001_NextPart470215821362_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF hi=20 Vint Cerf: In=20 high loss/latency environment, DTN is implicit the best choice for us. How= ever,=20 we focus on the wireless environment with low latency but sometime the lin= k will=20 disconnect for a few time. In other words, we wish using DTN to enhan= ce the=20 MANET's reliable and robust.  
As keith refer, now BBN technology has implement WN= aN with=20 handling BP under IP stack and transparent for upper=20 layers.
 

heyeast
 
From: Vint Cerf
Date: 2012-05-09 18:21
To: zhd5408
Subject: Re: [dtn-interest] Can we implement DTN in Netwo= rk=20 layer of protocol stack ?
I think the problem is that the lo= gic and behavior of DTN is different
from IP. Most of the IP-based protocols=  assume low latency while DTN
assume high latency and loss. The resul= t is that hiding the BP (or DTN
functionality) in the network layer leads&nb= sp;to applications that will be
confused or just fail when operating in=  a high loss/latency
environment. UDP applications don't necessarily&n= bsp;work either if they
assume implicit low latency.
 
v
 
 
On Wed, May 9, 2012 at 4:56 AM,&nb= sp;zhd5408 <zhd5408@gmail.com> wrote:
> Now almost all the DTN implement&n= bsp;with Adding bundle layer between
> application and transport layer.
>
> These DTN are separated with MANET=  completely, all the data from MANET
> should be translated through the D= TN gateway and all the applications used
> in DTN must be redesigned.But MANE= T and DTN can coexist in some cases.
>
> I wonder that whether can we = design DTN via modifying the network layer,&= nbsp;not
> using BP. Thus the MANET and = DTN can coexist and it is transparent f= or upper
> layers.  All the applications don'= t need to modify.
>
> If to do so. What problems wi= ll encounter? or is it possible?
>
> ________________________________
> heyeast
>
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
>
------=_001_NextPart470215821362_=------ From vint@google.com Fri May 11 01:21:16 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9494021F8636 for ; Fri, 11 May 2012 01:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wux-V4N5FlW7 for ; Fri, 11 May 2012 01:21:15 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id B26DF21F85A8 for ; Fri, 11 May 2012 01:21:15 -0700 (PDT) Received: by yenl8 with SMTP id l8so3057401yen.13 for ; Fri, 11 May 2012 01:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=oXVn+J9knkjsHLuGTaAeYta/uglUjtIjHCnUKy5WJys=; b=hbcFOfGRIIvHcHZVNbT3OiEc21tuLmuRhJbDXOn64nmlkrHEU7J5Tl7eCuIsni6xVN 55/+U2D4814oHrFqBsLPDAoQKBgKZhdrbxbOHnadxJhN2ZSIrHJjXoql8TQ91qvdssZL xTDXy6pzaaPDQ34Qpl0dZnY2OjL7o88I1gENMrrmDo3/SusA5Ef4ks+sRBNSwqKtIy1n i36s7LG361BVUP9EDS2kjToZl71PXmtg9OhiDEpzHgRCN3yXAxOBwoOrxA+4k3jOiG5p DONHt0q7S6F6PnitLhEEb5gjHFKhYGlsAMKvzaGaAo16mmx7qJfQYdl1vE2AmLMUcgCd bFPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=oXVn+J9knkjsHLuGTaAeYta/uglUjtIjHCnUKy5WJys=; b=PflJhhu2pnuvc20cjwWnyUPS9BRC1RWsE0zqtqswmaWazSrTlI+yDr1iXnRZjbXHuW CavV6fcOyhH/qJRcbugx9VxxgjltLWH4NMSqOk2c/bD+PHuAqqZUFqMYLpkCy8GKUS64 k7epoPY5DPLnWjD8vq+0pL8wAqNiryw0+ZinPl0ccB0P8lszYSNaFc76U3PhVj3NkvCl bcx+AjCDcWXcvHEAlos6wOJCwvZeGpPwhLUSAOPs6t47dAT4+pQBnfoRDxyvhGJ7NhwV oh83xXv8xt5cGUoXNviLr4XjchDshXK9pSVew/P86Yuv8bQli71p1tuVr1JUSl8EF/Aq X7nQ== Received: by 10.50.104.137 with SMTP id ge9mr1038194igb.67.1336724474505; Fri, 11 May 2012 01:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.104.137 with SMTP id ge9mr1038180igb.67.1336724474060; Fri, 11 May 2012 01:21:14 -0700 (PDT) Received: by 10.231.124.138 with HTTP; Fri, 11 May 2012 01:21:14 -0700 (PDT) In-Reply-To: <201205111618505003564@gmail.com> References: <201205091656034891078@gmail.com> <201205111618505003564@gmail.com> Date: Fri, 11 May 2012 04:21:14 -0400 Message-ID: From: Vint Cerf To: zhd5408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmES2lzhotlWuZJzchgfcKD1coAbKnfm1fDkQCBBhZ5VSmZ+tFyFNXQ9WQUbDjfXm7PoPsEvAsbNz1WHlUErKFbgiR2pNIMiSbfnS3Ui8ovjHnWTEj9c/Vcce9qFHqXUwdtTb/nMxSlPVGcbRkjkxbm5wXEfQ== Cc: dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:21:16 -0000 so the "transparency" assertion is of interest - DTN/BP is intended to be very resilient in the face of disconnection - IP is nominally not so "patient" - so how is this "transparency" achieved? vint On Fri, May 11, 2012 at 4:18 AM, heyeast wrote: > hi Vint Cerf: > In high loss/latency environment, DTN is implicit the best choice for us. > However, we focus on the wireless environment with low latency but someti= me > the link will disconnect for a few time. In other words, we wish using DT= N > to=A0enhance the MANET's reliable and robust. > > As keith refer, now BBN technology has implement WNaN with handling BP un= der > IP stack and transparent for upper layers. > > ________________________________ > heyeast > > From:=A0Vint Cerf > Date:=A02012-05-09=A018:21 > To:=A0zhd5408 > Subject:=A0Re: [dtn-interest] Can we implement DTN in Network layer of > protocol stack ? > I=A0think=A0the=A0problem=A0is=A0that=A0the=A0logic=A0and=A0behavior=A0of= =A0DTN=A0is=A0different > from=A0IP.=A0Most=A0of=A0the=A0IP-based=A0protocols=A0assume=A0low=A0late= ncy=A0while=A0DTN > assume=A0high=A0latency=A0and=A0loss.=A0The=A0result=A0is=A0that=A0hiding= =A0the=A0BP=A0(or=A0DTN > functionality)=A0in=A0the=A0network=A0layer=A0leads=A0to=A0applications= =A0that=A0will=A0be > confused=A0or=A0just=A0fail=A0when=A0operating=A0in=A0a=A0high=A0loss/lat= ency > environment.=A0UDP=A0applications=A0don't=A0necessarily=A0work=A0either= =A0if=A0they > assume=A0implicit=A0low=A0latency. > > v > > > On=A0Wed,=A0May=A09,=A02012=A0at=A04:56=A0AM,=A0zhd5408=A0=A0wrote: >>=A0Now=A0almost=A0all=A0the=A0DTN=A0implement=A0with=A0Adding=A0bundle=A0= layer=A0between >>=A0application=A0and=A0transport=A0layer. >> >>=A0These=A0DTN=A0are=A0separated=A0with=A0MANET=A0completely,=A0all=A0the= =A0data=A0from=A0MANET >>=A0should=A0be=A0translated=A0through=A0the=A0DTN=A0gateway=A0and=A0all= =A0the=A0applications=A0used >>=A0in=A0DTN=A0must=A0be=A0redesigned.But=A0MANET=A0and=A0DTN=A0can=A0coex= ist=A0in=A0some=A0cases. >> >>=A0I=A0wonder=A0that=A0whether=A0can=A0we=A0design=A0DTN=A0via=A0modifyin= g=A0the=A0network=A0layer,=A0not >>=A0using=A0BP.=A0Thus=A0the=A0MANET=A0and=A0DTN=A0can=A0coexist=A0and=A0i= t=A0is=A0transparent=A0for=A0upper >>=A0layers.=A0=A0All=A0the=A0applications=A0don't=A0need=A0to=A0modify. >> >>=A0If=A0to=A0do=A0so.=A0What=A0problems=A0will=A0encounter?=A0or=A0is=A0i= t=A0possible? >> >>=A0________________________________ >>=A0heyeast >> >>=A0_______________________________________________ >>=A0dtn-interest=A0mailing=A0list >>=A0dtn-interest@irtf.org >>=A0https://www.irtf.org/mailman/listinfo/dtn-interest >> From zhd5408@gmail.com Fri May 11 01:49:23 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A88321F8652 for ; Fri, 11 May 2012 01:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-1.319, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d829WvbiYrHw for ; Fri, 11 May 2012 01:49:22 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED0021F8659 for ; Fri, 11 May 2012 01:49:22 -0700 (PDT) Received: by dadv36 with SMTP id v36so3263007dad.13 for ; Fri, 11 May 2012 01:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=9eiUj44mAgf47qAU6AbLjLDlNwgNRm1iqaPD0DBwAA0=; b=qdZcZnZb0y79iqg/Uz1Mnnubw9r73fDeN7dfsbqsRrwhQjtoCywMXuui2WPq7u9Bpr GH0oLoIYNCbmB4iRql9sL92Aat2BEuHg1ybgHH5j4MnJc156onHh7ytLLFFN3UsgNo8N 9d5c9ZyjEMBG/ne+XAtbzzDX/aJYT4axQVPuEJRpMWzMvyqFexLGmpDyF2D5PVxCJxGi N0AtTNa2Mkq+HfJqnxBq1EkhBZdx0yn/OtKOs7x+9Nkc6eucDmvU7PmIr4fLcUK/uNU+ 5hf3j5dcD/QKK0EWYLWwCUHJ4YvAUNqCB85cyg+dUNih2DLKEn/mBxzLFWDjr/gDLiGN n6QQ== Received: by 10.68.194.73 with SMTP id hu9mr10638261pbc.44.1336726162225; Fri, 11 May 2012 01:49:22 -0700 (PDT) Received: from WIN-6HKLPKIT3IE ([113.221.136.141]) by mx.google.com with ESMTPS id qj6sm12190136pbc.19.2012.05.11.01.49.15 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 01:49:21 -0700 (PDT) Date: Fri, 11 May 2012 16:49:25 +0800 From: heyeast To: =?gb2312?B?U2NvdHQsIEtlaXRoIEwu?= References: <201205091656034891078@gmail.com>, <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2012051116492072556714@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart310548803121_=----" Cc: dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhd5408 List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 08:49:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart310548803121_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkga2VpdGg6DQoNClRoYW5rcyBmb3IgeW91ciBhdHRlbnRpb24uIFRvIHRoZSBxdWVzdGlvbiAi d2hhdKGvcyB0aGUgTUFORVQgZ2V0dGluZyB5b3UgdGhhdCBEVE4vQlAgY2Fuoa90IChvciBkb2Vz bqGvdCk/IiBteSBhbnN3ZXIgaXMsIGluIHNvbWUgY3JpdGljYWwgTUFORVQgZW52aXJvbm1lbnRz IGxpbmsgIHdpbGwgZGlzY29ubmVjdCBmcmVxdWVudGx5Lkl0IGlzIGEgTUFORVQgc2NlbmFyaW8g YnV0IG5vdCBhIERUTiBzY2VuYXJpbyBjb21wbGV0ZWx5LiBNYXliZSBNQU5FVCBjYW4ndCBoYW5k bGUgdGhlc2UgZGlzY29ubmVjdC5TbyB3ZSB3aXNoIHVzaW5nIERUTiB0byBlbmhhbmNlIHRoZSBy ZWxpYWJpbGl0eSBhbmQgcm9idXN0IG9mIHRoZSBNQU5FVC4gIGltcGxlbWVudCBEVE4gaW4gbmV0 d29yayBsYXllciwgdGh1cyBjYW4gYmUgdXNlZCBmb3IgTUFORVQuDQoNClRoZSBXTmFOIGRldmVs b3BlZCBieSBCQk4gVGVjaG5vbG9neSBpcyBhbWF6aW5nLiBCdXQgaXQgaXMgbm90IG9wZW4gZm9y IHVzLiBJIGhhdmUgcmVhZCB0aGlzIHBhcGVyICJUaGUgREFSUEEgV05hTiBOZXR3b3JrIEFyY2hp dGVjdHVyZSAiIGFib3V0IHRoYXQuIEl0IGlzIGhldXJpc3RpYyBmb3IgbWUuIEZpcnN0bHkgaXQg dGVsbHMgbWUgaXQgaXMgcG9zc2libGUgZm9yIG1lIHRvIGRvIHRoaXMuIGFsdGhvdWdoIGl0IGlz IHNvIGRpZmZpY3VsdHkuICAgIEkgd2lsbCBhbHNvIGNvbnNpZGVyIHRoZSBEVE4gVHVubmVsIGlu IERUTjIgc2VyaW91c2x5Lg0KDQpUaGFuayB1IGFnYWluLiANCg0KDQoNCg0KaGV5ZWFzdA0KDQpG cm9tOiBTY290dCwgS2VpdGggTC4NCkRhdGU6IDIwMTItMDUtMDkgMjA6MjYNClRvOiB6aGQ1NDA4 OyBkdG4taW50ZXJlc3QNClN1YmplY3Q6IFJFOiBbZHRuLWludGVyZXN0XSBDYW4gd2UgaW1wbGVt ZW50IERUTiBpbiBOZXR3b3JrIGxheWVyIG9mIHByb3RvY29sIHN0YWNrID8NCkRvIHlvdSBtZWFu IKGuY2FuIERUTiBiZSBpbXBsZW1lbnRlZCB1bmRlcm5lYXRoIHRoZSBzb2NrZXRzIEFQSaGvPyAg QW5kLCBpZiB5b3Ugd2FudCB0aGlzIHRvIGJlIGNvbXBsZXRlbHkgdHJhbnNwYXJlbnQgdG8gYXBw bGljYXRpb25zLCBwcmVzdW1hYmx5IKGuaGlkaW5nIHVuZGVybmVhdGggU09DS19TVFJFQU0gb3Ig U09DS19ER1JBTaGvPw0KSW4gYSBzZW5zZSwgdGhlcmWhr3Mgbm90aGluZyBpbiBJUCB0aGF0IHBy ZXZlbnRzIHlvdSBmcm9tIHN0b3JpbmcgSVAgZGF0YWdyYW1zIHdoaWxlIHdhaXRpbmcgZm9yIGEg Zm9yd2FyZCBwYXRoIHRvIGJlY29tZSBhdmFpbGFibGU7IHRoZSBpc3N1ZXMgaW4gaW1wbGVtZW50 aW5nIElQIHRoaXMgd2F5IGFsbCBoYXZlIHRvIGRvIHdpdGggdGhlIHRoaW5ncyBhcm91bmQgSVAs IGUuZy46DQqhpCAgICAgICAgIFJvdXRpbmcgaW1wbGVtZW50YXRpb25zIHRoYXQgZHJvcCBkYXRh Z3JhbXMgd2hlbiBubyBuZXh0IGhvcCBpcyBhdmFpbGFibGUNCqGkICAgICAgICAgQVJQICh3aGlj aCBoYXMgdGltZW91dHMpDQqhpCAgICAgICAgIEROUyBxdWVyaWVzICh3aGljaCBoYXZlIHRpbWVv dXRzKQ0KoaQgICAgICAgICBSb3V0aW5nIHByb3RvY29scyBsaWtlIE9TUEYgKHdoaWNoIGhhdmUg dGltZW91dHMgYW5kIHdoaWNoIHR5cGljYWxseSBkbyBub3QgZGVhbCB3ZWxsIHdpdGggZWl0aGVy IHNjaGVkdWxlZCBjb25uZWN0aXZpdHkgb3IgdGVtcG9yYXJ5IHBhcnRpdGlvbnMpDQqhpCAgICAg ICAgIEFwcGxpY2F0aW9ucyB0aGF0IGV4cGVjdCBlaXRoZXIgMSkgcmVhbC10aW1lIGNvbm5lY3Rp dml0eSBmcm9tIElQIKhDb3ItIDIpIG5vIGNvbm5lY3Rpdml0eSAoYnV0IG5vdCBhIHBvc3NpYmx5 LWRlbGF5ZWQgc3RvcmUtYW5kLWZvcndhcmQgc2VydmljZSkNClJvdXRpbmehr3MgcHJvYmFibHkg Tk9UIGFuIGlzc3VlIGhlcmUgaWYgd2Whr3JlIHRhbGtpbmcgYWJvdXQgTUFORVRzIHNpbmNlIHdl IGNvdWxkIHR3ZWFrIHRoZSBNQU5FVCByb3V0aW5nIHByb3RvY29scywgYnV0IHNvbWUgb2YgdGhl IG90aGVycyAoZXNwLiBhcHBsaWNhdGlvbiBleHBlY3RhdGlvbnMpIGFyZSBhIGJpdCBwcm9ibGVt YXRpYy4gIFlvdaGvZCBhbHNvIG5lZWQgdG8gd29ycnkgYWJvdXQgaG93L2lmIHlvdSB3YW50IHRv IGltcGxlbWVudCB0aGluZ3MgbGlrZSBjdXN0b2R5IHRyYW5zZmVyLCB0aGUgdmFyaW91cyBidW5k bGUgbm90aWZpY2F0aW9ucywgZXRjLg0KVGhhdCBzYWlkLCB0aGVyZSBhcmUgaW1wbGVtZW50YXRp b25zIG9mIEJQIHRoYXQgbGl2ZSB1bmRlcm5lYXRoIElQIChCQk4gaGFzIGFuIGltcGxlbWVudGF0 aW9uIHRoYXQgZG9lcyB0aGlzKS4gIFRoZSBjaGFuY2VzIGFyZSB0aGF0IHRoZSBjbGFzcyBvZiBh cHBsaWNhdGlvbnMgdGhhdCB3b3VsZCBiZSBhbWVuYWJsZSB0byChrnRyYW5zcGFyZW50oa8gdHJh bnNwbGFudGF0aW9uIHRvIHVzZSBCUCBzZXJ2aWNlcyBhcmUgVURQLWJhc2VkLCBhbmQgZm9yIHRo ZXNlIChpZiB0aGUgYXBwbGljYXRpb25zIGRvbqGvdCBoYXZlIHRpbWVycyB0aGF0IHdvdWxkIHBy ZWNsdWRlIGl0KSB5b3UgbWlnaHQgY29uc2lkZXIgdXNpbmcgdGhlIERUTiBUdW5uZWwgdGhhdKGv cyBpbiB0aGUgRFROMiByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gb3IgYW4gZXF1aXZhbGVudC4g IFRoYXQgaXMsIGlmIHRoZSBhcHBsaWNhdGlvbiBjYW4gaGFuZGxlIGl0LCBqdXN0IHR1bm5lbCBV RFAgb3ZlciBCUC4gIElmIHRoZSBhcHBsaWNhdGlvbiBjYW6hr3QgaGFuZGxlIGl0LCB0aGVuIGhp ZGluZyBCUCB1bmRlcm5lYXRoIHRoZSBzb2NrZXRzIEFQSSB3b3VsZG6hr3Qgd29yayAod2l0aG91 dCBtb2RpZnlpbmcgdGhlIGFwcGxpY2F0aW9uKSBhbnl3YXkuDQpBbm90aGVyIGFwcHJvYWNoIHdv dWxkIGJlIHRvIGFzazogd2hhdKGvcyB0aGUgTUFORVQgZ2V0dGluZyB5b3UgdGhhdCBEVE4vQlAg Y2Fuoa90IChvciBkb2VzbqGvdCk/DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0ta2Vp dGgNCkZyb206IGR0bi1pbnRlcmVzdC1ib3VuY2VzQGlydGYub3JnIFttYWlsdG86ZHRuLWludGVy ZXN0LWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiB6aGQ1NDA4DQpTZW50OiBXZWRuZXNk YXksIE1heSAwOSwgMjAxMiA0OjU2IEFNDQpUbzogZHRuLWludGVyZXN0DQpTdWJqZWN0OiBbZHRu LWludGVyZXN0XSBDYW4gd2UgaW1wbGVtZW50IERUTiBpbiBOZXR3b3JrIGxheWVyIG9mIHByb3Rv Y29sIHN0YWNrID8NCiANCk5vdyBhbG1vc3QgYWxsIHRoZSBEVE4gaW1wbGVtZW50IHdpdGggQWRk aW5nIGJ1bmRsZSBsYXllciBiZXR3ZWVuIGFwcGxpY2F0aW9uIGFuZCB0cmFuc3BvcnQgbGF5ZXIu IA0KIA0KVGhlc2UgRFROIGFyZSBzZXBhcmF0ZWQgd2l0aCBNQU5FVCBjb21wbGV0ZWx5LCBhbGwg dGhlIGRhdGEgZnJvbSBNQU5FVCBzaG91bGQgYmUgdHJhbnNsYXRlZCB0aHJvdWdoIHRoZSBEVE4g Z2F0ZXdheSBhbmQgYWxsIHRoZSBhcHBsaWNhdGlvbnMgdXNlZCBpbiBEVE4gbXVzdCBiZSByZWRl c2lnbmVkLkJ1dCBNQU5FVCBhbmQgRFROIGNhbiBjb2V4aXN0IGluIHNvbWUgY2FzZXMuDQogDQpJ IHdvbmRlciB0aGF0IHdoZXRoZXIgY2FuIHdlIGRlc2lnbiBEVE4gdmlhIG1vZGlmeWluZyB0aGUg bmV0d29yayBsYXllciwgbm90IHVzaW5nIEJQLiBUaHVzIHRoZSBNQU5FVCBhbmQgRFROIGNhbiBj b2V4aXN0IGFuZCBpdCBpcyB0cmFuc3BhcmVudCBmb3IgdXBwZXIgbGF5ZXJzLiAgQWxsIHRoZSBh cHBsaWNhdGlvbnMgZG9uJ3QgbmVlZCB0byBtb2RpZnkuDQogDQpJZiB0byBkbyBzby4gV2hhdCBw cm9ibGVtcyB3aWxsIGVuY291bnRlcj8gb3IgaXMgaXQgcG9zc2libGU/DQogDQoNCg0KDQpoZXll YXN0 ------=_001_NextPart310548803121_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi=20 keith:
 
Thanks for your attention. To the q= uestion=20 "what=A1=AFs the MANET getting you that = DTN/BP can=A1=AFt (or=20 doesn=A1=AFt)?" my answer is, in some critical MA= NET=20 environments link  will disconnect frequently.It is a MANET scen= ario=20 but not a DTN scenario completely. Maybe MANET can't handle thes= e=20 disconnect.So we wish using DTN to enhance the reliability and robust of t= he=20 MANET.  implement DTN in network layer, thus can be used for=20 MANET.
=  
The WNaN developed by BBN Technolog= y is=20 amazing. But it is not open for us. I have read this=20 paper "The DARPA WNaN Network Architecture " abou= t=20 that. It is heuristic for me. Firstly it tells me it is possible for = me to=20 do this. although it is so difficulty.    I will=20 also consider the DTN Tunnel in DTN2=20 seriously.
=  
Thank u=20 again. 
 

heyeast
 
Date: 2012-05-09 20:26
To: zhd5408; dtn-interest
Subject: RE: [dtn-interest] Can we implement DTN in Netwo= rk=20 layer of protocol stack ?

Do=20 you mean =A1=AEcan DTN be implemented underneath the sockets API=A1=AF?&nb= sp; And, if you=20 want this to be completely transparent to applications, presumably =A1=AEh= iding=20 underneath SOCK_STREAM or SOCK_DGRAM=A1=AF?

In=20 a sense, there=A1=AFs nothing in IP that prevents you from storing IP data= grams while=20 waiting for a forward path to become available; the issues in implementing= IP=20 this way all have to do with the things around IP, e.g.:=

=A1=A4      =   =20 Routing=20 implementations that drop datagrams when no next hop is=20 available

=A1=A4      =   =20 ARP=20 (which has timeouts)

=A1=A4      =   =20 DNS=20 queries (which have timeouts)

=A1=A4      =   =20 Routing=20 protocols like OSPF (which have timeouts and which typically do not deal w= ell=20 with either scheduled connectivity or temporary=20 partitions)

=A1=A4      =   =20 Applications=20 that expect either 1) real-time connectivity from IP =A8Cor- 2) no connect= ivity=20 (but not a possibly-delayed store-and-forward service)

Routing=A1=AFs=20 probably NOT an issue here if we=A1=AFre talking about MANETs since we cou= ld tweak=20 the MANET routing protocols, but some of the others (esp. application=20 expectations) are a bit problematic.  You=A1=AFd also need to worry a= bout how/if=20 you want to implement things like custody transfer, the various bundle=20 notifications, etc.

That=20 said, there are implementations of BP that live underneath IP (BBN has an=20 implementation that does this).  The chances are that the class of=20 applications that would be amenable to =A1=AEtransparent=A1=AF transplanta= tion to use BP=20 services are UDP-based, and for these (if the applications don=A1=AFt have= timers=20 that would preclude it) you might consider using the DTN Tunnel that=A1=AF= s in the=20 DTN2 reference implementation or an equivalent.  That is, if the=20 application can handle it, just tunnel UDP over BP.  If the applicati= on=20 can=A1=AFt handle it, then hiding BP underneath the sockets API wouldn=A1= =AFt work=20 (without modifying the application) anyway.

Another=20 approach would be to ask: what=A1=AFs the MANET getting you that DTN/BP ca= n=A1=AFt (or=20 doesn=A1=AFt)?

           &nb= sp;            = ;    =20 --keith

From:= =20 dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On= =20 Behalf Of zhd5408
Sent: Wednesday, May 09, 2012 4:56=20 AM
To: dtn-interest
Subject: [dtn-interest] Can we imp= lement=20 DTN in Network layer of protocol stack ?

 

Now almo= st all the=20 DTN implement with Adding bundle layer between application and transp= ort=20 layer.

 

These DT= N are=20 separated with MANET completely, all the data from MANET should=20 be translated through the DTN gateway and all the applications used i= n DTN=20 must be redesigned.But MANET and DTN can coexist in some=20 cases.

 

I wonder= that=20 whether can we design DTN via modifying the network layer, not u= sing=20 BP. Thus the MANET and DTN can coexist and it is transparent&nbs= p;for=20 upper layers.  All the applications don't need to=20 modify.

 

If to do= so. What=20 problems will encounter? or is it possible?

 


heyeast

------=_001_NextPart310548803121_=------ From zhd5408@gmail.com Fri May 11 02:06:24 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2721F863B for ; Fri, 11 May 2012 02:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKncPeXGXBaX for ; Fri, 11 May 2012 02:06:20 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5E21F8638 for ; Fri, 11 May 2012 02:06:18 -0700 (PDT) Received: by pbbro2 with SMTP id ro2so3502604pbb.13 for ; Fri, 11 May 2012 02:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=iVPShPLbl+CJOKt150wBP986SPqgGbiigQ6RpfDx4hE=; b=CcyossY2JEUKRJnQd6snTVMH4yXh2NC+FOjqW3vPWTNRf1BBX3vmVNnnpWBFuGQprr ZBwEWJkiKG8Sdy3iEZPpcwNVWFBYe63aS4cLhN/IDzgBtLhR+qyhG4zTQkMY11S9apuk Cs2Gg4Qs6AuAVwUfep9uZunQUjuzGI1Yyi58ydWOWGCtU+kIEky7Kd4Gb687dlGdnaQk QBzmyUOgSlSNz5dnwAPXNsF9kTfWJUTGBRi0vtXmc8DbjVFjT3EuJ4whtlprCBEErd18 tudCCyDQO40zU6sNwY/0jsNFCV+F5a5xR/GCLXTKFcC4ZTplMDlBZ/aS46U9v7Cen9gF G3Vg== Received: by 10.68.234.232 with SMTP id uh8mr11009827pbc.82.1336727177059; Fri, 11 May 2012 02:06:17 -0700 (PDT) Received: from WIN-6HKLPKIT3IE ([113.221.136.141]) by mx.google.com with ESMTPS id nk2sm12217728pbc.54.2012.05.11.02.06.12 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 02:06:16 -0700 (PDT) Date: Fri, 11 May 2012 17:06:22 +0800 From: heyeast To: "Ezra Kissel" References: <201205091656034891078@gmail.com> <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG>, <4FABED86.8000301@cis.udel.edu> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2012051117061669500418@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart141685856530_=----" Cc: dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhd5408 List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 09:06:25 -0000 This is a multi-part message in MIME format. ------=_001_NextPart141685856530_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhpcyBwYXBlci4gQnVmZmVyLWFuZC1idXJzdCBtb2RlbCByZWZlciBpbiB0 aGlzIHBhcGVyIGlzIHZlcnkgaW50ZXJlc3RpbmcuIEJ1dCBJIHRoaW5rIHlvdXIgZm9jdXMgaXMg bWFpbmx5IG9uIHRoZSBkYXRhIG1vdmVtZW50IGFuZCBoaWdoLXBlcmZvcm1hbmNlLiBsZXNzIGhh bmRsaW5nIG9uIHRoZSBkaXNjb25uZWN0IG9mIHRoZSBsaW5rLiBJIHRoaW5rIHRoZSBub3Rpb24g aXMgc2ltaWxhciB0byB0aGUgQlAuIGFuZCB0aGUgd29yayBpcyBhbHNvIHZhbHVhYmxlIGZvciB1 cy4NCg0KcmVnYXJkcy4NCg0KDQoNCg0KaGV5ZWFzdA0KDQpGcm9tOiBFenJhIEtpc3NlbA0KRGF0 ZTogMjAxMi0wNS0xMSAwMDozMg0KVG86IFNjb3R0LCBLZWl0aCBMLg0KQ0M6IHpoZDU0MDg7IGR0 bi1pbnRlcmVzdA0KU3ViamVjdDogUmU6IFJlOiBbZHRuLWludGVyZXN0XSBDYW4gd2UgaW1wbGVt ZW50IERUTiBpbiBOZXR3b3JrIGxheWVyIG9mIHByb3RvY29sIHN0YWNrID8NClRoaXMgbGlzdCBt aWdodCBiZSBpbnRlcmVzdGVkIGluIG91ciB3b3JrIG9uIHRoZSBlWHRlbnNpYmxlIFNlc3Npb24g DQpQcm90b2NvbCBhbmQgb3VyIG5vdGlvbiBvZiBhIHNlc3Npb24tZW5hYmxlZCBidWZmZXItYW5k LWJ1cnN0IG1vZGVsIGZvciANCmRhdGEgbW92ZW1lbnQuICBXaGlsZSBvdXIgZm9jdXMgaGFzIGJl ZW4gb24gaGlnaC1wZXJmb3JtYW5jZSwgYnVsayBkYXRhIA0KdHJhbnNmZXJzLCBJIGJlbGlldmUg b3VyIG1vZGVsIGNvdWxkIGluIG1hbnkgd2F5cyBhZGRyZXNzIHdoYXQgdGhlIA0Kb3JpZ2luYWwg cG9zdGVyIGhhZCBpbiBtaW5kLg0KDQooUEZMRE5ldCAyMDEwKQ0KaHR0cDovL2RhbXNsLmNpcy51 ZGVsLmVkdS9wcm9qZWN0cy9waG9lYnVzL3Bob2VidXNfc2xhYnMucGRmDQoNCkl0IGhhcyBvY2N1 cnJlZCB0byB1cyBvbiBtb3JlIHRoYW4gb25lIG9jY2FzaW9uIHRoYXQgd2UgY291bGQgYXBwbHkg b3VyIA0Kc3RvcmUtYW5kLWZvcndhcmQgYXBwcm9hY2ggZm9yIG1hbmFnaW5nIHRoZSBpbnRlcmFj dGlvbiBiZXR3ZWVuIE1BTkVUcyANCmFuZCBEVE5zLCBhcyB3ZWxsIGFzIG9wdGltaXppbmcgV0FO IHRyYW5zZmVycyBmb3IgZnJlcXVlbnRseSANCmRpc2Nvbm5lY3RlZCBlbmRwb2ludHMgd2hlcmUg dGhlIGxhdGVuY3kgb2YgaW5kaXZpZHVhbCBQRFVzIGlzIGxlc3Mgb2YgYSANCmNvbmNlcm4uDQoN CldlIHdvdWxkIGFsc28gdmVyeSBtdWNoIHdlbGNvbWUgZXhwbG9yaW5nIHRoZSBjb21tb25hbGl0 aWVzIG9mIEJQIHdpdGggDQpvdXIgbm90aW9uIG9mIGEgU2Vzc2lvbi1QRFUgd2l0aGluIHRoZSBE VE5SRy4NCg0KUmVnYXJkcywNCi0gZXpyYQ0KDQpPbiA1LzkvMjAxMiA4OjI2IEFNLCBTY290dCwg S2VpdGggTC4gd3JvdGU6DQo+IERvIHlvdSBtZWFuIJFjYW4gRFROIGJlIGltcGxlbWVudGVkIHVu ZGVybmVhdGggdGhlIHNvY2tldHMgQVBJPyBBbmQsIGlmDQo+IHlvdSB3YW50IHRoaXMgdG8gYmUg Y29tcGxldGVseSB0cmFuc3BhcmVudCB0byBhcHBsaWNhdGlvbnMsIHByZXN1bWFibHkNCj4gkWhp ZGluZyB1bmRlcm5lYXRoIFNPQ0tfU1RSRUFNIG9yIFNPQ0tfREdSQU0/DQo+DQo+IEluIGEgc2Vu c2UsIHRoZXJlknMgbm90aGluZyBpbiBJUCB0aGF0IHByZXZlbnRzIHlvdSBmcm9tIHN0b3Jpbmcg SVANCj4gZGF0YWdyYW1zIHdoaWxlIHdhaXRpbmcgZm9yIGEgZm9yd2FyZCBwYXRoIHRvIGJlY29t ZSBhdmFpbGFibGU7IHRoZQ0KPiBpc3N1ZXMgaW4gaW1wbGVtZW50aW5nIElQIHRoaXMgd2F5IGFs bCBoYXZlIHRvIGRvIHdpdGggdGhlIHRoaW5ncyBhcm91bmQNCj4gSVAsIGUuZy46DQo+DQo+ILdS b3V0aW5nIGltcGxlbWVudGF0aW9ucyB0aGF0IGRyb3AgZGF0YWdyYW1zIHdoZW4gbm8gbmV4dCBo b3AgaXMgYXZhaWxhYmxlDQo+DQo+ILdBUlAgKHdoaWNoIGhhcyB0aW1lb3V0cykNCj4NCj4gt0RO UyBxdWVyaWVzICh3aGljaCBoYXZlIHRpbWVvdXRzKQ0KPg0KPiC3Um91dGluZyBwcm90b2NvbHMg bGlrZSBPU1BGICh3aGljaCBoYXZlIHRpbWVvdXRzIGFuZCB3aGljaCB0eXBpY2FsbHkgZG8NCj4g bm90IGRlYWwgd2VsbCB3aXRoIGVpdGhlciBzY2hlZHVsZWQgY29ubmVjdGl2aXR5IG9yIHRlbXBv cmFyeSBwYXJ0aXRpb25zKQ0KPg0KPiC3QXBwbGljYXRpb25zIHRoYXQgZXhwZWN0IGVpdGhlciAx KSByZWFsLXRpbWUgY29ubmVjdGl2aXR5IGZyb20gSVAglm9yLQ0KPiAyKSBubyBjb25uZWN0aXZp dHkgKGJ1dCBub3QgYSBwb3NzaWJseS1kZWxheWVkIHN0b3JlLWFuZC1mb3J3YXJkIHNlcnZpY2Up DQo+DQo+IFJvdXRpbmeScyBwcm9iYWJseSBOT1QgYW4gaXNzdWUgaGVyZSBpZiB3ZZJyZSB0YWxr aW5nIGFib3V0IE1BTkVUcyBzaW5jZQ0KPiB3ZSBjb3VsZCB0d2VhayB0aGUgTUFORVQgcm91dGlu ZyBwcm90b2NvbHMsIGJ1dCBzb21lIG9mIHRoZSBvdGhlcnMgKGVzcC4NCj4gYXBwbGljYXRpb24g ZXhwZWN0YXRpb25zKSBhcmUgYSBiaXQgcHJvYmxlbWF0aWMuIFlvdZJkIGFsc28gbmVlZCB0bw0K PiB3b3JyeSBhYm91dCBob3cvaWYgeW91IHdhbnQgdG8gaW1wbGVtZW50IHRoaW5ncyBsaWtlIGN1 c3RvZHkgdHJhbnNmZXIsDQo+IHRoZSB2YXJpb3VzIGJ1bmRsZSBub3RpZmljYXRpb25zLCBldGMu DQo+DQo+IFRoYXQgc2FpZCwgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyBvZiBCUCB0aGF0IGxp dmUgdW5kZXJuZWF0aCBJUCAoQkJODQo+IGhhcyBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMg dGhpcykuIFRoZSBjaGFuY2VzIGFyZSB0aGF0IHRoZSBjbGFzcyBvZg0KPiBhcHBsaWNhdGlvbnMg dGhhdCB3b3VsZCBiZSBhbWVuYWJsZSB0byCRdHJhbnNwYXJlbnQ/dHJhbnNwbGFudGF0aW9uIHRv DQo+IHVzZSBCUCBzZXJ2aWNlcyBhcmUgVURQLWJhc2VkLCBhbmQgZm9yIHRoZXNlIChpZiB0aGUg YXBwbGljYXRpb25zIGRvbpJ0DQo+IGhhdmUgdGltZXJzIHRoYXQgd291bGQgcHJlY2x1ZGUgaXQp IHlvdSBtaWdodCBjb25zaWRlciB1c2luZyB0aGUgRFRODQo+IFR1bm5lbCB0aGF0knMgaW4gdGhl IERUTjIgcmVmZXJlbmNlIGltcGxlbWVudGF0aW9uIG9yIGFuIGVxdWl2YWxlbnQuDQo+IFRoYXQg aXMsIGlmIHRoZSBhcHBsaWNhdGlvbiBjYW4gaGFuZGxlIGl0LCBqdXN0IHR1bm5lbCBVRFAgb3Zl ciBCUC4gSWYNCj4gdGhlIGFwcGxpY2F0aW9uIGNhbpJ0IGhhbmRsZSBpdCwgdGhlbiBoaWRpbmcg QlAgdW5kZXJuZWF0aCB0aGUgc29ja2V0cw0KPiBBUEkgd291bGRuknQgd29yayAod2l0aG91dCBt b2RpZnlpbmcgdGhlIGFwcGxpY2F0aW9uKSBhbnl3YXkuDQo+DQo+IEFub3RoZXIgYXBwcm9hY2gg d291bGQgYmUgdG8gYXNrOiB3aGF0knMgdGhlIE1BTkVUIGdldHRpbmcgeW91IHRoYXQNCj4gRFRO L0JQIGNhbpJ0IChvciBkb2VzbpJ0KT8NCj4NCj4gLS1rZWl0aA0KPg0KPiAqRnJvbToqZHRuLWlu dGVyZXN0LWJvdW5jZXNAaXJ0Zi5vcmcNCj4gW21haWx0bzpkdG4taW50ZXJlc3QtYm91bmNlc0Bp cnRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqemhkNTQwOA0KPiAqU2VudDoqIFdlZG5lc2RheSwgTWF5 IDA5LCAyMDEyIDQ6NTYgQU0NCj4gKlRvOiogZHRuLWludGVyZXN0DQo+ICpTdWJqZWN0OiogW2R0 bi1pbnRlcmVzdF0gQ2FuIHdlIGltcGxlbWVudCBEVE4gaW4gTmV0d29yayBsYXllciBvZg0KPiBw cm90b2NvbCBzdGFjayA/DQo+DQo+IE5vdyBhbG1vc3QgYWxsIHRoZSBEVE4gaW1wbGVtZW50IHdp dGggQWRkaW5nIGJ1bmRsZSBsYXllciBiZXR3ZWVuDQo+IGFwcGxpY2F0aW9uIGFuZCB0cmFuc3Bv cnQgbGF5ZXIuDQo+DQo+IFRoZXNlIERUTiBhcmUgc2VwYXJhdGVkIHdpdGggTUFORVQgY29tcGxl dGVseSwgYWxsIHRoZSBkYXRhIGZyb20gTUFORVQNCj4gc2hvdWxkIGJlIHRyYW5zbGF0ZWQgdGhy b3VnaCB0aGUgRFROIGdhdGV3YXkgYW5kIGFsbCB0aGUgYXBwbGljYXRpb25zDQo+IHVzZWQgaW4g RFROIG11c3QgYmUgcmVkZXNpZ25lZC5CdXQgTUFORVQgYW5kIERUTiBjYW4gY29leGlzdCBpbiBz b21lIGNhc2VzLg0KPg0KPiBJIHdvbmRlciB0aGF0IHdoZXRoZXIgY2FuIHdlIGRlc2lnbiBEVE4g dmlhIG1vZGlmeWluZyB0aGUgbmV0d29yayBsYXllciwNCj4gbm90IHVzaW5nIEJQLiBUaHVzIHRo ZSBNQU5FVCBhbmQgRFROIGNhbiBjb2V4aXN0IGFuZCBpdCBpcyB0cmFuc3BhcmVudA0KPiBmb3Ig dXBwZXIgbGF5ZXJzLiBBbGwgdGhlIGFwcGxpY2F0aW9ucyBkb24ndCBuZWVkIHRvIG1vZGlmeS4N Cj4NCj4gSWYgdG8gZG8gc28uIFdoYXQgcHJvYmxlbXMgd2lsbCBlbmNvdW50ZXI/IG9yIGlzIGl0 IHBvc3NpYmxlPw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gaGV5ZWFzdA0KPg== ------=_001_NextPart141685856530_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I have read this paper. Buffer-and-burst model refer in this paper is= =20 very interesting. But I think your focus is mainly on the data=20 movement and high-performance. less handling on the disconnect of the link= . I=20 think the notion is similar to the BP. and the work is also valuable for=20 us.
 
regards.
 

heyeast
 
Date: 2012-05-11 00:32
CC: zhd5408; dtn-interest
Subject: Re: Re: [dtn-interest] Can we implement DTN in N= etwork=20 layer of protocol stack ?
This list might be interested in our&nb= sp;work on the eXtensible Session 
Protocol and our notion of a session-en= abled buffer-and-burst model for 
data movement.  While our focus has&nbs= p;been on high-performance, bulk data 
transfers, I believe our model could in=  many ways address what the 
original poster had in mind.
 
(PFLDNet 2010)
http://damsl.cis.udel.edu/projects/phoebus/phoebus_slabs.pdf
 
It has occurred to us on more than=  one occasion that we could apply our&n= bsp;
store-and-forward approach for managing the = interaction between MANETs 
and DTNs, as well as optimizing WAN&nbs= p;transfers for frequently 
disconnected endpoints where the latency of&= nbsp;individual PDUs is less of a 
concern.
 
We would also very much welcome explori= ng the commonalities of BP with 
our notion of a Session-PDU within the&= nbsp;DTNRG.
 
Regards,
- ezra
 
On 5/9/2012 8:26 AM, Scott, Keith L.&nb= sp;wrote:
> Do you mean =91can DTN be imp= lemented underneath the sockets API? And, if=
> you want this to be completely&nbs= p;transparent to applications, presumably
> =91hiding underneath SOCK_STREAM or SOC= K_DGRAM?
>
> In a sense, there=92s nothing in&n= bsp;IP that prevents you from storing IP
> datagrams while waiting for a forw= ard path to become available; the
> issues in implementing IP this way=  all have to do with the things ar= ound
> IP, e.g.:
>
> =B7Routing implementations that drop da= tagrams when no next hop is available
>
> =B7ARP (which has timeouts)
>
> =B7DNS queries (which have timeouts)
>
> =B7Routing protocols like OSPF (which&n= bsp;have timeouts and which typically do
> not deal well with either schedule= d connectivity or temporary partitions)
>
> =B7Applications that expect either 1)&n= bsp;real-time connectivity from IP =96or-
> 2) no connectivity (but not a = ;possibly-delayed store-and-forward service)
>
> Routing=92s probably NOT an issue = here if we=92re talking about MANETs since
> we could tweak the MANET routing&n= bsp;protocols, but some of the others (esp.<= /DIV>
> application expectations) are a bit&nbs= p;problematic. You=92d also need to
> worry about how/if you want to&nbs= p;implement things like custody transfer,
> the various bundle notifications, etc.<= /DIV>
>
> That said, there are implementations&nb= sp;of BP that live underneath IP (BBN
> has an implementation that does th= is). The chances are that the class of<= /DIV>
> applications that would be amenable&nbs= p;to =91transparent?transplantation to
> use BP services are UDP-based, and=  for these (if the applications don=92t
> have timers that would preclude it= ) you might consider using the DTN
> Tunnel that=92s in the DTN2 refere= nce implementation or an equivalent.
> That is, if the application can&nb= sp;handle it, just tunnel UDP over BP. = If
> the application can=92t handle it, = ;then hiding BP underneath the sockets
> API wouldn=92t work (without modifying&= nbsp;the application) anyway.
>
> Another approach would be to ask:&= nbsp;what=92s the MANET getting you that
> DTN/BP can=92t (or doesn=92t)?
>
> --keith
>
> *From:*dtn-interest-bounces@irtf.org
> [mailto:dtn-interest-bounces@irtf.org] *On Behalf=  Of *zhd5408
> *Sent:* Wednesday, May 09, 2012 4:= 56 AM
> *To:* dtn-interest
> *Subject:* [dtn-interest] Can we implem= ent DTN in Network layer of
> protocol stack ?
>
> Now almost all the DTN implement&n= bsp;with Adding bundle layer between
> application and transport layer.
>
> These DTN are separated with MANET=  completely, all the data from MANET
> should be translated through the D= TN gateway and all the applications
> used in DTN must be redesigned.But=  MANET and DTN can coexist in some = ;cases.
>
> I wonder that whether can we = design DTN via modifying the network layer,<= /DIV>
> not using BP. Thus the MANET = and DTN can coexist and it is transpare= nt
> for upper layers. All the applicat= ions don't need to modify.
>
> If to do so. What problems wi= ll encounter? or is it possible?
>
> -----------------------------------------------------------= -------------
>
> heyeast
>
------=_001_NextPart141685856530_=------ From kscott@mitre.org Fri May 11 04:32:37 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20CA21F846A for ; Fri, 11 May 2012 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xkRjIKPKB8m for ; Fri, 11 May 2012 04:32:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F21B521F845F for ; Fri, 11 May 2012 04:32:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 44A2E21B1786; Fri, 11 May 2012 07:32:34 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2C6CC21B1791; Fri, 11 May 2012 07:32:34 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Fri, 11 May 2012 07:32:33 -0400 From: "Scott, Keith L." To: "Burleigh, Scott C (313B)" , "dtn-interest@irtf.org" Thread-Topic: DTN enabled printer or fax machine? Thread-Index: Ac0uipkLzKF363IpRaSCk7foLxEDJgAe8ssQABi+LHA= Date: Fri, 11 May 2012 11:32:32 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE206017@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_5EE81C5C4CFFF4418C5EAD12F49D64EE206017IMCMBX01MITREORG_" MIME-Version: 1.0 Subject: Re: [dtn-interest] DTN enabled printer or fax machine? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 11:32:37 -0000 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE206017IMCMBX01MITREORG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This has got to be doable. A coupling between BP for OpenWRT and either tu= nneling or proxying the Windows shared printer service or CUPS... You might want duplicate suppression at the printer a la the Disruption Tol= erant Payload Conditioning work that SPICE/NASA have been working on. --keith From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Burleigh, Scott C (313B) Sent: Thursday, May 10, 2012 7:43 PM To: dtn-interest@irtf.org Subject: Re: [dtn-interest] DTN enabled printer or fax machine? This sounds like a great idea to me; I don't know of anybody who's working = on anything similar, and it does sound like something that could be very us= eful. Scott From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Jeremiah Scholl Sent: Thursday, May 10, 2012 2:02 AM To: dtn-interest@irtf.org Cc: Shabbir Subject: [dtn-interest] DTN enabled printer or fax machine? Hello DTN people. Just now I was looking the presentation slides at the li= nk below, specifically slide 10. It shows an "sms printer" that is used fo= r printing out results from laboratory tests so they can be returned to a c= linic via SMS, instead of requiring the physical transport of paper records= . http://www.teampata.org/downloads/presentations/2011/2%20Shaffiq%20Essajee%= 20Fast%20tracking%20infants.pdf The idea is being applied to reduce the time from when tests are taken of i= nfants that might have HIV, to when they can put them on Anti Retroviral Tr= eatment. It made me wonder if anyone has implemented a "dtn printer" or "dtn fax mac= hine". It could be used as a substitute for paper mail, where SMS is not th= e best alternative. It could provide several advantages. For example, some studies that transmit health information to mobile phones= run into problems because the phones get stolen. The printer hardware wou= ld not be so useful for general purposes however, like a mobile phone is, s= o the incentive to steal one would not be as great. Also in situations wher= e you want a paper copy of the information that a DTN network is transmitti= ng, then the usability would be much better than having a general computer-= printer combo. This is usually the case in a healthcare setting since the = remote clinics that would use a system like this use paper records and it i= s quite difficult to get them to change over to completely use electronic r= ecords. Also potentially you could transmit much nicer documents than the SMS versi= on. So I have two questions.... a) Has anyone ever implemented a DTN-enabled fax machine or printer? b) If not would anyone be interested in creating an open source hardwa= re/software implementation of one? I think that it could be useful in the h= ealthcare domain. Jeremiah ---------------------------------------------- Jeremiah Scholl, Ph.D. Senior Researcher Health Informatics Centre Karolinska Institutet +46852483926 --_000_5EE81C5C4CFFF4418C5EAD12F49D64EE206017IMCMBX01MITREORG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This has got to be doa= ble.  A coupling between BP for OpenWRT and either tunneling or proxyi= ng the Windows shared printer service or CUPS…

 

You might want duplica= te suppression at the printer a la the Disruption Tolerant Payload Conditio= ning work that SPICE/NASA have been working on.

 

   &nbs= p;            &= nbsp;           &nbs= p;   --keith

 

From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounc= es@irtf.org] On Behalf Of Burleigh, Scott C (313B)
Sent: Thursday, May 10, 2012 7:43 PM
To: dtn-interest@irtf.org
Subject: Re: [dtn-interest] DTN enabled printer or fax machine?=

 

This sounds like a great idea to me; I don’t know of anybody who= ’s working on anything similar, and it does sound like something that= could be very useful.

 

Scott

 

 

Hello DTN people.  J= ust now I was looking the presentation slides at the link below, specifical= ly slide 10.  It shows an “sms printer” that is used for p= rinting out results from laboratory tests so they can be returned to a clinic via SMS, instead of requiring the physical transport of paper = records. 

 

http://www.teampa= ta.org/downloads/presentations/2011/2%20Shaffiq%20Essajee%20Fast%20tracking= %20infants.pdf

 

The idea is being applied= to reduce the time from when tests are taken of infants that might have HI= V, to when they can put them on Anti Retroviral Treatment.

 

It made me wonder if anyo= ne has implemented a ”dtn printer” or “dtn fax machine= 221;. It could be used as a substitute for paper mail, where SMS is not the= best alternative. It could provide several advantages.

 

For example, some studies= that transmit health information to mobile phones run into problems becaus= e the phones get stolen.  The printer hardware would not be so useful = for general purposes however, like a mobile phone is, so the incentive to steal one would not be as great. Also in sit= uations where you want a paper copy of the information that a DTN network i= s transmitting, then the usability would be much better than having a gener= al computer-printer combo. This is usually the case in  a healthcare setting since the remote clinics= that would use a system like this use paper records and it is quite diffic= ult to get them to change over to completely use electronic records.

 

Also potentially you coul= d transmit much nicer documents than the SMS version. 

 

So I have two questions&#= 8230;.

 

a)      Has anyone ever implemented a DTN-enabled fax machi= ne or printer?

b)      If not would anyone be interested in creating an op= en source hardware/software implementation of one? I think that it could be= useful in the healthcare domain.

 

Jeremiah

 

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

Jeremiah Scholl, Ph.D.

Senior Researcher<= o:p>

Health Informatics Centre

Karolinska Institutet

+46852483926

--_000_5EE81C5C4CFFF4418C5EAD12F49D64EE206017IMCMBX01MITREORG_-- From scott.c.burleigh@jpl.nasa.gov Fri May 11 07:52:45 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C220321F851E for ; Fri, 11 May 2012 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG0kFZBXfjF7 for ; Fri, 11 May 2012 07:52:42 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 73A8021F8512 for ; Fri, 11 May 2012 07:52:42 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4BEqdbk004510 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 11 May 2012 07:52:40 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.245]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.250]) with mapi id 14.02.0298.004; Fri, 11 May 2012 07:52:39 -0700 From: "Burleigh, Scott C (313B)" To: zhd5408 , "Scott, Keith L." Thread-Topic: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? Thread-Index: AQHNL1L/hVp86Dgz50WmACIpmHBOnpbEqrxw Date: Fri, 11 May 2012 14:52:38 +0000 Message-ID: References: <201205091656034891078@gmail.com>, <5EE81C5C4CFFF4418C5EAD12F49D64EE2049C5@IMCMBX01.MITRE.ORG> <2012051116492072556714@gmail.com> In-Reply-To: <2012051116492072556714@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B056141apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 14:52:45 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B056141apembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An even easier solution might be the BPTAP implementation described in http= ://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D06187106. BPTAP is unfor= tunately not publicly releasable due to ITAR restrictions, but not because = it's a real defense article, simply because of the way its development was = funded. We're working on a different, and I think more capable, implementa= tion that's funded in a way that will enable JPL to at least license it and= possible release it as open source. But it's not ready yet. Scott From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of heyeast Sent: Friday, May 11, 2012 1:49 AM To: Scott, Keith L. Cc: dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protoc= ol stack ? Hi keith: Thanks for your attention. To the question "what's the MANET getting you th= at DTN/BP can't (or doesn't)?" my answer is, in some critical MANET environ= ments link will disconnect frequently.It is a MANET scenario but not a DTN= scenario completely. Maybe MANET can't handle these disconnect.So we wish = using DTN to enhance the reliability and robust of the MANET. implement DT= N in network layer, thus can be used for MANET. The WNaN developed by BBN Technology is amazing. But it is not open for us.= I have read this paper "The DARPA WNaN Network Architecture " about that. = It is heuristic for me. Firstly it tells me it is possible for me to do thi= s. although it is so difficulty. I will also consider the DTN Tunnel in = DTN2 seriously. Thank u again. ________________________________ heyeast From: Scott, Keith L. Date: 2012-05-09 20:26 To: zhd5408; dtn-interest Subject: RE: [dtn-interest] Can we implement DTN in Network layer of protoc= ol stack ? Do you mean 'can DTN be implemented underneath the sockets API'? And, if y= ou want this to be completely transparent to applications, presumably 'hidi= ng underneath SOCK_STREAM or SOCK_DGRAM'? In a sense, there's nothing in IP that prevents you from storing IP datagra= ms while waiting for a forward path to become available; the issues in impl= ementing IP this way all have to do with the things around IP, e.g.: 1. Routing implementations that drop datagrams when no next hop is availab= le 2. ARP (which has timeouts) 3. DNS queries (which have timeouts) 4. Routing protocols like OSPF (which have timeouts and which typically do= not deal well with either scheduled connectivity or temporary partitions) 5. Applications that expect either 1) real-time connectivity from IP -or- = 2) no connectivity (but not a possibly-delayed store-and-forward service) Routing's probably NOT an issue here if we're talking about MANETs since we= could tweak the MANET routing protocols, but some of the others (esp. appl= ication expectations) are a bit problematic. You'd also need to worry abou= t how/if you want to implement things like custody transfer, the various bu= ndle notifications, etc. That said, there are implementations of BP that live underneath IP (BBN has= an implementation that does this). The chances are that the class of appl= ications that would be amenable to 'transparent' transplantation to use BP = services are UDP-based, and for these (if the applications don't have timer= s that would preclude it) you might consider using the DTN Tunnel that's in= the DTN2 reference implementation or an equivalent. That is, if the appli= cation can handle it, just tunnel UDP over BP. If the application can't ha= ndle it, then hiding BP underneath the sockets API wouldn't work (without m= odifying the application) anyway. Another approach would be to ask: what's the MANET getting you that DTN/BP = can't (or doesn't)? --keith From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of zhd5408 Sent: Wednesday, May 09, 2012 4:56 AM To: dtn-interest Subject: [dtn-interest] Can we implement DTN in Network layer of protocol s= tack ? Now almost all the DTN implement with Adding bundle layer between applicati= on and transport layer. These DTN are separated with MANET completely, all the data from MANET shou= ld be translated through the DTN gateway and all the applications used in D= TN must be redesigned.But MANET and DTN can coexist in some cases. I wonder that whether can we design DTN via modifying the network layer, no= t using BP. Thus the MANET and DTN can coexist and it is transparent for up= per layers. All the applications don't need to modify. If to do so. What problems will encounter? or is it possible? ________________________________ heyeast --_000_A5BEAD028815CB40A32A5669CF737C3B056141apembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An even easier solution m= ight be the BPTAP implementation described in = http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=3D06187106.  B= PTAP is unfortunately not publicly releasable due to ITAR restrictions, but= not because it’s a real defense article, simply because of the way its development was funded.  We’re working o= n a different, and I think more capable, implementation that’s funded= in a way that will enable JPL to at least license it and possible release = it as open source.  But it’s not ready yet.

Scott

From: dtn-interest-bounces@irtf.org [mailto:dt= n-interest-bounces@irtf.org] On Behalf Of heyeast
Sent: Friday, May 11, 2012 1:49 AM
To: Scott, Keith L.
Cc: dtn-interest
Subject: Re: [dtn-interest] Can we implement DTN in Network layer of= protocol stack ?

 

Hi<= span style=3D"font-size:10.5pt;font-family:"Times New Roman",&quo= t;serif";color:navy"> keith:

 

Thanks for your attention. To the question "whatR= 17;s the MANET getting you that DTN/BP can’t (or doesn’t)?"= ; my answer is, in some critical MANET environments link  will disconnect fr= equently.It is a MANET scenario but not a DTN scenario completely.&nbs= p;Maybe MANET can't handle these disconnect.So we wish using DTN to enhance= the reliability and robust of the MANET.  implement DTN in network layer, thus can be used for MANET.

 

The WNaN developed by BBN Technology is amazing. But it i= s not open for us. I have read this paper "The DARPA WN= aN Network Architecture " about that. It is heuristic for me. Firstly it tells me it is = possible for me to do this. although it is so difficulty.   = I will also consider the DTN Tunnel in DTN2 seriously.

 

Thank u again. 

 


heyeast

 

Date: 2012-05-09 20:26

Subject: RE: [dtn-interest] Can we implemen= t DTN in Network layer of protocol stack ?

Do you mean ‘can DT= N be implemented underneath the sockets API’?  And, if you want = this to be completely transparent to applications, presumably ‘hiding= underneath SOCK_STREAM or SOCK_DGRAM’?

In a sense, there’s= nothing in IP that prevents you from storing IP datagrams while waiting fo= r a forward path to become available; the issues in implementing IP this way all have to do with the things around IP, e.g.:

1.  Routing implement= ations that drop datagrams when no next hop is available<= /p>

2.  ARP (which has ti= meouts)

3.  DNS queries (whic= h have timeouts)

4.  Routing protocols= like OSPF (which have timeouts and which typically do not deal well with e= ither scheduled connectivity or temporary partitions)

5.  Applications that= expect either 1) real-time connectivity from IP –or- 2) no connectiv= ity (but not a possibly-delayed store-and-forward service)

Routing’s probably NOT an issue here if we’re talking abou= t MANETs since we could tweak the MANET routing protocols, but some of the others (esp. application expectations) are a bit problematic.  Yo= u’d also need to worry about how/if you want to implement things like= custody transfer, the various bundle notifications, etc.=

That said, there are implementations of BP that live underneath IP (BB= N has an implementation that does this).  The chances are that the class of applications that would be amenable to ‘transparen= t’ transplantation to use BP services are UDP-based, and for these (i= f the applications don’t have timers that would preclude it) you migh= t consider using the DTN Tunnel that’s in the DTN2 reference implementation or an equivalent.  That is, if the applicati= on can handle it, just tunnel UDP over BP.  If the application canR= 17;t handle it, then hiding BP underneath the sockets API wouldn’t wo= rk (without modifying the application) anyway.

Another approach would be to ask: what’s the MANET getting you t= hat DTN/BP can’t (or doesn’t)?

           &nbs= p;            &= nbsp;    --keith

From: dtn-interest-bounces@irtf.= org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of zhd5408
Sent: Wednesday, May 09, 2012 4:56 AM
To: dtn-interest
Subject: [dtn-interest] Can we implement DTN in Network layer of pro= tocol stack ?

 

Now almost all the DTN impleme= nt with Adding bundle layer between application and transport layer.

 

These DTN are separated w= ith MANET completely, all the data from MANET should be translated thr= ough the DTN gateway and all the applications used in DTN must be redesigne= d.But MANET and DTN can coexist in some cases.

 

I wonder that whether can we d= esign DTN via modifying the network layer, not using BP. Thu= s the MANET and DTN can coexist and it is transparent for upper l= ayers.  All the applications don't need to modify.

 

If to do so. What problems wil= l encounter? or is it possible?

 


heyeast

--_000_A5BEAD028815CB40A32A5669CF737C3B056141apembxsp40RESADJP_-- From acaro@bbn.com Fri May 11 08:19:33 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8EC21F8539 for ; Fri, 11 May 2012 08:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjsGpjb2p3JI for ; Fri, 11 May 2012 08:19:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4567221F8523 for ; Fri, 11 May 2012 08:19:33 -0700 (PDT) Received: from lion.bbn.com ([128.89.80.73]:48335) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SSrcW-00009R-MP; Fri, 11 May 2012 11:19:04 -0400 Message-ID: <4FAD2DF1.8050301@bbn.com> Date: Fri, 11 May 2012 11:19:13 -0400 From: Armando Caro User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Vint Cerf References: <201205091656034891078@gmail.com> <201205111618505003564@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: zhd5408 , dtn-interest Subject: Re: [dtn-interest] Can we implement DTN in Network layer of protocol stack ? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:19:34 -0000 Vint, BBN's BP stack uses the IP ToS bits to determine which IP packets can tolerate delay and which cannot. BBN's BP implementation provides configuration options to control which ToS bits are provided DTN service. All IP packets are BP encapsulated, but not all IP packets are provided DTN service. Armando On 05/11/2012 04:21 AM, Vint Cerf wrote: > so the "transparency" assertion is of interest - DTN/BP is intended to > be very resilient in the face of disconnection - IP is nominally not > so "patient" - so how is this "transparency" achieved? > > vint > > > > On Fri, May 11, 2012 at 4:18 AM, heyeast wrote: >> hi Vint Cerf: >> In high loss/latency environment, DTN is implicit the best choice for us. >> However, we focus on the wireless environment with low latency but sometime >> the link will disconnect for a few time. In other words, we wish using DTN >> to enhance the MANET's reliable and robust. >> >> As keith refer, now BBN technology has implement WNaN with handling BP under >> IP stack and transparent for upper layers. >> >> ________________________________ >> heyeast >> >> From: Vint Cerf >> Date: 2012-05-09 18:21 >> To: zhd5408 >> Subject: Re: [dtn-interest] Can we implement DTN in Network layer of >> protocol stack ? >> I think the problem is that the logic and behavior of DTN is different >> from IP. Most of the IP-based protocols assume low latency while DTN >> assume high latency and loss. The result is that hiding the BP (or DTN >> functionality) in the network layer leads to applications that will be >> confused or just fail when operating in a high loss/latency >> environment. UDP applications don't necessarily work either if they >> assume implicit low latency. >> >> v >> >> >> On Wed, May 9, 2012 at 4:56 AM, zhd5408 wrote: >>> Now almost all the DTN implement with Adding bundle layer between >>> application and transport layer. >>> >>> These DTN are separated with MANET completely, all the data from MANET >>> should be translated through the DTN gateway and all the applications used >>> in DTN must be redesigned.But MANET and DTN can coexist in some cases. >>> >>> I wonder that whether can we design DTN via modifying the network layer, not >>> using BP. Thus the MANET and DTN can coexist and it is transparent for upper >>> layers. All the applications don't need to modify. >>> >>> If to do so. What problems will encounter? or is it possible? >>> >>> ________________________________ >>> heyeast >>> >>> _______________________________________________ >>> dtn-interest mailing list >>> dtn-interest@irtf.org >>> https://www.irtf.org/mailman/listinfo/dtn-interest >>> > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From eric.dot.travis@gmail.com Fri May 11 11:50:14 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6896B21F86FE for ; Fri, 11 May 2012 11:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xNU89vbOIhg for ; Fri, 11 May 2012 11:50:12 -0700 (PDT) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87721F86FA for ; Fri, 11 May 2012 11:50:12 -0700 (PDT) Received: by vbmv11 with SMTP id v11so4165272vbm.13 for ; Fri, 11 May 2012 11:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RVnibhPZCcdZSabuzYU7B48E+oHNSg2ALE641+8nwCM=; b=xtS8qrEKlwGpG4bbLieN/Y/eYEhl6Io4CKTvXlNxVCqt2tpp/qTF+P54Ej1BfJNJtR FAp5KztmyohPqbFRoAkWOrO1Pp7MTrnBIDF2fRiJa9s6+nkzz2OmH3DRwddyR92FzTs9 GcDpa/HKHkQ+kzvlXYCZgQG2D3FASpELG7v6XeIgpBs4MyvbZx2hJyPe+8HXroB+pOAW 6lNbGEk1J/IlzpaMYA20qK2JzjPsFKV7mo1nEjii7ix9N4LVFtROTz4pycriPcUJTxrE g5o0VUdbW+7/kvxj69rqDYdsDGwOq9Hg4oKp6udQrFkqOsUJ8PlZ/0eRcv52bidwL9OD pV1A== MIME-Version: 1.0 Received: by 10.52.180.232 with SMTP id dr8mr4478754vdc.111.1336762211755; Fri, 11 May 2012 11:50:11 -0700 (PDT) Received: by 10.52.91.34 with HTTP; Fri, 11 May 2012 11:50:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 May 2012 14:50:11 -0400 Message-ID: From: Eric Travis To: Jeremiah Scholl Content-Type: text/plain; charset=ISO-8859-1 Cc: Shabbir , "dtn-interest@irtf.org" Subject: Re: [dtn-interest] DTN enabled printer or fax machine? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:50:14 -0000 > Also potentially you could transmit much nicer documents than the SMS > version. > > So I have two questions.... > > > a) Has anyone ever implemented a DTN-enabled fax machine or printer? > > b) If not would anyone be interested in creating an open source > hardware/software implementation of one? I think that it could be useful in > the healthcare domain. While not a "bundling" flavored DTN approach, we built and deployed a DTN-enabled logger for remotely deployed middle boxes a while back using XMPP (RFC 6121,6122 originall known as Jabber) as the persistent messaging infrastructure. We chose to embedded xmpp servers with the clients to make the disconnects transparent to the reporting processes and used a previously deployed xmpp server local to the log repository. It was simple to implement most of it using mature open source code. There are little bits of glue that are implementation dependent (client and server interfaces) but those are low impact. If you haven't already considered a similar approach, it might be able to provide just what you need. Eric From jo@netlab.tkk.fi Sun May 13 12:47:33 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4821F84CF for ; Sun, 13 May 2012 12:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wukxb1M2EwNJ for ; Sun, 13 May 2012 12:47:33 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by ietfa.amsl.com (Postfix) with ESMTP id E936D21F84B3 for ; Sun, 13 May 2012 12:47:32 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q4DJlTxx029086; Sun, 13 May 2012 22:47:29 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 22249-952; Sun, 13 May 2012 22:47:28 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q4DJlMj8029082; Sun, 13 May 2012 22:47:22 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 989D41E1DD; Sun, 13 May 2012 22:47:22 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RLuftO9uzBdj; Sun, 13 May 2012 22:47:17 +0300 (EEST) Received: from [192.168.0.5] (a91-154-110-176.elisa-laajakaista.fi [91.154.110.176]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 659671E00B; Sun, 13 May 2012 22:47:17 +0300 (EEST) Message-ID: <4FB00FDF.2090305@netlab.tkk.fi> Date: Sun, 13 May 2012 22:47:43 +0300 From: Joerg Ott User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: dtn-interest@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Subject: [dtn-interest] DTNRG meeting in San Jose X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 19:47:33 -0000 Hi, having talked to various people, we feel that there is potential for having another longer DTNRG meeting to make active progress on the specifications. Google has kindly offered to host a meeting on 26/27 July 2012 in San Jose, CA. Time and date are chosen so that the IETF meeting is not too far away. The meeting will run for two full days. One major discussion item will be revising RFC 5050 and related specifications. We have gained lots of experience and have found that some things work better than others. It appears a good point in time to start thinking on how to fold this experience into our specs. We will provide more detailed information about the venue soonish. Please send us private email if you want to attend so that we can get a rough estimate of the group size. Stephen, Kevin, and Jörg From kfall@qualcomm.com Sun May 13 13:20:00 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B921F84FF for ; Sun, 13 May 2012 13:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIjrJCi0MoQr for ; Sun, 13 May 2012 13:20:00 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id F385321F84D6 for ; Sun, 13 May 2012 13:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=kfall@qualcomm.com; q=dns/txt; s=qcdkim; t=1336940399; x=1368476399; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip: content-type:content-id:content-transfer-encoding: mime-version; bh=PwGsiIaM5JE5mNxmpFqU4xdO3Zp/eSqLwU7vMUCi/1A=; b=lLj2q+UwAWGxHIYHnKPowEY+id8WT1NCZoADbSHJjuLhRs1zNUdHuky8 s+nwpizk0EVxpsEuenYCeZZal2NusHs1TidBXSeBbWHwOpLxs1ozDkIwU w/DYpKjtmdq4brngcPaKieztQPUEOWIeXz9sVpfqy5ZXmj6pnCz+UtgT/ U=; X-IronPort-AV: E=McAfee;i="5400,1158,6710"; a="188239095" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 13 May 2012 13:19:59 -0700 X-IronPort-AV: E=Sophos;i="4.75,579,1330934400"; d="scan'208";a="220371073" Received: from nasanexhc09.na.qualcomm.com ([172.30.39.8]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 May 2012 13:19:59 -0700 Received: from NASANEXD01E.na.qualcomm.com ([169.254.5.82]) by nasanexhc09.na.qualcomm.com ([172.30.39.8]) with mapi id 14.02.0283.003; Sun, 13 May 2012 13:19:59 -0700 From: "Fall, Kevin" To: Joerg Ott , "dtn-interest@irtf.org" Thread-Topic: DTNRG meeting in San Jose [Mountain View] Thread-Index: AQHNMUXE2K6Mbtfiek6g4vnsER4gJg== Date: Sun, 13 May 2012 20:19:59 +0000 Message-ID: In-Reply-To: <4FB00FDF.2090305@netlab.tkk.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.114.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <20E6B74093011349A4FD1C81A79D212E@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-interest] DTNRG meeting in San Jose [Mountain View] X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 20:20:00 -0000 Slight correction-- that will presumably be Mountain View rather than San Jose. [a few miles further north]. Regards, - Kevin On 5/13/12 12:47 PM PDT, "Joerg Ott" wrote: >Hi, > >having talked to various people, we feel that there is potential >for having another longer DTNRG meeting to make active progress on >the specifications. > >Google has kindly offered to host a meeting on 26/27 July 2012 >in San Jose, CA. Time and date are chosen so that the IETF meeting >is not too far away. The meeting will run for two full days. > >One major discussion item will be revising RFC 5050 and related >specifications. We have gained lots of experience and have found >that some things work better than others. It appears a good point >in time to start thinking on how to fold this experience into our >specs. > >We will provide more detailed information about the venue soonish. > >Please send us private email if you want to attend so that we can >get a rough estimate of the group size. > >Stephen, Kevin, and J=F6rg From vint@google.com Sun May 13 14:11:48 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ABF21F84A5 for ; Sun, 13 May 2012 14:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QupMPZuxP11R for ; Sun, 13 May 2012 14:11:47 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id B13C321F84DE for ; Sun, 13 May 2012 14:11:47 -0700 (PDT) Received: by yhgm50 with SMTP id m50so4810662yhg.13 for ; Sun, 13 May 2012 14:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=8zHxc9AgJa+ya0ZiJvFwidg/D5S7UvhPpXaI12iFGEo=; b=j0MLcqdImPnDkHX3WORtKRIZ1ghTPszQmQE4Y8UYN0DmywNQGWC4tUt/Xv72/64Mrz a2ncn1oEYBYaI53+bWjivQFYORxjNme8Eb2AQtB+Tt7+BrzeblznsXMjfe5u7HEXTSL7 NWgBemHo5Op1fy5KDIXiqDrosSYZR8/EhXweKFy1dSMqPed+jag8VSW2QmvSPIzdhKi/ D3D9Bawe4EU8HoEbWwTDk7dxGF0lPcEH8AswkaScwG52mQmbmE+T8hzuJAgUU8wAShOH a/rnV0pYho6cWI+yraoB1tuboJCaQlBfK+wZLhCiBKe/3GBpjPB6RGKwrTdDcepvQmEG PNyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=8zHxc9AgJa+ya0ZiJvFwidg/D5S7UvhPpXaI12iFGEo=; b=mH1E6fUP46MHsPqqOHD/ldHgspRV3NMWnfdsfSYIObeaDsg5TGVcVrzuEDeGdGKgjR Stpgppo14q6rvcqqxFVB1dmxSRWjcyARb/RUSekqECbUuNcDVgWjhLabnFJW6lV4fAY9 /h5lEDZ0rYEy+0cG7Ny0JcU2eDJowmLjD0VYvYO2FcqBzR37Skf4wJcZC8PpO+xiFeTB 5vt8VGcFVmMmoSp+B/Aaho2QouTbdqrJ2nSq+BJiGfB3SLefnI8a+arW5tTNa59ISde7 GSog7UbhRLLKPsYajLHzp+equL0Twfg9t6un//LE2hmz1liZeQlUn40ZcTGr1nqlyeCt rRow== Received: by 10.50.169.7 with SMTP id aa7mr2929375igc.52.1336943507058; Sun, 13 May 2012 14:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.169.7 with SMTP id aa7mr2929368igc.52.1336943506824; Sun, 13 May 2012 14:11:46 -0700 (PDT) Received: by 10.231.124.138 with HTTP; Sun, 13 May 2012 14:11:46 -0700 (PDT) In-Reply-To: References: <4FB00FDF.2090305@netlab.tkk.fi> Date: Sun, 13 May 2012 17:11:46 -0400 Message-ID: From: Vint Cerf To: "Fall, Kevin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlda/7O2RmN+g8AHzVbNOEzpm5nhxlf+asVslZGnYK8GlvSG8iGrV7TuaBhf/ApSHY0lyGUvpjsZdnonZ4amUhbowF9FdvSW8Q5ehz5kklC/JjSO5mBBIQXzWVbaCPlIJRTx+3uuA4FVsB2oTWkTHAx6r4xlQ== Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] DTNRG meeting in San Jose [Mountain View] X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 21:11:48 -0000 yes, mountain view. v On Sun, May 13, 2012 at 4:19 PM, Fall, Kevin wrote: > Slight correction-- that will presumably be Mountain View rather than San > Jose. > [a few miles further north]. > Regards, > - Kevin > > On 5/13/12 12:47 PM PDT, "Joerg Ott" wrote: > >>Hi, >> >>having talked to various people, we feel that there is potential >>for having another longer DTNRG meeting to make active progress on >>the specifications. >> >>Google has kindly offered to host a meeting on 26/27 July 2012 >>in San Jose, CA. =A0Time and date are chosen so that the IETF meeting >>is not too far away. =A0The meeting will run for two full days. >> >>One major discussion item will be revising RFC 5050 and related >>specifications. =A0We have gained lots of experience and have found >>that some things work better than others. =A0It appears a good point >>in time to start thinking on how to fold this experience into our >>specs. >> >>We will provide more detailed information about the venue soonish. >> >>Please send us private email if you want to attend so that we can >>get a rough estimate of the group size. >> >>Stephen, Kevin, and J=F6rg > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From cpetrioli@gmail.com Mon May 14 04:28:59 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A721F86D3 for ; Mon, 14 May 2012 04:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQxjMxpf8E2Y for ; Mon, 14 May 2012 04:28:59 -0700 (PDT) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 489DB21F86CB for ; Mon, 14 May 2012 04:28:59 -0700 (PDT) Received: by ggnm2 with SMTP id m2so3829530ggn.13 for ; Mon, 14 May 2012 04:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Zg39zvgY3wyi6TKbxliMFEPBLEfB6RWyMV1qwNVCMo=; b=sIZkORR0QKTnyFN497PE3bR1dBMrCDqBAkqwiaHXQGJb36Bati2zrbachxeKwWizY7 FwdgDWifwaSfgy0DztfEeqk348fK+yXH1QcyrYlGle+WxyfP8GQjWrW52b/6kNrDRsoZ 0W3Me/0DCiP3wngQQ1VIiAAbcZ+SRpvs0GubG/pDYfrNEXNEWvqrG+fa/ZhuXOkbEcQc wBpQ0y3pOQgoDAf+C0pzItWAc4Sdn+VpCpLpw4jHtieylQ2c5Rc3HMohxpb95PTZtnzQ B3KyLSZDbEi62IEgPoNebCnSTD8TNDvF7aICjp57BXq/a9f68C3yDa0ato64bslKlZki pdWQ== MIME-Version: 1.0 Received: by 10.50.185.165 with SMTP id fd5mr4021123igc.46.1336994938669; Mon, 14 May 2012 04:28:58 -0700 (PDT) Received: by 10.42.169.4 with HTTP; Mon, 14 May 2012 04:28:58 -0700 (PDT) Date: Mon, 14 May 2012 13:28:58 +0200 Message-ID: From: Chiara Petrioli To: dtn-interest@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dtn-interest] SUNSET (open source framework for underwater sensor networks) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:31:40 -0000 Dear colleagues, We are releasing SUNSET (La Sapienza University Networking framework for underwater Simulation Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test at sea novel communication protocols for underwater communications. We have extensively used it for in field tests for two years, and we are now releasing it to the research community believing it can speed up significantly research in the field of underwater sensor networks. It allows to seamlessy use the same code for simulating, emulating and experimenting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here Underwater wireless sensor network group: http://reti.dsi.uniroma1.it/UWSN_Group/ SENSES laboratory: http://reti.dsi.uniroma1.it/SENSES_lab/ Best Regards Prof. Chiara Petrioli Director, SENSES lab Computer Science Department University of Rome La Sapienza E-mail: petrioli@di.uniroma1.it From petrioli@di.uniroma1.it Mon May 14 07:44:44 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10321F8512 for ; Mon, 14 May 2012 07:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oE0gVwpwImt for ; Mon, 14 May 2012 07:44:43 -0700 (PDT) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 43D5621F850C for ; Mon, 14 May 2012 07:44:43 -0700 (PDT) Received: by laai10 with SMTP id i10so3520853laa.13 for ; Mon, 14 May 2012 07:44:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=9zFjvCM+OUH6whj23inzjfjsYczUzCAFPZStnL2gpAQ=; b=GCiy1odX6WzzzXOSY3aQ/HxOBvYi9jLt1a4MTKc2PiHF8AXXybzCts7ahQtO+9iUhN PD8FMuZgzdiXHTo65AXSp14LXGipXVe0zARALstv5AkEEVwAxv1Pmjsc1fXTrHDHQBy+ zCXgZTWmaZLtzHJZhq07tShnvnepIiE44vto3IbHqmlndyB+RvzqYHNsS2u0Z0rGRP2V p/eQRSQNUqHZLmPyIOEGdc0Hv1kOi5didKfOgQH2ja5/covgNma3STPMAaoXTLumzqDv ofpmwnmVOyVag0BEgxgrCVYEgjRRFFHkRhS8gbv+rHPQhSeMfN60ViE1Y1G9SG4xF2mN NxuA== MIME-Version: 1.0 Received: by 10.112.101.169 with SMTP id fh9mr3875317lbb.18.1337006681951; Mon, 14 May 2012 07:44:41 -0700 (PDT) Received: by 10.112.86.40 with HTTP; Mon, 14 May 2012 07:44:41 -0700 (PDT) Date: Mon, 14 May 2012 16:44:41 +0200 Message-ID: From: Chiara Petrioli To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary=f46d04016ae1570e1c04c00020f6 X-Gm-Message-State: ALoCoQmqcckE35gXKq9GGEyi3t2S/1gKMYMrLA+rgRsMJ2zmVXZVZ4Gw3FM3ZMdPKij2YbMS8dqb Subject: [dtn-interest] SUNSET (open source framework for underwater sensor networks) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:44:44 -0000 --f46d04016ae1570e1c04c00020f6 Content-Type: text/plain; charset=ISO-8859-1 Dear colleagues, We are releasing SUNSET (La Sapienza University Networking framework for underwater Simulation Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test at sea novel communication protocols for underwater communications. We have extensively used it for in field tests for two years, and we are now releasing it to the research community believing it can speed up significantly research in the field of underwater sensor networks. It allows to seamlessy use the same code for simulating, emulating and experimenting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here Underwater wireless sensor network group: http://reti.dsi.uniroma1.it/UWSN_Group/ SENSES laboratory: http://reti.dsi.uniroma1.it/SENSES_lab/ Best Regards Prof. Chiara Petrioli Director, SENSES lab Computer Science Department University of Rome La Sapienza E-mail: petrioli@di.uniroma1.it --f46d04016ae1570e1c04c00020f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear colleagues,

=C2=A0

We are releasing SUNSET=C2=A0 (La Sapienza University Networking framework for underwater Simulati= on Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test=C2=A0 at sea novel communication protocols for underwater communications.

=C2=A0

We have extensively used it for in field tests for t= wo years, and we are now releasing it to the research community believing it c= an speed up significantly=C2=A0 research in the field of underwater sensor networks.=C2=A0=C2=A0 It allows to seamlessy use the same code for simulating, emulating and experim= enting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here

=C2=A0

Underwater wireless sensor network group:

= http://reti.dsi.uniroma1.it/UWSN_Group/

=C2=A0

SENSES laboratory:

= http://reti.dsi.uniroma1.it/SENSES_lab/

=C2=A0

Best Regards

Prof. Chiara Petrioli

Director, SENSES lab

Computer Science Department

University of Rome La Sapienza

E-mail: p= etrioli@di.uniroma1.it

--f46d04016ae1570e1c04c00020f6-- From kscott@mitre.org Tue May 15 07:54:04 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109721F87E3 for ; Tue, 15 May 2012 07:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYslIS0KHNcN for ; Tue, 15 May 2012 07:54:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0E21F21F87E2 for ; Tue, 15 May 2012 07:54:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8B5B321B1D7B; Tue, 15 May 2012 10:53:56 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7F62921B1D7A; Tue, 15 May 2012 10:53:56 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Tue, 15 May 2012 10:53:56 -0400 From: "Scott, Keith L." To: Chiara Petrioli , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] SUNSET (open source framework for underwater sensor networks) Thread-Index: AQHNMcUl0+a5WskC9UaDQHuf+HLjs5bK8IFw Date: Tue, 15 May 2012 14:53:55 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE208DC1@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-interest] SUNSET (open source framework for underwater sensor networks) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:54:04 -0000 There was a paper recently out of Brazil about using DTN to do deepwater mo= nitoring (http://www.gta.ufrj.br/ftp/gta/TechReports/RPC11.pdf). Would there be interest in integrating a DTN implementation with the ns-2 s= imulator and emulation framework/testbed? DTN (specifically the DTN2 imple= mentation of the Bundle Protocol) has been ported to Gumstix, and I assume = that the Interplanetary Overlay Network (ION) implementation could be as we= ll. --keith -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Chiara Petrioli Sent: Monday, May 14, 2012 7:29 AM To: dtn-interest@irtf.org Subject: [dtn-interest] SUNSET (open source framework for underwater sensor= networks) Dear colleagues, We are releasing SUNSET (La Sapienza University Networking framework for underwater Simulation Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test at sea novel communication protocols for underwater communications. We have extensively used it for in field tests for two years, and we are now releasing it to the research community believing it can speed up significantly research in the field of underwater sensor networks. It allows to seamlessy use the same code for simulating, emulating and experimenting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here Underwater wireless sensor network group: http://reti.dsi.uniroma1.it/UWSN_Group/ SENSES laboratory: http://reti.dsi.uniroma1.it/SENSES_lab/ Best Regards Prof. Chiara Petrioli Director, SENSES lab Computer Science Department University of Rome La Sapienza E-mail: petrioli@di.uniroma1.it _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From dugdale@gmail.com Tue May 15 08:01:12 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751021F8930 for ; Tue, 15 May 2012 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFZjKEyR0ZAD for ; Tue, 15 May 2012 08:01:09 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9321F8934 for ; Tue, 15 May 2012 08:01:09 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so6180282wgb.19 for ; Tue, 15 May 2012 08:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=IZQdQCkjWuhjlH+fBikFSENWx7NWkozbDnajzO/fhfQ=; b=vdk7QyZobT9ccb68qnCdMbDQHA8P12zkB//r0KE1sE+5fQzo256t+962hh8GEUCz5f m9ks6YDDbyqJ8nM1xDhwgCB2yxH+kD6ADAbaudE32ZCYKkESqf5LgB5QhQvTlgGLXvNy rPtPTydPR8IWyooJXSa4cfE4gmN+XDdMMCfS6NhUc4BvF2QEkgqE+LCIWIRNSlLi/cc6 UvF6nyjtKARBLGziKEmphQ06BMYC8dGieSPr4ITBzQYjUSxseKW4DfpK9OkEslamzWMO b4l8eGADx7qvGdFLdX534yoYYM1NPsRLa2f+VL1dVYgWKMUqECZ/JZbSHjUlvPSEXD6z d7ng== Received: by 10.50.85.196 with SMTP id j4mr7228539igz.30.1337094065528; Tue, 15 May 2012 08:01:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.50.139 with HTTP; Tue, 15 May 2012 08:00:45 -0700 (PDT) In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE208DC1@IMCMBX01.MITRE.ORG> References: <5EE81C5C4CFFF4418C5EAD12F49D64EE208DC1@IMCMBX01.MITRE.ORG> From: Anders Lindgren Date: Tue, 15 May 2012 17:00:45 +0200 Message-ID: To: "Scott, Keith L." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] SUNSET (open source framework for underwater sensor networks) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:01:12 -0000 This (integrating DTN2 with ns simulation/emulation) has already been done, but with ns-3 instead of ns-2 as the underlying simulator. It was done within the N4C project. Paper: http://www.springerlink.com/content/2677573v6u3l8151/?MUD=3DMP Youtube video explaining the system: http://www.youtube.com/watch?v=3Dbqq1jNVgRgc /A On Tue, May 15, 2012 at 4:53 PM, Scott, Keith L. wrote: > There was a paper recently out of Brazil about using DTN to do deepwater = monitoring (http://www.gta.ufrj.br/ftp/gta/TechReports/RPC11.pdf). > > Would there be interest in integrating a DTN implementation with the ns-2= simulator and emulation framework/testbed? =A0DTN (specifically the DTN2 i= mplementation of the Bundle Protocol) has been ported to Gumstix, and I ass= ume that the Interplanetary Overlay Network (ION) implementation could be a= s well. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--keith > > -----Original Message----- > From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org= ] On Behalf Of Chiara Petrioli > Sent: Monday, May 14, 2012 7:29 AM > To: dtn-interest@irtf.org > Subject: [dtn-interest] SUNSET (open source framework for underwater sens= or networks) > > Dear colleagues, > > We are releasing SUNSET =A0(La Sapienza University Networking framework > for underwater Simulation Emulation and real-life Testing). SUNSET is > a new open source solution, developed by the UWSN SENSES Lab Group, to > seamlessly simulate (using ns2), emulate and test =A0at sea novel > communication protocols for underwater communications. > > We have extensively used it for in field tests for two years, and we > are now releasing it to the research community believing it can speed > up significantly =A0research in the field of underwater sensor networks. > =A0It allows to seamlessy use the same code for simulating, emulating > and experimenting at sea solutions for UWSNs. You can find information > on SUNSET and on our activities here > > Underwater wireless sensor network group: > http://reti.dsi.uniroma1.it/UWSN_Group/ > > SENSES laboratory: > http://reti.dsi.uniroma1.it/SENSES_lab/ > > Best Regards > Prof. Chiara Petrioli > Director, SENSES lab > Computer Science Department > University of Rome La Sapienza > E-mail: petrioli@di.uniroma1.it > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest From thomas.r.henderson@boeing.com Tue May 15 11:22:37 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F3D21F85F6 for ; Tue, 15 May 2012 11:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfVc+c6BG0+U for ; Tue, 15 May 2012 11:22:35 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id EB07521F85E3 for ; Tue, 15 May 2012 11:22:34 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q4FIMR1K000923 for ; Tue, 15 May 2012 11:22:28 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q4FIMRTD000918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 May 2012 11:22:27 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q4FIMW59007257; Tue, 15 May 2012 11:22:32 -0700 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q4FIMWrW007244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 15 May 2012 11:22:32 -0700 Received: from XCH-NW-16V.nw.nos.boeing.com ([130.247.25.240]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Tue, 15 May 2012 11:22:31 -0700 From: "Henderson, Thomas R" To: "'Scott, Keith L.'" , Chiara Petrioli , "dtn-interest@irtf.org" Date: Tue, 15 May 2012 11:22:31 -0700 Thread-Topic: [dtn-interest] SUNSET (open source framework for underwater sensor networks) Thread-Index: AQHNMcUl0+a5WskC9UaDQHuf+HLjs5bK8IFwgAA2mJA= Message-ID: <758141CC3D829043A8C3164DD3D593EA1BD24C87BA@XCH-NW-16V.nw.nos.boeing.com> References: <5EE81C5C4CFFF4418C5EAD12F49D64EE208DC1@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE208DC1@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [dtn-interest] SUNSET (open source framework for underwater sensor networks) X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:22:37 -0000 > -----Original Message----- > From: dtn-interest-bounces@irtf.org [mailto:dtn-interest- > bounces@irtf.org] On Behalf Of Scott, Keith L. > Sent: Tuesday, May 15, 2012 7:54 AM > To: Chiara Petrioli; dtn-interest@irtf.org > Subject: Re: [dtn-interest] SUNSET (open source framework for > underwater sensor networks) >=20 > There was a paper recently out of Brazil about using DTN to do > deepwater monitoring > (http://www.gta.ufrj.br/ftp/gta/TechReports/RPC11.pdf). >=20 > Would there be interest in integrating a DTN implementation with the > ns-2 simulator and emulation framework/testbed? DTN (specifically the > DTN2 implementation of the Bundle Protocol) has been ported to Gumstix, > and I assume that the Interplanetary Overlay Network (ION) > implementation could be as well. >=20 > --keith Keith, if the goal is to integrate implementation code, I'd recommend to us= e ns-3 rather than ns-2 for new simulation efforts, due to its improved cap= abilities in that regard. In another message in this thread, Anders Lindgr= en pointed to one example of how ns-3 can be integrated with LXC containers= . ns-3 is also being integrated with the CORE network emulator. There are= some other efforts in development (INRIA's direct code execution environme= nt, allowing implementation code to execute in a simulation context) that m= ay apply as well. With respect to underwater networking in particular, there have been a few = previous contributions to ns-3 of underwater acoustic network models and un= derwater mobility models, and I'm aware of at least one other project getti= ng started in this area. Although I haven't had a chance to look at SUNSET= , I'd be curious to see whether those models could be made available in ns-= 3 as well. - Tom From L.Wood@surrey.ac.uk Tue May 15 12:42:55 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DCA11E8099 for ; Tue, 15 May 2012 12:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwNHY8gddqdW for ; Tue, 15 May 2012 12:42:54 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3442D21F8621 for ; Tue, 15 May 2012 12:42:49 -0700 (PDT) Received: from [195.245.231.67:41627] by server-7.bemta-5.messagelabs.com id 6A/D9-16195-8B1B2BF4; Tue, 15 May 2012 19:42:48 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-82.messagelabs.com!1337111066!29306890!1 X-Originating-IP: [131.227.200.39] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13246 invoked from network); 15 May 2012 19:44:26 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-14.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 15 May 2012 19:44:26 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.156]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 15 May 2012 20:42:47 +0100 From: To: , Date: Tue, 15 May 2012 20:42:46 +0100 Thread-Topic: [dtn-interest] DTNRG meeting in San Jose Thread-Index: Ac0xQUTx54s8nD0dQLS1wLvjYzYhOgBjTfcL Message-ID: References: <4FB00FDF.2090305@netlab.tkk.fi> In-Reply-To: <4FB00FDF.2090305@netlab.tkk.fi> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-interest] DTNRG meeting in San Jose X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:42:55 -0000 If work is to be done on revising RFC5050, addressing these weak points wou= ld be a good idea: 1. RFC5050's dependence on clocks; a delay-tolerant protocol that requires = synchronised system clocks, and can't tolerate delays between them, has lim= ited application and awkward failure modes. One description of the problem = is in http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time-00 2. RFC5050's inability to detect errors in transmission or delivery, even i= n its own payload headers - a disadvantage in the disrupted, unreliable, ne= tworks that RFC5050 is intended for. A description of the problem and propo= sal to address this is in: http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-09 (I see from a garbled note in the minutes of the last IRTF meeting that thi= s was discussed there? http://www.ietf.org/proceedings/83/minutes/minutes-83-dtnrg.txt No idea what was said) There are probably other points on RFC5050 discussed in 'A Bundle of Proble= ms' that will be useful to consider: http://sat-net.com/L.Wood/publications/index.html#bundle-problems http://dx.doi.org/10.1109/AERO.2009.4839384 Lloyd Wood http://sat-net.com/L.Wood/dtn ________________________________________ From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] On Beha= lf Of Joerg Ott [jo@netlab.tkk.fi] Sent: 13 May 2012 20:47 To: dtn-interest@irtf.org Subject: [dtn-interest] DTNRG meeting in San Jose Hi, having talked to various people, we feel that there is potential for having another longer DTNRG meeting to make active progress on the specifications. Google has kindly offered to host a meeting on 26/27 July 2012 in San Jose, CA. Time and date are chosen so that the IETF meeting is not too far away. The meeting will run for two full days. One major discussion item will be revising RFC 5050 and related specifications. We have gained lots of experience and have found that some things work better than others. It appears a good point in time to start thinking on how to fold this experience into our specs. We will provide more detailed information about the venue soonish. Please send us private email if you want to attend so that we can get a rough estimate of the group size. Stephen, Kevin, and J=F6rg _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From stephen.farrell@cs.tcd.ie Tue May 15 12:47:10 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0068911E809C for ; Tue, 15 May 2012 12:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsAvt1SZ6G9d for ; Tue, 15 May 2012 12:47:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1949A11E808F for ; Tue, 15 May 2012 12:46:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DD354171476; Tue, 15 May 2012 20:46:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337111218; bh=2bOqKcV5U9F26u K0kSNyp+Yg14SrWx0dtQhtYlHN9S0=; b=OnqN8iBWd9o+TOVQMVL2lAamLsD+GC b8WL4CpVu1teXpDFhoyI3qBZil5sEgRlCXFk/SR3cBwe6xUM/FTE3ESvABuW8uWc gqBckCu1HiPh3EXQS/zVRTZMEOtGKct2Ru9E9UCs1AtYthJYL6shPaOEWSFDVw/j y6Yn47tiiRmbpFYniu+H/oczYQ+EWHturgrMzjaBoqeplBgYoGdN41g59WUp3Ju9 9sBIA1VJVuZog/DbOZd63oeJXrzZIPoPR0c5icx7Rw8mRO4EWVGotFIQcBu/jBl6 4HadSq5oU8uEWQ1psfEx4A4IjvMgAbgWpCO9DkfmG3qTHxK3+K5BJ5OA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JtvHlb+RN9gV; Tue, 15 May 2012 20:46:58 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.12.219]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A8DC8171475; Tue, 15 May 2012 20:46:56 +0100 (IST) Message-ID: <4FB2B2B0.7070801@cs.tcd.ie> Date: Tue, 15 May 2012 20:46:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4FB00FDF.2090305@netlab.tkk.fi> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] DTNRG meeting in San Jose X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 19:47:10 -0000 Thanks Lloyd, I'm going to start a new thread because we (chairs) agreed we would try to put a bit of structure on this discussion. (You can respond to that if you like but no need if you'd rather not, we'll make sure these suggestions are taken into account.) Cheers, S. On 05/15/2012 08:42 PM, L.Wood@surrey.ac.uk wrote: > If work is to be done on revising RFC5050, addressing these weak points would be a good idea: > > 1. RFC5050's dependence on clocks; a delay-tolerant protocol that requires synchronised system clocks, and can't tolerate delays between them, has limited application and awkward failure modes. One description of the problem is in > http://tools.ietf.org/html/draft-farrell-dtnrg-alt-time-00 > > 2. RFC5050's inability to detect errors in transmission or delivery, even in its own payload headers - a disadvantage in the disrupted, unreliable, networks that RFC5050 is intended for. A description of the problem and proposal to address this is in: > http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-09 > (I see from a garbled note in the minutes of the last IRTF meeting that this was discussed there? > http://www.ietf.org/proceedings/83/minutes/minutes-83-dtnrg.txt > No idea what was said) > > There are probably other points on RFC5050 discussed in 'A Bundle of Problems' that will be useful to consider: > http://sat-net.com/L.Wood/publications/index.html#bundle-problems > http://dx.doi.org/10.1109/AERO.2009.4839384 > > > Lloyd Wood > http://sat-net.com/L.Wood/dtn > > > > ________________________________________ > From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] On Behalf Of Joerg Ott [jo@netlab.tkk.fi] > Sent: 13 May 2012 20:47 > To: dtn-interest@irtf.org > Subject: [dtn-interest] DTNRG meeting in San Jose > > Hi, > > having talked to various people, we feel that there is potential > for having another longer DTNRG meeting to make active progress on > the specifications. > > Google has kindly offered to host a meeting on 26/27 July 2012 > in San Jose, CA. Time and date are chosen so that the IETF meeting > is not too far away. The meeting will run for two full days. > > One major discussion item will be revising RFC 5050 and related > specifications. We have gained lots of experience and have found > that some things work better than others. It appears a good point > in time to start thinking on how to fold this experience into our > specs. > > We will provide more detailed information about the venue soonish. > > Please send us private email if you want to attend so that we can > get a rough estimate of the group size. > > Stephen, Kevin, and Jörg > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > From stephen.farrell@cs.tcd.ie Tue May 15 13:01:25 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F192821F87F8 for ; Tue, 15 May 2012 13:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzs04-zJZRVP for ; Tue, 15 May 2012 13:01:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 37BD821F87EA for ; Tue, 15 May 2012 13:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A363E171476 for ; Tue, 15 May 2012 21:01:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1337112084; bh=RwcAMNvbg3tAgGCYp6Vp/KQn N0MwJCY+sRGn7RyLxEo=; b=TH1/oFK+oMUZWFZ6H90hpErUM2vbuSikX8FxrXPW N67ifZ/hoD3TWv8tDWEAfnT6kpRY5fBvX7M3FELPtCIsP3sotIKYtr8kgOlZ7Wws D3/tFnOvRQc91hsIcWcE6FVNRJZLDMgsTshNuCAisY6TdX6LOXWd7pi9eI471Mkp igt/JOqbZPlkx6HrVGnlFk5/Pue2ae6BCcqxCw5T2PZQbqoaS4u8nG/WEvUu6Jjd yHsAnjc6I+n2bOSQVVB5GvS8yqjNw/mCLovBHMpovnMxNp0N3MQ9TEIprHKflKLx AxpjcT1fo7yNo39DMIj8kmBdF2iz+NvkzkaJH8P8xBUVqQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id BwgbP+QVBg4Y for ; Tue, 15 May 2012 21:01:24 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.12.219]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 443B2171475 for ; Tue, 15 May 2012 21:01:24 +0100 (IST) Message-ID: <4FB2B614.1090303@cs.tcd.ie> Date: Tue, 15 May 2012 21:01:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: DTN interest X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 20:01:26 -0000 Hi all, As Joerg noted we're interested in whether or not, and if so how, folks would like to do some work on an update or revision for RFC 5050, or ideas for alternatives to the BP or additional DTN protocols. Things we're interested in hearing about, are: - Should we rev 5050? why? why not? - What do you not like about 5050? how'd you fix that? - What is missing from 5050? how'd you add that? - What's great about 5050? why'd you keep that? - What 2119 MUST/SHOULD/MAY would you change and why? - What DTN research questions would you like to tackle where RFC 5050 (or implementations thereof) are a barrier? In addition, we'd be interested in hearing whether folks would like to explore doing DTN based not on a straight revision of the BP, but maybe e.g. based on CoAP, SPDY, websockets, or other protocols. Or, if you've something else to say/suggest, fo ahead and do that too. At this point the goal is to gather and discuss ideas on the list, with a view to seeing what's of interest to RG participants. If we get a bunch of ideas, then we'll try to organise those a bit and start separate threads. For now, if you can respond to this mail, that'll help us track the discussion later. Later on, the question of who's actually willing to do stuff will get more interesting, since that's how things get done - just saying that it "must be so" is frequently trumped by the fact that someone else has the energy to actually do something. Lastly, none of this means that there's anything wrong with RFC 5050 which has been great for both doing DTN experiments and for the CCSDS folks who're building on it for their work. (And in case CCSDS people get process-scared, no, nothing will ever change the existing RFCs, so documents referring to them are unaffected.) Cheers, Stephen, Kevin, Joerg. From alessandro.berni@gmail.com Tue May 15 14:11:45 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAD11E8083 for ; Tue, 15 May 2012 14:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjEM5+yzRvJr for ; Tue, 15 May 2012 14:11:44 -0700 (PDT) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9511E8074 for ; Tue, 15 May 2012 14:11:43 -0700 (PDT) Received: by bkvi18 with SMTP id i18so36474bkv.13 for ; Tue, 15 May 2012 14:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qgYRzvyVsWER/vmcvT+etl93kT9Fw54UDh3a0E5TTDw=; b=cjtEncA1pLDBGR/3kSgiIt8GlPzIHsKUBSo9FsY/l0A+yqTDCQwSmiuujNhkneAhfz 53NApUIovwFGz3NhjtTJu6zhQwx55L9vybyeMtCinc1rRiCUuS/R1PPoqhKpFzQp2172 amMKFVJhM7JKlLoKQEZY5Mtb4I+IkC3/4r1Jny97ofghJEt54sVV0BXJs8Cty41MUd1G YTxFSO4dk2Xbn8Wul3e6WlxX7b6PXMdBkI7Q+HATeZT3LbarQ6xMo29hOWgSVam6DGeA ckXVOv/Mdvb8U2Xi98yS7hWjXf2CFcqKKbomagKZLCPO9kXmARM6pKQJuhCIR4X5SjfV 3iIA== MIME-Version: 1.0 Received: by 10.204.154.142 with SMTP id o14mr140712bkw.116.1337116302835; Tue, 15 May 2012 14:11:42 -0700 (PDT) Received: by 10.205.120.4 with HTTP; Tue, 15 May 2012 14:11:42 -0700 (PDT) Date: Tue, 15 May 2012 23:11:42 +0200 Message-ID: From: Alessandro Berni To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary=0015175cae1840ff0f04c019a644 Subject: [dtn-interest] Maritime/Underwater DTN X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 21:11:45 -0000 --0015175cae1840ff0f04c019a644 Content-Type: text/plain; charset=ISO-8859-1 As a contribution to the recent discussions on the simulation of underwater sensor networks I have updated the "Docs" section of the DTNRG Wiki with couple of recent papers on our "real life" (i.e. non-simulated) application of DTN: - D. Merani, A. Berni, J. Potter and R. Martins, An Underwater Convergence Layer for Disruption Tolerant Networking, IEEE Baltic Congress on Future Internet Communications (BCFIC), pp. 103-108, February 2011 - A. Berni, D. Merani, J. Potter and R. Been, Heterogeneous system framework for underwater networking, IEEE Military Communications Conference (MILCOM) 2011, pp. 2050-2056, September 2011 The Underwater Convergence Layer (UCL) developed by NURC and University of Porto was tested at sea over the past couple of years and we have started sharing it with selected collaborators. At the recent IETF in Paris we also discussed the possibility of documenting the UCL as an Internet Draft: I can confirm that we intend to follow that path. IETF 83 meeting minutes: http://www.ietf.org/proceedings/83/minutes/minutes-83-dtnrg.txt IETF 83 presentation: http://www.ietf.org/proceedings/83/slides/slides-83-dtnrg-3.pdf We also have a definite interest on "lightweight" DTN: we see CBHE as an asset and we are looking towards further optimizations to "squeeze" the most out of the communication capabilities that are available underwater. Regards, Alessandro -- -- Alessandro Berni, --0015175cae1840ff0f04c019a644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a contribution to the recent discussions on the simulation of unde= rwater sensor networks I have updated the "Docs" section of the D= TNRG Wiki with couple of recent papers on our "real life" (i.e. n= on-simulated) application of DTN:
The Underwater Convergence Layer (UCL) developed by NURC and= University of Porto was tested at sea over the past couple of years and we= have started sharing it with selected collaborators.=A0

At the recent IETF in Paris we also discussed the possibility of docum= enting the UCL as an Internet Draft: I can confirm that we intend to follow= that path.

IETF 83 presentation:=A0http://www.ietf.org/proceedings/83/slides/slides-83-dtnrg-3.pdf

We also have a definite interest on "lightweight" = DTN: we see CBHE as an asset and we are looking towards further optimizatio= ns to "squeeze" the most out of the communication capabilities th= at are available underwater.

Regards,
Alessandro

--
-- Alessandro Berni, <alessandro.berni@gmail.com>
--0015175cae1840ff0f04c019a644-- From bill@immerman-inc.com Wed May 16 08:22:59 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD2921F85D7 for ; Wed, 16 May 2012 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFoQVzUdZ8hv for ; Wed, 16 May 2012 08:22:58 -0700 (PDT) Received: from outbound004.roc2.bluetie.com (outbound004.roc2.bluetie.com [208.89.132.144]) by ietfa.amsl.com (Postfix) with ESMTP id DC46821F85D5 for ; Wed, 16 May 2012 08:22:57 -0700 (PDT) Received: from emta001.roc2.bluetie.com ([10.200.2.131]) by outbound004.roc2.bluetie.com with bizsmtp id AfNw1j0062pbusy01fNwxN; Wed, 16 May 2012 11:22:56 -0400 X-CMAE-OUT-Analysis: v=2.0 cv=TuRkdUrh c=1 sm=1 a=ZBPPO9w3+4e/aq0cDrVbUQ==:17 a=0JGos8m9gWsA:10 a=dvGUPGJ3whYA:10 a=kj9zAlcOel0A:10 a=YlDpyLmHAAAA:8 a=0dh6eSspDu9khuaOjN0A:9 a=fzVD5CpGAlRySg27jHUA:7 a=CjuIK1q_8ugA:10 a=WZiKUSCcF5cA:10 a=BBOljZ5xfniJNn6g:21 a=vPEN_qI7et--9_zy:21 a=rANQrBm0nlgJGMq7J4Ei9A==:117 X-CMAE-OUT-Score: 0.00 Received: from [192.168.2.103] (pool-71-163-238-75.washdc.fios.verizon.net [71.163.238.75]) (Authenticated sender: bill@immerman-inc.com) by emta001.roc2.bluetie.com (Postfix) with ESMTP id 6446593016E; Wed, 16 May 2012 11:22:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: William Immerman In-Reply-To: <4FB2B614.1090303@cs.tcd.ie> Date: Wed, 16 May 2012 11:22:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF5ABF7-CC23-41BE-8553-902594357B79@immerman-inc.com> References: <4FB2B614.1090303@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: DTN interest Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:22:59 -0000 I'd like to comment on one aspect of these questions from the point of = view of a newbie to DTN, and one who is more focussed on use of DTN than = on research into the protocol(s). I've visited with a number of people who I believe (should) see DTN as a = solution to their common set of problems, and many believe that their = existing one-off implementations are solutions. One of my observations = to them that seems to be opening doors is the potential that DTN will = permit their devices/subsystems to interoperate with others. I've also = observed without contradiction that these won't be the last systems they = build that face these issues, and that no one would adopt their = stovepipe solution as THE basis for a common solution, but that the DTN = community's work may serve that purpose. Finally, I've had to field a = bunch of questions about the maturity of DTN, and I've had a difficult = enough time explaining to would-be sponsors that a lot of the less = mature aspects are in implementations and ancillary components/protocols = (e.g., routing, naming), but that the DTN community has at least = converged largely on BP as a core protocol with proven capability and = which interoperates over multiple implementations. This explanation = seems to have had a mildly calming effect. I'm concerned that a substantial effort to replace 5050 might undermine = some of these arguments, and that every time a leg is knocked out from = under us we make it more difficult for people with needs to choose to = adopt DTN. This doesn't mean that there wouldn't be good reason to examine changes = to 5050 at this time: if there are things that people have found = obstruct adoption and can be fixed without negative impact on other = uses, that'd be very positive. Likewise, I don't mean to say people = should stop researching core problems, just expressing concerns that if = a proposal is based mainly on how somebody might do it differently if = starting fresh, they might want to consider the chilling effect that = optimization might have on getting users on board now. There's a lot of = potential utility to DTN, but it still addresses a population that is, = for some observers, a niche, albeit an important and sizable niche. If = we fragment that niche too much, we may end up with no critical mass of = support. Thanks, Bill Immerman =20 On May 15, 2012, at 4:01 PM, Stephen Farrell wrote: >=20 > Hi all, >=20 > As Joerg noted we're interested in whether or not, > and if so how, folks would like to do some work on an > update or revision for RFC 5050, or ideas for > alternatives to the BP or additional DTN protocols. >=20 > Things we're interested in hearing about, are: >=20 > - Should we rev 5050? why? why not? > - What do you not like about 5050? how'd you fix that? > - What is missing from 5050? how'd you add that? > - What's great about 5050? why'd you keep that? > - What 2119 MUST/SHOULD/MAY would you change and why? > - What DTN research questions would you like to tackle > where RFC 5050 (or implementations thereof) are > a barrier? >=20 > In addition, we'd be interested in hearing whether > folks would like to explore doing DTN based not on > a straight revision of the BP, but maybe e.g. based > on CoAP, SPDY, websockets, or other protocols. >=20 > Or, if you've something else to say/suggest, fo > ahead and do that too. >=20 > At this point the goal is to gather and discuss > ideas on the list, with a view to seeing what's of > interest to RG participants. >=20 > If we get a bunch of ideas, then we'll try to > organise those a bit and start separate threads. > For now, if you can respond to this mail, that'll > help us track the discussion later. >=20 > Later on, the question of who's actually willing to > do stuff will get more interesting, since that's how > things get done - just saying that it "must be so" > is frequently trumped by the fact that someone else > has the energy to actually do something. >=20 > Lastly, none of this means that there's anything > wrong with RFC 5050 which has been great for both > doing DTN experiments and for the CCSDS folks who're > building on it for their work. (And in case CCSDS > people get process-scared, no, nothing will ever > change the existing RFCs, so documents referring > to them are unaffected.) >=20 > Cheers, > Stephen, Kevin, Joerg. >=20 > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest >=20 From valerio.arnaboldi@iit.cnr.it Thu May 17 00:07:36 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AA521F85AC for ; Thu, 17 May 2012 00:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.52 X-Spam-Level: * X-Spam-Status: No, score=1.52 tagged_above=-999 required=5 tests=[AWL=2.239, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgDxu0Dkh4Yj for ; Thu, 17 May 2012 00:07:34 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4056321F858E for ; Thu, 17 May 2012 00:07:33 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id C7D563D8238; Thu, 17 May 2012 09:07:01 +0200 (CEST) Date: Thu, 17 May 2012 09:07:01 +0200 From: Valerio Arnaboldi To: dtn-interest@irtf.org Message-ID: <4fb4a395.TgS623z9WfeQEHZF%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dtn-interest] SustainIT 2012 - Call for short papers and demos X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 07:07:36 -0000 [Apologies for possible multiple copies] ------------------------------------------------------------------------ Call for WORK-IN-PROGRESS papers and DEMOS SustainIT 2012 Second IFIP Conference on Sustainable Internet and ICT for Sustainability http://cnd.iit.cnr.it/sustainit2012/ October 4-5, 2012 Pisa, Tuscany, Italy ******* WIP/DEMO PAPER SUBMISSION DEADLINE: June 11, 2012 ******* Conference proceedings in IEEE Xplore ------------------------------------------------------------------------ SustainIT 2012 invites Work in Progress (WIP) papers and technical demonstrations (DEMOs) showing innovative and original research in the areas of Sustainable Internet and ICT for Sustainability. Submissions from both industry and academia are strongly encouraged. WIP papers are expected to report on early or ongoing research activities, while DEMO papers are expected to present innovative applications and tools. The WIP and DEMO sessions will provide a forum to discuss novel ideas and emerging results, presenting innovative applications and tools, and bring about novel research questions, approaches, and directions. TOPICS: Topics of interest include, but are not limited to: - Green Internet - Power-aware Internet applications - Energy-efficient network architecture and protocols - Green wireless networking - Energy-efficient network technologies - Cross-layer optimization for green networking - Standards and metrics for green communications - Energy-efficient management of network resources - Energy efficiency in data centers - Energy efficiency, Quality of Service, and reliability - Algorithms for reduced power, energy and heat - ICT for energy efficiency in buildings - ICT for sustainable smart cities - ICT for sustainable transports and logistics - ICT for green mobility - ICT for energy efficiency in industrial environments - ICT for smart grids - Sustainability achievements due to ICT-based optimization - Energy consumption measurements, models, and monitoring tools - Measurement and evaluation of the Internet sustainability - Test-bed and prototype implementations SUBMISSION GUIDELINES: Authors are requested to submit original, unpublished manuscripts in standard IEEE proceedings format in PDF. The IEEE LaTeX and Microsoft Word templates, as well as related information, can be found at the IEEE Computer Society website (http://www.computer.org/portal/web/cscps/formatting). Submitted papers must include the contact information of all the authors. Manuscripts must be submitted electronically through EDAS. When submitting, please select the appropriate Track for your paper (i.e., WIP or Demo). WIP papers must be, at most, 5 pages in size (including figures, tables, and references). They are expected to present early or ongoing research activities. Novel approaches and preliminary results are especially appreciated. Demo papers must be up to 4 pages in size (including figures, tables, and references). They should explicitly state what will be demonstrated to the audience, and how the attendees will be able to interact, enjoy, and experiment. The submitted manuscripts will be reviewed by members of the SustainIT 2012 Technical Program Committee. All the accepted papers will be presented during the conference. At least one author of each accepted paper must register and attend the conference to present it. The accepted papers will be published in the conference proceedings by IEEE, and will be included in the Digital Library. IMPORTANT DATES: Paper submissions: June 11, 2012 Notification of acceptance: July 15, 2012 Camera-ready copy due: July 30, 2012 Conference date: October 4-5, 2012 ============================================== Valerio Arnaboldi - SUSTAINIT2012 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: +39 050 315 2195 email: valerio.arnaboldi@iit.cnr.it From valerio.arnaboldi@iit.cnr.it Fri May 18 03:12:33 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9921F852A for ; Fri, 18 May 2012 03:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.831 X-Spam-Level: X-Spam-Status: No, score=0.831 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HivmR81NcYF for ; Fri, 18 May 2012 03:12:32 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id B298E21F8526 for ; Fri, 18 May 2012 03:12:32 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id 964BC3D8238; Fri, 18 May 2012 12:12:01 +0200 (CEST) Date: Fri, 18 May 2012 12:12:01 +0200 From: Valerio Arnaboldi To: dtn-interest@irtf.org Message-ID: <4fb62071.pdAHWiKRHza5+2aQ%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dtn-interest] SustainIT 2012 - Ph.D. Forum: Call for extended abstracts X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 10:12:33 -0000 ------------------------------------------------------------------------ PhD FORUM: CALL FOR EXTENDED ABSTRACTS SustainIT 2012 Second IFIP Conference on Sustainable Internet and ICT for Sustainability http://cnd.iit.cnr.it/sustainit2012/ October 4-5, 2012 Pisa, Tuscany, Italy ******* PhD FORUM SUBMISSION DEADLINE: June 11, 2012 ******* ------------------------------------------------------------------------ SustainIT 2012 hosts the PhD Forum on Sustainable Internet and ICT for Sustainability. The Forum will provide an opportunity for PhD students to present their dissertation research, including work in progress. In addition, it will be a platform for PhD students to interact both with their peers as well as with experienced researchers from industry and academia. The Forum will be organized as a poster session and will include a '1-minute madness' introduction by each student. Current PhD students and researchers who completed their PhD dissertations after December 2011 are encouraged to submit extended abstracts. The PhD student and his/her advisor(s) can be the only authors. Submissions will be reviewed to ensure quality and relevance. Authors of accepted submissions are expected to attend SustainIT 2012 and present their poster at the PhD Forum. Accepted extended abstracts will appear in conference proceedings. SUBMISSION GUIDELINES: PhD students are invited to submit an extended abstract describing current research and potential contributions to theory and innovation in the areas of Sustainable Internet and ICT for Sustainability. Extended abstracts should include the authors' names, affiliation, and email address. Submissions must be PDF files, written in English. Submissions should adhere to the IEEE format and be no more than 3 pages in size (all inclusive). Abstracts must be submitted by e-mail to the following address: sustainit2012-PHD@gerad.ca. Please send the PDF file as attachment of an e-mail having as subject: "PhD-Submission-AUTHORS(last names only, separated by a '-')". IMPORTANT DATES: Manuscript submissions: June 11, 2012 Notification of acceptance: July 9, 2012 Camera-ready copy due: July 30, 2012 Conference date: October 4-5, 2012 PhD Forum Co-Chairs Franco Davoli, University of Genova, Italy Brunilde Sanso, Ecole Polytechnique de Montreal, Canada From scott.c.burleigh@jpl.nasa.gov Fri May 18 09:50:46 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0324C21F85FF for ; Fri, 18 May 2012 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcdGaZToR-81 for ; Fri, 18 May 2012 09:50:41 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9021F8603 for ; Fri, 18 May 2012 09:50:40 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4IGoWE4003702 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 18 May 2012 09:50:33 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.245]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.250]) with mapi id 14.02.0298.004; Fri, 18 May 2012 09:50:32 -0700 From: "Burleigh, Scott C (313B)" To: Stephen Farrell , DTN interest Thread-Topic: [dtn-interest] RFC 5050 revision? Thread-Index: AQHNMtWYge0gb7FuIEm7A/oTQqDLqpbPrA3A Date: Fri, 18 May 2012 16:50:31 +0000 Message-ID: References: <4FB2B614.1090303@cs.tcd.ie> In-Reply-To: <4FB2B614.1090303@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 16:50:46 -0000 I think we got a lot of things right in RFC 5050: I think it's just about o= pen-ended enough -- I'm a big fan of the extension block mechanism -- and I= think the notions of node, endpoint, forwarding, delivery, custody, etc. a= re generally pretty solid. But I do think we got one major thing wrong: although we recognize the sign= ificance of nodes, we nowhere establish any concept of node ID. All we've = got are endpoint IDs. And we need that concept. As important as endpoints are, we define a large= (and growing) number of critical DTN functions in terms of nodes, not endp= oints: - Custody transfer is accomplished between nodes, not endpoints. - In practice, we route on the basis of nodes, not endpoints. (Delivery = predictability in PROPHET, for example, is associated with nodes. Everythi= ng in Contact Graph Routing is implemented in terms of nodes.) - All of the Bundle Security Protocol mechanisms actually operate on the = basis of nodes, not endpoints. (For example, section 1.2 of RFC 6257 defin= es "security source" and "security destination" as nodes.) Since nodes have got to be identified in order to accomplish these function= s, and we can't live without these functions, we identify nodes now. We us= e endpoint identifiers to identify them. But endpoint identifiers don't identify nodes. They identify endpoints. By convention we mutually agree that a node can always be identified by the= ID of one of the singleton endpoints in which it is registered (and there = always has to be at least one, per section 3.1 of RFC 5050). This works, s= o long as our nodes all know which singleton endpoints other nodes are regi= stered in, and those registrations never change without notification to all= other nodes who care about them. But there's nothing in any specification anywhere that requires this persis= tent registration. A node could register in a new singleton endpoint (and = unregister in all old ones) once every second, making its use as a "router"= node impossible, and yet remain fully conformant with RFC 5050. Since the= re is no requirement for persistent endpoint registration in any DTN specif= ication, and therefore no assurance of persistent node identity, the founda= tion on which many critical DTN functions rests is really just good will an= d out-of-band consensus on the part of node administrators. I will freely admit to a bias on this topic: I think the CBHE (and "ipn" sc= heme) notion of explicitly identifying nodes and services (i.e., demuxes) b= y numbers, expressing most endpoint IDs in terms of node and service number= s, and directly encoding those numeric EIDs as SDNVs in the primary block -= - rather than carrying arbitrarily long ASCII strings in a dictionary array= -- has been shown to work well, and I'd like to see that representation ma= de standard in the Bundle Protocol rather than supported only as a converge= nce-layer adaptation. I'm fully on board with retaining the expressive pow= er of URIs for complex and interesting new destination EIDs (intentional na= ming, etc.), but the vast bulk of BP traffic now and in the foreseeable fut= ure doesn't need any of that power. I believe we can, and should, optimize= for the uninteresting, prevailing case of sending bundles directly to expl= icitly identified service points at explicitly identified nodes, and define= one or more destination EID override extension blocks for the scenarios th= at need more complex endpoint IDs. But whether or not we make that adjustment, at the very least I believe we = have got to acknowledge nodes as first-class entities in the DTN architectu= re and decide how we're going to reference them in our protocols. Scott -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Stephen Farrell Sent: Tuesday, May 15, 2012 1:01 PM To: DTN interest Subject: [dtn-interest] RFC 5050 revision? Hi all, As Joerg noted we're interested in whether or not, and if so how, folks wou= ld like to do some work on an update or revision for RFC 5050, or ideas for= alternatives to the BP or additional DTN protocols. Things we're interested in hearing about, are: - Should we rev 5050? why? why not? - What do you not like about 5050? how'd you fix that? - What is missing from 5050? how'd you add that? - What's great about 5050? why'd you keep that? - What 2119 MUST/SHOULD/MAY would you change and why? - What DTN research questions would you like to tackle where RFC 5050 (or implementations thereof) are a barrier? In addition, we'd be interested in hearing whether folks would like to expl= ore doing DTN based not on a straight revision of the BP, but maybe e.g. ba= sed on CoAP, SPDY, websockets, or other protocols. Or, if you've something else to say/suggest, fo ahead and do that too. At this point the goal is to gather and discuss ideas on the list, with a v= iew to seeing what's of interest to RG participants. If we get a bunch of ideas, then we'll try to organise those a bit and star= t separate threads. For now, if you can respond to this mail, that'll help us track the discuss= ion later. Later on, the question of who's actually willing to do stuff will get more = interesting, since that's how things get done - just saying that it "must b= e so" is frequently trumped by the fact that someone else has the energy to actua= lly do something. Lastly, none of this means that there's anything wrong with RFC 5050 which = has been great for both doing DTN experiments and for the CCSDS folks who'r= e building on it for their work. (And in case CCSDS people get process-scar= ed, no, nothing will ever change the existing RFCs, so documents referring = to them are unaffected.) Cheers, Stephen, Kevin, Joerg. _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From stephen.farrell@cs.tcd.ie Fri May 18 09:56:16 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949FF21F864A for ; Fri, 18 May 2012 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKfTwqRXAjg2 for ; Fri, 18 May 2012 09:56:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9C921F8633 for ; Fri, 18 May 2012 09:56:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1AC33171501; Fri, 18 May 2012 17:56:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337360170; bh=suxHQJUx6BMcBV e2ddRzumLjgKSuaU+/4tPihhHGH9w=; b=6kMIhP+ykapn5+qVrpe23ct9+tL74L h+kM19Mr8I6UXarsEhCA98KvO69atD8PAeqwZH2lEf6N297uZl57lO5HFCWjWJnD rKyR7/OWJ3OtYggxxr1VDTi/EkY7Ear6ZJYEeLiYgMDv8lGQ7Yr/gkgclsn/sI9p yK47rl6bB4B02l8ZUqlOQrnEuYouC2wtzHUZWYLXZTDgdVFP8wL0AFeVIlR3zUpj HQoCKm3xpOYd+xYilkFXsZWFAyJmCoK32OiYpW5UzyAtI0/YS3tfdTb8HC6YKtzf Mbz9MZKq8Wl7cONCiGxop8sjJZE+41J3j0vN6BLcVGyFzWJG/e7NcfmQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s5SCKVBoJK55; Fri, 18 May 2012 17:56:10 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.26.127]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 49FB11714FE; Fri, 18 May 2012 17:56:10 +0100 (IST) Message-ID: <4FB67F2A.1040307@cs.tcd.ie> Date: Fri, 18 May 2012 17:56:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Burleigh, Scott C (313B)" References: <4FB2B614.1090303@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DTN interest Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 16:56:16 -0000 Hi Scott, Interesting that this is sort of the opposite of the ideas that we're working on in the newly-formed ICNRG, where we want to name data and not nodes! But I think I agree with you here - all of the DTN trials that I can think of involved naming the nodes. S On 05/18/2012 05:50 PM, Burleigh, Scott C (313B) wrote: > I think we got a lot of things right in RFC 5050: I think it's just about open-ended enough -- I'm a big fan of the extension block mechanism -- and I think the notions of node, endpoint, forwarding, delivery, custody, etc. are generally pretty solid. > > But I do think we got one major thing wrong: although we recognize the significance of nodes, we nowhere establish any concept of node ID. All we've got are endpoint IDs. > > And we need that concept. As important as endpoints are, we define a large (and growing) number of critical DTN functions in terms of nodes, not endpoints: > - Custody transfer is accomplished between nodes, not endpoints. > - In practice, we route on the basis of nodes, not endpoints. (Delivery predictability in PROPHET, for example, is associated with nodes. Everything in Contact Graph Routing is implemented in terms of nodes.) > - All of the Bundle Security Protocol mechanisms actually operate on the basis of nodes, not endpoints. (For example, section 1.2 of RFC 6257 defines "security source" and "security destination" as nodes.) > > Since nodes have got to be identified in order to accomplish these functions, and we can't live without these functions, we identify nodes now. We use endpoint identifiers to identify them. > > But endpoint identifiers don't identify nodes. They identify endpoints. > > By convention we mutually agree that a node can always be identified by the ID of one of the singleton endpoints in which it is registered (and there always has to be at least one, per section 3.1 of RFC 5050). This works, so long as our nodes all know which singleton endpoints other nodes are registered in, and those registrations never change without notification to all other nodes who care about them. > > But there's nothing in any specification anywhere that requires this persistent registration. A node could register in a new singleton endpoint (and unregister in all old ones) once every second, making its use as a "router" node impossible, and yet remain fully conformant with RFC 5050. Since there is no requirement for persistent endpoint registration in any DTN specification, and therefore no assurance of persistent node identity, the foundation on which many critical DTN functions rests is really just good will and out-of-band consensus on the part of node administrators. > > I will freely admit to a bias on this topic: I think the CBHE (and "ipn" scheme) notion of explicitly identifying nodes and services (i.e., demuxes) by numbers, expressing most endpoint IDs in terms of node and service numbers, and directly encoding those numeric EIDs as SDNVs in the primary block -- rather than carrying arbitrarily long ASCII strings in a dictionary array -- has been shown to work well, and I'd like to see that representation made standard in the Bundle Protocol rather than supported only as a convergence-layer adaptation. I'm fully on board with retaining the expressive power of URIs for complex and interesting new destination EIDs (intentional naming, etc.), but the vast bulk of BP traffic now and in the foreseeable future doesn't need any of that power. I believe we can, and should, optimize for the uninteresting, prevailing case of sending bundles directly to explicitly identified service points at explicitly identified nodes, and define one or more destinati on EID override extension blocks for the scenarios that need more complex endpoint IDs. > > But whether or not we make that adjustment, at the very least I believe we have got to acknowledge nodes as first-class entities in the DTN architecture and decide how we're going to reference them in our protocols. > > Scott > > -----Original Message----- > From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Stephen Farrell > Sent: Tuesday, May 15, 2012 1:01 PM > To: DTN interest > Subject: [dtn-interest] RFC 5050 revision? > > > Hi all, > > As Joerg noted we're interested in whether or not, and if so how, folks would like to do some work on an update or revision for RFC 5050, or ideas for alternatives to the BP or additional DTN protocols. > > Things we're interested in hearing about, are: > > - Should we rev 5050? why? why not? > - What do you not like about 5050? how'd you fix that? > - What is missing from 5050? how'd you add that? > - What's great about 5050? why'd you keep that? > - What 2119 MUST/SHOULD/MAY would you change and why? > - What DTN research questions would you like to tackle > where RFC 5050 (or implementations thereof) are > a barrier? > > In addition, we'd be interested in hearing whether folks would like to explore doing DTN based not on a straight revision of the BP, but maybe e.g. based on CoAP, SPDY, websockets, or other protocols. > > Or, if you've something else to say/suggest, fo ahead and do that too. > > At this point the goal is to gather and discuss ideas on the list, with a view to seeing what's of interest to RG participants. > > If we get a bunch of ideas, then we'll try to organise those a bit and start separate threads. > For now, if you can respond to this mail, that'll help us track the discussion later. > > Later on, the question of who's actually willing to do stuff will get more interesting, since that's how things get done - just saying that it "must be so" > is frequently trumped by the fact that someone else has the energy to actually do something. > > Lastly, none of this means that there's anything wrong with RFC 5050 which has been great for both doing DTN experiments and for the CCSDS folks who're building on it for their work. (And in case CCSDS people get process-scared, no, nothing will ever change the existing RFCs, so documents referring to them are unaffected.) > > Cheers, > Stephen, Kevin, Joerg. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > From stephen.farrell@cs.tcd.ie Fri May 18 10:05:01 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4736A21F857A for ; Fri, 18 May 2012 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoXQrQXEiFLQ for ; Fri, 18 May 2012 10:05:00 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4721F84D8 for ; Fri, 18 May 2012 10:05:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 93860171508 for ; Fri, 18 May 2012 18:04:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337360698; bh=5yOOsW6cVeXify zIjyJ2jTVNxnE7xDAPAtw8BSHN4AM=; b=TlEcSuGI/MV5M7bBHftu3E7DBCj8Nr eRnezCdk7Giks7t8gEQ2fBGQD547iOTwODP0G/QsD03tTw81LFU4bLmI0UA513X7 z2eE0m9wn4d3t6e+F6vLOTBotYRXJ8XvKjwcgNnpb/juetohX3elelDmbIhoP8jO prKdygdbC6dqcwX7+Q5sRimuZM7MtLvuyybUWL0V3qNQrHFkiKj+ASw9vOOSyxsg N6j8GsvJoH7vIeoVrpNl39gOaiFrTYXtO4C3ZDD5KFWr8fE9KAteEg6Njr7rY5zN CgC8TIhSYC0xRVfdsxWstjWQlv+GGFSnkqAOj031heWRc5XDEeJJ2iyA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Iz+KEOXh72kS; Fri, 18 May 2012 18:04:58 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.26.127]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0904B1714FE; Fri, 18 May 2012 18:04:57 +0100 (IST) Message-ID: <4FB68139.4010005@cs.tcd.ie> Date: Fri, 18 May 2012 18:04:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4FB2B614.1090303@cs.tcd.ie> In-Reply-To: <4FB2B614.1090303@cs.tcd.ie> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DTN interest Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 17:05:01 -0000 So, replying to my own mail, at least in part, and not as chair,.. I'd think I'd like to see a rev of the BP that includes the security stuff from day 1 as a MUST implement, that gets rid of the dictionary in favour of some kind of generic compression (if IPR-free) and that also loses the absolute time requirement. I think that'd be best done as a new BP version that didn't have to be backwards compatible with the 5050, and we'd want to define a way for (some?) CLs to negotiate versions of the BP to make sure that smooth migration was possible. I'd also like to see some bits of current work finished (e.g CL RFCs), and also progression of the BPQ work we've been doing and on key management. I'm sure there's more but those are my main things for now. S On 05/15/2012 09:01 PM, Stephen Farrell wrote: > > Hi all, > > As Joerg noted we're interested in whether or not, > and if so how, folks would like to do some work on an > update or revision for RFC 5050, or ideas for > alternatives to the BP or additional DTN protocols. > > Things we're interested in hearing about, are: > > - Should we rev 5050? why? why not? > - What do you not like about 5050? how'd you fix that? > - What is missing from 5050? how'd you add that? > - What's great about 5050? why'd you keep that? > - What 2119 MUST/SHOULD/MAY would you change and why? > - What DTN research questions would you like to tackle > where RFC 5050 (or implementations thereof) are > a barrier? > > In addition, we'd be interested in hearing whether > folks would like to explore doing DTN based not on > a straight revision of the BP, but maybe e.g. based > on CoAP, SPDY, websockets, or other protocols. > > Or, if you've something else to say/suggest, fo > ahead and do that too. > > At this point the goal is to gather and discuss > ideas on the list, with a view to seeing what's of > interest to RG participants. > > If we get a bunch of ideas, then we'll try to > organise those a bit and start separate threads. > For now, if you can respond to this mail, that'll > help us track the discussion later. > > Later on, the question of who's actually willing to > do stuff will get more interesting, since that's how > things get done - just saying that it "must be so" > is frequently trumped by the fact that someone else > has the energy to actually do something. > > Lastly, none of this means that there's anything > wrong with RFC 5050 which has been great for both > doing DTN experiments and for the CCSDS folks who're > building on it for their work. (And in case CCSDS > people get process-scared, no, nothing will ever > change the existing RFCs, so documents referring > to them are unaffected.) > > Cheers, > Stephen, Kevin, Joerg. > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > From scott.c.burleigh@jpl.nasa.gov Fri May 18 10:14:29 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733C021F8623 for ; Fri, 18 May 2012 10:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSvQCPe7SKHJ for ; Fri, 18 May 2012 10:14:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id CF28821F8615 for ; Fri, 18 May 2012 10:14:28 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q4IHBVdM015176 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 18 May 2012 10:14:17 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.245]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.250]) with mapi id 14.02.0298.004; Fri, 18 May 2012 10:13:22 -0700 From: "Burleigh, Scott C (313B)" To: Stephen Farrell Thread-Topic: [dtn-interest] RFC 5050 revision? Thread-Index: AQHNMtWYge0gb7FuIEm7A/oTQqDLqpbQQGGA//+LF0A= Date: Fri, 18 May 2012 17:13:21 +0000 Message-ID: References: <4FB2B614.1090303@cs.tcd.ie> <4FB68139.4010005@cs.tcd.ie> In-Reply-To: <4FB68139.4010005@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: DTN interest Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 17:14:29 -0000 I agree with at least the first part of your list, Stephen, and probably th= e rest as well except that I haven't been following BPQ closely enough to c= omment. I think the BABs, at least, should be MUST implement (so long as t= hey can be turned off in deployment); I'm all for getting rid of the dictio= nary, and I'd propose CBHE as the generic compression that takes its place;= and I think we've got to support aggregated bundle age as an alternative t= o authoritative bundle creation time for bundle expiration purposes. And I= think this does require a new version of BP. Scott -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Stephen Farrell Sent: Friday, May 18, 2012 10:05 AM To: Stephen Farrell Cc: DTN interest Subject: Re: [dtn-interest] RFC 5050 revision? So, replying to my own mail, at least in part, and not as chair,.. I'd think I'd like to see a rev of the BP that includes the security stuff = from day 1 as a MUST implement, that gets rid of the dictionary in favour o= f some kind of generic compression (if IPR-free) and that also loses the ab= solute time requirement. I think that'd be best done as a new BP version th= at didn't have to be backwards compatible with the 5050, and we'd want to d= efine a way for (some?) CLs to negotiate versions of the BP to make sure th= at smooth migration was possible. I'd also like to see some bits of current work finished (e.g CL RFCs), and = also progression of the BPQ work we've been doing and on key management. I'm sure there's more but those are my main things for now. S On 05/15/2012 09:01 PM, Stephen Farrell wrote: >=20 > Hi all, >=20 > As Joerg noted we're interested in whether or not, and if so how,=20 > folks would like to do some work on an update or revision for RFC=20 > 5050, or ideas for alternatives to the BP or additional DTN protocols. >=20 > Things we're interested in hearing about, are: >=20 > - Should we rev 5050? why? why not? > - What do you not like about 5050? how'd you fix that? > - What is missing from 5050? how'd you add that? > - What's great about 5050? why'd you keep that? > - What 2119 MUST/SHOULD/MAY would you change and why? > - What DTN research questions would you like to tackle > where RFC 5050 (or implementations thereof) are > a barrier? >=20 > In addition, we'd be interested in hearing whether folks would like to=20 > explore doing DTN based not on a straight revision of the BP, but=20 > maybe e.g. based on CoAP, SPDY, websockets, or other protocols. >=20 > Or, if you've something else to say/suggest, fo ahead and do that too. >=20 > At this point the goal is to gather and discuss ideas on the list,=20 > with a view to seeing what's of interest to RG participants. >=20 > If we get a bunch of ideas, then we'll try to organise those a bit and=20 > start separate threads. > For now, if you can respond to this mail, that'll help us track the=20 > discussion later. >=20 > Later on, the question of who's actually willing to do stuff will get=20 > more interesting, since that's how things get done - just saying that=20 > it "must be so" > is frequently trumped by the fact that someone else has the energy to=20 > actually do something. >=20 > Lastly, none of this means that there's anything wrong with RFC 5050=20 > which has been great for both doing DTN experiments and for the CCSDS=20 > folks who're building on it for their work. (And in case CCSDS people=20 > get process-scared, no, nothing will ever change the existing RFCs, so=20 > documents referring to them are unaffected.) >=20 > Cheers, > Stephen, Kevin, Joerg. >=20 > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest >=20 >=20 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From L.Wood@surrey.ac.uk Sun May 20 01:30:13 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21BA21F8474 for ; Sun, 20 May 2012 01:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsbAVDqDXhLu for ; Sun, 20 May 2012 01:30:13 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id ABA6B21F8472 for ; Sun, 20 May 2012 01:30:12 -0700 (PDT) Received: from [195.245.230.131:10019] by server-8.bemta-3.messagelabs.com id 06/77-24428-29BA8BF4; Sun, 20 May 2012 08:30:10 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-78.messagelabs.com!1337502610!29409778!1 X-Originating-IP: [131.227.200.35] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6683 invoked from network); 20 May 2012 08:30:10 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-10.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 20 May 2012 08:30:10 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.156]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Sun, 20 May 2012 09:30:07 +0100 From: To: , Date: Sun, 20 May 2012 09:30:05 +0100 Thread-Topic: [dtn-interest] RFC 5050 revision? Thread-Index: Ac0y1YdiRHea7HrYQLijHO3m8hdNIADirZKn Message-ID: References: <4FB2B614.1090303@cs.tcd.ie> In-Reply-To: <4FB2B614.1090303@cs.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 08:30:13 -0000 Stephen Farrell wrote: > In addition, we'd be interested in hearing whether > folks would like to explore doing DTN based not on > a straight revision of the BP, but maybe e.g. based > on CoAP, SPDY, websockets, or other protocols. Since this group was set up to push and develop only the bundle protocol, t= he group will probably need to be rechartered to allow this. Non-bundle pro= tocol work has been ignored previously. To consider CoAP or SPDY or websockets in dtns, it is necessary to consider= how HTTP - which CoAP, SPDY and websockets are based on - fits into dtns. = And since HTTP assumes full path connectivity between the endpoints, and dt= ns don't have that, it's not as easy as one might think... Fortunately, that consideration and mapping HTTP to dtns has already been t= hought out, and has been previously presented to the group: http://sat-net.com/L.Wood/dtn/http-dtn http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery From L.Wood@surrey.ac.uk Sun May 20 01:49:45 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3121F8589 for ; Sun, 20 May 2012 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDU+Gqz8hJX7 for ; Sun, 20 May 2012 01:49:44 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0621F8573 for ; Sun, 20 May 2012 01:49:43 -0700 (PDT) Received: from [195.245.230.131:53021] by server-8.bemta-3.messagelabs.com id 48/B1-24428-720B8BF4; Sun, 20 May 2012 08:49:43 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-16.tower-78.messagelabs.com!1337503782!26199544!1 X-Originating-IP: [131.227.200.31] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22095 invoked from network); 20 May 2012 08:49:42 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-16.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 20 May 2012 08:49:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.156]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 20 May 2012 09:49:41 +0100 From: To: Date: Sun, 20 May 2012 09:49:41 +0100 Thread-Topic: [dtn-interest] RFC 5050 revision? Thread-Index: Ac01GGOQ3JML2O8FThOISbI4RDFp1wBSp+1r Message-ID: References: <4FB2B614.1090303@cs.tcd.ie>,<4FB68139.4010005@cs.tcd.ie> In-Reply-To: <4FB68139.4010005@cs.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 08:49:45 -0000 > I'd think I'd like to see a rev of the BP that > includes the security stuff from day 1 as a > MUST implement,=20 No surprises there - the chairs of this group have always been very focused= on security. But many embedded systems don't need, want, or can afford the overheads and= complexity of the BP security protocols, so mandating security will make t= he bundle protocol even less relevant to operational dtns than it is now.=20 > that gets rid of the dictionary > in favour of some kind of generic compression > (if IPR-free) and that also loses the absolute > time requirement.=20 The absolute time requirement has indeed prevented adoption of the BP. However, mandating the security protocol may well need absolute time anyway= ... I imagine that uniquely identifying a bundle (or preventing replay atta= cks?) becomes less straightforward without timestamps. > I'd also like to see some bits of current > work finished (e.g CL RFCs), since the TCP convergence layer draft expired in 2008, and 99+% of bundle t= ransfers rely on the Internet (because TCP/IP is widely available and bundl= ing's just built on top) and use the TCP convergence layer, getting that pu= blished would seem to be essential. http://tools.ietf.org/html/draft-irtf-dtnrg-tcp-clayer-02 (Any reliability that the bundle protocol is perceived to have is probably = due to its reliance on TCP. Mandating the security protocol forces a degree= of reliability, but at a performance cost.) > and also progression > of the BPQ work we've been doing and on > key management. Key management and revocation without absolute time could be... interesting= . Lloyd Wood http://sat-net.com/L.Wood/dtn= From stephen.farrell@cs.tcd.ie Sun May 20 03:47:17 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914B421F851B for ; Sun, 20 May 2012 03:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAz4OeVJXWXI for ; Sun, 20 May 2012 03:47:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0C21F8503 for ; Sun, 20 May 2012 03:47:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 271A117153E; Sun, 20 May 2012 11:47:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337510835; bh=GZbtbfDBp/ewzG UPTX/EjJxWXq+zOoB1zKnUoYBSRBY=; b=ssF0DY5L/qcFBjZBdRiSmiz2/vw7Ff 4Gp2qK0ejje7qFMjcTrz4UDTwhjfUUcVrG8OBgxMrZ0Fa3U02AL4fYrYqCE9NCEn vA08x99hmWS2NjVE6Hf6wLVvc6zZbsPAj9qlDrjvn+pVbeIGyOGziXefZtKe6yFF ps+1uFSDilTYz7Yq+aPEDltB+/EcA46g1ufjy5UoVBXE8rtv5WNncDIE7mffyNha ccJ8Nee+wdtr80SvsQunKzpI5mQllEXFeHaPS3ui5TtM8bfXWJrz+8LBpIdRWSYh dUV7Os5dxuN/JsTpGoCUTm+dQf0whw4gnSGUaWZ39BYscU4x38cGdMQQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id s0c8lssvG4om; Sun, 20 May 2012 11:47:15 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.20.120]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 406D417153D; Sun, 20 May 2012 11:47:15 +0100 (IST) Message-ID: <4FB8CBB2.1000304@cs.tcd.ie> Date: Sun, 20 May 2012 11:47:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4FB2B614.1090303@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 10:47:17 -0000 On 05/20/2012 09:30 AM, L.Wood@surrey.ac.uk wrote: > Stephen Farrell wrote: >> In addition, we'd be interested in hearing whether >> folks would like to explore doing DTN based not on >> a straight revision of the BP, but maybe e.g. based >> on CoAP, SPDY, websockets, or other protocols. > > Since this group was set up to push and develop only the bundle protocol, the group will probably need to be rechartered to allow this. Non-bundle protocol work has been ignored previously. I don't think rechartering is a must-do, but I do agree that if enough people want to do credible DTN work not associated with the BP then we probably should update the charter text so the very few people who read the charter [1] don't get confused. [1] http://irtf.org/dtnrg > To consider CoAP or SPDY or websockets in dtns, it is necessary to consider how HTTP - which CoAP, SPDY and websockets are based on - fits into dtns. And since HTTP assumes full path connectivity between the endpoints, and dtns don't have that, it's not as easy as one might think... > > Fortunately, that consideration and mapping HTTP to dtns has already been thought out, and has been previously presented to the group: > http://sat-net.com/L.Wood/dtn/http-dtn > http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery I agree that if we seriously discuss non-BP things then HTTP ought be considered. S. > > > > > From stephen.farrell@cs.tcd.ie Sun May 20 03:59:25 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8608321F8547 for ; Sun, 20 May 2012 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG+B0SZwBUCR for ; Sun, 20 May 2012 03:59:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3709721F8546 for ; Sun, 20 May 2012 03:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9DA9617153F; Sun, 20 May 2012 11:59:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337511562; bh=lZmjHgP5zQp4IC GOvWq8ZXKpbilhdPAuV7DrgGhhC0U=; b=NaNWPmlEG+U7fGLWtd/2sKJPhBdDPP egFhMzYsXCvLMavtI205qYJwVmB2eISj4sACSGcVIHKYIBMaKerrekEYgFwctG+m VxNDXuGHQ8tU6gnK6xAuuW86CI2++hK1hGJ0Tuap/c8XZC2Ly7lNQ4CPxXSwzVMo C+kW5njcwVyLLRcSaTBeYqApNOQfM/GsePSbQ1G1ln+rLCBUL33KsdaugQ7nyy9h VEt5IN8QAwvMWvnhNywt4nDxEtWFWox90bUKSpgKU8X6P90TF3XxVbIHUPHh+IxY MRiq/GceldE1URGgR65+d8PU4XElIPOw1IHjmtiqjjjRE4aVnrX3/yrw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Z0+UI4MChVZ3; Sun, 20 May 2012 11:59:22 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.20.120]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 76CF417153E; Sun, 20 May 2012 11:59:22 +0100 (IST) Message-ID: <4FB8CE8A.9080904@cs.tcd.ie> Date: Sun, 20 May 2012 11:59:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4FB2B614.1090303@cs.tcd.ie>, <4FB68139.4010005@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 10:59:25 -0000 On 05/20/2012 09:49 AM, L.Wood@surrey.ac.uk wrote: > >> I'd think I'd like to see a rev of the BP that >> includes the security stuff from day 1 as a >> MUST implement, > > No surprises there - the chairs of this group have always been very focused on security Ah. I so missed that kind of thing;-) > But many embedded systems don't need, want, or can afford the overheads and complexity of the BP security protocols, so mandating security will make the bundle protocol even less relevant to operational dtns than it is now. Sure, there's a discussion to be had there. IMO the BSP stuff is too complex, but had to be since it was designed after the fact. I think we could do better. >> that gets rid of the dictionary >> in favour of some kind of generic compression >> (if IPR-free) and that also loses the absolute >> time requirement. > > The absolute time requirement has indeed prevented adoption of the BP. > > However, mandating the security protocol may well need absolute time anyway... I imagine that uniquely identifying a bundle (or preventing replay attacks?) becomes less straightforward without timestamps. Yep. Didn't say all these changes were easy or trivial. >> I'd also like to see some bits of current >> work finished (e.g CL RFCs), > > since the TCP convergence layer draft expired in 2008, and 99+% of bundle transfers rely on the Internet (because TCP/IP is widely available and bundling's just built on top) and use the TCP convergence layer, getting that published would seem to be essential. > > http://tools.ietf.org/html/draft-irtf-dtnrg-tcp-clayer-02 > > (Any reliability that the bundle protocol is perceived to have is probably due to its reliance on TCP. Mandating the security protocol forces a degree of reliability, but at a performance cost.) > >> and also progression >> of the BPQ work we've been doing and on >> key management. > > Key management and revocation without absolute time could be... interesting. Revocation with hard-fail hasn't been deployed by most Internet applications. Could be that in DTNs its just not worth it - might be better to try distribute new keys at whatever frequency you could have done CRL-equivalents. But DTN key management is an area that needs real research, I agree. S. > > Lloyd Wood > http://sat-net.com/L.Wood/dtn From chiara.boldrini@iit.cnr.it Mon May 21 07:00:07 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4B21F8678 for ; Mon, 21 May 2012 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExB8yAlBcS7W for ; Mon, 21 May 2012 07:00:06 -0700 (PDT) Received: from turig1.iit.cnr.it (turig1.iit.cnr.it [146.48.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2135921F8673 for ; Mon, 21 May 2012 07:00:05 -0700 (PDT) Received: by turig1.iit.cnr.it (Postfix, from userid 1002) id 6123E3C8155; Mon, 21 May 2012 16:00:02 +0200 (CEST) Date: Mon, 21 May 2012 16:00:02 +0200 From: Chiara Boldrini To: dtn-interest@irtf.org Message-ID: <4fba4a62.74POROUbUDm73OZM%chiara.boldrini@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dtn-interest] IEEE PerCom 2013 - Call for Papers X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 14:00:08 -0000 ------------------------------------------------------------------------------------------------------- CALL FOR PAPERS PerCom 2013 IEEE International Conference on Pervasive Computing and Communications 18-22 March 2013, San Diego, USA ------------------------------------------------------------------------------------------------------- IEEE PerCom, now in its eleventh edition, is established as the premier annual scholarly venue in the areas of pervasive computing and communications. Pervasive computing and communications has evolved into an active area of research and development, due to the tremendous advances in a broad spectrum of technologies and topics including wireless networking, mobile and distributed computing, sensor systems, RFID technology, and the ubiquitous mobile phone. PerCom 2013 will be held in San Diego, "America's finest city", famous for its climate, its beaches, and numerous tourist attractions. PerCom 2013 will provide a leading edge, scholarly forum for researchers, engineers, and students alike to share their state-of-the art research and developmental work in the broad areas of pervasive computing and communications. The conference will feature a diverse mixture of interactive forums: core technical sessions of high quality cutting-edge research articles; targeted workshops on exciting topics; live demonstrations of pervasive computing in action; insightful keynote speeches; panel discussions from domain experts; and posters of budding ideas. Research contributions are solicited in all areas pertinent to pervasive computing and communications, including: - Innovative pervasive computing applications - Context modeling and reasoning - Data management for pervasive computing - Programming paradigms for pervasive systems - Software evolution and maintenance in pervasive systems - Middleware for pervasive services and applications - Adaptive, autonomic and context-aware computing - Mobile/wearable computing systems and services in pervasive computing - Energy-efficient and green pervasive computing - Communication architectures for pervasive computing - Ad hoc networks for pervasive communications - Pervasive opportunistic communications and applications - Enabling technologies for pervasive systems (e.g., wireless BAN, PAN) - Positioning and tracking technologies - Sensors and RFIDs in pervasive systems - Multimodal sensing and context for pervasive applications - Participatory, opportunistic and social sensing - Smart devices and intelligent environments - Trust, security and privacy issues in pervasive systems - User interface, interaction, and persuasion - Virtual immersive communications - Pervasive computing aspects of social networks - Social and economic models for pervasive systems Workshops and Affiliated Events Many workshops will be held in conjunction with the main conference. Workshop papers will be included and indexed in the IEEE digital libraries (Xplore), showing their affiliation with IEEE PerCom. As in the past, PerCom 2013 will also feature a PhD Forum, Demonstrations and a Work-in-Progress Session. Please visit the conference website for details. Important Dates Paper Registration: Sep. 21st, 2012 Paper submission: Sep. 28th, 2012 Notification: Dec. 22nd, 2012 Camera Ready: Jan. 25th, 2013 Best paper award The best paper will receive the prestigious Mark Weiser best paper award. Papers of particular merit will be considered for a special issue of the Elsevier journal of Pervasive and Mobile Computing (PMC). Submission Guidelines Submitted papers must be unpublished and not considered elsewhere for publication. Also, they must show a significant relevance to pervasive computing and networking. Guidelines for preparing and submitting the manuscript will be made available on the conference website. All papers will be managed electronically through EDAS. Submitted papers will undergo a rigorous review process handled by the Technical Program Committee. For additional information, see www.percom.org for details on current and past PerCom conferences, or contact the PerCom 2013 organizing committee at percom2013@dico.unimi.it Organizing Committee General Chair: Jadwiga Indulska, The University of Queensland, Australia Vice General Chair: Chatschik Bisdikian, IBM T. J. Watson Research, USA Program Chair: Claudio Bettini, University of Milan, Italy Vice Program Co-Chairs: Marco Gruteser, Rutgers University, USA Christine Julien, University of Texas at Austin, USA Marius Portmann, The University of Queensland, Australia Workshops Co-Chairs: Urs Hengartner, University of Waterloo, Canada Gregor Schiele, University of Mannheim, Germany Steering Committee Chair: Marco Conti, IIT-CNR, Italy ==================================================== Chiara Boldrini, Ph.D. IEEE PerCom 2013 Publicity Co-Chair Institute for Informatics and Telematics (IIT) National Research Council of Italy (CNR) Via G. Moruzzi 1, 56124, Pisa ==================================================== From lars@netapp.com Tue May 22 11:15:47 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEA21F85F0; Tue, 22 May 2012 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG5c2LKJkHbL; Tue, 22 May 2012 11:15:47 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id EAE4A21F848E; Tue, 22 May 2012 11:15:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,639,1330934400"; d="p7s'?scan'208";a="649504516" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 22 May 2012 11:15:31 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4MIFUsa012208; Tue, 22 May 2012 11:15:30 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.15]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0298.004; Tue, 22 May 2012 11:15:29 -0700 From: "Eggert, Lars" To: RFC Editor Thread-Topic: Request to publish draft-irtf-dtnrg-prophet-10 Thread-Index: AQHNOEbeN7rWZ0Pce0CdOVSmPuPSNw== Date: Tue, 22 May 2012 18:15:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_29673ECD-C348-44DA-9ED1-34F13E7E2053"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Internet Research Steering Group , "iana@iana.org" , "dtn-interest@irtf.org" Subject: [dtn-interest] Request to publish draft-irtf-dtnrg-prophet-10 X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 18:15:47 -0000 --Apple-Mail=_29673ECD-C348-44DA-9ED1-34F13E7E2053 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, RFC Editor, please publish draft-irtf-dtnrg-prophet-10 as an Experimental RFC on the = IRTF Stream. (IANA CC'ed for information.) The document has been approved for publication by the IRSG and also = received an RFC5742 review by the IESG. See = http://wiki.tools.ietf.org/group/irtf/trac/ticket/37 for details and = history. Please copy all correspondence to the document shepherd, Stephen Farrell = (stephen.farrell@cs.tcd.ie). Thanks, Lars= --Apple-Mail=_29673ECD-C348-44DA-9ED1-34F13E7E2053 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyMjE4MTUyOFowIwYJKoZIhvcNAQkEMRYEFAaG gOiuXtwaiuF+u8HQT+oEKGGaMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBADYdDVsy uxE1MVsoacPM6XD6OR/9YCaOl/5IOYGLFDF/2wfv2F7GIwmo6lsjVJynrbrCwk8OusKigSp9CfD0 p8RB5eqhOkZS2S/yCdjLPC5BE06CfT7jA69M0S6xMopKA6LCwcErLfy3yN2WU5oAyBxVyNnBVjuT E8vUDVrFYYde2u20lGwa5kSASNP3V2QwH98nZnjoqL4h++0b68Xyh571gM4zOfy0Zdd3ZuFd/Cwo 3oOog81ScPJJy2NRfpQkUFEHSdSdZJFvI8xrpdbuQePAR4uLULWgZONdirTuo680BrgIwBrYXtjY PM6Vg/+AQeKu4d1uU+xW78V6q0yMPkAAAAAAAAA= --Apple-Mail=_29673ECD-C348-44DA-9ED1-34F13E7E2053-- From elwynd@folly.org.uk Wed May 23 12:32:43 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3821F867A for ; Wed, 23 May 2012 12:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.672 X-Spam-Level: X-Spam-Status: No, score=0.672 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1C1VaH-xgjM for ; Wed, 23 May 2012 12:32:43 -0700 (PDT) Received: from c.painless.aaisp.net.uk (c.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e35]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33221F8643 for ; Wed, 23 May 2012 12:32:43 -0700 (PDT) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[81.187.254.250]) by c.painless.aaisp.net.uk with esmtp (Exim 4.72) (envelope-from ) id 1SXHIX-0002oS-NV; Wed, 23 May 2012 20:32:41 +0100 From: Elwyn Davies To: Joerg Ott Content-Type: text/plain Organization: Folly Consulting Date: Wed, 23 May 2012 20:32:39 +0100 Message-Id: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: DTN interest Subject: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 19:32:43 -0000 Hi, Joerg. Thanks for looking after the latter stages of the PRoPHET draft's progress to approval. Its now in the RFC Editor queue at last! Making the final odd updates to the draft (including moving from I-D to RFC for the reference to the Bundle Security protocol) I realized that the PRoPHET draft has a reference to the TCP CL draft and, although this is illustrative rather than normatuve, it may stall the PRoPHET draft when editing reaches that point. The TCP CL draft has been stalled for nearly four years now. Is there any chance that we can get it finished and published? I know thare has been discussion of this from time to time. I'll put some time into it if need be. Regards, Elwyn From jo@netlab.tkk.fi Wed May 23 22:53:47 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2816621F8592 for ; Wed, 23 May 2012 22:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfA+d9bEEozt for ; Wed, 23 May 2012 22:53:46 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by ietfa.amsl.com (Postfix) with ESMTP id 779A321F8585 for ; Wed, 23 May 2012 22:53:38 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id q4O5rZOM012482; Thu, 24 May 2012 08:53:35 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 16645-730; Thu, 24 May 2012 08:53:35 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id q4O5rYfD012476; Thu, 24 May 2012 08:53:34 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 32D2D1E174; Thu, 24 May 2012 08:53:34 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gGk-1LTxCaM2; Thu, 24 May 2012 08:53:30 +0300 (EEST) Received: from joerg-otts-macbook.local (a91-154-110-176.elisa-laajakaista.fi [91.154.110.176]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 69B881E0E5; Thu, 24 May 2012 08:53:30 +0300 (EEST) Message-ID: <4FBDCCF3.90006@netlab.tkk.fi> Date: Thu, 24 May 2012 08:53:55 +0300 From: Joerg Ott User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Elwyn Davies References: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> In-Reply-To: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: DTN interest Subject: Re: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 05:53:47 -0000 Hi Elwyn, indeed, it's been on our list for a while. You are more than welcome to contribute to get this out of the way. We have a couple of items from numerous discussions that want to be done -- it's a bit more than a trivial rev and resubmission for publication. Jörg On 23.05.2012 22:32, Elwyn Davies wrote: > Hi, Joerg. > > Thanks for looking after the latter stages of the PRoPHET draft's > progress to approval. Its now in the RFC Editor queue at last! > > Making the final odd updates to the draft (including moving from I-D to > RFC for the reference to the Bundle Security protocol) I realized that > the PRoPHET draft has a reference to the TCP CL draft and, although this > is illustrative rather than normatuve, it may stall the PRoPHET draft > when editing reaches that point. > > The TCP CL draft has been stalled for nearly four years now. Is there > any chance that we can get it finished and published? I know thare has > been discussion of this from time to time. I'll put some time into it > if need be. > > Regards, > Elwyn > > > From lars@netapp.com Thu May 24 00:41:24 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE87521F8550 for ; Thu, 24 May 2012 00:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnCwCJJbRO-6 for ; Thu, 24 May 2012 00:41:24 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85621F854D for ; Thu, 24 May 2012 00:41:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,649,1330934400"; d="p7s'?scan'208";a="650027625" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 May 2012 00:41:19 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4O7fIgQ027439; Thu, 24 May 2012 00:41:18 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.15]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Thu, 24 May 2012 00:41:17 -0700 From: "Eggert, Lars" To: Elwyn Davies Thread-Topic: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft Thread-Index: AQHNORrWyJSU5LK+vk2Mxnj+wcfrP5bZBFeA Date: Thu, 24 May 2012 07:41:16 +0000 Message-ID: <1749B351-0906-454D-A08A-45E01252A726@netapp.com> References: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> In-Reply-To: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_3E802A77-D195-4740-BFA2-875A2F95F11F"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: DTN interest Subject: Re: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 07:41:24 -0000 --Apple-Mail=_3E802A77-D195-4740-BFA2-875A2F95F11F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On May 23, 2012, at 21:32, Elwyn Davies wrote: > I realized that > the PRoPHET draft has a reference to the TCP CL draft and, although this > is illustrative rather than normatuve, it may stall the PRoPHET draft > when editing reaches that point. Informative References do not stall publication. Lars --Apple-Mail=_3E802A77-D195-4740-BFA2-875A2F95F11F Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyNDA3NDExN1owIwYJKoZIhvcNAQkEMRYEFN+x FBz4a5irH7v0jvleKEumsAqoMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAC9JD6Cq Ty7tbP3tnATXj9e4sJUBvH/QEiTjZpzkCJFpSu0MnVJbcO3vjf9ggIhmP961+2AGlmoFFQWcrR8g kPcutm8uaOr4a8+OT+6ja6uey2lXnKQEPot21oWdwMSE7soB9hlmxrUsgGfxl/KUIbav93W8KOWE gVkSQ374C1LzOx18MTpdSyD8/S6aMXbKDd3r5K1gEnJqmNt0zcczLdVjvkKGwx+mKgyQurlJ7db1 orIDgjbskjbK2wSnQrhD07Jobiu6h7p5VHYbsvevykoIFmaPzF5v9w+/4/mywLN2MkEQSiUs1yU4 T0QwgMCl9gxxHgtMucwU1huIQT79RkcAAAAAAAA= --Apple-Mail=_3E802A77-D195-4740-BFA2-875A2F95F11F-- From kscott@mitre.org Thu May 24 05:33:50 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C9321F8671 for ; Thu, 24 May 2012 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rbw0rxGslu1 for ; Thu, 24 May 2012 05:33:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5621F8631 for ; Thu, 24 May 2012 05:33:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6C96521B04A9; Thu, 24 May 2012 08:33:47 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5CDB221B1AD8; Thu, 24 May 2012 08:33:47 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0283.003; Thu, 24 May 2012 08:33:46 -0400 From: "Scott, Keith L." To: Elwyn Davies , Joerg Ott Thread-Topic: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft Thread-Index: AQHNORrYszZTKhtx90qZbYCs0WnWCJbY4JBQ Date: Thu, 24 May 2012 12:33:46 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE2104E7@IMCMBX01.MITRE.ORG> References: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> In-Reply-To: <1337801559.31554.12215.camel@mightyatom.folly.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DTN interest Subject: Re: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL draft X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:33:50 -0000 I'd be happy to assist getting the TCP CL draft tied off. --keith -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Elwyn Davies Sent: Wednesday, May 23, 2012 3:33 PM To: Joerg Ott Cc: DTN interest Subject: [dtn-interest] PRoPHET draft approved and Progressing the TCP CL d= raft Hi, Joerg. Thanks for looking after the latter stages of the PRoPHET draft's progress to approval. Its now in the RFC Editor queue at last! Making the final odd updates to the draft (including moving from I-D to RFC for the reference to the Bundle Security protocol) I realized that the PRoPHET draft has a reference to the TCP CL draft and, although this is illustrative rather than normatuve, it may stall the PRoPHET draft when editing reaches that point. The TCP CL draft has been stalled for nearly four years now. Is there any chance that we can get it finished and published? I know thare has been discussion of this from time to time. I'll put some time into it if need be. Regards, Elwyn _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From chiara.boldrini@iit.cnr.it Fri May 25 02:10:05 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA72521F85BE for ; Fri, 25 May 2012 02:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8BhZg+wvU9H for ; Fri, 25 May 2012 02:10:03 -0700 (PDT) Received: from turig1.iit.cnr.it (turig1.iit.cnr.it [146.48.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98621F85AC for ; Fri, 25 May 2012 02:10:02 -0700 (PDT) Received: by turig1.iit.cnr.it (Postfix, from userid 1002) id BB0213C8155; Fri, 25 May 2012 11:10:01 +0200 (CEST) Date: Fri, 25 May 2012 11:10:01 +0200 From: Chiara Boldrini To: dtn-interest@irtf.org Message-ID: <4fbf4c69.94oZsO1ezvajLgxb%chiara.boldrini@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dtn-interest] IEEE PerCom 2013 - Call for Workshop Proposals - Deadline fast approaching! X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 09:10:05 -0000 ******************************************************************************* IEEE PerCom 2013 11th IEEE Int. Conf. on Pervasive Computing and Communications March 18-22, 2013 - San Diego, CA, USA ******************************************************************************* CALL FOR WORKSHOP PROPOSALS **************************************** IEEE PerCom, now in its 11th edition, is the premier conference for presenting scholarly research in pervasive computing and communications. Advances in this field are leading to innovative platforms, protocols, systems and applications for always-on, always-connected services. The PerCom 2013 Organizing Committee invites proposals for one-day or half-day workshops affiliated with the conference. The workshops will be held prior to, or immediately after, the main conference. The purpose of these workshops is to provide a venue for presenting novel ideas in a less formal and typically more focused area than at the conference itself. Please visit http://www.percom.org to learn about earlier PerCom workshops. Note that PerCom workshops are expected to enable stimulating discussions of state-of-the-art, emerging, visionary, and perhaps controversial topics. Workshops should be organized to promote such lively interaction. Plans to promote interaction and discussion should be clearly addressed in workshop proposals. Workshop proposals are solicited in all areas and topics pertaining to pervasive computing and communications research and applications. Workshops addressing new emerging research directions in pervasive computing and communication are especially welcome. Proposal Submission Guidelines: ******************************* Each workshop proposal must include: - The name of the workshop. - The preferred date of the workshop (Monday or Friday). - The names, addresses, and a short bio (up to 200 words) of the organizers (up to three, from at least two different institutions). - A brief description (up to 1 page) of the technical issues that the workshop will address and the reasons why the workshop is of interest at this time. Please also include a short discussion of related workshops and conferences and outline why the proposed workshop is unique. - The names of potential program committee members, and some consideration on the communities/groups it intends to attract. - The planned format of the workshop, including a strategy to facilitate lively and interactive discussions. - If applicable, a description of past versions of the workshop, including: number of submitted and accepted papers and number of attendees. - If the workshop does not have any past editions, an estimate of the expected number of submitted and accepted papers, and of the expected number of attendees. - A description of the publicity plan. - A call for papers. - The workshop website address. Workshop proposals should be submitted, no later than *May 31, 2012*, by e-mail (in PDF format), to the PerCom 2013 Workshop Co-chairs at the following address percom2013workshops@cs.uwaterloo.ca, with "PerCom 2013 Workshop Proposal" in the subject. Important Dates *************** Workshop proposals submission Deadline: May 31, 2012 Notification: June 22, 2012 The following dates for the workshops schedule are strongly recommended. The date that papers are due to the IEEE is firm: Paper submissions: October 30, 2012 Paper notifications: December 21, 2012 Urs Hengartner and Gregor Schiele -- Percom Workshop co-chairs ==================================================== Chiara Boldrini - PerCom 2013 Publicity Co-Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy homepage: http://cnd.iit.cnr.it/chiara/ ==================================================== From aline.viana@inria.fr Fri May 25 11:41:50 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D926F21F8773 for ; Fri, 25 May 2012 11:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXZzn3QLgjFx for ; Fri, 25 May 2012 11:41:49 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1C521F8770 for ; Fri, 25 May 2012 11:41:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,657,1330902000"; d="scan'208,217";a="145308377" Received: from bny92-2-81-56-19-67.fbx.proxad.net (HELO [192.168.0.17]) ([81.56.19.67]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 May 2012 20:41:27 +0200 Message-ID: <4FBFD258.3050401@inria.fr> Date: Fri, 25 May 2012 20:41:28 +0200 From: Aline Carneiro Viana User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dtn-interest@irtf.org Content-Type: multipart/alternative; boundary="------------050805050108030107010407" Subject: [dtn-interest] =?windows-1252?q?Call_for_participation_=96_IEEE_S?= =?windows-1252?q?ECON_2012_-_Early_registration_deadline_May_29?= X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 18:41:51 -0000 This is a multi-part message in MIME format. --------------050805050108030107010407 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit *********************************************************************************** [Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).] *********************************************************************************** CALL FOR PARTICIPATION IEEE SECON 2012 9th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/ June 18-21, 2012 - Seoul, Korea *********************************************************************************** * IMPORTANT DATES Discounted hotel reservation deadline 29 May 2012 Early registration deadline 29 May 2012 Conference dates 18-21 June 2012 Workshops (ETSIoT’12 and VCSC’12) date 18 June 2012 * SCOPE: Building on the success of previous years, IEEE SECON 2012 provides a unique forum to exchange innovative research ideas, recent results, and share experiences among researchers and practitioners in the field of sensor, mesh, and ad hoc networks and systems. IEEE SECON grew out of the IEEE INFOCOM conference in 2004, in order to create an event that focused on the important and exciting topics of Sensor, Mesh and Ad Hoc Communications Networks. In addition to the traditional topics published in SECON, this year the conference especially brings papers in emerging applications and services, involving sensor, mesh and ad-hoc communications, such as green technologies, smart grids, urban sensing systems, the Internet of Things, social networking, etc. * KEYNOTE TALKS: 1)Dr. Yoonchae Cheong (Senior Vice President at the Samsung Advanced Institute of Technology, Samsung Electronics Co. Ltd.). Talk titled "Digital Space Expansion through Smartphone" and 2) Dr. Kang G. Shin (Professor at the University of Michigan. Talk titled "Is Dynamic Spectrum Access a Blessing or Curse?". Speaker bio and talk abstracts can be found at http://www.ieee-secon.org/keynote.html * TECHNICAL PROGRAM: 67 papers have been accepted for presentation and for publication in the conference proceedings. The complete list of accepted papers can be found on-line at the conference web page: http://www.ieee-secon.org/program.html * PANEL: The panel, moderated by Prof. Sunghyun Choi (Seoul National University, Korea), will provide discussion on “M2M/D2D toward Beyond 4G Wireless” and will be held on June 20th, 2012. * Workshops: IEEE SECON 2012 features two workshops to be held on June 18, 2012: 1. The IEEE Workshop on Enabling Technologies for Smartphone and Internet of Things (ETSIoT) 2012 aims to provide a forum for academic researchers and industrial experts possessing the vision of IoT with smartphones. 2. The IEEE Workshop on Vehicular Communications, Sensing, and Computing (VCSC) 2012 aims to cover all related topics of intra/inter-vehicular communications, sensing on the road, and computing to support safer and more efficient driving. * POSTERS/DEMOS: IEEE SECON 2012 includes poster and demostration sessions providing a forum to present and discuss works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. This year IEEE SECON is also running a best poster and best demo award competition. Awards will be based on the novelty and the potentials of the poster/demo to drive further research. * STUDENT TRAVEL GRANTS: The IEEE SECON 2012 organizing committee is pleased to provide a limited number of Student Travel Grants to graduate students to participate in our conference, workshops, poster, and demo sessions. See more information at http://www.ieee-secon.org/sttravel.html. * SPONSORS: IEEE SECON 2012 organizing committee is pleased to announce it has 3 Gold patrons (ETRI, HP Laboratories, and Samsung Electronics) and 3 Silver patrons (IBM Research, INRIA, and KEPCO). See more information at http://www.ieee-secon.org/patrons.html. * VENUE: IEEE SECON 2012 will take place at the Millennium Seoul Hilton at 395, 5-ga, Namdaemun-ro, Jung-gu, Seoul, South Korea 100-802. A block of rooms have been reserved for June 15, 2012 - June 23, 2012. The special room rate will be available until May 29th or until the group block is sold-out, whichever comes first. Please make your hotel arrangements early in order to insure getting a room at the special conference rate price. Reservations can be made on-line http://www.hilton.com/en/hi/groups/personalized/S/SELHITW-GIEE06-20120615/index.jhtml?WT.mc_id=POG.** --------------050805050108030107010407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

***********************************************************************************

 

[Please accept our apologies if you receive multiple copies of this Call for Participation (CFP).]

 

***********************************************************************************

                             CALL FOR PARTICIPATION

 

                                 IEEE SECON 2012

                  9th Annual IEEE Communications Society Conference on

                 Sensor, Mesh and Ad Hoc Communications and Networks

                            http://www.ieee-secon.org/

 

                         June 18-21, 2012 - Seoul, Korea

 

***********************************************************************************

 

* IMPORTANT DATES

  Discounted hotel reservation deadline       29 May 2012

  Early registration deadline                 29 May 2012

  Conference dates                            18-21 June 2012

  Workshops (ETSIoT’12 and VCSC’12) date      18 June 2012

 

 

* SCOPE: Building on the success of previous years, IEEE  SECON  2012  provides a unique forum to exchange innovative research ideas, recent results, and share experiences among researchers and practitioners in the field of sensor, mesh, and ad hoc networks and systems.  IEEE SECON grew out of the IEEE INFOCOM conference in 2004, in order to create an event that focused on the important and exciting topics of Sensor, Mesh and Ad Hoc Communications Networks. In addition to the traditional topics published in SECON, this year the conference especially brings papers in emerging applications and services, involving sensor, mesh and ad-hoc communications, such as green technologies, smart grids, urban sensing systems, the Internet of Things, social networking, etc.

 

* KEYNOTE TALKS:  1)Dr. Yoonchae Cheong (Senior Vice President at the Samsung Advanced Institute of Technology, Samsung Electronics Co. Ltd.). Talk titled "Digital Space Expansion through Smartphone" and 2) Dr. Kang G. Shin (Professor at the University of Michigan. Talk titled "Is Dynamic Spectrum Access a Blessing or Curse?". Speaker bio and talk abstracts can be found at http://www.ieee-secon.org/keynote.html 

 

* TECHNICAL  PROGRAM:  67  papers  have  been  accepted  for presentation   and  for   publication   in  the   conference proceedings. The complete list of accepted papers can be found on-line at the conference web page: http://www.ieee-secon.org/program.html 

 

* PANEL:  The panel, moderated by Prof. Sunghyun Choi (Seoul National University, Korea),  will provide discussion on “M2M/D2D toward Beyond 4G Wireless” and will be held on June 20th, 2012.

 

* Workshops: IEEE SECON 2012 features two workshops to be held on June 18, 2012:

1. The IEEE Workshop on Enabling Technologies for Smartphone and Internet of Things (ETSIoT) 2012 aims to provide a forum for academic researchers and industrial experts possessing the vision of IoT with smartphones.

 

2. The IEEE Workshop on Vehicular Communications, Sensing, and Computing (VCSC) 2012 aims to cover all related topics of intra/inter-vehicular communications, sensing on the road, and computing to support safer and more efficient driving.

 

* POSTERS/DEMOS: IEEE SECON 2012 includes poster and demostration sessions providing a forum to present and discuss works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. This year IEEE SECON is also running a best poster and best demo award competition. Awards will be based on the novelty and the potentials of the poster/demo to drive further research.

 

* STUDENT  TRAVEL  GRANTS: The  IEEE  SECON 2012  organizing committee is pleased to provide a limited number of Student Travel Grants  to graduate students to participate in our conference, workshops, poster, and demo sessions. See more information at http://www.ieee-secon.org/sttravel.html.

 

* SPONSORS: IEEE SECON 2012 organizing committee is pleased to announce it has 3 Gold patrons (ETRI, HP Laboratories, and Samsung Electronics) and 3 Silver patrons (IBM Research, INRIA, and KEPCO). See more information at http://www.ieee-secon.org/patrons.html.

 

* VENUE: IEEE SECON 2012 will take place at the Millennium Seoul Hilton at  395, 5-ga, Namdaemun-ro, Jung-gu, Seoul, South Korea 100-802. A block of rooms have been reserved for June 15, 2012 - June 23, 2012. The special room rate will be available until May 29th or until the group block is sold-out, whichever comes first.  Please  make   your  hotel arrangements early in order to  insure getting a room at the special conference  rate price. Reservations can be made on-line http://www.hilton.com/en/hi/groups/personalized/S/SELHITW-GIEE06-20120615/index.jhtml?WT.mc_id=POG.
--------------050805050108030107010407-- From william.d.ivancic@nasa.gov Wed May 30 12:02:29 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF6411E817E for ; Wed, 30 May 2012 12:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiGWzyTSK14P for ; Wed, 30 May 2012 12:02:28 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id AE53E11E8136 for ; Wed, 30 May 2012 12:02:27 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id B3867260435; Wed, 30 May 2012 14:02:26 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q4UJ2PWk027205; Wed, 30 May 2012 14:02:25 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 30 May 2012 14:02:25 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Stephen Farrell Date: Wed, 30 May 2012 14:04:36 -0500 Thread-Topic: [dtn-interest] RFC 5050 revision? Thread-Index: Ac0+lr/38rnvlTtpQM2Q4WF+30vkig== Message-ID: References: <4FB2B614.1090303@cs.tcd.ie> <4FB8CBB2.1000304@cs.tcd.ie> In-Reply-To: <4FB8CBB2.1000304@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2--679775697"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-30_02:2012-05-21, 2012-05-30, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:02:29 -0000 --Apple-Mail-2--679775697 Content-Type: multipart/alternative; boundary=Apple-Mail-1--679775735 --Apple-Mail-1--679775735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 20, 2012, at 6:47 AM, Stephen Farrell wrote: >=20 >=20 > On 05/20/2012 09:30 AM, L.Wood@surrey.ac.uk wrote: >> Stephen Farrell wrote: >>> In addition, we'd be interested in hearing whether >>> folks would like to explore doing DTN based not on >>> a straight revision of the BP, but maybe e.g. based >>> on CoAP, SPDY, websockets, or other protocols. >>=20 >> Since this group was set up to push and develop only the bundle = protocol, the group will probably need to be rechartered to allow this. = Non-bundle protocol work has been ignored previously. >=20 > I don't think rechartering is a must-do, but I do agree that > if enough people want to do credible DTN work not associated > with the BP then we probably should update the charter text > so the very few people who read the charter [1] don't get > confused. I think a recharter is necessary to encourage additional thinking in = store-carry-and-forward techniques. The first two paragraphs are more = open thinking, but the following two propose a specific solution and = appears rather restrictive. http://irtf.org/dtnrg "The group intends to build upon the extended =93bundling=94 = architecture created originally for the Interplanetary Internet. This = architecture proposes an alternative to the Internet TCP/IP end-to-end = model and employs hop-by-hop storage and retransmission as a = transport-layer overlay. It provides a messaging service interface = conceptually similar to electronic mail, but generalized for = application-independence and supported by specialized reliability and = routing capabilities. The intended work products of the DTNRG include architectural = descriptions (concept documents) a bundling protocol specification, and = a series of one or more network-environment-specific =93profile=94 = documents. These profile documents will include descriptions of = =91convergence layers=92 intended to adapt the overlying messaging = architecture for use in specialized networking environments (space, = water, sensor networks), and are expected to be created by the study = teams described in the Membership section below. One study team output = will be an =93Internet profile=94 document, developed in concert with = the architectural and protocol specification documents, giving suggested = naming conventions and protocols to use for transport within the public = Internet." - Will= --Apple-Mail-1--679775735 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


On 05/20/2012 09:30 AM, L.Wood@surrey.ac.uk = wrote:
Stephen Farrell = wrote:
In addition, we'd be interested in hearing = whether
folks would like to explore doing DTN based not = on
a straight revision of the BP, but maybe e.g. = based
on CoAP, SPDY, websockets, or other = protocols.

Since this = group was set up to push and develop only the bundle protocol, the group = will probably need to be rechartered to allow this. Non-bundle protocol = work has been ignored previously.

I don't think = rechartering is a must-do, but I do agree that
if enough people want = to do credible DTN work not associated
with the BP then we probably = should update the charter text
so the very few people who read the = charter [1] don't = get
confused.

I think a = recharter is necessary to encourage additional thinking in = store-carry-and-forward techniques.  The first two paragraphs are = more open thinking, but the following two propose a specific solution = and appears rather restrictive.

"The= group intends to build upon the extended =93bundling=94 architecture=20 created originally for the Interplanetary Internet. This architecture=20 proposes an alternative to the Internet TCP/IP end-to-end model and=20 employs hop-by-hop storage and retransmission as a transport-layer=20 overlay. It provides a messaging service interface conceptually similar=20= to electronic mail, but generalized for application-independence and=20 supported by specialized reliability and routing capabilities.

The = intended work products of the DTNRG include architectural descriptions (concept documents) a bundling=20 protocol specification, and a series of one or more=20 network-environment-specific =93profile=94 documents. These profile=20 documents will include descriptions of =91convergence layers=92 intended = to=20 adapt the overlying messaging architecture for use in specialized=20 networking environments (space, water, sensor networks), and are=20 expected to be created by the study teams described in the Membership=20 section below. One study team output will be an =93Internet profile=94=20= document, developed in concert with the architectural and protocol=20 specification documents, giving suggested naming conventions and=20 protocols to use for transport within the public Internet."

- = Will
= --Apple-Mail-1--679775735-- --Apple-Mail-2--679775697 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQTzCCCA0w ggb1oAMCAQICBEvVLBkwDQYJKoZIhvcNAQEFBQAweDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Uu Uy4gR292ZXJubWVudDENMAsGA1UECxMETkFTQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEcMBoGA1UECxMTTkFTQSBPcGVyYXRpb25hbCBDQTAeFw0xMDEwMTUxNjIyMTVaFw0x MzEwMTUxNjUyMTVaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTAL BgNVBAsTBE5BU0ExDzANBgNVBAsTBlBlb3BsZTEwMBYGA1UEAxMPV0lMTElBTSBJVkFOQ0lDMBYG CgmSJomT8ixkAQETCHdpdmFuY2ljMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqn5l 7k+sZH12gm4g3FPjj2l5X89tn5rbXw3uv2oc6iJ2Cv9RwFN5IYpcBYrUAVRnpGveEBAX6PTSBunt feMBPSGgO731DnGvV0mQLmghDP/lDqESkQlbThZ/42RnON+eSMa7OW+nFXAJsIjvfcxS84Bizy/4 J8XOXnTrg+csQ5BPyKgO0N2lm8WbgzfM0zZNxMe8esFxdEd5DnTo3IEPB9C7awf9/4zlB4kVfTa/ DG87iaAhgY4yJ3iyvSUHn1FdHo3VviRmDPBiVlceNwZh5esbwPFRh9/WAakV6KIneedN9sCO1XAY ZGrB25NT27vDaBKlKExDy0OhL3RCwV1j+QIDAQABo4IEnDCCBJgwDgYDVR0PAQH/BAQDAgUgMCUG A1UdIAQeMBwwDAYKYIZIAWUDAgEDBjAMBgpghkgBZQMCAQUHMFgGCWCGSAGG+mseAQRLDElUaGUg cHJpdmF0ZSBrZXkgY29ycmVzcG9uZGluZyB0byB0aGlzIGNlcnRpZmljYXRlIG1heSBoYXZlIGJl ZW4gZXhwb3J0ZWQuMIH9BggrBgEFBQcBAQSB8DCB7TAwBggrBgEFBQcwAoYkaHR0cDovL3BraS50 cmVhcy5nb3Yvbm9jYV9lZV9haWEucDdjMIGVBggrBgEFBQcwAoaBiGxkYXA6Ly9uZGFjLmFyYy5u YXNhLmdvdi9vdT1OQVNBJTIwT3BlcmF0aW9uYWwlMjBDQSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0 aG9yaXRpZXMsb3U9TkFTQSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y0FDZXJ0aWZpY2F0ZTti aW5hcnkwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLnRyZWFzLmdvdjBFBgNVHREEPjA8gR53aWxs aWFtLmQuaXZhbmNpY0BncmMubmFzYS5nb3aBGndpbGxpYW0uZC5pdmFuY2ljQG5hc2EuZ292MBsG A1UdCQQUMBIwEAYJKoZIhvZ9B0QdMQMCARwwggI5BgNVHR8EggIwMIICLDCB9KCB8aCB7oYjaHR0 cDovL2hjLm5hc2EuZ292L2NvbWJpbmVkQ1JMMS5jcmyGgZdsZGFwOi8vbGMubmFzYS5nb3YvY249 V2luQ29tYmluZWQxLG91PU5BU0ElMjBPcGVyYXRpb25hbCUyMENBLG91PUNlcnRpZmljYXRpb24l MjBBdXRob3JpdGllcyxvdT1OQVNBLG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0hi1odHRwOi8vcGtpLnRyZWFzLmdvdi9OQVNBX09wZXJhdGlvbmFsX0NB MS5jcmwwggExoIIBLaCCASmGgZdsZGFwOi8vbmRhYy5hcmMubmFzYS5nb3YvY249Q1JMMzA3LG91 PU5BU0ElMjBPcGVyYXRpb25hbCUyMENBLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv dT1OQVNBLG89VS5TLiUyMEdvdmVybm1lbnQsYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 pIGMMIGJMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQ0wCwYDVQQLEwRO QVNBMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhvcml0aWVzMRwwGgYDVQQLExNOQVNBIE9w ZXJhdGlvbmFsIENBMQ8wDQYDVQQDEwZDUkwzMDcwHwYDVR0jBBgwFoAUqm21iZ4nGumsLfHmb40j tqC/k8EwHQYDVR0OBBYEFByv2xEOrHmeYif9763Hp4VNNKgtMAkGA1UdEwQCMAAwGQYJKoZIhvZ9 B0EABAwwChsEVjcuMQMCBJAwDQYJKoZIhvcNAQEFBQADggEBAB7uuaeEKO9rXWYHsguOTYbLR8QT cvOvDO3dKmWS+Iro6xjbRx+su+aVtk9JKLfNV3JJyH2PjMV26Fe3mlfLYFK1nDfHtubTF5u1GSU/ keLn53lgprV5GxF6IseX02jMbjqd8SDsMWlOEbr1GlrhwDkI4OrTJPP9x9TvFLwJZ8OUbk2FjV32 y/Cv9ARLVafpsNIkyznu5w5LVOr58Cl/pNBeHOJj/xLE0yNm0qnS9/J9z025EqM/pKiSHC+iGbE/ tb5rtAAxz3LqU8kwUBS4XMX/KQakpMQyNOX39T+/zX9FTVdRtik0+bkF20tWxIVs9pYXb3XLn1mf g2vd9tAQUPYwggg6MIIHIqADAgECAgRF45rtMA0GCSqGSIb3DQEBBQUAMHgxCzAJBgNVBAYTAlVT MRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBE5BU0ExIjAgBgNVBAsTGUNlcnRp ZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAsTE05BU0EgT3BlcmF0aW9uYWwgQ0EwHhcNMTAw NDA5MTQ0MzM2WhcNMTMwNDA5MTUxMzM2WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBH b3Zlcm5tZW50MQ0wCwYDVQQLEwROQVNBMQ8wDQYDVQQLEwZQZW9wbGUxMDAWBgNVBAMTD1dJTExJ QU0gSVZBTkNJQzAWBgoJkiaJk/IsZAEBEwh3aXZhbmNpYzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAOGA/uCyQ8dCx3eSgrjJEfY6FEipS6tlMP6IaosNDkhyxrQd2PjYdzFipp3rwGie Iyo44HfBGZ9eCaAD4wm6ho2gZD1r9mhKGOGC8gHWT5jaRB4vVpA8Pt4uzKznbgeBmb2YHQNNCi/j IUA9s7hfAj2wL5K2leumve7VFXu0DMaCDPQ4eCvsyDCnQnDygTze3Ngxb0vEfCIyUKuii9doYRb9 6QQa0zMwcWhf3CQQczHPJQ3SXlw/sOFUmyrvgtyzVxrujLV0Asck0BFONBCnT+ruC1AL+dhgFwf8 2TqwOhDPqFdeTFFlkd4AYWjuuyPQ5vhGzdB4tTDvczFQNVmhOJcCAwEAAaOCBMkwggTFMA4GA1Ud DwEB/wQEAwIGwDArBgNVHRAEJDAigA8yMDEwMDQwOTE0NDMzNlqBDzIwMTIwNTE1MTkxMzM2WjAl BgNVHSAEHjAcMAwGCmCGSAFlAwIBAwYwDAYKYIZIAWUDAgEFBzBYBglghkgBhvprHgEESwxJVGhl IHByaXZhdGUga2V5IGNvcnJlc3BvbmRpbmcgdG8gdGhpcyBjZXJ0aWZpY2F0ZSBtYXkgaGF2ZSBi ZWVuIGV4cG9ydGVkLjCB/QYIKwYBBQUHAQEEgfAwge0wMAYIKwYBBQUHMAKGJGh0dHA6Ly9wa2ku dHJlYXMuZ292L25vY2FfZWVfYWlhLnA3YzCBlQYIKwYBBQUHMAKGgYhsZGFwOi8vbmRhYy5hcmMu bmFzYS5nb3Yvb3U9TkFTQSUyME9wZXJhdGlvbmFsJTIwQ0Esb3U9Q2VydGlmaWNhdGlvbiUyMEF1 dGhvcml0aWVzLG91PU5BU0Esbz1VLlMuJTIwR292ZXJubWVudCxjPVVTP2NBQ2VydGlmaWNhdGU7 YmluYXJ5MCEGCCsGAQUFBzABhhVodHRwOi8vb2NzcC50cmVhcy5nb3YwRQYDVR0RBD4wPIEed2ls bGlhbS5kLml2YW5jaWNAZ3JjLm5hc2EuZ292gRp3aWxsaWFtLmQuaXZhbmNpY0BuYXNhLmdvdjAb BgNVHQkEFDASMBAGCSqGSIb2fQdEHTEDAgEcMIICOQYDVR0fBIICMDCCAiwwgfSggfGgge6GI2h0 dHA6Ly9oYy5uYXNhLmdvdi9jb21iaW5lZENSTDEuY3JshoGXbGRhcDovL2xjLm5hc2EuZ292L2Nu PVdpbkNvbWJpbmVkMSxvdT1OQVNBJTIwT3BlcmF0aW9uYWwlMjBDQSxvdT1DZXJ0aWZpY2F0aW9u JTIwQXV0aG9yaXRpZXMsb3U9TkFTQSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdIYtaHR0cDovL3BraS50cmVhcy5nb3YvTkFTQV9PcGVyYXRpb25hbF9D QTEuY3JsMIIBMaCCAS2gggEphoGXbGRhcDovL25kYWMuYXJjLm5hc2EuZ292L2NuPUNSTDI3MCxv dT1OQVNBJTIwT3BlcmF0aW9uYWwlMjBDQSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMs b3U9TkFTQSxvPVUuUy4lMjBHb3Zlcm5tZW50LGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dKSBjDCBiTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDENMAsGA1UECxME TkFTQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEcMBoGA1UECxMTTkFTQSBP cGVyYXRpb25hbCBDQTEPMA0GA1UEAxMGQ1JMMjcwMB8GA1UdIwQYMBaAFKpttYmeJxrprC3x5m+N I7agv5PBMB0GA1UdDgQWBBQWXJKHrIuZ+GiRe0BQ9V81wGEpcTAJBgNVHRMEAjAAMBkGCSqGSIb2 fQdBAAQMMAobBFY3LjEDAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQCKdAGdNGrsprekQbQDyeHcBjO4 bN84v2WaCOVswOgIknOwLpGr1uGRxURVhoGFRML/SOsVbPGIQSyzb+BpSQiyi0cc3paD3XGv/h4v kf3tvVFlIHGM/5HLtG7yDUh90VdqicGEcv3anqbs4Dq7dUUxJUp1dWQ2JE5XnkA9v5VPmgPMG6LO fCT+u9gkIF2fNKLxKgqCG25nO9QGjhiDo5Q4PidXdPg6jqsDM/3lgflJphHOwP/f94ySCLexhpt+ CKdI8UeADOTq+wRbGt3SRnLGyrb1zaMGBgC33RZR7IWvturcfPIIBtKHtnFMRl6HExVR8zc/nj6L kuAk4Smw/lIwMYIDMzCCAy8CAQEwgYAweDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292 ZXJubWVudDENMAsGA1UECxMETkFTQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEcMBoGA1UECxMTTkFTQSBPcGVyYXRpb25hbCBDQQIEReOa7TAJBgUrDgMCGgUAoIIBhzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1MzAxOTA0MzdaMCMGCSqG SIb3DQEJBDEWBBRUNgEiaujCV9uEge7kXpPcAJfKsDCBkQYJKwYBBAGCNxAEMYGDMIGAMHgxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBE5BU0ExIjAgBgNV BAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxHDAaBgNVBAsTE05BU0EgT3BlcmF0aW9uYWwg Q0ECBEvVLBkwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHgxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9V LlMuIEdvdmVybm1lbnQxDTALBgNVBAsTBE5BU0ExIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0 aG9yaXRpZXMxHDAaBgNVBAsTE05BU0EgT3BlcmF0aW9uYWwgQ0ECBEvVLBkwDQYJKoZIhvcNAQEB BQAEggEAXA5uX4UP1KnPJSRxvLPkDX1fuvcZeNMp+FMPYtfnMxufbnMPpfeja2KwW3OBMDXSNKv2 TfZFLIW4jS8H6rM24tLwCnmrCqcPj6jtpmO9OY5u/biEJto/Bg2h4S2e/kgyfVxJDUpHzEw3Enf/ 9T3QdtfzW6uFZUsxgcQOLnJa5VAJoSdIM1tbHxKaN7RoWAgBjK2X/NyFEKtDQXJfXn/S2ezTPkNk CcHBaHqXWpV6TgxuN4oh/mAEZ8pLr8ZbxM1foZp1N+g8Wmqlc1dumFX0i2iuOiYK+fihRIuslYxz O0vz9WaQpievfVl/copoEJ+0lzuwKlan/sN7m+ppRt09eQAAAAAAAA== --Apple-Mail-2--679775697-- From stephen.farrell@cs.tcd.ie Wed May 30 15:24:03 2012 Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E950811E80A2 for ; Wed, 30 May 2012 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7Z8Ry5KzI4c for ; Wed, 30 May 2012 15:24:01 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C01B411E8073 for ; Wed, 30 May 2012 15:24:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 193FD153959; Wed, 30 May 2012 23:23:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338416637; bh=pNDL5pq/abyl5L ufHad6sfbW8IkqnanQDVI7Eg2Euok=; b=lFrL34dtjHNGX8YcTZjBnSdKb49pyp V38sR3CXuvO/e/TwFj7pj7ocoV9oTmHxgpWiA6Jsh35eU/CjORmWYEoobiieuXCc GYM0hUWma9Hv1gmAC6yF815HxfPks78uFo0CGxgEkHbS+0pEFaM2g/LcaojJulSD O6FHqPF24rDxNx9oNqo/L1HhHczocbLYcjnihPJ9eBQpj7EoU1BIOjROKlz8rP6T KNWuNGpoamMcJZ0ouvIVufyzj8gnoK8wuLLCLHGLZcB3RJzFHDolrldNQVo0oEyc uCeBwCRhJZ36jfs9bcWw46MRZAEac/8DNsx2h9kTSzQGk/ZOPiMowW7w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id CyHAd0cV75Gx; Wed, 30 May 2012 23:23:57 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.25.154]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C9940153B1E; Wed, 30 May 2012 23:23:54 +0100 (IST) Message-ID: <4FC69DFA.60003@cs.tcd.ie> Date: Wed, 30 May 2012 23:23:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: <4FB2B614.1090303@cs.tcd.ie> <4FB8CBB2.1000304@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] RFC 5050 revision? X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 22:24:04 -0000 Hi Will, On 05/30/2012 08:04 PM, Ivancic, William D. (GRC-RHN0) wrote: > > On May 20, 2012, at 6:47 AM, Stephen Farrell wrote: > >> >> >> On 05/20/2012 09:30 AM, L.Wood@surrey.ac.uk wrote: >>> Stephen Farrell wrote: >>>> In addition, we'd be interested in hearing whether >>>> folks would like to explore doing DTN based not on >>>> a straight revision of the BP, but maybe e.g. based >>>> on CoAP, SPDY, websockets, or other protocols. >>> >>> Since this group was set up to push and develop only the bundle protocol, the group will probably need to be rechartered to allow this. Non-bundle protocol work has been ignored previously. >> >> I don't think rechartering is a must-do, but I do agree that >> if enough people want to do credible DTN work not associated >> with the BP then we probably should update the charter text >> so the very few people who read the charter [1] don't get >> confused. > > I think a recharter is necessary to encourage additional thinking in store-carry-and-forward techniques. The first two paragraphs are more open thinking, but the following two propose a specific solution and appears rather restrictive. IRTF RG charters aren't meant to be restrictive like that. I'd rather discuss what people want to do and then decide if we want new charter text. (Note: want, not need:-) S > http://irtf.org/dtnrg > "The group intends to build upon the extended “bundling” architecture created originally for the Interplanetary Internet. This architecture proposes an alternative to the Internet TCP/IP end-to-end model and employs hop-by-hop storage and retransmission as a transport-layer overlay. It provides a messaging service interface conceptually similar to electronic mail, but generalized for application-independence and supported by specialized reliability and routing capabilities. > > The intended work products of the DTNRG include architectural descriptions (concept documents) a bundling protocol specification, and a series of one or more network-environment-specific “profile” documents. These profile documents will include descriptions of ‘convergence layers’ intended to adapt the overlying messaging architecture for use in specialized networking environments (space, water, sensor networks), and are expected to be created by the study teams described in the Membership section below. One study team output will be an “Internet profile” document, developed in concert with the architectural and protocol specification documents, giving suggested naming conventions and protocols to use for transport within the public Internet." > > - Will