From william.d.ivancic@nasa.gov Mon Apr 2 05:35:28 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 B5FF321F8681 for ; Mon, 2 Apr 2012 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 j4rBmAbgcXwO for ; Mon, 2 Apr 2012 05:35:26 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9804421F866A for ; Mon, 2 Apr 2012 05:35:23 -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 36C382601C8; Mon, 2 Apr 2012 07:35:22 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q32CZKE2021076; Mon, 2 Apr 2012 07:35:20 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Mon, 2 Apr 2012 07:35:20 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Abdulkader Benchi Date: Mon, 2 Apr 2012 07:35:18 -0500 Thread-Topic: [dtn-interest] banking system in a DTN Thread-Index: Ac0QzRCRsHFjELyQRVmN2CVmiduhdg== Message-ID: <7462779A-5F0C-42BA-875A-262ED05B65B3@nasa.gov> References: <1333184299.24288.YahooMailClassic@web120405.mail.ne1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7462779A5F0C42BA875A262ED05B65B3nasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-02_01:2012-04-02, 2012-04-02, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] banking system in a 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: Mon, 02 Apr 2012 12:35:28 -0000 --_000_7462779A5F0C42BA875A262ED05B65B3nasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are disconnected - which is when you should be using DTN - then the = banking application needs to be re-written to handle long periods of discon= nection, or you security and session timers will time out. If you think of DTN as a network of multi-hop nodes in which Node A can nev= er talk to Node D directly, but has to hop through B and C and there is nev= er a completely connected path from A to D, you should begin to understand = why applications have to be DTN aware to actually be useful in a generic Di= sconnected Tolerant Network. If you just want to tunnel IP over DTN in a fully connected, always-on netw= ork, everything should work just fine. - Will On Mar 31, 2012, at 6:14 AM, Abdulkader Benchi wrote: Hello, As long as I know, when you use a DTN protocol in your communication level you will have many other problems in the upper levels. In fact, it will not be so easy (perhaps impossible) to support or guarantee security and consensus issues in the application levels when using a DTN protocol. As you know, these issues are very important to be supported in any bank system. So to answer your question, you can use any type of communication protocols but you have to think twice how will such protocol helps you to support other issues. Sincerely, Kader the transaction needs to be idempotent in case duplicate detection of the convention type fails. v On Sat, Mar 31, 2012 at 5:51 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: On Sat, Mar 31, 2012 at 4:58 AM, Tom Sparks > wrote: How would the banking system work in a DTN? DTN is a transport mode. As long as the packets get there, why should the banking be different? After all, there was banking back when it took weeks to cross the Atlantic. Why should it be a fundamental problem if it takes 30 minutes to send a message to Mars? Regards Marshall --- tom_a_sparks "It's a nerdy thing I like to do" Please use ISO approved file formats excluding Office Open XML - http://www.gnu.org/philosophy/no-word-attachments.html Ubuntu wiki page https://wiki.ubuntu.com/tomsparks 3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 Premium Edition, AF 2012 Plus Edition, Sam440 AOS 4.1.2, Roland DXY-1300 pen plotter, Cutok DC330 cutter/pen plotter Wanted: RiscOS system, GEOS system (C64/C128), Atari ST, Apple Macintosh (6502/68k/PPC only) _______________________________________________ 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 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest -- BENCHI Abdulkader --------------------------------------------- Doctorant Laboratoire VALORIA - Universit=E9 de Bretagne Sud Rue Yves Mainguy Campus de Tohannic, BP 573 56017 Vannes cedex, France Email: abdulkader.benchi@univ-ubs.fr http://www-valoria.univ-ubs.fr/Abdulkader.Benchi/ tel : +33 (0)2 97 01 72 96 fax : +33 (0)9 56 89 94 20 ---------------------------------------------------------------------------= - _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_7462779A5F0C42BA875A262ED05B65B3nasagov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are disconnected - = which is when you should be using DTN - then the banking application needs = to be re-written to handle long periods of disconnection, or you security a= nd session timers will time out.

If you think of DTN as = a network of multi-hop nodes in which Node A can never talk to Node D direc= tly, but has to hop through B and C and there is never a completely connect= ed path from A to D, you should begin to understand why applications have t= o be DTN aware to actually be useful in a generic Disconnected Tolerant Net= work.

If you just want to tunnel IP over DTN in a fu= lly connected, always-on network, everything should work just fine.  <= /div>


- Will



On Mar 31, 2012, at 6:14 AM, Abdul= kader Benchi wrote:

Hello,
As long as I know, when you use a DTN protoc= ol in your communication level
you will have many other problems in the = upper levels.
In fact, it will not be so easy (perhaps impossible) to su= pport or
guarantee security and consensus issues in the application leve= ls when
using a DTN protocol.
As you know, these issues are very impo= rtant to be supported in any bank
system.
So to answer your question,= you can use any type of communication
protocols but you have to think t= wice how will such protocol helps you to
support other issues.

Si= ncerely,

Kader

the transaction need= s to be idempotent in case duplicate detection of the
convention type fails.

v


On Sat, Mar 31, 2012 at 5:51 AM, Marshall= Eubanks <
marshall.eubanks@gmail.com> wrote:

On Sat, Mar 31, 2012 at 4:58 AM, Tom Sparks &= lt;tom_a_sparks@yahoo.com.au>
wrote:
=
How would the banking s= ystem work in a DTN?

DTN is a transport mode. As = long as the packets get there, why should
the
banking be differ= ent?

After all, there was banking back when it took weeks to c= ross the
Atlantic. Why
should it be a fundamental problem if i= t takes 30 minutes to send a
message to Mars?

Regards
Marshall


---
to= m_a_sparks "It's a nerdy thing I like to do"
<= /blockquote>
Please use ISO approved file formats excluding Office Open X= ML -
http://www.gnu.org/philosophy/no-word-attachments.html<= br>
Ubuntu wiki page https://wiki.ubuntu.com/tomsparks
<= /blockquote>
3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF= 2006 Premium Edition,
AF
<= blockquote type=3D"cite">
2012 Plus Edition, Sam44= 0 AOS 4.1.2, Roland DXY-1300 pen plotter, Cutok
DC330 cutter/pen plot= ter
Wanted: RiscOS system, GEOS system (C64= /C128), Atari ST, Apple
Macintosh
(6502/68k/PPC on= ly)
_______________________________________= ________
dtn-interest mailing = list
dtn-interest@irtf.org
= https://www.irtf.org/mailman/listinfo/dtn-interest
_= ______________________________________________
dtn-interest mailing l= ist
dtn-interest@irtf.org
ht= tps://www.irtf.org/mailman/listinfo/dtn-interest

___________________________________= ____________
dtn-interest mailing= list
dtn-interest@irtf.org
https= ://www.irtf.org/mailman/listinfo/dtn-interest



--
BENCHI Abdulkader --------= -------------------------------------
Doctorant
Laboratoire VALORIA -= Universit=E9 de Bretagne Sud
Rue Yves Mainguy
Campus de Tohannic, BP= 573
56017 Vannes cedex, France
Email: abdulkader.benchi@univ-ubs.fr
http://www-valoria.univ-ubs.fr/A= bdulkader.Benchi/
tel :     +33 (0)2 97 01 72 96=
fax :     +33 (0)9 56 89 94 20
-----------------= -----------------------------------------------------------

________= _______________________________________
dtn-interest mailing list
dtn= -interest@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-interest

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne= tworking Lab 216-433-2620
Mobile = 440-503-4892
http://roland.grc.nasa.gov/~ivancic

= --_000_7462779A5F0C42BA875A262ED05B65B3nasagov_-- From khelil@informatik.tu-darmstadt.de Tue Apr 3 10:08:18 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 4EC0A21F865B for ; Tue, 3 Apr 2012 10:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 AlZm1pLmwmVs for ; Tue, 3 Apr 2012 10:08:17 -0700 (PDT) Received: from lnx503.hrz.tu-darmstadt.de (lnx503.hrz.tu-darmstadt.de [130.83.156.232]) by ietfa.amsl.com (Postfix) with ESMTP id 223C421F8780 for ; Tue, 3 Apr 2012 10:08:16 -0700 (PDT) Received: from localhost.localdomain (deeds05.deeds.informatik.tu-darmstadt.de [130.83.162.134]) by lnx503.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id q33H8E1B003357; Tue, 3 Apr 2012 19:08:14 +0200 (envelope-from khelil@informatik.tu-darmstadt.de) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id q33H8E8O014926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Apr 2012 19:08:14 +0200 Received: (from wwwadm@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id q33H8Ekj014923; Tue, 3 Apr 2012 19:08:14 +0200 X-Authentication-Warning: localhost.localdomain: wwwadm set sender to khelil@informatik.tu-darmstadt.de using -f Received: from 89.14.197.138 (SquirrelMail authenticated user khelil) by webmail.deeds.informatik.tu-darmstadt.de with HTTP; Tue, 3 Apr 2012 19:08:14 +0200 Message-ID: In-Reply-To: <1333184299.24288.YahooMailClassic@web120405.mail.ne1.yahoo.com> References: <1333184299.24288.YahooMailClassic@web120405.mail.ne1.yahoo.com> Date: Tue, 3 Apr 2012 19:08:14 +0200 From: "Abdelmajid Khelil" To: "Tom Sparks" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.3.170016 X-PMX-RELAY: outgoing X-Mailman-Approved-At: Wed, 04 Apr 2012 08:04:28 -0700 Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] banking system in a 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, 03 Apr 2012 17:08:18 -0000 Dear Tom, We have published some preliminary results on DT transactions in the following papers. I hope this helps you answering your question: - Brahim Ayari, Abdelmajid khelil, Neearj Suri "Exploring Delay-Aware Transactions in Heterogenous Mobile Environments" In: Journal of Software - Volume 4 issue 7, pp. 634-643, 2009. - Brahim Ayari, Abdelmajid Khelil, Neeraj Suri "On the Design of Perturbation-Resilient Atomic Commit Protocols for Mobile Transactions", ACM Transactions on Computer Systems (ToCS), Vol. 29, No. 3, PP 7:1-7:36, August 2011. - Brahim Ayari, Abdelmajid Khelil and Neeraj Suri "ParTAC: A Partition-Tolerant Atomic Commit Protocol for MANETs", In Proc. of The 11th International Conference on Mobile Data Management (MDM), 2010. Best, Majid On Sat, March 31, 2012 10:58 am, Tom Sparks wrote: > How would the banking system work in a DTN? > > --- > tom_a_sparks "It's a nerdy thing I like to do" > Please use ISO approved file formats excluding Office Open XML - > http://www.gnu.org/philosophy/no-word-attachments.html > Ubuntu wiki page https://wiki.ubuntu.com/tomsparks > 3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 Premium Edition, AF > 2012 Plus Edition, Sam440 AOS 4.1.2, Roland DXY-1300 pen plotter, Cutok > DC330 cutter/pen plotter > Wanted: RiscOS system, GEOS system (C64/C128), Atari ST, Apple Macintosh > (6502/68k/PPC only) > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > ------------------------------------------------------------- Dr. Abdelmajid Khelil khelil(at)informatik.tu-darmstadt.de TU Darmstadt - CS Department DEEDS Group Hochschulstr. 10 S2:02 E219 D-64289 Darmstadt, GER Tel. +49-6151-16-3414 Fax. +49-6151-16-4310 http://www.deeds.informatik.tu-darmstadt.de/khelil/index.html ------------------------------------------------------------- From ahennes1@math.umd.edu Wed Apr 4 14:22: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 B6D2521F85F4 for ; Wed, 4 Apr 2012 14:22: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 ehVi0CqCdM-Z for ; Wed, 4 Apr 2012 14:22:47 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE5721F85F2 for ; Wed, 4 Apr 2012 14:22:47 -0700 (PDT) X-ASG-Debug-ID: 1333574565-04739d102722b040001-c1rJwl Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id DdhCQChaOVQWD9qm for ; Wed, 04 Apr 2012 17:22:45 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 9309A20FC8B; Wed, 4 Apr 2012 17:22:45 -0400 (EDT) Received: from 63.239.65.11 by webmail.math.umd.edu with HTTP; Wed, 4 Apr 2012 17:22:45 -0400 Message-ID: Date: Wed, 4 Apr 2012 17:22:45 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Two new Internet-Drafts To: dtn-interest@irtf.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1333574565 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=5.0 KILL_LEVEL=1000.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.93197 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Subject: [dtn-interest] Two new Internet-Drafts 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, 04 Apr 2012 21:22:47 -0000 There are two new Internet-Drafts: Title : Suite B Ciphersuites for the Bundle Security Protocol Author(s) : Kelley Burgin Angela Hennessy Filename : draft-hennessy-bsp-suiteb-ciphersuites-00.txt Pages : 12 Date : 2012-03-05 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hennessy-bsp-suiteb-ciphersuites-00.txt Title : Suite B Profile for the Bundle Security Protocol Author(s) : Kelley Burgin Angela Hennessy Filename : draft-hennessy-bsp-suiteb-profile-00.txt Pages : 8 Date : 2012-03-05 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hennessy-bsp-suiteb-profile-00.txt Thanks, Angela From lars@netapp.com Tue Apr 10 02:44: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 3C3DB21F85FC for ; Tue, 10 Apr 2012 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.82 X-Spam-Level: X-Spam-Status: No, score=-11.82 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, SARE_NETPROD=0.111] 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 qq7Yi2ozEKgL for ; Tue, 10 Apr 2012 02:44:03 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8D721F8780 for ; Tue, 10 Apr 2012 02:44:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,398,1330934400"; d="p7s'?scan'208";a="639668989" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Apr 2012 02:43:02 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3A9h2jN016446 for ; Tue, 10 Apr 2012 02:43:02 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.117]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Tue, 10 Apr 2012 02:43:01 -0700 From: "Eggert, Lars" To: "dtn-interest@irtf.org" Thread-Topic: Call for Nominations: Applied Networking Research Prize 2012 Thread-Index: AQHNFv5SaVVjymGDDE2RRjYUEWxMeQ== Date: Tue, 10 Apr 2012 09:43:01 +0000 Message-ID: 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=_4618A539-7455-4D62-AC13-3B91AE3248AE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [dtn-interest] Call for Nominations: Applied Networking Research Prize 2012 X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "anrp@irtf.org" 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, 10 Apr 2012 09:44:04 -0000 --Apple-Mail=_4618A539-7455-4D62-AC13-3B91AE3248AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 CALL FOR NOMINATIONS: =20 APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2012 =20 http://irtf.org/anrp *** Submit nominations for the 2012 award period of the *** *** Applied Networking Research Prize until May 13, 2012! *** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) =20 * travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) =20 * invited talk at the IRTF Open Meeting =20 * recognition at the IETF plenary =20 * invitation to related social activities =20 * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one=92s own paper) and third-party nominations (nominating someone else=92s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=92s IETF meetings in person and in its entirety. Nominations must include: * the name and email address of the nominee * a bibliographic reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement about which of the year=92s IETF meetings the nominee would be available to attend in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee=92s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2012/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: May 13, 2012 (hard) Notifications: June 1, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2012-flyer.pdf --Apple-Mail=_4618A539-7455-4D62-AC13-3B91AE3248AE 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMDA5NDMwM1owIwYJKoZIhvcNAQkEMRYEFGEw LN5fMhmCBX41q2BJFBad7p6FMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAC1UkkQ2 /Mv5VVsVEaAXGgjGA/xq5Hp6+7z0Ui15Dm0g7ZoQwPpMzJ8FGbDY/QlOCHud91VTjM58IL+Oebsf 4aZlF6kYUBhYYzZWD6qbWDmp5TLMUWjyubs/QxNpnYAvYFceChsofrppr10Rccveb163wWydvsCA 8o9ELVrvmgL5P8lG2Uz+w33cI/BGo0w9toBW/o7ISwyjFbm8dmpi9IxE9LZDVu11BK0zNIPlfHF8 JbzeBKkTR4bvUKuWXN2xBJvkGl+Gk7Y1XXvA415C7tzI+vhEVsKDyCwD+0mRIl7G7RzV+V9LPEGe m9IaAeKq8MO7BD5zdn1a1nrqOQLGj1cAAAAAAAA= --Apple-Mail=_4618A539-7455-4D62-AC13-3B91AE3248AE-- From james.r.wright@colorado.edu Wed Apr 18 12:58: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 D122B11E8095 for ; Wed, 18 Apr 2012 12:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 GjWI86cuQL8e for ; Wed, 18 Apr 2012 12:58:29 -0700 (PDT) Received: from kahuna.puaa.net (jwright145.dsl.frii.net [216.17.155.145]) by ietfa.amsl.com (Postfix) with ESMTP id D5D2E11E8094 for ; Wed, 18 Apr 2012 12:58:28 -0700 (PDT) Received: from kipu.bioserve.prv (bioserve.colorado.edu [128.138.158.99]) by kahuna.puaa.net (Postfix) with ESMTP id 53842E44782; Wed, 18 Apr 2012 13:58:16 -0600 (MDT) From: Jim Wright Content-Type: multipart/alternative; boundary="Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B" Date: Wed, 18 Apr 2012 13:58:16 -0600 To: dtn-interest@irtf.org Message-Id: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-PuaaConsulting-MailScanner-Information: Please contact the ISP for more information X-PuaaConsulting-MailScanner-ID: 53842E44782.AFB39 X-PuaaConsulting-MailScanner: Found to be clean X-PuaaConsulting-MailScanner-SpamScore: s X-PuaaConsulting-MailScanner-From: james.r.wright@colorado.edu Subject: [dtn-interest] Custody transfer specification in RFC5050 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, 18 Apr 2012 19:59:57 -0000 --Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been reading RFC5050 and specifically trying to understand the = custody transfer mechanism. In my reading of RFC5050, I see no provision = to allow for a Bundle Node to receive a bundle with the Custody Transfer = Request bit set and simply forward it on, without taking custody of the = bundle. It seems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a = Bundle Node that receives and forwards bundles without taking custody, = then where in RFC5050 is this specified? Thanks, Jim --=20 Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 --Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I have been reading RFC5050 and specifically trying to understand the custody transfer mechanism. In my reading of RFC5050, I see no provision to allow for a Bundle Node to receive a bundle with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.

Is this correct? If it is not correct, and it is allowed to have a Bundle Node that receives and forwards bundles without taking custody, then where in RFC5050 is this specified?

Thanks,
Jim



-- 
Jim Wright
BioServe Space Technologies
303-492-1579

--Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B-- From william.d.ivancic@nasa.gov Wed Apr 18 13:22:26 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 AB5CE11E8094 for ; Wed, 18 Apr 2012 13:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.291, 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 JqjDmCXpQPR9 for ; Wed, 18 Apr 2012 13:22:22 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 971FC11E8080 for ; Wed, 18 Apr 2012 13:22:22 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D04762D8523; Wed, 18 Apr 2012 15:22:21 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3IKMLo0003270; Wed, 18 Apr 2012 15:22:21 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Wed, 18 Apr 2012 15:22:20 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Jim Wright Date: Wed, 18 Apr 2012 15:22:42 -0500 Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: Ac0doPTMwgCLhHLNQFurmPh2NrPlWA== Message-ID: <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> In-Reply-To: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_" 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-04-18_07:2012-04-18, 2012-04-18, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 18 Apr 2012 20:22:26 -0000 --_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was just discussing custody transfer with a few colleagues. I haven't go= ne into RFC5050 to confirm you confusion. However, my understanding of cu= stody transfer is that if a node B accepts custody from node A, node A may = decide to clear its storage. Node B is suppose to then do its best to forw= ard the bundle. I believe node B can accept a bundle from node A without a= ccepting custody and forward on to node C which accepts custody. However, = how does node C let node A know it has custody in a meaningful way if they = are disconnected for long periods of time? In the mean time, node A would = likely NOT clear its storage until receiving an acknowledgement of custody = acceptance from some node. In reality, I think custody transfer is just a warm fuzzy good feeling for = the space operations community. In reality, if node accepts a bundle, isn= 't it going to do its best to forward it? If bundles are different sizes w= ith different lifetimes and different priorities to different destinations,= what is the proper algorithm to decide which to forward first? I would like to see an analysis regarding custody transfer. I would not be= surprised to find out that custody transfer actually results in worse perf= ormance in complex networks. If you are string network (A to B to C to D),= it is likely to be a wash. Furthermore, much depends on the routing algor= ithms used as well if if your system is multi-homed. - Will On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: I have been reading RFC5050 and specifically trying to understand the custo= dy transfer mechanism. In my reading of RFC5050, I see no provision to allo= w for a Bundle Node to receive a bundle with the Custody Transfer Request b= it set and simply forward it on, without taking custody of the bundle. It s= eems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a Bundle N= ode that receives and forwards bundles without taking custody, then where i= n RFC5050 is this specified? Thanks, Jim -- Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I was just discussing= custody transfer with a few colleagues.  I haven't gone into RFC5050 = to confirm you confusion.  However, my understanding of  custody = transfer is that if a node B accepts custody from node A, node A may decide= to clear its storage.  Node B is suppose to then do its best to forwa= rd the bundle.  I believe node B can accept a bundle from node A witho= ut accepting custody and forward on to node C which accepts custody.  = However, how does node C let node A know it has custody in a meaningful way= if they are disconnected for long periods of time?  In the mean time,= node A would likely NOT clear its storage until receiving an acknowledgeme= nt of custody acceptance from some node.


In reality, I think custody transfer is just a warm fuzzy good feelin= g for the space operations community.  In reality, if  node accep= ts a bundle, isn't it going to do its best to forward it?  If bundles = are different sizes with different lifetimes and different priorities to di= fferent destinations, what is the proper algorithm to decide which to forwa= rd first?

I would like to see an analysis regardin= g custody transfer.  I would not be surprised to find out that custody= transfer actually results in worse performance in complex networks.  = If you are string network (A to B to C to D), it is likely to be a wash. &n= bsp;Furthermore, much depends on the routing algorithms used as well if if = your system is multi-homed.  

- Will



On Apr 18, 2012, at 3:58 PM, Jim W= right wrote:

I have been reading RFC5050 and spec= ifically trying to understand the custody transfer mechanism. In my reading= of RFC5050, I see no provision to allow for a Bundle Node to receive a bun= dle with the Custody Transfer Request bit set and simply forward it on, wit= hout taking custody of the bundle. It seems every Bundle Node MUST implemen= t custody transfer.

Is this correct? If it is not correc= t, and it is allowed to have a Bundle Node that receives and forwards bundl= es without taking custody, then where in RFC5050 is this specified?

Thanks,
Jim


=
-- 
Jim Wright
BioServe Space Technologies
<= a href=3D"mailto:james.r.wright@colorado.edu">james.r.wright@colorado.edu
303-492-1579

_______________________________________________
dtn-interest m= ailing list
dtn-interest@irtf.o= rg
https://www.irtf.org/mailman/listinfo/dtn-interest

= --_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_-- From james.r.wright@colorado.edu Wed Apr 18 13:43:31 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 1CB5E11E8097 for ; Wed, 18 Apr 2012 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=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 mjkqP5pi2aa5 for ; Wed, 18 Apr 2012 13:43:27 -0700 (PDT) Received: from kahuna.puaa.net (jwright145.dsl.frii.net [216.17.155.145]) by ietfa.amsl.com (Postfix) with ESMTP id AB6EC11E8091 for ; Wed, 18 Apr 2012 13:43:26 -0700 (PDT) Received: from kipu.bioserve.prv (bioserve.colorado.edu [128.138.158.99]) by kahuna.puaa.net (Postfix) with ESMTP id 08D2CE44789; Wed, 18 Apr 2012 14:43:20 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4" From: Jim Wright In-Reply-To: <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> Date: Wed, 18 Apr 2012 14:43:20 -0600 Message-Id: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> To: "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1257) X-PuaaConsulting-MailScanner-Information: Please contact the ISP for more information X-PuaaConsulting-MailScanner-ID: 08D2CE44789.A5906 X-PuaaConsulting-MailScanner: Found to be clean X-PuaaConsulting-MailScanner-From: james.r.wright@colorado.edu Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 18 Apr 2012 20:43:31 -0000 --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think custody transfer is more than a warm fuzzy, it is an important = part of the store-and-forward routing in DTN. Custody transfer = acknowledgement allows a node to clear a stored bundle. Without that the = only way to flush bundles from a node's storage would be through = timeout. Regarding your example, I believe this happens: Node A sends a bundle with the Custody Transfer Requested bit set, and = the Request Reporting of Custody Acceptance bit set. The bundle is sent = to node B. Node B receives the bundle and forwards it to node C, but = node B does not take custody of the bundle. Node C receives the bundle = and accepts custody. Node C looks in the dictionary to find the = Custodian EID, and sends an administrative record bundle to node A to = signal custody acceptance. Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission = deals only with initial transmission from an application agent (getting = a bundle into the DTN), and if section 5.4 Bundle Forwarding deals with = bundles already in the DTN, then my confusion is cleared up. If an = application wants custody transfer, and the originating node does not = support that, then fail immediately. I was reading 5.2 as being a = required step for forwarding of bundles in the network. So does this = make sense and answer my question? Jim On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: > I was just discussing custody transfer with a few colleagues. I = haven't gone into RFC5050 to confirm you confusion. However, my = understanding of custody transfer is that if a node B accepts custody = from node A, node A may decide to clear its storage. Node B is suppose = to then do its best to forward the bundle. I believe node B can accept = a bundle from node A without accepting custody and forward on to node C = which accepts custody. However, how does node C let node A know it has = custody in a meaningful way if they are disconnected for long periods of = time? In the mean time, node A would likely NOT clear its storage until = receiving an acknowledgement of custody acceptance from some node. >=20 >=20 > In reality, I think custody transfer is just a warm fuzzy good feeling = for the space operations community. In reality, if node accepts a = bundle, isn't it going to do its best to forward it? If bundles are = different sizes with different lifetimes and different priorities to = different destinations, what is the proper algorithm to decide which to = forward first? >=20 > I would like to see an analysis regarding custody transfer. I would = not be surprised to find out that custody transfer actually results in = worse performance in complex networks. If you are string network (A to = B to C to D), it is likely to be a wash. Furthermore, much depends on = the routing algorithms used as well if if your system is multi-homed. =20= >=20 > - Will >=20 >=20 >=20 > On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: >=20 >> I have been reading RFC5050 and specifically trying to understand the = custody transfer mechanism. In my reading of RFC5050, I see no provision = to allow for a Bundle Node to receive a bundle with the Custody Transfer = Request bit set and simply forward it on, without taking custody of the = bundle. It seems every Bundle Node MUST implement custody transfer. >>=20 >> Is this correct? If it is not correct, and it is allowed to have a = Bundle Node that receives and forwards bundles without taking custody, = then where in RFC5050 is this specified? >>=20 >> Thanks, >> Jim >>=20 >>=20 >>=20 >> --=20 >> Jim Wright >> BioServe Space Technologies >> james.r.wright@colorado.edu >> 303-492-1579 >>=20 >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest >=20 --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think custody transfer is more than a warm fuzzy, it is an important = part of the store-and-forward routing in DTN. Custody transfer = acknowledgement allows a node to clear a stored bundle. Without that the = only way to flush bundles from a node's storage would be through = timeout.

Regarding your example, I believe this = happens:

Node A sends a bundle with the Custody = Transfer Requested bit set, and the Request Reporting of Custody = Acceptance bit set. The bundle is sent to node B. Node B receives the = bundle and forwards it to node C, but node B does not take custody of = the bundle. Node C receives the bundle and accepts custody. Node C looks = in the dictionary to find the Custodian EID, and sends an administrative = record bundle to node A to signal custody = acceptance.


Hmm, maybe I've = found my problem. If section 5.2 Bundle Transmission deals only with = initial transmission from an application agent (getting a bundle into = the DTN), and if section 5.4 Bundle Forwarding deals with bundles = already in the DTN, then my confusion is cleared up. If an application = wants custody transfer, and the originating node does not support that, = then fail immediately. I was reading 5.2 as being a required step for = forwarding of bundles in the network. So does this make sense and answer = my = question?

Jim


=
On Apr 18, 2012, at 2:22 PM, Ivancic, William D. = (GRC-RHN0) wrote:

I was just = discussing custody transfer with a few colleagues.  I haven't gone = into RFC5050 to confirm you confusion.  However, my understanding = of  custody transfer is that if a node B accepts custody from node = A, node A may decide to clear its storage.  Node B is suppose to = then do its best to forward the bundle.  I believe node B can = accept a bundle from node A without accepting custody and forward on to = node C which accepts custody.  However, how does node C let node A = know it has custody in a meaningful way if they are disconnected for = long periods of time?  In the mean time, node A would likely NOT = clear its storage until receiving an acknowledgement of custody = acceptance from some node.


In = reality, I think custody transfer is just a warm fuzzy good feeling for = the space operations community.  In reality, if  node accepts = a bundle, isn't it going to do its best to forward it?  If bundles = are different sizes with different lifetimes and different priorities to = different destinations, what is the proper algorithm to decide which to = forward first?

I would like to see an analysis = regarding custody transfer.  I would not be surprised to find out = that custody transfer actually results in worse performance in complex = networks.  If you are string network (A to B to C to D), it is = likely to be a wash.  Furthermore, much depends on the routing = algorithms used as well if if your system is multi-homed. =  

- = Will



On Apr 18, 2012, = at 3:58 PM, Jim Wright wrote:

I have been reading RFC5050 and = specifically trying to understand the custody transfer mechanism. In my = reading of RFC5050, I see no provision to allow for a Bundle Node to = receive a bundle with the Custody Transfer Request bit set and simply = forward it on, without taking custody of the bundle. It seems every = Bundle Node MUST implement custody transfer.

Is this = correct? If it is not correct, and it is allowed to have a Bundle Node = that receives and forwards bundles without taking custody, then where in = RFC5050 is this = specified?

Thanks,
Jim



-- 
Jim = Wright
BioServe Space Technologies
=
_______________________________________________
dtn-interest = mailing list
dtn-interest@irtf.org
https://www.ir= tf.org/mailman/listinfo/dtn-interest

<= /blockquote>

= --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4-- From scott.c.burleigh@jpl.nasa.gov Wed Apr 18 13:57: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 77B2C11E8095 for ; Wed, 18 Apr 2012 13:57:48 -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 ClxHPVkEhB6k for ; Wed, 18 Apr 2012 13:57:44 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 57FFD21E801E for ; Wed, 18 Apr 2012 13:57:44 -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 q3IKvgLg026548 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 18 Apr 2012 13:57:42 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 13:57:42 -0700 From: "Burleigh, Scott C (313B)" To: Jim Wright , "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGg== Date: Wed, 18 Apr 2012 20:57:40 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>, 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.114] Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 18 Apr 2012 20:57:48 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, bu= t 5.4 applies on every transmission of a bundle including the first. I thi= nk the more general answer to your question is in the second paragraph of 5= .10: each node makes its own decision as to whether or not to take custody = of each bundle for which custodial transmission was requested. Scott ________________________________ From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] on beha= lf of Jim Wright [james.r.wright@colorado.edu] Sent: Wednesday, April 18, 2012 1:43 PM To: Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 I think custody transfer is more than a warm fuzzy, it is an important part= of the store-and-forward routing in DTN. Custody transfer acknowledgement = allows a node to clear a stored bundle. Without that the only way to flush = bundles from a node's storage would be through timeout. Regarding your example, I believe this happens: Node A sends a bundle with the Custody Transfer Requested bit set, and the = Request Reporting of Custody Acceptance bit set. The bundle is sent to node= B. Node B receives the bundle and forwards it to node C, but node B does n= ot take custody of the bundle. Node C receives the bundle and accepts custo= dy. Node C looks in the dictionary to find the Custodian EID, and sends an = administrative record bundle to node A to signal custody acceptance. Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals = only with initial transmission from an application agent (getting a bundle = into the DTN), and if section 5.4 Bundle Forwarding deals with bundles alre= ady in the DTN, then my confusion is cleared up. If an application wants cu= stody transfer, and the originating node does not support that, then fail i= mmediately. I was reading 5.2 as being a required step for forwarding of bu= ndles in the network. So does this make sense and answer my question? Jim On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: I was just discussing custody transfer with a few colleagues. I haven't go= ne into RFC5050 to confirm you confusion. However, my understanding of cu= stody transfer is that if a node B accepts custody from node A, node A may = decide to clear its storage. Node B is suppose to then do its best to forw= ard the bundle. I believe node B can accept a bundle from node A without a= ccepting custody and forward on to node C which accepts custody. However, = how does node C let node A know it has custody in a meaningful way if they = are disconnected for long periods of time? In the mean time, node A would = likely NOT clear its storage until receiving an acknowledgement of custody = acceptance from some node. In reality, I think custody transfer is just a warm fuzzy good feeling for = the space operations community. In reality, if node accepts a bundle, isn= 't it going to do its best to forward it? If bundles are different sizes w= ith different lifetimes and different priorities to different destinations,= what is the proper algorithm to decide which to forward first? I would like to see an analysis regarding custody transfer. I would not be= surprised to find out that custody transfer actually results in worse perf= ormance in complex networks. If you are string network (A to B to C to D),= it is likely to be a wash. Furthermore, much depends on the routing algor= ithms used as well if if your system is multi-homed. - Will On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: I have been reading RFC5050 and specifically trying to understand the custo= dy transfer mechanism. In my reading of RFC5050, I see no provision to allo= w for a Bundle Node to receive a bundle with the Custody Transfer Request b= it set and simply forward it on, without taking custody of the bundle. It s= eems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a Bundle N= ode that receives and forwards bundles without taking custody, then where i= n RFC5050 is this specified? Thanks, Jim -- Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim, yes, section 5.2 does pertain only to initial issuance of a bun= dle, but 5.4 applies on every transmission of a bundle including the first.=  I think the more general answer to your question is in the second paragraph of 5.10: each node makes its o= wn decision as to whether or not to take custody of each bundle for which c= ustodial transmission was requested.

Scott
From: dtn-interest-bounces@irtf.org [dtn= -interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wright@colorad= o.edu]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

I think custody transfer is more than a warm fuzzy, it is an important= part of the store-and-forward routing in DTN. Custody transfer acknowledge= ment allows a node to clear a stored bundle. Without that the only way to f= lush bundles from a node's storage would be through timeout.

Regarding your example, I believe this happens:

Node A sends a bundle with the Custody Transfer Requested bit set, and= the Request Reporting of Custody Acceptance bit set. The bundle is sent to= node B. Node B receives the bundle and forwards it to node C, but node B d= oes not take custody of the bundle. Node C receives the bundle and accepts custody. Node C looks in the dictio= nary to find the Custodian EID, and sends an administrative record bundle t= o node A to signal custody acceptance.


Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission d= eals only with initial transmission from an application agent (getting a bu= ndle into the DTN), and if section 5.4 Bundle Forwarding deals with bundles= already in the DTN, then my confusion is cleared up. If an application wants custody transfer, and the originati= ng node does not support that, then fail immediately. I was reading 5.2 as = being a required step for forwarding of bundles in the network. So does thi= s make sense and answer my question?

Jim


On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:
I was just discussing custody transfer with a few colleagues.  I = haven't gone into RFC5050 to confirm you confusion.  However, my under= standing of  custody transfer is that if a node B accepts custody from= node A, node A may decide to clear its storage.  Node B is suppose to then do its best to forward the bundle.  I= believe node B can accept a bundle from node A without accepting custody a= nd forward on to node C which accepts custody.  However, how does node= C let node A know it has custody in a meaningful way if they are disconnected for long periods of time?  In the mean t= ime, node A would likely NOT clear its storage until receiving an acknowled= gement of custody acceptance from some node.


In reality, I think custody transfer is just a warm fuzzy good feeling= for the space operations community.  In reality, if  node accept= s a bundle, isn't it going to do its best to forward it?  If bundles a= re different sizes with different lifetimes and different priorities to different destinations, what is the proper algorit= hm to decide which to forward first?

I would like to see an analysis regarding custody transfer.  I wo= uld not be surprised to find out that custody transfer actually results in = worse performance in complex networks.  If you are string network (A t= o B to C to D), it is likely to be a wash.  Furthermore, much depends on the routing algorithms used as well if = if your system is multi-homed.  

- Will



On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:

I have been reading RFC5050 and specifi= cally trying to understand the custody transfer mechanism. In my reading of= RFC5050, I see no provision to allow for a Bundle Node to receive a bundle= with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It= seems every Bundle Node MUST implement custody transfer.

Is this correct? If it is not correct, and it is allowed to have a Bun= dle Node that receives and forwards bundles without taking custody, then wh= ere in RFC5050 is this specified?

Thanks,
Jim



-- 
Jim Wright
BioServe Space Technologies
303-492-1579

_______________________________________________
dtn-interest mailing list
dtn-interest@irt= f.org
https://www.irtf.org/mailman/listinfo/dtn-interest


--_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_-- From william.d.ivancic@nasa.gov Wed Apr 18 14:10:31 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 1A5B321F84A7 for ; Wed, 18 Apr 2012 14:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.356 X-Spam-Level: X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 7p9-AGnla681 for ; Wed, 18 Apr 2012 14:10:30 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 89BCD21F84A1 for ; Wed, 18 Apr 2012 14:10:30 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id ED8E7260864; Wed, 18 Apr 2012 16:10:29 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3ILATNB019615; Wed, 18 Apr 2012 16:10:29 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 18 Apr 2012 16:10:29 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Jim Wright Date: Wed, 18 Apr 2012 16:10:51 -0500 Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: Ac0dp662QDX8ySSzSYaVDCaNCyg39g== Message-ID: <408DC84E-6E39-44E9-AD7D-D02BFF9C9330@nasa.gov> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-18_08:2012-04-18, 2012-04-18, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 18 Apr 2012 21:10:31 -0000 On Apr 18, 2012, at 4:43 PM, Jim Wright wrote: > I think custody transfer is more than a warm fuzzy, it is an important pa= rt of the store-and-forward routing in DTN. Custody transfer acknowledgemen= t allows a node to clear a stored bundle. Without that the only way to flus= h bundles from a node's storage would be through timeout. >=20 I reiterate: =20 if node accepts a bundle, isn't it going to do its best to forward it - cu= stody accepted or not?=20 If bundles are different sizes with different lifetimes and different prior= ities to different destinations, what is the proper algorithm to decide whi= ch to forward first? If C cannot contact A with Custody Accepted, but forwards A's bundle on and= the bundle reaches its final destination, A either re-forwards to another = node; or the bundle times out on A and A does not release storage. Or, A c= an release storage if needed because it knows B at least got the bundle and= "hopefully" forwarded it on.=20 Think "Disconnected Networks." Think beyond Space Networks. - Will From kscott@mitre.org Thu Apr 19 04:43:26 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 5C69C21F849B for ; Thu, 19 Apr 2012 04:43:26 -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 LL44GZbsnQpH for ; Thu, 19 Apr 2012 04:43:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF2B21F8567 for ; Thu, 19 Apr 2012 04:43:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ABBE621B148A; Thu, 19 Apr 2012 07:43:21 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A680921B1455; Thu, 19 Apr 2012 07:43:21 -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, 19 Apr 2012 07:43:21 -0400 From: "Scott, Keith L." To: "Ivancic, William D. (GRC-RHN0)" , Jim Wright Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ7Js2KDwALDFEmwJldJCKj21JahSdQAgAAFwwCAAAexgIAArh6O Date: Thu, 19 Apr 2012 11:43:21 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE1F8B21@IMCMBX01.MITRE.ORG> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> , <408DC84E-6E39-44E9-AD7D-D02BFF9C9330@nasa.gov> In-Reply-To: <408DC84E-6E39-44E9-AD7D-D02BFF9C9330@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] 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] Custody transfer specification in RFC5050 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, 19 Apr 2012 11:43:26 -0000 Will,=0A= =0A= Answers to your questions inline below.=0A= =0A= --keith=0A= ________________________________________=0A= From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] on beha= lf of Ivancic, William D. (GRC-RHN0) [william.d.ivancic@nasa.gov]=0A= Sent: Wednesday, April 18, 2012 5:10 PM=0A= To: Jim Wright=0A= Cc: dtn-interest@irtf.org=0A= Subject: Re: [dtn-interest] Custody transfer specification in RFC5050=0A= =0A= On Apr 18, 2012, at 4:43 PM, Jim Wright wrote:=0A= =0A= > I think custody transfer is more than a warm fuzzy, it is an important pa= rt of the store-and-forward routing in DTN. Custody transfer acknowledgemen= t allows a node to clear a stored bundle. Without that the only way to flus= h bundles from a node's storage would be through timeout.=0A= >=0A= =0A= I reiterate:=0A= =0A= if node accepts a bundle, isn't it going to do its best to forward it - cu= stody accepted or not?=0A= ** Certainly the node should do its best to forward the bundle, reg= ardless of whether or not it takes custody. There's no problem here, since= if the node runs out of resources and discards the bundle (of which it doe= s not have custody) OK.=0A= =0A= If bundles are different sizes with different lifetimes and different prior= ities to different destinations, what is the proper algorithm to decide whi= ch to forward first?=0A= ** This is a question about forwarding, not custody transfer, but a= valid question. First I would think that the priorities of the bundles sh= ould be taken into consideration, then (possibly) their remaining lifetimes= , sizes, etc. I can think of several heuristics that might be good, but a = thorough theoretic treatment has not (to my knowledge) been done.=0A= =0A= If C cannot contact A with Custody Accepted, but forwards A's bundle on and= the bundle reaches its final destination, A either re-forwards to another = node; or the bundle times out on A and A does not release storage. Or, A c= an release storage if needed because it knows B at least got the bundle and= "hopefully" forwarded it on.=0A= ** If I understand your example correctly, A has custody of a bundl= e which it forwarded to B and B then forwarded to C; C took custody of the = bundle and then forwarded it on to the destination, which informed node C t= hat C no longer needed to maintain custody. In the meantime, there is no w= ay for C to communicate with A so C cannot inform A that C has taken custod= y. Correct?=0A= ** If this is the case then yes, A is stuck with custody until 1) i= t gets a custody acknowledgement from C 2) the bundle times out 3) A re= transmits the bundle and somebody successfully takes custody of it from A.= =0A= =0A= Think "Disconnected Networks." Think beyond Space Networks.=0A= =0A= =0A= - Will=0A= =0A= _______________________________________________=0A= dtn-interest mailing list=0A= dtn-interest@irtf.org=0A= https://www.irtf.org/mailman/listinfo/dtn-interest=0A= From durst@mitre.org Thu Apr 19 05:09: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 60CCA21F85E3 for ; Thu, 19 Apr 2012 05:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, 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 W3kgHzFPb2ed for ; Thu, 19 Apr 2012 05:09:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0D49B21F8460 for ; Thu, 19 Apr 2012 05:09:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7C51B21B0622; Thu, 19 Apr 2012 08:09:40 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7261621B061E; Thu, 19 Apr 2012 08:09:40 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.252]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.02.0283.003; Thu, 19 Apr 2012 08:09:40 -0400 From: "Durst, Robert C." To: "Burleigh, Scott C (313B)" , Jim Wright , "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ7HVQr17KmOFEi0m4KTpFj7qpahSdQAgAAFwwCAAAQCAIAArOAA Date: Thu, 19 Apr 2012 12:09:39 +0000 Message-ID: <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.29.23.10] Content-Type: multipart/alternative; boundary="_000_7A1B9532DA609B46927331283910A4C40AE86BF6IMCMBX02MITREOR_" MIME-Version: 1.0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 19 Apr 2012 12:09:48 -0000 --_000_7A1B9532DA609B46927331283910A4C40AE86BF6IMCMBX02MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Adding to what Scott said, I'd like to follow up on the point about bundle = storage management. First, you may be interested in the following, by Fall= , Hong, and Madden: http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf Unless custody transfer is requested and has been accepted, a bundle node i= s free to recover the storage associated with a bundle at essentially any t= ime. In practice, that usually happens after it's been forwarded :). In D= TN2, there's a run-time configuration option that permits bundles to be ret= ained in storage until they time out. This is usually not set and was put = in for diagnostic purposes. However, for multicast distribution in time-di= sjoint networks, it has the beneficial effect of allowing late-joiners to a= group to acquire bundle content that is already in storage. (In the paper "Multicasting in Delay Tolerant Networks: Semantic Models and= Routing Algorithms" by Zhao, Ammar, and Zegura, ref. http://chants.cs.ucsb= .edu/2005/papers/paper-ZhaAmm.pdf, this roughly corresponds to the "Tempora= l Membership Model." In that model, the intended receivers of a multicast m= essage are those who are members of the multicast endpoint at any time duri= ng the period [t1, t2], where the bounds of the membership interval are t1= =3Dthe time of bundle generation and t2=3Dthe time of bundle expiration. I= don't believe that the DTN2 implementation fully implements this model, be= cause I believe it only delivers to current members at the time of bundle r= eceipt or future members at the time of late joining. It doesn't go back a= nd deliver to members whose time of departure from the multicast endpoint i= s later than t1. There are several options that a DTN presents in multicas= ting that are different from traditional multicasting in a connected networ= k; this paper is worth a read to either confirm existing notions or open ne= w avenues of thought.) Back to bundle storage management: If custody transfer is either not reque= sted on a bundle or not accepted by the forwarder, then (for bundles destin= ed to a singleton endpoint) typically the bundle storage is recovered after= the bundle is forwarded. If custody transfer is accepted by the forwarder= , then it promises to treat that bundle's storage more favorably than that = of non-custodial bundles. If it gets horribly congested, the forwarder is = going to dump non-custodial bundles (meaning those for which it has not acc= epted custody, irrespective of whether custody was requested on those bundl= es) before it dumps ones for which it has accepted custody. That's really = the main difference in custody transfer as far as bundle storage goes. In = your example below, B would be under no obligation to show preferential tre= atment to the bundle, because it hadn't accepted custody, while C is expect= ed to try really, really hard not to delete the bundle before it receives = a signal from some node downstream accepting custody of it. (If node C get= s blown up or crashes and loses its persistent state, there's little that c= an be done, hence the "really, really hard." The expectation is roughly th= e same as your mortgage payment...) Once custody has been accepted, the no= de is free to recover the storage. (There isn't really a custodial model for multicast DTN traffic. Susan Sym= ington, Keith Scott, and I explored some of the issues in http://www.mitre.= org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn= 't moved forward yet. We're just not there yet...) Regards, Bob Durst From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Burleigh, Scott C (313B) Sent: Wednesday, April 18, 2012 4:58 PM To: Jim Wright; Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, bu= t 5.4 applies on every transmission of a bundle including the first. I thi= nk the more general answer to your question is in the second paragraph of 5= .10: each node makes its own decision as to whether or not to take custody = of each bundle for which custodial transmission was requested. Scott ________________________________ From: dtn-interest-bounces@irtf.org [= dtn-interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wright@colo= rado.edu] Sent: Wednesday, April 18, 2012 1:43 PM To: Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 I think custody transfer is more than a warm fuzzy, it is an important part= of the store-and-forward routing in DTN. Custody transfer acknowledgement = allows a node to clear a stored bundle. Without that the only way to flush = bundles from a node's storage would be through timeout. Regarding your example, I believe this happens: Node A sends a bundle with the Custody Transfer Requested bit set, and the = Request Reporting of Custody Acceptance bit set. The bundle is sent to node= B. Node B receives the bundle and forwards it to node C, but node B does n= ot take custody of the bundle. Node C receives the bundle and accepts custo= dy. Node C looks in the dictionary to find the Custodian EID, and sends an = administrative record bundle to node A to signal custody acceptance. Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals = only with initial transmission from an application agent (getting a bundle = into the DTN), and if section 5.4 Bundle Forwarding deals with bundles alre= ady in the DTN, then my confusion is cleared up. If an application wants cu= stody transfer, and the originating node does not support that, then fail i= mmediately. I was reading 5.2 as being a required step for forwarding of bu= ndles in the network. So does this make sense and answer my question? Jim On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: I was just discussing custody transfer with a few colleagues. I haven't go= ne into RFC5050 to confirm you confusion. However, my understanding of cu= stody transfer is that if a node B accepts custody from node A, node A may = decide to clear its storage. Node B is suppose to then do its best to forw= ard the bundle. I believe node B can accept a bundle from node A without a= ccepting custody and forward on to node C which accepts custody. However, = how does node C let node A know it has custody in a meaningful way if they = are disconnected for long periods of time? In the mean time, node A would = likely NOT clear its storage until receiving an acknowledgement of custody = acceptance from some node. In reality, I think custody transfer is just a warm fuzzy good feeling for = the space operations community. In reality, if node accepts a bundle, isn= 't it going to do its best to forward it? If bundles are different sizes w= ith different lifetimes and different priorities to different destinations,= what is the proper algorithm to decide which to forward first? I would like to see an analysis regarding custody transfer. I would not be= surprised to find out that custody transfer actually results in worse perf= ormance in complex networks. If you are string network (A to B to C to D),= it is likely to be a wash. Furthermore, much depends on the routing algor= ithms used as well if if your system is multi-homed. - Will On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: I have been reading RFC5050 and specifically trying to understand the custo= dy transfer mechanism. In my reading of RFC5050, I see no provision to allo= w for a Bundle Node to receive a bundle with the Custody Transfer Request b= it set and simply forward it on, without taking custody of the bundle. It s= eems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a Bundle N= ode that receives and forwards bundles without taking custody, then where i= n RFC5050 is this specified? Thanks, Jim -- Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_7A1B9532DA609B46927331283910A4C40AE86BF6IMCMBX02MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

Adding to what Scott said= , I’d like to follow up on the point about bundle storage management.=   First, you may be interested in the following, by Fall, Hong, and Madden:  http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf

 <= /p>

Unless custody transfer i= s requested and has been accepted, a bundle node is free to recover the storage asso= ciated with a bundle at essentially any time.  In practice, that usual= ly happens after it’s been forwarded J= .  In DTN2, there’s a run-time configuration option that permits bundles to be retained in storage until they time out.  This i= s usually not set and was put in for diagnostic purposes.  However, fo= r multicast distribution in time-disjoint networks, it has the beneficial e= ffect of allowing late-joiners to a group to acquire bundle content that is already in storage.

 <= /p>

(In the paper “Mult= icasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms= ” by Zhao, Ammar, and Zegura, ref. http://c= hants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly correspond= s to the “Temporal Membership Model.” In that model, the intend= ed receivers of a multicast message are those who are members of the multicast endpoint at any time during the pe= riod [t1, t2], where the bounds of the membership interval are t1=3Dthe= time of bundle generation and t2=3Dthe time of bundle expiration.  I don’t believe that= the DTN2 implementation fully implements this model, because I believe it = only delivers to current members at the time of bundle receipt or future me= mbers at the time of late joining.  It doesn’t go back and deliver to members whose time of departure from the multicast = endpoint is later than t1.  There are several options that a DTN presents in multicast= ing that are different from traditional multicasting in a connected network= ; this paper is worth a read to either confirm existing notions or open new= avenues of thought.)

 <= /p>

Back to bundle storage ma= nagement:  If custody transfer is either not requested on a bundle or = not accepted by the forwarder, then (for bundles destined to a singleton endpoint) typically the bundle storage is recovered after the = bundle is forwarded.  If custody transfer is accepted by the forwarder, then it promises to treat that bundle&= #8217;s storage more favorably than that of non-custodial bundles.  If= it gets horribly congested, the forwarder is going to dump non-custodial b= undles (meaning those for which it has not accepted custody, irrespective of whether custody was requested on t= hose bundles) before it dumps ones for which it has accepted custody.  That’s really the main difference = in custody transfer as far as bundle storage goes.  In your example be= low, B would be under no obligation to show preferential treatment to the b= undle, because it hadn’t accepted custody, while C is expected to try really, really hard not to delete the bundle before &= nbsp;it receives a signal from some node downstream accepting custody of it= .  (If node C gets blown up or crashes and loses its persistent state,= there’s little that can be done, hence the “really, really hard.”  The expectation is roughly the sa= me as your mortgage payment…)  Once custody has been accepted, t= he node is free to recover the storage.

 <= /p>

(There isn’t really= a custodial model for multicast DTN traffic.  Susan Symington, Keith = Scott, and I explored some of the issues in http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn’t moved forward yet.  We’re just not= there yet…)

 <= /p>

Regards,
Bob Durst 

 <= /p>

From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounc= es@irtf.org] On Behalf Of Burleigh, Scott C (313B)
Sent: Wednesday, April 18, 2012 4:58 PM
To: Jim Wright; Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

 

J= im, yes, section 5.2 does pertain only to initial issuance of a bundle, but= 5.4 applies on every transmission of a bundle including the first.  I think the more general answer to your question is in the se= cond paragraph of 5.10: each node makes its own decision as to whether or n= ot to take custody of each bundle for which custodial transmission was requ= ested.

<= o:p> 

S= cott


From: dtn-interest-bounces@irtf.= org [dtn-interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wr= ight@colorado.edu]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

I think custody transfer is more than a warm fuzzy, it is an important p= art of the store-and-forward routing in DTN. Custody transfer acknowledgeme= nt allows a node to clear a stored bundle. Without that the only way to flush bundles from a node's storage would be = through timeout.

 

Regarding your example, I believe this happens:

 

Node A sends a bundle with the Custody Transfer Requested bit set, and t= he Request Reporting of Custody Acceptance bit set. The bundle is sent to n= ode B. Node B receives the bundle and forwards it to node C, but node B does not take custody of the bundle. Nod= e C receives the bundle and accepts custody. Node C looks in the dictionary= to find the Custodian EID, and sends an administrative record bundle to no= de A to signal custody acceptance.

 

 

Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission dea= ls only with initial transmission from an application agent (getting a bund= le into the DTN), and if section 5.4 Bundle Forwarding deals with bundles already in the DTN, then my confusion is cle= ared up. If an application wants custody transfer, and the originating node= does not support that, then fail immediately. I was reading 5.2 as being a= required step for forwarding of bundles in the network. So does this make sense and answer my question?

 

Jim

 

 

On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:<= /o:p>



I was just discussing custody transfer with a few colleagues.  I ha= ven't gone into RFC5050 to confirm you confusion.  However, my underst= anding of  custody transfer is that if a node B accepts custody from node A, node A may decide to clear its storage.  = ;Node B is suppose to then do its best to forward the bundle.  I belie= ve node B can accept a bundle from node A without accepting custody and for= ward on to node C which accepts custody.  However, how does node C let node A know it has custody in a meaningful way if they= are disconnected for long periods of time?  In the mean time, node A = would likely NOT clear its storage until receiving an acknowledgement of cu= stody acceptance from some node.

 

 

In reality, I think custody transfer is just a warm fuzzy good feeling f= or the space operations community.  In reality, if  node accepts = a bundle, isn't it going to do its best to forward it?  If bundles are different sizes with different lifetimes and diff= erent priorities to different destinations, what is the proper algorithm to= decide which to forward first?

 

I would like to see an analysis regarding custody transfer.  I woul= d not be surprised to find out that custody transfer actually results in wo= rse performance in complex networks.  If you are string network (A to B to C to D), it is likely to be a wash.  Fu= rthermore, much depends on the routing algorithms used as well if if your s= ystem is multi-homed.  

 

- Will

 

 

 

On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:



 

--_000_7A1B9532DA609B46927331283910A4C40AE86BF6IMCMBX02MITREOR_-- From elwynd@folly.org.uk Thu Apr 19 05:59: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 B286621F85C3 for ; Thu, 19 Apr 2012 05:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, HTML_MESSAGE=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 Toe8lTQcfNbG for ; Thu, 19 Apr 2012 05:59:43 -0700 (PDT) Received: from a.painless.aa.net.uk (auth.a.painless.aa.net.uk [IPv6:2001:8b0:0:30:230:48ff:fe72:d05c]) by ietfa.amsl.com (Postfix) with ESMTP id 805B521F8452 for ; Thu, 19 Apr 2012 05:59:41 -0700 (PDT) Received: from host172-114-static.124-81-b.business.telecomitalia.it ([81.124.114.172]) by a.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SKqxU-00074j-3J; Thu, 19 Apr 2012 13:59:36 +0100 Message-ID: <4F900C30.20301@folly.org.uk> Date: Thu, 19 Apr 2012 14:59:28 +0200 From: Elwyn Davies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Durst, Robert C." References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>, <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> In-Reply-To: <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> Content-Type: multipart/alternative; boundary="------------090308080909070701060105" Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: elwynd@folly.org.uk 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, 19 Apr 2012 12:59:48 -0000 This is a multi-part message in MIME format. --------------090308080909070701060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. I have to admit that RFC 5050 can be read as saying that if a bundle has the flag requesting custody transfer set, then a receiving node MUST take custody or reject the bundle. However: - I think that it could be that this could be read as the *initial* node having to accept custody... it isn't going to work too good if an application injects a bundle which specifies custody transfer if the initial node refuses to take custody. If nothing else this would mean that there was no initial custodian and a later node wouldn't know what to do with a custody report. Doh! - My interpretation has (more or less always) been that it is a policy decision for an intermediate node to decide whether it should accept custody, and the node could act as a forwarder *without* needing to accept custody. I have to say that I did think quite hard about this at one stage and discussed it with others. - DTN2 has a global (policy) flag that determines whether the node does custody acceptance. If this is not set, bundles will be received and stored for forwarding but without indicating that custody has been accepted. Consequently if the bundle is forwarded again to a node that *does* do custody acceptance, then that node will send a custody report back to the node that previously had custody in the way that seems natural. In line with the previous comment, it strikes me that a node should *always* offer custody to bundles that come from the client API if they have the custody transfer flag set initially. Otherwise you can't get the custody transfer process started. I don't think DTN2 handles this at the moment. However DTN2 *does* handle the case that a bundle is delivered in a node that doesn't do custody acceptance - a successful delivery sends a custody report if the bundle had requested custody transfer. Regards, Elwyn On 19/04/12 14:09, Durst, Robert C. wrote: > > Jim, > > Adding to what Scott said, I'd like to follow up on the point about > bundle storage management. First, you may be interested in the > following, by Fall, Hong, and Madden: > http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf > > Unless custody transfer is requested and /has been accepted/, a bundle > node is free to recover the storage associated with a bundle at > essentially any time. In practice, that usually happens /after/ it's > been forwarded J. In DTN2, there's a run-time configuration option > that permits bundles to be /retained/ in storage until they time out. > This is usually not set and was put in for diagnostic purposes. > However, for multicast distribution in time-disjoint networks, it has > the beneficial effect of allowing late-joiners to a group to acquire > bundle content that is already in storage. > > (In the paper "Multicasting in Delay Tolerant Networks: Semantic > Models and Routing Algorithms" by Zhao, Ammar, and Zegura, ref. > http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly > corresponds to the "Temporal Membership Model." In that model, the > intended receivers of a multicast message are those who are members of > the multicast endpoint at /any /time during the period [/t1/, /t2/], > where the bounds of the membership interval are /t1/=the time of > bundle generation and /t2/=the time of bundle expiration. I don't > believe that the DTN2 implementation fully implements this model, > because I believe it only delivers to current members at the time of > bundle receipt or future members at the time of late joining. It > doesn't go back and deliver to members whose time of departure from > the multicast endpoint is later than /t1./ There are several options > that a DTN presents in multicasting that are different from > traditional multicasting in a connected network; this paper is worth a > read to either confirm existing notions or open new avenues of thought.) > > Back to bundle storage management: If custody transfer is either not > requested on a bundle or not accepted by the forwarder, then (for > bundles destined to a singleton endpoint) typically the bundle storage > is recovered after the bundle is forwarded. If custody transfer /is/ > accepted by the forwarder, then it promises to treat that bundle's > storage more favorably than that of non-custodial bundles. If it gets > horribly congested, the forwarder is going to dump non-custodial > bundles (meaning those for which it has not /accepted/ custody, > irrespective of whether custody was requested on those bundles) before > it dumps ones for which it /has/ accepted custody. That's really the > main difference in custody transfer as far as bundle storage goes. In > your example below, B would be under no obligation to show > preferential treatment to the bundle, because it hadn't accepted > custody, while C is expected to try really, really hard not to delete > the bundle before it receives a signal from some node downstream > accepting custody of it. (If node C gets blown up or crashes and > loses its persistent state, there's little that can be done, hence the > "really, really hard." The expectation is roughly the same as your > mortgage payment...) Once custody has been accepted, the node is free > to recover the storage. > > (There isn't really a custodial model for multicast DTN traffic. > Susan Symington, Keith Scott, and I explored some of the issues in > http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, > but it really hasn't moved forward yet. We're just not there yet...) > > Regards, > Bob Durst > > *From:*dtn-interest-bounces@irtf.org > [mailto:dtn-interest-bounces@irtf.org] *On Behalf Of *Burleigh, Scott > C (313B) > *Sent:* Wednesday, April 18, 2012 4:58 PM > *To:* Jim Wright; Ivancic, William D. (GRC-RHN0) > *Cc:* dtn-interest@irtf.org > *Subject:* Re: [dtn-interest] Custody transfer specification in RFC5050 > > Jim, yes, section 5.2 does pertain only to initial issuance of a > bundle, but 5.4 applies on every transmission of a bundle including > the first. I think the more general answer to your question is in the > second paragraph of 5.10: each node makes its own decision as to > whether or not to take custody of each bundle for which custodial > transmission was requested. > > Scott > > ------------------------------------------------------------------------ > > *From:*dtn-interest-bounces@irtf.org > [dtn-interest-bounces@irtf.org] > on behalf of Jim Wright [james.r.wright@colorado.edu] > *Sent:* Wednesday, April 18, 2012 1:43 PM > *To:* Ivancic, William D. (GRC-RHN0) > *Cc:* dtn-interest@irtf.org > *Subject:* Re: [dtn-interest] Custody transfer specification in RFC5050 > > I think custody transfer is more than a warm fuzzy, it is an important > part of the store-and-forward routing in DTN. Custody transfer > acknowledgement allows a node to clear a stored bundle. Without that > the only way to flush bundles from a node's storage would be through > timeout. > > Regarding your example, I believe this happens: > > Node A sends a bundle with the Custody Transfer Requested bit set, and > the Request Reporting of Custody Acceptance bit set. The bundle is > sent to node B. Node B receives the bundle and forwards it to node C, > but node B does not take custody of the bundle. Node C receives the > bundle and accepts custody. Node C looks in the dictionary to find the > Custodian EID, and sends an administrative record bundle to node A to > signal custody acceptance. > > Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission > deals only with initial transmission from an application agent > (getting a bundle into the DTN), and if section 5.4 Bundle Forwarding > deals with bundles already in the DTN, then my confusion is cleared > up. If an application wants custody transfer, and the originating node > does not support that, then fail immediately. I was reading 5.2 as > being a required step for forwarding of bundles in the network. So > does this make sense and answer my question? > > Jim > > On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: > > > > I was just discussing custody transfer with a few colleagues. I > haven't gone into RFC5050 to confirm you confusion. However, my > understanding of custody transfer is that if a node B accepts custody > from node A, node A may decide to clear its storage. Node B is > suppose to then do its best to forward the bundle. I believe node B > can accept a bundle from node A without accepting custody and forward > on to node C which accepts custody. However, how does node C let node > A know it has custody in a meaningful way if they are disconnected for > long periods of time? In the mean time, node A would likely NOT clear > its storage until receiving an acknowledgement of custody acceptance > from some node. > > In reality, I think custody transfer is just a warm fuzzy good feeling > for the space operations community. In reality, if node accepts a > bundle, isn't it going to do its best to forward it? If bundles are > different sizes with different lifetimes and different priorities to > different destinations, what is the proper algorithm to decide which > to forward first? > > I would like to see an analysis regarding custody transfer. I would > not be surprised to find out that custody transfer actually results in > worse performance in complex networks. If you are string network (A > to B to C to D), it is likely to be a wash. Furthermore, much depends > on the routing algorithms used as well if if your system is multi-homed. > > - Will > > On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: > > > > I have been reading RFC5050 and specifically trying to understand the > custody transfer mechanism. In my reading of RFC5050, I see no > provision to allow for a Bundle Node to receive a bundle with the > Custody Transfer Request bit set and simply forward it on, without > taking custody of the bundle. It seems every Bundle Node MUST > implement custody transfer. > > Is this correct? If it is not correct, and it is allowed to have a > Bundle Node that receives and forwards bundles without taking custody, > then where in RFC5050 is this specified? > > Thanks, > > Jim > > > -- > > Jim Wright > > BioServe Space Technologies > > james.r.wright@colorado.edu > > 303-492-1579 > > _______________________________________________ > 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 --------------090308080909070701060105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi.

I have to admit that RFC 5050 can be read as saying that if a bundle has the flag requesting custody transfer set, then a receiving node MUST take custody or reject the bundle.  However:
- I think that it could be that this could be read as the *initial* node having to accept custody... it isn't going to work too good if an application injects a bundle which specifies custody transfer if the initial node refuses to take custody.  If nothing else this would mean that there was no initial custodian and a later node wouldn't know what to do with a custody report. Doh!
- My interpretation has (more or less always) been that it is a policy decision for an intermediate node to decide whether it should accept custody, and the node could act as a forwarder *without* needing to accept custody.  I have to say that I did think quite hard about this at one stage and discussed it with others. 
- DTN2 has a global (policy) flag that determines whether the node does custody acceptance.  If this is not set, bundles will be received and stored for forwarding but without indicating that custody has been accepted.  Consequently if the bundle is forwarded again to a node that *does* do custody acceptance, then that node will send a custody report back to the node that previously had custody in the way that seems natural. In line with the previous comment, it strikes me that a node should *always* offer custody to bundles that come from the client API  if they have the custody transfer flag set initially.  Otherwise you can't get the custody transfer process started.  I don't think DTN2 handles this at the moment.   However DTN2 *does* handle the case that a bundle is delivered in a node that doesn't do custody acceptance - a successful delivery sends a custody report if the bundle had requested custody transfer.

Regards,
Elwyn

On 19/04/12 14:09, Durst, Robert C. wrote:

Jim,

 

Adding to what Scott said, I’d like to follow up on the point about bundle storage management.  First, you may be interested in the following, by Fall, Hong, and Madden:  http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf

 

Unless custody transfer is requested and has been accepted, a bundle node is free to recover the storage associated with a bundle at essentially any time.  In practice, that usually happens after it’s been forwarded J.  In DTN2, there’s a run-time configuration option that permits bundles to be retained in storage until they time out.  This is usually not set and was put in for diagnostic purposes.  However, for multicast distribution in time-disjoint networks, it has the beneficial effect of allowing late-joiners to a group to acquire bundle content that is already in storage.

 

(In the paper “Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms” by Zhao, Ammar, and Zegura, ref. http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly corresponds to the “Temporal Membership Model.” In that model, the intended receivers of a multicast message are those who are members of the multicast endpoint at any time during the period [t1, t2], where the bounds of the membership interval are t1=the time of bundle generation and t2=the time of bundle expiration.  I don’t believe that the DTN2 implementation fully implements this model, because I believe it only delivers to current members at the time of bundle receipt or future members at the time of late joining.  It doesn’t go back and deliver to members whose time of departure from the multicast endpoint is later than t1.  There are several options that a DTN presents in multicasting that are different from traditional multicasting in a connected network; this paper is worth a read to either confirm existing notions or open new avenues of thought.)

 

Back to bundle storage management:  If custody transfer is either not requested on a bundle or not accepted by the forwarder, then (for bundles destined to a singleton endpoint) typically the bundle storage is recovered after the bundle is forwarded.  If custody transfer is accepted by the forwarder, then it promises to treat that bundle’s storage more favorably than that of non-custodial bundles.  If it gets horribly congested, the forwarder is going to dump non-custodial bundles (meaning those for which it has not accepted custody, irrespective of whether custody was requested on those bundles) before it dumps ones for which it has accepted custody.  That’s really the main difference in custody transfer as far as bundle storage goes.  In your example below, B would be under no obligation to show preferential treatment to the bundle, because it hadn’t accepted custody, while C is expected to try really, really hard not to delete the bundle before  it receives a signal from some node downstream accepting custody of it.  (If node C gets blown up or crashes and loses its persistent state, there’s little that can be done, hence the “really, really hard.”  The expectation is roughly the same as your mortgage payment…)  Once custody has been accepted, the node is free to recover the storage.

 

(There isn’t really a custodial model for multicast DTN traffic.  Susan Symington, Keith Scott, and I explored some of the issues in http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn’t moved forward yet.  We’re just not there yet…)

 

Regards,
Bob Durst 

 

From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B)
Sent: Wednesday, April 18, 2012 4:58 PM
To: Jim Wright; Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

 

Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, but 5.4 applies on every transmission of a bundle including the first.  I think the more general answer to your question is in the second paragraph of 5.10: each node makes its own decision as to whether or not to take custody of each bundle for which custodial transmission was requested.

 

Scott


From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wright@colorado.edu]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050

I think custody transfer is more than a warm fuzzy, it is an important part of the store-and-forward routing in DTN. Custody transfer acknowledgement allows a node to clear a stored bundle. Without that the only way to flush bundles from a node's storage would be through timeout.

 

Regarding your example, I believe this happens:

 

Node A sends a bundle with the Custody Transfer Requested bit set, and the Request Reporting of Custody Acceptance bit set. The bundle is sent to node B. Node B receives the bundle and forwards it to node C, but node B does not take custody of the bundle. Node C receives the bundle and accepts custody. Node C looks in the dictionary to find the Custodian EID, and sends an administrative record bundle to node A to signal custody acceptance.

 

 

Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals only with initial transmission from an application agent (getting a bundle into the DTN), and if section 5.4 Bundle Forwarding deals with bundles already in the DTN, then my confusion is cleared up. If an application wants custody transfer, and the originating node does not support that, then fail immediately. I was reading 5.2 as being a required step for forwarding of bundles in the network. So does this make sense and answer my question?

 

Jim

 

 

On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:



I was just discussing custody transfer with a few colleagues.  I haven't gone into RFC5050 to confirm you confusion.  However, my understanding of  custody transfer is that if a node B accepts custody from node A, node A may decide to clear its storage.  Node B is suppose to then do its best to forward the bundle.  I believe node B can accept a bundle from node A without accepting custody and forward on to node C which accepts custody.  However, how does node C let node A know it has custody in a meaningful way if they are disconnected for long periods of time?  In the mean time, node A would likely NOT clear its storage until receiving an acknowledgement of custody acceptance from some node.

 

 

In reality, I think custody transfer is just a warm fuzzy good feeling for the space operations community.  In reality, if  node accepts a bundle, isn't it going to do its best to forward it?  If bundles are different sizes with different lifetimes and different priorities to different destinations, what is the proper algorithm to decide which to forward first?

 

I would like to see an analysis regarding custody transfer.  I would not be surprised to find out that custody transfer actually results in worse performance in complex networks.  If you are string network (A to B to C to D), it is likely to be a wash.  Furthermore, much depends on the routing algorithms used as well if if your system is multi-homed.  

 

- Will

 

 

 

On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:



I have been reading RFC5050 and specifically trying to understand the custody transfer mechanism. In my reading of RFC5050, I see no provision to allow for a Bundle Node to receive a bundle with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.

 

Is this correct? If it is not correct, and it is allowed to have a Bundle Node that receives and forwards bundles without taking custody, then where in RFC5050 is this specified?

 

Thanks,

Jim

 

 


-- 

Jim Wright

BioServe Space Technologies

303-492-1579

 

_______________________________________________
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

--------------090308080909070701060105-- From lars@netapp.com Thu Apr 19 06:03:41 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 92C4521F849B; Thu, 19 Apr 2012 06:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.347 X-Spam-Level: X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=-0.547, 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 nAYsXRXW1Y8R; Thu, 19 Apr 2012 06:03:37 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9321F8496; Thu, 19 Apr 2012 06:03:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,446,1330934400"; d="p7s'?scan'208";a="642008057" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 19 Apr 2012 06:03:37 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3JD3aBm015103; Thu, 19 Apr 2012 06:03:37 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.117]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Thu, 19 Apr 2012 06:03:35 -0700 From: "Eggert, Lars" To: IESG IESG Thread-Topic: Request for RFC5742 review of draft-irtf-dtnrg-prophet-09 Thread-Index: AQHNHizUBL2wvFFWD0y2yXzsMc3whg== Date: Thu, 19 Apr 2012 13:03:34 +0000 Message-ID: <3108B397-4960-4DB4-95F7-AAEFC9177AE0@netapp.com> 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=_1B69AE93-7782-4A12-A7B5-56EB5FC454AA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "dtn-interest@irtf.org" , Internet Research Steering Group Subject: [dtn-interest] Request for RFC5742 review of draft-irtf-dtnrg-prophet-09 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, 19 Apr 2012 13:03:41 -0000 --Apple-Mail=_1B69AE93-7782-4A12-A7B5-56EB5FC454AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, IESG secretary (BCC'ed), this is a request for the IESG to perform an RFC5742 review of the = following draft from the DTNRG, to be published as an RFC on the IRTF = Stream: - draft-irtf-dtnrg-prophet-09 (Experimental RFC) The document has been approved for publication by the IRSG. See = http://wiki.tools.ietf.org/group/irtf/trac/ticket/37 for details on = prior reviews. Please copy all correspondence to the document shepherd, = Stephen Farrell (stephen.farrell@cs.tcd.ie). Thanks, Lars --Apple-Mail=_1B69AE93-7782-4A12-A7B5-56EB5FC454AA 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxOTEzMDMzNVowIwYJKoZIhvcNAQkEMRYEFLlC Z260OTq8kiRWXG5PG+/j4D5pMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAIBrgb7o 1atOw7Yjieex8RF/91upta+49CG5xQdVB52p/C1gpup9nLawmhG+AHUn0mq/ghj42QzhL6TKCaPM YxPb/7dVmRzPaTtJylOWbYwuL7EhxeM6NZJ39pAV6BZ+HYC36LNGieLSXNACiHB0iG3ZOe7FdWaM yoJ8tNld0ZPRcCu70uDVfVDn2mGKEP7KJQWSinmczaBUfR/4H4jjxomKkNJVQVVXqdCDLAKkgEUu Fc8bb2UkxV9wEM/16FtnKVv/lRKq1n94G8VOtmf3/ZytEXU7VPwJl0qeCL10DTxzhqc3XB74PD2I +YSU66i6ImjcXAfpxKfV4EVK+3jdHfwAAAAAAAA= --Apple-Mail=_1B69AE93-7782-4A12-A7B5-56EB5FC454AA-- From kfall@qualcomm.com Thu Apr 19 07:26:49 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 9A6C921F865F for ; Thu, 19 Apr 2012 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V37I0iJkxzEQ for ; Thu, 19 Apr 2012 07:26:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5199D21F8643 for ; Thu, 19 Apr 2012 07:26:45 -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=1334845605; x=1366381605; 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:mime-version; bh=P4lp8w+zz6wRsfEe7JA6NHFnPP2m7YrahG5W/UaAT8A=; b=VlSAxoCuui04IbzLfTZBaPivL+q0kfZD/i+N1zPu6a1v8P9U0EEzTFV6 IeNs8F9PqIIvpaGgQWkYfAFAyNnufXAEFQ7jCYki4bnhpqWNt634JjDoT +K0OfSzmGTAPH+x9e6Qoi8Jokcin3Mke9XyklJVgM5DImM6cbZomXAxP1 c=; X-IronPort-AV: E=McAfee;i="5400,1158,6685"; a="183127334" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 19 Apr 2012 07:26:45 -0700 X-IronPort-AV: E=Sophos;i="4.75,446,1330934400"; d="scan'208,217";a="221540047" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 19 Apr 2012 07:26:44 -0700 Received: from NASANEXD01E.na.qualcomm.com ([169.254.5.81]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.02.0283.003; Thu, 19 Apr 2012 07:26:44 -0700 From: "Fall, Kevin" To: "Durst, Robert C." , "Burleigh, Scott C (313B)" , Jim Wright , "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3bDxoD5+qD0EmJwE9y2i1LWZahfCAAgAAFxACAAAQBAIAA/s6A//+w8AA= Date: Thu, 19 Apr 2012 14:26:44 +0000 Message-ID: In-Reply-To: <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> 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: multipart/alternative; boundary="_000_CBB56E2234DA9kfallqualcommcom_" MIME-Version: 1.0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 19 Apr 2012 14:26:49 -0000 --_000_CBB56E2234DA9kfallqualcommcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I've also generally assumed that when a bundle indicates custody transfer t= hat its selected routed may be different than routes for bundles for which = custody has not been requested=85 although I'm not sure anyone has actually= implemented this. - K --_000_CBB56E2234DA9kfallqualcommcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <304DE204B34F46469716AA34E1536489@qualcomm.com> Content-Transfer-Encoding: quoted-printable
I've also generally assumed that when a bundle indicates custody trans= fer that its selected routed may be different than routes for bundles for w= hich custody has not been requested=85 although I'm not sure anyone has act= ually implemented this.
- K

--_000_CBB56E2234DA9kfallqualcommcom_-- From scott.c.burleigh@jpl.nasa.gov Fri Apr 20 09:48: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 450B621F8659 for ; Fri, 20 Apr 2012 09:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, 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 ytaRvpWCVAp1 for ; Fri, 20 Apr 2012 09:48:36 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 529A521F8656 for ; Fri, 20 Apr 2012 09:48:36 -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 q3KGmXJ9008405 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 20 Apr 2012 09:48:34 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 09:48:33 -0700 From: "Burleigh, Scott C (313B)" To: "Durst, Robert C." , Jim Wright , "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGoABdXOAgAFdcRA= Date: Fri, 20 Apr 2012 16:48:32 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>, <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> In-Reply-To: <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> 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_A5BEAD028815CB40A32A5669CF737C3B0401C4apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 20 Apr 2012 16:48:43 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B0401C4apembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, the storage management issues Bob brings up might be worth a few more = words of discussion: * It's not quite the case that the storage associated with a bundle= can be recovered at any time unless custody has been accepted. Acceptance= of custody is one of the constraints that inhibit the discarding of a bund= le (section 5.14 of the BP spec), but there are others. The bundle can't b= e discarded while dispatch is pending (i.e., while a forwarding decision is= still in progress) or while forwarding is pending (i.e., while the selecte= d convergence layer adapters have not yet informed the bundle protocol agen= t that they have concluded their data sending procedures - successfully or = unsuccessfully - with regard to this bundle) or while bundle reassembly fro= m this (fragmentary) bundle is pending. The first and third of these are p= retty obvious, but the second may be less so: retention of the bundle until= after it has been forwarded - or forwarding failure has been reported - is= n't just a good idea, it's actually required. * Extending more favorable retention treatment to a bundle for whic= h custody has been accepted is certainly consistent with the concept of cus= tody transfer as understood by DTNRG, but not as an RFC 5050 requirement. = That is, not only is retention of a bundle after all retention constraints = have been removed a discretionary feature that is implemented in DTN2, but = also the policy for selecting which of these retained bundles (retained at = the discretion of the implementation, fully in conformance with RFC 5050 bu= t not required by RFC 5050) to discard during periods of congestion is like= wise a DTN2 implementation feature. * On the other hand, discarding a bundle for which custody has been= accepted (prior to its lifetime expiration) really isn't RFC5050-compliant= unless transmission is explicitly canceled by the application or some oper= ational anomaly is encountered. I think you can define extreme congestion = to be such an anomaly, but RFC5050 doesn't do so; this is an implementation= decision. So yes, if node C gets blown up or crashes and loses persistent= state then the bundles for which it has accepted - and not yet released - = custody will get discarded. But otherwise they may well be there for the d= uration; a conformant implementation might simply stop receiving any more b= undles until storage is recovered by bundle lifetime expirations and/or exp= licit cancellation of bundle transmissions. Scott From: Durst, Robert C. [mailto:durst@mitre.org] Sent: Thursday, April 19, 2012 5:10 AM To: Burleigh, Scott C (313B); Jim Wright; Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: RE: [dtn-interest] Custody transfer specification in RFC5050 Jim, Adding to what Scott said, I'd like to follow up on the point about bundle = storage management. First, you may be interested in the following, by Fall= , Hong, and Madden: http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf Unless custody transfer is requested and has been accepted, a bundle node i= s free to recover the storage associated with a bundle at essentially any t= ime. In practice, that usually happens after it's been forwarded :). In D= TN2, there's a run-time configuration option that permits bundles to be ret= ained in storage until they time out. This is usually not set and was put = in for diagnostic purposes. However, for multicast distribution in time-di= sjoint networks, it has the beneficial effect of allowing late-joiners to a= group to acquire bundle content that is already in storage. (In the paper "Multicasting in Delay Tolerant Networks: Semantic Models and= Routing Algorithms" by Zhao, Ammar, and Zegura, ref. http://chants.cs.ucsb= .edu/2005/papers/paper-ZhaAmm.pdf, this roughly corresponds to the "Tempora= l Membership Model." In that model, the intended receivers of a multicast m= essage are those who are members of the multicast endpoint at any time duri= ng the period [t1, t2], where the bounds of the membership interval are t1= =3Dthe time of bundle generation and t2=3Dthe time of bundle expiration. I= don't believe that the DTN2 implementation fully implements this model, be= cause I believe it only delivers to current members at the time of bundle r= eceipt or future members at the time of late joining. It doesn't go back a= nd deliver to members whose time of departure from the multicast endpoint i= s later than t1. There are several options that a DTN presents in multicas= ting that are different from traditional multicasting in a connected networ= k; this paper is worth a read to either confirm existing notions or open ne= w avenues of thought.) Back to bundle storage management: If custody transfer is either not reque= sted on a bundle or not accepted by the forwarder, then (for bundles destin= ed to a singleton endpoint) typically the bundle storage is recovered after= the bundle is forwarded. If custody transfer is accepted by the forwarder= , then it promises to treat that bundle's storage more favorably than that = of non-custodial bundles. If it gets horribly congested, the forwarder is = going to dump non-custodial bundles (meaning those for which it has not acc= epted custody, irrespective of whether custody was requested on those bundl= es) before it dumps ones for which it has accepted custody. That's really = the main difference in custody transfer as far as bundle storage goes. In = your example below, B would be under no obligation to show preferential tre= atment to the bundle, because it hadn't accepted custody, while C is expect= ed to try really, really hard not to delete the bundle before it receives = a signal from some node downstream accepting custody of it. (If node C get= s blown up or crashes and loses its persistent state, there's little that c= an be done, hence the "really, really hard." The expectation is roughly th= e same as your mortgage payment...) Once custody has been accepted, the no= de is free to recover the storage. (There isn't really a custodial model for multicast DTN traffic. Susan Sym= ington, Keith Scott, and I explored some of the issues in http://www.mitre.= org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn= 't moved forward yet. We're just not there yet...) Regards, Bob Durst From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) Sent: Wednesday, April 18, 2012 4:58 PM To: Jim Wright; Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, bu= t 5.4 applies on every transmission of a bundle including the first. I thi= nk the more general answer to your question is in the second paragraph of 5= .10: each node makes its own decision as to whether or not to take custody = of each bundle for which custodial transmission was requested. Scott ________________________________ From: dtn-interest-bounces@irtf.org [= dtn-interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wright@colo= rado.edu] Sent: Wednesday, April 18, 2012 1:43 PM To: Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 I think custody transfer is more than a warm fuzzy, it is an important part= of the store-and-forward routing in DTN. Custody transfer acknowledgement = allows a node to clear a stored bundle. Without that the only way to flush = bundles from a node's storage would be through timeout. Regarding your example, I believe this happens: Node A sends a bundle with the Custody Transfer Requested bit set, and the = Request Reporting of Custody Acceptance bit set. The bundle is sent to node= B. Node B receives the bundle and forwards it to node C, but node B does n= ot take custody of the bundle. Node C receives the bundle and accepts custo= dy. Node C looks in the dictionary to find the Custodian EID, and sends an = administrative record bundle to node A to signal custody acceptance. Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals = only with initial transmission from an application agent (getting a bundle = into the DTN), and if section 5.4 Bundle Forwarding deals with bundles alre= ady in the DTN, then my confusion is cleared up. If an application wants cu= stody transfer, and the originating node does not support that, then fail i= mmediately. I was reading 5.2 as being a required step for forwarding of bu= ndles in the network. So does this make sense and answer my question? Jim On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: I was just discussing custody transfer with a few colleagues. I haven't go= ne into RFC5050 to confirm you confusion. However, my understanding of cu= stody transfer is that if a node B accepts custody from node A, node A may = decide to clear its storage. Node B is suppose to then do its best to forw= ard the bundle. I believe node B can accept a bundle from node A without a= ccepting custody and forward on to node C which accepts custody. However, = how does node C let node A know it has custody in a meaningful way if they = are disconnected for long periods of time? In the mean time, node A would = likely NOT clear its storage until receiving an acknowledgement of custody = acceptance from some node. In reality, I think custody transfer is just a warm fuzzy good feeling for = the space operations community. In reality, if node accepts a bundle, isn= 't it going to do its best to forward it? If bundles are different sizes w= ith different lifetimes and different priorities to different destinations,= what is the proper algorithm to decide which to forward first? I would like to see an analysis regarding custody transfer. I would not be= surprised to find out that custody transfer actually results in worse perf= ormance in complex networks. If you are string network (A to B to C to D),= it is likely to be a wash. Furthermore, much depends on the routing algor= ithms used as well if if your system is multi-homed. - Will On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: I have been reading RFC5050 and specifically trying to understand the custo= dy transfer mechanism. In my reading of RFC5050, I see no provision to allo= w for a Bundle Node to receive a bundle with the Custody Transfer Request b= it set and simply forward it on, without taking custody of the bundle. It s= eems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a Bundle N= ode that receives and forwards bundles without taking custody, then where i= n RFC5050 is this specified? Thanks, Jim -- Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_A5BEAD028815CB40A32A5669CF737C3B0401C4apembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, the storage manageme= nt issues Bob brings up might be worth a few more words of discussion:=

·      = ;   It’s not qu= ite the case that the storage associated with a bundle can be recovered at = any time unless custody has been accepted.  Acceptance of custody is one of the constraints that inhibit the discarding of a bundle (section= 5.14 of the BP spec), but there are others.  The bundle can’t b= e discarded while dispatch is pending (i.e., while a forwarding decision is= still in progress) or while forwarding is pending (i.e., while the selected convergence layer adapters have not yet = informed the bundle protocol agent that they have concluded their data send= ing procedures – successfully or unsuccessfully – with regard t= o this bundle) or while bundle reassembly from this (fragmentary) bundle is pending.  The first and third of these a= re pretty obvious, but the second may be less so: retention of the bundle u= ntil after it has been forwarded – or forwarding failure has been rep= orted – isn’t just a good idea, it’s actually required.

·      = ;   Extending more fa= vorable retention treatment to a bundle for which custody has been accepted= is certainly consistent with the concept of custody transfer as understood by DTNRG, but not as an RFC 5050 requirement.  That is,= not only is retention of a bundle after all retention constraints have bee= n removed a discretionary feature that is implemented in DTN2, but also the= policy for selecting which of these retained bundles (retained at the discretion of the implementation, fully = in conformance with RFC 5050 but not required by RFC 5050) to discard durin= g periods of congestion is likewise a DTN2 implementation feature.

·      = ;   On the other hand= , discarding a bundle for which custody has been accepted (prior to its lif= etime expiration) really isn’t RFC5050-compliant unless transmission is explicitly canceled by the application or some operational= anomaly is encountered.  I think you can define extreme congestion to= be such an anomaly, but RFC5050 doesn’t do so; this is an implementa= tion decision.  So yes, if node C gets blown up or crashes and loses persistent state then the bundles for which it has= accepted – and not yet released – custody will get discarded.&= nbsp; But otherwise they may well be there for the duration; a conformant i= mplementation might simply stop receiving any more bundles until storage is recovered by bundle lifetime expirations and/or e= xplicit cancellation of bundle transmissions.

 <= /p>

Scott

 <= /p>

From: Durst, R= obert C. [mailto:durst@mitre.org]
Sent: Thursday, April 19, 2012 5:10 AM
To: Burleigh, Scott C (313B); Jim Wright; Ivancic, William D. (GRC-R= HN0)
Cc: dtn-interest@irtf.org
Subject: RE: [dtn-interest] Custody transfer specification in RFC505= 0

 

Jim,

 <= /p>

Adding to what Scott said= , I’d like to follow up on the point about bundle storage management.=   First, you may be interested in the following, by Fall, Hong, and Madden:  http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf

 <= /p>

Unless custody transfer i= s requested and has been accepted, a bundle node is free to recover the storage asso= ciated with a bundle at essentially any time.  In practice, that usual= ly happens after it’s been forwarded J= .  In DTN2, there’s a run-time configuration option that permits bundles to be retained in storage until they time out.  This i= s usually not set and was put in for diagnostic purposes.  However, fo= r multicast distribution in time-disjoint networks, it has the beneficial e= ffect of allowing late-joiners to a group to acquire bundle content that is already in storage.

 <= /p>

(In the paper “Mult= icasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms= ” by Zhao, Ammar, and Zegura, ref. http://c= hants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly correspond= s to the “Temporal Membership Model.” In that model, the intend= ed receivers of a multicast message are those who are members of the multicast endpoint at any time during the pe= riod [t1, t2], where the bounds of the membership interval are t1=3Dthe= time of bundle generation and t2=3Dthe time of bundle expiration.  I don’t believe that= the DTN2 implementation fully implements this model, because I believe it = only delivers to current members at the time of bundle receipt or future me= mbers at the time of late joining.  It doesn’t go back and deliver to members whose time of departure from the multicast = endpoint is later than t1.  There are several options that a DTN presents in multicast= ing that are different from traditional multicasting in a connected network= ; this paper is worth a read to either confirm existing notions or open new= avenues of thought.)

 <= /p>

Back to bundle storage ma= nagement:  If custody transfer is either not requested on a bundle or = not accepted by the forwarder, then (for bundles destined to a singleton endpoint) typically the bundle storage is recovered after the = bundle is forwarded.  If custody transfer is accepted by the forwarder, then it promises to treat that bundle&= #8217;s storage more favorably than that of non-custodial bundles.  If= it gets horribly congested, the forwarder is going to dump non-custodial b= undles (meaning those for which it has not accepted custody, irrespective of whether custody was requested on t= hose bundles) before it dumps ones for which it has accepted custody.  That’s really the main difference = in custody transfer as far as bundle storage goes.  In your example be= low, B would be under no obligation to show preferential treatment to the b= undle, because it hadn’t accepted custody, while C is expected to try really, really hard not to delete the bundle before &= nbsp;it receives a signal from some node downstream accepting custody of it= .  (If node C gets blown up or crashes and loses its persistent state,= there’s little that can be done, hence the “really, really hard.”  The expectation is roughly the sa= me as your mortgage payment…)  Once custody has been accepted, t= he node is free to recover the storage.

 <= /p>

(There isn’t really= a custodial model for multicast DTN traffic.  Susan Symington, Keith = Scott, and I explored some of the issues in http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, but it really hasn’t moved forward yet.  We’re just not= there yet…)

 <= /p>

Regards,
Bob Durst 

 <= /p>

From: dtn-interest-bounces@irtf.= org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Sc= ott C (313B)
Sent: Wednesday, April 18, 2012 4:58 PM
To: Jim Wright; Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

 

J= im, yes, section 5.2 does pertain only to initial issuance of a bundle, but= 5.4 applies on every transmission of a bundle including the first.  I think the more general answer to your question is in the se= cond paragraph of 5.10: each node makes its own decision as to whether or n= ot to take custody of each bundle for which custodial transmission was requ= ested.

<= o:p> 

S= cott


From: dtn-interest-bounces@irtf.= org [dtn-interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wr= ight@colorado.edu]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

I think custody transfer is more than a warm fuzzy, it is an important p= art of the store-and-forward routing in DTN. Custody transfer acknowledgeme= nt allows a node to clear a stored bundle. Without that the only way to flush bundles from a node's storage would be = through timeout.

 

Regarding your example, I believe this happens:

 

Node A sends a bundle with the Custody Transfer Requested bit set, and t= he Request Reporting of Custody Acceptance bit set. The bundle is sent to n= ode B. Node B receives the bundle and forwards it to node C, but node B does not take custody of the bundle. Nod= e C receives the bundle and accepts custody. Node C looks in the dictionary= to find the Custodian EID, and sends an administrative record bundle to no= de A to signal custody acceptance.

 

 

Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission dea= ls only with initial transmission from an application agent (getting a bund= le into the DTN), and if section 5.4 Bundle Forwarding deals with bundles already in the DTN, then my confusion is cle= ared up. If an application wants custody transfer, and the originating node= does not support that, then fail immediately. I was reading 5.2 as being a= required step for forwarding of bundles in the network. So does this make sense and answer my question?

 

Jim

 

 

On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:<= /o:p>

 

I was just discussing custody transfer with a few colleagues.  I ha= ven't gone into RFC5050 to confirm you confusion.  However, my underst= anding of  custody transfer is that if a node B accepts custody from node A, node A may decide to clear its storage.  = ;Node B is suppose to then do its best to forward the bundle.  I belie= ve node B can accept a bundle from node A without accepting custody and for= ward on to node C which accepts custody.  However, how does node C let node A know it has custody in a meaningful way if they= are disconnected for long periods of time?  In the mean time, node A = would likely NOT clear its storage until receiving an acknowledgement of cu= stody acceptance from some node.

 

 

In reality, I think custody transfer is just a warm fuzzy good feeling f= or the space operations community.  In reality, if  node accepts = a bundle, isn't it going to do its best to forward it?  If bundles are different sizes with different lifetimes and diff= erent priorities to different destinations, what is the proper algorithm to= decide which to forward first?

 

I would like to see an analysis regarding custody transfer.  I woul= d not be surprised to find out that custody transfer actually results in wo= rse performance in complex networks.  If you are string network (A to B to C to D), it is likely to be a wash.  Fu= rthermore, much depends on the routing algorithms used as well if if your s= ystem is multi-homed.  

 

- Will

 

 

 

On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:

 

 

--_000_A5BEAD028815CB40A32A5669CF737C3B0401C4apembxsp40RESADJP_-- From bill@immerman-inc.com Fri Apr 20 11:37:02 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 B493E11E80C2 for ; Fri, 20 Apr 2012 11:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, FM_FORGED_GMAIL=0.622] 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 pJN+63qtWujG for ; Fri, 20 Apr 2012 11:37:01 -0700 (PDT) Received: from outbound003.roc2.bluetie.com (outbound003.roc2.bluetie.com [208.89.132.143]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC911E80A5 for ; Fri, 20 Apr 2012 11:37:00 -0700 (PDT) Received: from emta001.roc2.bluetie.com ([10.200.2.131]) by outbound003.roc2.bluetie.com with bizsmtp id 0Jcz1j00C2pbusy01Jczpz; Fri, 20 Apr 2012 14:36:59 -0400 X-CMAE-OUT-Analysis: v=2.0 cv=K7+g7lqI c=1 sm=1 a=TMOnIMl2GRoA:10 a=dvGUPGJ3whYA:10 a=8rnNb4UG2toA:10 a=8nJEP1OIZ-IA:10 a=sMBj6sIwAAAA:8 a=YlDpyLmHAAAA:8 a=v-b4H_r_AAAA:8 a=zWc4U4XLAAAA:8 a=EegMxSVKsFEYeyN00UMA:9 a=icJ0mxfrMWJMLuj2cSoA:7 a=wPNLvfGTeEIA:10 a=Xbp_WQAVk_wA:10 a=3iK1i4ecmUoA:10 a=WZiKUSCcF5cA:10 a=kf-3vNJK3vJSdTtk:21 a=mRp0sL6v2Z1bbmql:21 a=rANQrBm0nlgJGMq7J4Ei9A==:117 X-CMAE-OUT-Score: 0.00 Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) (Authenticated sender: bill@immerman-inc.com) by emta001.roc2.bluetie.com (Postfix) with ESMTP id 45E0393019E for ; Fri, 20 Apr 2012 14:36:59 -0400 (EDT) Received: by bkcjc3 with SMTP id jc3so10120350bkc.13 for ; Fri, 20 Apr 2012 11:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.10.92 with SMTP id o28mr725778bko.31.1334947017775; Fri, 20 Apr 2012 11:36:57 -0700 (PDT) Received: by 10.205.112.134 with HTTP; Fri, 20 Apr 2012 11:36:57 -0700 (PDT) In-Reply-To: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> Date: Fri, 20 Apr 2012 14:36:57 -0400 Message-ID: From: Bill Immerman To: "Burleigh, Scott C (313B)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bill@immerman-inc.com 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, 20 Apr 2012 18:37:02 -0000 I'm sure I'm missing something, and the discussion of storage management in custody transfer is very interesting wrt implementation issues, but in terms of the original comment about custody transfer being about getting a "warm and fuzzy" and whether the node will "do its best to forward anyway" isn't connection opportunity at least as significant a resource in DTN as storage, and isn't the point of custody transfer to move the chains forward when that opportunity exists? I would think that at least as significant a reason to transfer custody would be the reverse (acknowledgement) traffic: if I transfer custody when an opportunity exists, downstream the receiving node should only have to acknowledge to a node that is closer and more likely to be available than the node that transferred custody. I would guess that typically the node granting custody might be more likely to be able to receive acknowledgement shortly after transmitting the bundle, but in the worst case might be unable for some substantial time after becoming disconnected to be reached for acknowledgement. Maybe forever. Am I misunderstanding what a correctly implemented custody transfer would accomplish? Thanks, Bill Immerman On 4/20/12, Burleigh, Scott C (313B) wrote: > Jim, the storage management issues Bob brings up might be worth a few more > words of discussion: > > * It's not quite the case that the storage associated with a bundle > can be recovered at any time unless custody has been accepted. Acceptance > of custody is one of the constraints that inhibit the discarding of a bundle > (section 5.14 of the BP spec), but there are others. The bundle can't be > discarded while dispatch is pending (i.e., while a forwarding decision is > still in progress) or while forwarding is pending (i.e., while the selected > convergence layer adapters have not yet informed the bundle protocol agent > that they have concluded their data sending procedures - successfully or > unsuccessfully - with regard to this bundle) or while bundle reassembly from > this (fragmentary) bundle is pending. The first and third of these are > pretty obvious, but the second may be less so: retention of the bundle until > after it has been forwarded - or forwarding failure has been reported - > isn't just a good idea, it's actually required. > > * Extending more favorable retention treatment to a bundle for which > custody has been accepted is certainly consistent with the concept of > custody transfer as understood by DTNRG, but not as an RFC 5050 requirement. > That is, not only is retention of a bundle after all retention constraints > have been removed a discretionary feature that is implemented in DTN2, but > also the policy for selecting which of these retained bundles (retained at > the discretion of the implementation, fully in conformance with RFC 5050 but > not required by RFC 5050) to discard during periods of congestion is > likewise a DTN2 implementation feature. > > * On the other hand, discarding a bundle for which custody has been > accepted (prior to its lifetime expiration) really isn't RFC5050-compliant > unless transmission is explicitly canceled by the application or some > operational anomaly is encountered. I think you can define extreme > congestion to be such an anomaly, but RFC5050 doesn't do so; this is an > implementation decision. So yes, if node C gets blown up or crashes and > loses persistent state then the bundles for which it has accepted - and not > yet released - custody will get discarded. But otherwise they may well be > there for the duration; a conformant implementation might simply stop > receiving any more bundles until storage is recovered by bundle lifetime > expirations and/or explicit cancellation of bundle transmissions. > > Scott > > From: Durst, Robert C. [mailto:durst@mitre.org] > Sent: Thursday, April 19, 2012 5:10 AM > To: Burleigh, Scott C (313B); Jim Wright; Ivancic, William D. (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: RE: [dtn-interest] Custody transfer specification in RFC5050 > > Jim, > > Adding to what Scott said, I'd like to follow up on the point about bundle > storage management. First, you may be interested in the following, by Fall, > Hong, and Madden: http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf > > Unless custody transfer is requested and has been accepted, a bundle node is > free to recover the storage associated with a bundle at essentially any > time. In practice, that usually happens after it's been forwarded :). In > DTN2, there's a run-time configuration option that permits bundles to be > retained in storage until they time out. This is usually not set and was > put in for diagnostic purposes. However, for multicast distribution in > time-disjoint networks, it has the beneficial effect of allowing > late-joiners to a group to acquire bundle content that is already in > storage. > > (In the paper "Multicasting in Delay Tolerant Networks: Semantic Models and > Routing Algorithms" by Zhao, Ammar, and Zegura, ref. > http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly > corresponds to the "Temporal Membership Model." In that model, the intended > receivers of a multicast message are those who are members of the multicast > endpoint at any time during the period [t1, t2], where the bounds of the > membership interval are t1=the time of bundle generation and t2=the time of > bundle expiration. I don't believe that the DTN2 implementation fully > implements this model, because I believe it only delivers to current members > at the time of bundle receipt or future members at the time of late joining. > It doesn't go back and deliver to members whose time of departure from the > multicast endpoint is later than t1. There are several options that a DTN > presents in multicasting that are different from traditional multicasting in > a connected network; this paper is worth a read to either confirm existing > notions or open new avenues of thought.) > > Back to bundle storage management: If custody transfer is either not > requested on a bundle or not accepted by the forwarder, then (for bundles > destined to a singleton endpoint) typically the bundle storage is recovered > after the bundle is forwarded. If custody transfer is accepted by the > forwarder, then it promises to treat that bundle's storage more favorably > than that of non-custodial bundles. If it gets horribly congested, the > forwarder is going to dump non-custodial bundles (meaning those for which it > has not accepted custody, irrespective of whether custody was requested on > those bundles) before it dumps ones for which it has accepted custody. > That's really the main difference in custody transfer as far as bundle > storage goes. In your example below, B would be under no obligation to show > preferential treatment to the bundle, because it hadn't accepted custody, > while C is expected to try really, really hard not to delete the bundle > before it receives a signal from some node downstream accepting custody of > it. (If node C gets blown up or crashes and loses its persistent state, > there's little that can be done, hence the "really, really hard." The > expectation is roughly the same as your mortgage payment...) Once custody > has been accepted, the node is free to recover the storage. > > (There isn't really a custodial model for multicast DTN traffic. Susan > Symington, Keith Scott, and I explored some of the issues in > http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.pdf, > but it really hasn't moved forward yet. We're just not there yet...) > > Regards, > Bob Durst > > From: dtn-interest-bounces@irtf.org > [mailto:dtn-interest-bounces@irtf.org] > On Behalf Of Burleigh, Scott C (313B) > Sent: Wednesday, April 18, 2012 4:58 PM > To: Jim Wright; Ivancic, William D. (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 > > Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, but > 5.4 applies on every transmission of a bundle including the first. I think > the more general answer to your question is in the second paragraph of 5.10: > each node makes its own decision as to whether or not to take custody of > each bundle for which custodial transmission was requested. > > Scott > ________________________________ > From: dtn-interest-bounces@irtf.org > [dtn-interest-bounces@irtf.org] on behalf of Jim Wright > [james.r.wright@colorado.edu] > Sent: Wednesday, April 18, 2012 1:43 PM > To: Ivancic, William D. (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 > I think custody transfer is more than a warm fuzzy, it is an important part > of the store-and-forward routing in DTN. Custody transfer acknowledgement > allows a node to clear a stored bundle. Without that the only way to flush > bundles from a node's storage would be through timeout. > > Regarding your example, I believe this happens: > > Node A sends a bundle with the Custody Transfer Requested bit set, and the > Request Reporting of Custody Acceptance bit set. The bundle is sent to node > B. Node B receives the bundle and forwards it to node C, but node B does not > take custody of the bundle. Node C receives the bundle and accepts custody. > Node C looks in the dictionary to find the Custodian EID, and sends an > administrative record bundle to node A to signal custody acceptance. > > > Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals > only with initial transmission from an application agent (getting a bundle > into the DTN), and if section 5.4 Bundle Forwarding deals with bundles > already in the DTN, then my confusion is cleared up. If an application wants > custody transfer, and the originating node does not support that, then fail > immediately. I was reading 5.2 as being a required step for forwarding of > bundles in the network. So does this make sense and answer my question? > > Jim > > > On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: > > I was just discussing custody transfer with a few colleagues. I haven't > gone into RFC5050 to confirm you confusion. However, my understanding of > custody transfer is that if a node B accepts custody from node A, node A may > decide to clear its storage. Node B is suppose to then do its best to > forward the bundle. I believe node B can accept a bundle from node A > without accepting custody and forward on to node C which accepts custody. > However, how does node C let node A know it has custody in a meaningful way > if they are disconnected for long periods of time? In the mean time, node A > would likely NOT clear its storage until receiving an acknowledgement of > custody acceptance from some node. > > > In reality, I think custody transfer is just a warm fuzzy good feeling for > the space operations community. In reality, if node accepts a bundle, > isn't it going to do its best to forward it? If bundles are different sizes > with different lifetimes and different priorities to different destinations, > what is the proper algorithm to decide which to forward first? > > I would like to see an analysis regarding custody transfer. I would not be > surprised to find out that custody transfer actually results in worse > performance in complex networks. If you are string network (A to B to C to > D), it is likely to be a wash. Furthermore, much depends on the routing > algorithms used as well if if your system is multi-homed. > > - Will > > > > On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: > > I have been reading RFC5050 and specifically trying to understand the > custody transfer mechanism. In my reading of RFC5050, I see no provision to > allow for a Bundle Node to receive a bundle with the Custody Transfer > Request bit set and simply forward it on, without taking custody of the > bundle. It seems every Bundle Node MUST implement custody transfer. > > Is this correct? If it is not correct, and it is allowed to have a Bundle > Node that receives and forwards bundles without taking custody, then where > in RFC5050 is this specified? > > Thanks, > Jim > > > > -- > Jim Wright > BioServe Space Technologies > james.r.wright@colorado.edu > 303-492-1579 > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > > From william.d.ivancic@nasa.gov Fri Apr 20 12:29:26 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 11D2611E8085 for ; Fri, 20 Apr 2012 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.183, 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 tY9m97TXeavK for ; Fri, 20 Apr 2012 12:29:25 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8E11E8079 for ; Fri, 20 Apr 2012 12:29:24 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 2D1C6108840; Fri, 20 Apr 2012 14:29:24 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3KJTNTs022025; Fri, 20 Apr 2012 14:29:24 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Fri, 20 Apr 2012 14:29:23 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "bill@immerman-inc.com" Date: Fri, 20 Apr 2012 14:29:22 -0500 Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: Ac0fK+P4zWHvd9sBRny7PksLJ1eKcg== Message-ID: <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-20_06:2012-04-20, 2012-04-20, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 20 Apr 2012 19:29:26 -0000 On Apr 20, 2012, at 2:36 PM, Bill Immerman wrote: > I'm sure I'm missing something, and the discussion of storage > management in custody transfer is very interesting wrt implementation > issues, > but in terms of the original comment about custody transfer > being about getting a "warm and fuzzy" and whether the node will "do > its best to forward anyway" Yes that was sort of my question. Actually, all the implementations I have= seen WILL do its best to forward a bundle if received. Custody just provi= des a priority of some sort (implementation dependent) - not that it has b= een fully tested in any or all implementations. > isn't connection opportunity at least as > significant a resource in DTN as storage, Most likely depends on the deployment scenario. But, yes, connection opport= unity is something to consider. You may know it a-priori as with contract = graph routing (as least you sort of know), or you may not have much clue as= with opportunistic totally random, or you may have some clue via past hist= ory build up (Prophet) > and isn't the point of > custody transfer to move the chains forward when that opportunity > exists? Sort of, but maybe not when the first opportunity exists. For example, wha= t if I have a bundle with no custody but has 1 day to live and I have anoth= er bundle with custody that has 1 YEAR to live? You may decide to forward = the custody bundle first and then the Non-custody bundle dies. Hence my or= iginal question. Does custody transfer really help? Or perhaps hurt? or pe= rhaps a wash (in which case you have expended a lot of energy for no gain)? > I would think that at least as significant a reason to > transfer custody would be the reverse (acknowledgement) traffic: I think in CCSDS CFDP, custody sort of was as much an Ack that the File was= receive by Node B from Node A and Node A could release if from memory. Wi= th DTN it is a little more abstracted. The interface between the Bundling = Agent and convergence layer Ack that the bundle was fully or partially rece= ived (DTN2 does reactive fragmentation in the TCP convergence layer). This= Ack is NOT tthe same a accepting custody. Node B can the forward to Node = C which accepts Custody and (if at all possible) notifies A (and perhaps t= hat notification goes through a different path entirely). http://public.ccsds.org/publications/archive/727x0b4.pdf See section 2.3.4 and 2.4 Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very clos= ely matching the transport part of CFDP. (Interestingly, if I read it correctly, CFDP allows one to receive part of = a file and begin moving it forward. DTN, particularly with security or CRC= checks does not really lend itself to such.) > if I > transfer custody when an opportunity exists, downstream the receiving > node should only have to acknowledge to a node that is closer and more > likely to be available than the node that transferred custody. Careful - "closer" assumes a particular topology, and/or what does "closer"= mean? The node that accepted custody has to notify the node that requested releas= e of custody (granted custody). Otherwise, the requesting release of custo= dy has no clue that the bundle was successfully transmitted AND received AN= D accepted. I'm not sure that is what you stated above. > I would > guess that typically the node granting custody might be more likely to > be able to receive acknowledgement shortly after transmitting the > bundle, but in the worst case might be unable for some substantial > time after becoming disconnected to be reached for acknowledgement. > Maybe forever. Correct. - Will= From scott.c.burleigh@jpl.nasa.gov Fri Apr 20 12:31:39 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 0E04321F85E1 for ; Fri, 20 Apr 2012 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FB_YOUR_MORTGAGE=2.128, 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 YM5bCMrnAzn2 for ; Fri, 20 Apr 2012 12:31:37 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 56A9921F85DD for ; Fri, 20 Apr 2012 12:31:37 -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 q3KJVW98021438 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 20 Apr 2012 12:31:32 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 12:31:32 -0700 From: "Burleigh, Scott C (313B)" To: "bill@immerman-inc.com" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGoABdXOAgAFdcRCAAKEagP//jT0w Date: Fri, 20 Apr 2012 19:31:31 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> 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: 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@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 20 Apr 2012 19:31:39 -0000 There are a few cases in which a node cannot arbitrarily ignore a request t= o take custody: - If the attempt to forward a bundle fails, and custody transfer was reques= ted for the bundle, then transmission of a Failed custody signal back to th= e current custodian is mandatory. - If custody of a previously received copy of the same bundle has already b= een taken, then transmission of a Failed custody signal back to the current= custodian is mandatory. - When a bundle for which custody transfer is requested is delivered to its= destination endpoint, transmission of a Succeeded custody signal back to t= he current custodian is mandatory. But otherwise the node is free to decide whether or not to attempt to take = custody. Deciding not to attempt to take custody does not cause any signal to go bac= k to the current custodian. There is no signal for actively "rejecting" cu= stody at whim; instead, the node just silently proceeds with forwarding the= bundle. This leaves the current custodian in the dark, forced to retain i= ts copy of the bundle at least until the bundle reaches the next node in th= e path. If the node decides that it will attempt to take custody, then a custody si= gnal is always going to be returned, indicating either that the attempt Suc= ceeded or that it Failed for some reason such as insufficient storage space= . This gives the current custodian an opportunity to act, potentially enab= ling recovery of storage one way or another. So I think you've got it right, Bill: when a node decides not to attempt to= take custody of a bundle for which custody transfer is requested, it alway= s does the current custodian a small disservice. There may be good reasons= to make such a decision, but there are also consequences. Scott -----Original Message----- From: Bill Immerman [mailto:bill@immerman-inc.com]=20 Sent: Friday, April 20, 2012 11:37 AM To: Burleigh, Scott C (313B) Cc: Durst, Robert C.; Jim Wright; Ivancic, William D. (GRC-RHN0); dtn-inter= est@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 I'm sure I'm missing something, and the discussion of storage management in= custody transfer is very interesting wrt implementation issues, but in ter= ms of the original comment about custody transfer being about getting a "wa= rm and fuzzy" and whether the node will "do its best to forward anyway" isn= 't connection opportunity at least as significant a resource in DTN as stor= age, and isn't the point of custody transfer to move the chains forward whe= n that opportunity exists? I would think that at least as significant a rea= son to transfer custody would be the reverse (acknowledgement) traffic: if = I transfer custody when an opportunity exists, downstream the receiving nod= e should only have to acknowledge to a node that is closer and more likely = to be available than the node that transferred custody. I would guess that = typically the node granting custody might be more likely to be able to rece= ive acknowledgement shortly after transmitting the bundle, but in the worst= case might be unable for some substantial time after becoming disconnected= to be reached for acknowledgement. Maybe forever. Am I misunderstanding what a correctly implemented custody transfer would a= ccomplish? Thanks, Bill Immerman On 4/20/12, Burleigh, Scott C (313B) wrote: > Jim, the storage management issues Bob brings up might be worth a few=20 > more words of discussion: > > * It's not quite the case that the storage associated with a bund= le > can be recovered at any time unless custody has been accepted. =20 > Acceptance of custody is one of the constraints that inhibit the=20 > discarding of a bundle (section 5.14 of the BP spec), but there are=20 > others. The bundle can't be discarded while dispatch is pending=20 > (i.e., while a forwarding decision is still in progress) or while=20 > forwarding is pending (i.e., while the selected convergence layer=20 > adapters have not yet informed the bundle protocol agent that they=20 > have concluded their data sending procedures - successfully or=20 > unsuccessfully - with regard to this bundle) or while bundle=20 > reassembly from this (fragmentary) bundle is pending. The first and=20 > third of these are pretty obvious, but the second may be less so:=20 > retention of the bundle until after it has been forwarded - or forwarding= failure has been reported - isn't just a good idea, it's actually required= . > > * Extending more favorable retention treatment to a bundle for wh= ich > custody has been accepted is certainly consistent with the concept of=20 > custody transfer as understood by DTNRG, but not as an RFC 5050 requireme= nt. > That is, not only is retention of a bundle after all retention=20 > constraints have been removed a discretionary feature that is=20 > implemented in DTN2, but also the policy for selecting which of these=20 > retained bundles (retained at the discretion of the implementation,=20 > fully in conformance with RFC 5050 but not required by RFC 5050) to=20 > discard during periods of congestion is likewise a DTN2 implementation fe= ature. > > * On the other hand, discarding a bundle for which custody has be= en > accepted (prior to its lifetime expiration) really isn't=20 > RFC5050-compliant unless transmission is explicitly canceled by the=20 > application or some operational anomaly is encountered. I think you=20 > can define extreme congestion to be such an anomaly, but RFC5050=20 > doesn't do so; this is an implementation decision. So yes, if node C=20 > gets blown up or crashes and loses persistent state then the bundles=20 > for which it has accepted - and not yet released - custody will get=20 > discarded. But otherwise they may well be there for the duration; a=20 > conformant implementation might simply stop receiving any more bundles=20 > until storage is recovered by bundle lifetime expirations and/or explicit= cancellation of bundle transmissions. > > Scott > > From: Durst, Robert C. [mailto:durst@mitre.org] > Sent: Thursday, April 19, 2012 5:10 AM > To: Burleigh, Scott C (313B); Jim Wright; Ivancic, William D.=20 > (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: RE: [dtn-interest] Custody transfer specification in RFC5050 > > Jim, > > Adding to what Scott said, I'd like to follow up on the point about=20 > bundle storage management. First, you may be interested in the=20 > following, by Fall, Hong, and Madden: =20 > http://www.dtnrg.org/docs/papers/custody-xfer-tr.pdf > > Unless custody transfer is requested and has been accepted, a bundle=20 > node is free to recover the storage associated with a bundle at=20 > essentially any time. In practice, that usually happens after it's=20 > been forwarded :). In DTN2, there's a run-time configuration option=20 > that permits bundles to be retained in storage until they time out. =20 > This is usually not set and was put in for diagnostic purposes. =20 > However, for multicast distribution in time-disjoint networks, it has=20 > the beneficial effect of allowing late-joiners to a group to acquire=20 > bundle content that is already in storage. > > (In the paper "Multicasting in Delay Tolerant Networks: Semantic=20 > Models and Routing Algorithms" by Zhao, Ammar, and Zegura, ref. > http://chants.cs.ucsb.edu/2005/papers/paper-ZhaAmm.pdf, this roughly=20 > corresponds to the "Temporal Membership Model." In that model, the=20 > intended receivers of a multicast message are those who are members of=20 > the multicast endpoint at any time during the period [t1, t2], where=20 > the bounds of the membership interval are t1=3Dthe time of bundle=20 > generation and t2=3Dthe time of bundle expiration. I don't believe that= =20 > the DTN2 implementation fully implements this model, because I believe=20 > it only delivers to current members at the time of bundle receipt or futu= re members at the time of late joining. > It doesn't go back and deliver to members whose time of departure=20 > from the multicast endpoint is later than t1. There are several=20 > options that a DTN presents in multicasting that are different from=20 > traditional multicasting in a connected network; this paper is worth a=20 > read to either confirm existing notions or open new avenues of=20 > thought.) > > Back to bundle storage management: If custody transfer is either not=20 > requested on a bundle or not accepted by the forwarder, then (for=20 > bundles destined to a singleton endpoint) typically the bundle storage=20 > is recovered after the bundle is forwarded. If custody transfer is=20 > accepted by the forwarder, then it promises to treat that bundle's=20 > storage more favorably than that of non-custodial bundles. If it gets=20 > horribly congested, the forwarder is going to dump non-custodial=20 > bundles (meaning those for which it has not accepted custody,=20 > irrespective of whether custody was requested on those bundles) before it= dumps ones for which it has accepted custody. > That's really the main difference in custody transfer as far as bundle=20 > storage goes. In your example below, B would be under no obligation=20 > to show preferential treatment to the bundle, because it hadn't=20 > accepted custody, while C is expected to try really, really hard not=20 > to delete the bundle before it receives a signal from some node=20 > downstream accepting custody of it. (If node C gets blown up or=20 > crashes and loses its persistent state, there's little that can be=20 > done, hence the "really, really hard." The expectation is roughly the=20 > same as your mortgage payment...) Once custody has been accepted, the no= de is free to recover the storage. > > (There isn't really a custodial model for multicast DTN traffic. =20 > Susan Symington, Keith Scott, and I explored some of the issues in=20 > http://www.mitre.org/work/tech_papers/tech_papers_07/06_1000/06_1000.p > df, but it really hasn't moved forward yet. We're just not there=20 > yet...) > > Regards, > Bob Durst > > From:=20 > dtn-interest-bounces@irtf.org > [mailto:dtn-interest-bounces@irtf.org] nces@irtf.org]> > On Behalf Of Burleigh, Scott C (313B) > Sent: Wednesday, April 18, 2012 4:58 PM > To: Jim Wright; Ivancic, William D. (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 > > Jim, yes, section 5.2 does pertain only to initial issuance of a=20 > bundle, but > 5.4 applies on every transmission of a bundle including the first. I=20 > think the more general answer to your question is in the second paragraph= of 5.10: > each node makes its own decision as to whether or not to take custody=20 > of each bundle for which custodial transmission was requested. > > Scott > ________________________________ > From:=20 > dtn-interest-bounces@irtf.org > [dtn-interest-bounces@irtf.org] on behalf of Jim Wright=20 > [james.r.wright@colorado.edu] > Sent: Wednesday, April 18, 2012 1:43 PM > To: Ivancic, William D. (GRC-RHN0) > Cc: dtn-interest@irtf.org > Subject: Re: [dtn-interest] Custody transfer specification in RFC5050=20 > I think custody transfer is more than a warm fuzzy, it is an important=20 > part of the store-and-forward routing in DTN. Custody transfer=20 > acknowledgement allows a node to clear a stored bundle. Without that=20 > the only way to flush bundles from a node's storage would be through time= out. > > Regarding your example, I believe this happens: > > Node A sends a bundle with the Custody Transfer Requested bit set, and=20 > the Request Reporting of Custody Acceptance bit set. The bundle is=20 > sent to node B. Node B receives the bundle and forwards it to node C,=20 > but node B does not take custody of the bundle. Node C receives the bundl= e and accepts custody. > Node C looks in the dictionary to find the Custodian EID, and sends an=20 > administrative record bundle to node A to signal custody acceptance. > > > Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission=20 > deals only with initial transmission from an application agent=20 > (getting a bundle into the DTN), and if section 5.4 Bundle Forwarding=20 > deals with bundles already in the DTN, then my confusion is cleared=20 > up. If an application wants custody transfer, and the originating node=20 > does not support that, then fail immediately. I was reading 5.2 as=20 > being a required step for forwarding of bundles in the network. So does t= his make sense and answer my question? > > Jim > > > On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: > > I was just discussing custody transfer with a few colleagues. I=20 > haven't gone into RFC5050 to confirm you confusion. However, my=20 > understanding of custody transfer is that if a node B accepts custody=20 > from node A, node A may decide to clear its storage. Node B is=20 > suppose to then do its best to forward the bundle. I believe node B=20 > can accept a bundle from node A without accepting custody and forward on = to node C which accepts custody. > However, how does node C let node A know it has custody in a=20 > meaningful way if they are disconnected for long periods of time? In=20 > the mean time, node A would likely NOT clear its storage until=20 > receiving an acknowledgement of custody acceptance from some node. > > > In reality, I think custody transfer is just a warm fuzzy good feeling=20 > for the space operations community. In reality, if node accepts a=20 > bundle, isn't it going to do its best to forward it? If bundles are=20 > different sizes with different lifetimes and different priorities to=20 > different destinations, what is the proper algorithm to decide which to f= orward first? > > I would like to see an analysis regarding custody transfer. I would=20 > not be surprised to find out that custody transfer actually results in=20 > worse performance in complex networks. If you are string network (A=20 > to B to C to D), it is likely to be a wash. Furthermore, much depends=20 > on the routing algorithms used as well if if your system is multi-homed. > > - Will > > > > On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: > > I have been reading RFC5050 and specifically trying to understand the=20 > custody transfer mechanism. In my reading of RFC5050, I see no=20 > provision to allow for a Bundle Node to receive a bundle with the=20 > Custody Transfer Request bit set and simply forward it on, without=20 > taking custody of the bundle. It seems every Bundle Node MUST implement c= ustody transfer. > > Is this correct? If it is not correct, and it is allowed to have a=20 > Bundle Node that receives and forwards bundles without taking custody,=20 > then where in RFC5050 is this specified? > > Thanks, > Jim > > > > -- > Jim Wright > BioServe Space Technologies > james.r.wright@colorado.edu > 303-492-1579 > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > > From eric.dot.travis@gmail.com Fri Apr 20 20:39:42 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 4508911E809B for ; Fri, 20 Apr 2012 20:39:42 -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 SzudnkxErCsJ for ; Fri, 20 Apr 2012 20:39:37 -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 6620C11E8099 for ; Fri, 20 Apr 2012 20:39:37 -0700 (PDT) Received: by vbmv11 with SMTP id v11so9601699vbm.13 for ; Fri, 20 Apr 2012 20:39:36 -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=LN/0pT37oUUq9X2+D5jt8JJpWzv9WyEITPG1UUnbiUs=; b=DX7wwHDtiLikG/y+XX0lzbHEDRA127F34WBOC/XS5y3m8HF3fDVeg5m7o6F/KBQoIl P6nCaQH/VsUhr4Uq4NlCbUdb4AzulF1Nd5spsKIhjHV5SD18Ljh82P+72nla16kBs69O pYaXN0ZEdAs6gIbaCUZiX6lfcYyfGxZlilVC4eE/SFw74pnHO+ogSK6gIaOSPLcutiRx SW+LvGFxladB+PmtZQwzI44Z2r9H3Ju5wOUsJes0XsA+KYX4n1s2Ov6udKXhlfuvNvnu 0UrjkANMFMohBygcCP4Igf3q2ryHrgWI/zmpxCBACo+8zJRYTihl3WcYhEX5zHPc4m6c A0YA== MIME-Version: 1.0 Received: by 10.52.91.231 with SMTP id ch7mr6368931vdb.20.1334979576441; Fri, 20 Apr 2012 20:39:36 -0700 (PDT) Received: by 10.52.35.137 with HTTP; Fri, 20 Apr 2012 20:39:36 -0700 (PDT) In-Reply-To: <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> Date: Fri, 20 Apr 2012 23:39:36 -0400 Message-ID: From: Eric Travis To: "Ivancic, William D. (GRC-RHN0)" Content-Type: multipart/alternative; boundary=20cf307c9e146fad3804be2827cc Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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: Sat, 21 Apr 2012 03:39:42 -0000 --20cf307c9e146fad3804be2827cc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Will, An interesting discussion. I have some notes/comments that included inline below: Eric >> but in terms of the original comment about custody transfer >> being about getting a "warm and fuzzy" and whether the node will "do >> its best to forward anyway" > > Yes that was sort of my question. Actually, all the implementations I have > seen WILL do its best to forward a bundle if received. Custody just > provides a priority of some sort (implementation dependent) - not that i= t > has been fully tested in any or all implementations. *Your judgement of the utility of custody seems to be predicated on the following assumptions: 1. All the implementations you have seen reflect the *minimum* functionality specified in RFC 5050. (The implementations are an accurate reflection of *all* possible compliant implementations) 2. No convergence layer implementation will *ever* indicate a forwarding failure because it will keep trying over multiple contact opportunities until it is successful (a bad assumption for multitude reasons) 3. Should the convergence layer actually report a forwarding failure, a non-custodial bundle *will* be forwarded again at a later time. I trust your experience here but my concerns are based on the current specification (only the contents of the RFC)=85 I'm confident that the implementations you are familiar with implement a *superset* of RFC 5050; That's not a bad thing, but it should not shape your expectations of the behavior of *all* RFC-compliant implementations. You should only depend on the (minimum) functionality and policies identified in the RFC. I don't believe that (2) is - or can be - a requirement of all convergence layers. Similarly, I don't believe that (3) is required by RFC 5050. In fact from my interpretation of RFC 5050, (5.4.2, Step 2) dictates that a non-custodial bundle MUST be *deleted* in response to a forwarding failure indication. I suppose the "get out of jail" card for this would be an implementation policy invoked in (5.4.1, Step 1) that maps a convergence layer failure to "try again" rather than "forwarding failure". Or, I can be misinterpreting the text. Regardless: At best, RFC 5050 allows for a forwarding node to be *arbitrarily* persistent in forwarding non-custodial bundles. It is custodial service that *will* get you the persistence in delivery service that you are implying/expecting above.* >> isn't connection opportunity at least as >> significant a resource in DTN as storage, > > Most likely depends on the deployment scenario. But, yes, connection > opportunity is something to consider. You may know it a-priori as with > contract graph routing (as least you sort of know), or you may not have much > clue as with opportunistic totally random, or you may have some clue via > past history build up (Prophet) > > >> and isn't the point of >> custody transfer to move the chains forward when that opportunity >> exists? > > Sort of, but maybe not when the first opportunity exists. For example, what > if I have a bundle with no custody but has 1 day to live and I have another > bundle with custody that has 1 YEAR to live? You may decide to forward the > custody bundle first and then the Non-custody bundle dies. Hence my > original question. Does custody transfer really help? Or perhaps hurt? o= r > perhaps a wash (in which case you have expended a lot of energy for no > gain)? *It all depends on policy, but if I risk making an assumption, it would be that bundles marked for custodial handling are considered to be more valuable/higher priority than non-custodial bundles. For example, an unremarkable hourly temperature sample could be sourced as non-custodial and an indication that somebody just stole the rover's hubcaps would likely be sent custodial. Custodial operation has the same potential downsides as a priority mechanism, it can be abused to the point of being harmful - but that is a failure of policy rather than mechanism. I can't help but think you are generally skeptical about the utility of a custody transfer mechanism for bundle operations. I'd like to try and help you to change your mind... Consider the strawman A->B->C->D network with the following mapping: A =3D=3D rover or sensor located on a distant rock B =3D=3D polar orbiter in proximity of same distant rock C =3D=3D dedicated communications relay satellite for distant rock activities D =3D=3D terrestrial Deep Space Network (aggregate node) Here, for at least some of the bundles sourced on the distant rock, custody transfer makes perfect sense. The custody of the bundle is transferred to successively more capable, less vulnerable entities. Retransmission of the bundle (should it be necessary) is off-loaded from the most "expensive" hops and also closes the reliability feedback look more quickly. Custody transfer also makes sense for bundles flowing in the reverse direction for the same reasons. Custody transfer decisions will always be policy decisions. To me, the scenario above is a gimmee. For more arbitrary cases, I'd have to fall back to using terminology and concepts that didn't make the leap from IPN -> DTN - but the original idea was custody would transfer to more capable and/or advantaged intermediate nodes. "Capable" and "advantaged" are terms defined according to the network and its value system (read: it is all about the policy).* > > >> I would think that at least as significant a reason to >> transfer custody would be the reverse (acknowledgement) traffic: > > I think in CCSDS CFDP, custody sort of was as much an Ack that the File was > receive by Node B from Node A and Node A could release if from memory. With > DTN it is a little more abstracted. The interface between the Bundling > Agent and convergence layer Ack that the bundle was fully or partially > received (DTN2 does reactive fragmentation in the TCP convergence layer). > This Ack is NOT tthe same a accepting custody. Node B can the forward to > Node C which accepts Custody and (if at all possible) notifies A (and > perhaps that notification goes through a different path entirely). > > http://public.ccsds.org/publications/archive/727x0b4.pdf > See section 2.3.4 and 2.4 > Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very > closely matching the transport part of CFDP. > (Interestingly, if I read it correctly, CFDP allows one to receive part of a > file and begin moving it forward. DTN, particularly with security or CRC > checks does not really lend itself to such.) > > >> if I >> transfer custody when an opportunity exists, downstream the receiving >> node should only have to acknowledge to a node that is closer and more >> likely to be available than the node that transferred custody. > > Careful - "closer" assumes a particular topology, and/or what does "closer" > mean? *Substitute "closer" for "more advantaged" and see above :) Note, at least for space networks of the foreseeable future I believe the concept of "closer" used above will be easy to handle in policy definition.= * > The node that accepted custody has to notify the node that requested release > of custody (granted custody). Otherwise, the requesting release of custody > has no clue that the bundle was successfully transmitted AND received AND > accepted. I'm not sure that is what you stated above. *Assuming (I know, I know...) there exists a rational mechanism for determining an expected custody transfer time (countdown?), this should not present any real issue - especially in networks where connectivity episodes (even N-hops from the source/custodian) are highly predictable. * > >> I would >> guess that typically the node granting custody might be more likely to >> be able to receive acknowledgement shortly after transmitting the >> bundle, but in the worst case might be unable for some substantial >> time after becoming disconnected to be reached for acknowledgement. >> Maybe forever. > > Correct. > > > - Will > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > --20cf307c9e146fad3804be2827cc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Will,

An interesting discussion.=A0

I have some notes/c= omments that included inline below:

Eric


>> but in = terms of the original comment about custody transfer
>> being abou= t getting a "warm and fuzzy" and whether the node will "do >> its best to forward anyway"
>
> Yes that was sort= of my question. =A0Actually, all the implementations I have
> seen W= ILL do its best to forward a bundle if received. =A0Custody just
> pr= ovides a priority of some sort (implementation dependent) - not that =A0it<= br> > has been fully tested in any or all implementations.

Your= judgement of the utility of custody seems to be predicated on the followin= g assumptions:

=A0 1. =A0All the implementations you have seen refl= ect the *minimum* functionality specified in RFC 5050. (The implementations= are an accurate reflection of *all* possible compliant implementations)
=A0 2. =A0No convergence layer implementation will *ever* indicate a f= orwarding failure because it will keep trying over multiple contact opportu= nities until it is successful (a bad assumption for multitude reasons)
<= br> =A0 3. Should the convergence layer actually report a forwarding failure, = a non-custodial bundle *will* be forwarded again at a later time.

I = trust your experience here but my concerns are based on the current specifi= cation (only the contents of the RFC)=85

I'm confident that the implementations you are familiar with implem= ent a *superset* of RFC 5050; =A0That's not a bad thing, but it should = not shape your expectations of the behavior of *all* RFC-compliant implemen= tations. =A0You should only depend on the (minimum) functionality and polic= ies identified in the RFC.

I don't believe that (2) is - or can be - a requirement of all conv= ergence layers.
Similarly, I don't believe that (3) is required by R= FC 5050.

In fact from my interpretation of RFC 5050, (5.4.2, Step 2= ) dictates that a non-custodial bundle MUST be *deleted* in response to a f= orwarding failure indication. =A0I suppose the "get out of jail" = card for this would be an implementation policy invoked in (5.4.1, Step 1) = that maps a convergence layer failure to "try again" rather than = "forwarding failure".=A0 Or, I can be misinterpreting the text.= =A0 Regardless:

At best, RFC 5050 allows for a forwarding node to be *arbitrarily* pers= istent in forwarding non-custodial bundles. =A0



It is custod= ial service that *will* get you the persistence in delivery service that yo= u are implying/expecting above.



>> isn't connection opportunity at least as
>> s= ignificant a resource in DTN as storage,
>
> Most likely depend= s on the deployment scenario. But, yes, connection
> opportunity is s= omething to consider. =A0You may know it a-priori as with
> contract graph routing (as least you sort of know), or you may not hav= e much
> clue as with opportunistic totally random, or you may have s= ome clue via
> past history build up (Prophet)
>
>
>> and isn't the point of
>> custody transfer to move th= e chains forward when that opportunity
>> exists?
>
> = Sort of, but maybe not when the first opportunity exists. =A0For example, w= hat
> if I have a bundle with no custody but has 1 day to live and I have an= other
> bundle with custody that has 1 YEAR to live? =A0You may decid= e to forward the
> custody bundle first and then the Non-custody bund= le dies. =A0Hence my
> original question. =A0Does custody transfer really help? Or perhaps hu= rt? or
> perhaps a wash (in which case you have expended a lot of ene= rgy for no
> gain)?

It all depends on policy, but if I r= isk making an assumption, it would be that bundles marked for custodial han= dling are considered to be more valuable/higher priority than non-custodial= bundles. For example, an unremarkable hourly temperature sample could be s= ourced as non-custodial and an indication that somebody just stole the rove= r's hubcaps would likely be sent custodial.

Custodial operation has the same potential downsides as a priority mech= anism, it can be abused to the point of being harmful - but that is a failu= re of policy rather than mechanism.

I can't help but think you a= re generally skeptical about the utility of a custody transfer mechanism fo= r bundle operations. =A0I'd like to try and help you to change your min= d...

Consider the strawman A->B->C->D network with the following ma= pping:

=A0 =A0 A =3D=3D rover or sensor located on a distant rock =A0 =A0 B =3D=3D polar orbiter in proximity of same distant rock
=A0= =A0 C =3D=3D dedicated communications relay satellite for distant rock act= ivities
=A0 =A0 D =3D=3D terrestrial Deep Space Network (aggregate node)

He= re, for at least some of the bundles sourced on the distant rock, custody t= ransfer makes perfect sense. =A0The custody of the bundle is transferred to= successively more capable, less vulnerable entities. =A0Retransmission of = the bundle (should it be necessary) is off-loaded from the most "expen= sive" hops and also closes the reliability feedback look more quickly.=

Custody transfer also makes sense for bundles flowing in the reverse di= rection for the same reasons.

Custody transfer decisions will always= be policy decisions. =A0To me, the scenario above is a gimmee. =A0For more= arbitrary cases, I'd have to fall back to using terminology and concep= ts that didn't make the leap from IPN -> DTN - but the original idea= was custody would transfer to more capable and/or advantaged intermediate = nodes. =A0"Capable" and "advantaged" are terms defined = according to the network and its value system (read: it is all about the po= licy).


>
>
>> I would think that at least as significant a r= eason to
>> transfer custody would be the reverse (acknowledgement= ) traffic:
>
> I think in CCSDS CFDP, custody sort of was as mu= ch an Ack that the File was
> receive by Node B from Node A and Node A could release if from memory.= =A0With
> DTN it is a little more abstracted. =A0The interface betwe= en the Bundling
> Agent and convergence layer Ack that the bundle was= fully or partially
> received (DTN2 does reactive fragmentation in the TCP convergence laye= r).
> This Ack is NOT tthe same a accepting custody. =A0Node B can t= he forward to
> Node C which accepts Custody and (if at all possible)= notifies A =A0(and
> perhaps that notification goes through a different path entirely).
= >
> http://public.ccsds.org/publications/archive/727x0b4.pdf
>= See section 2.3.4 and 2.4
> Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very=
> closely matching the transport part of CFDP.
> (Interestingl= y, if I read it correctly, CFDP allows one to receive part of a
> fil= e and begin moving it forward. =A0DTN, particularly with security or CRC > checks does not really lend itself to such.)
>
>
>&g= t; if I
>> transfer custody when an opportunity exists, downstream= the receiving
>> node should only have to acknowledge to a node t= hat is closer and more
>> likely to be available than the node that transferred custody.
= >
> Careful - "closer" assumes a particular topology, an= d/or what does "closer"
> mean?

Substitute &qu= ot;closer" for "more advantaged" and see above :)

Note, at least for space networks of the foreseeable future I believe t= he concept of "closer" used above will be easy to handle in polic= y definition.



> The node that accepted custody has to= notify the node that requested release
> of custody (granted custody). =A0Otherwise, the requesting release of = custody
> has no clue that the bundle was successfully transmitted AN= D received AND
> accepted. =A0I'm not sure that is what you state= d above.

Assuming (I know, I know...) there exists a rational mechanism fo= r determining an expected custody transfer time (countdown?), this should n= ot present any real issue - especially in networks where connectivity episo= des (even N-hops from the source/custodian) are highly predictable.


>
>> I would
>> guess that typically t= he node granting custody might be more likely to
>> be able to rec= eive acknowledgement shortly after transmitting the
>> bundle, but= in the worst case might be unable for some substantial
>> time after becoming disconnected to be reached for acknowledgement= .
>> Maybe forever.
>
> Correct.
>
>
&g= t; - Will
> _______________________________________________
> d= tn-interest mailing list
> dtn-interest@irtf.org
= > https:/= /www.irtf.org/mailman/listinfo/dtn-interest
>
--20cf307c9e146fad3804be2827cc-- From scott.c.burleigh@jpl.nasa.gov Sun Apr 22 08:11:21 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 F023721F85E6 for ; Sun, 22 Apr 2012 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.710, 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 Z70uzHlA6Oym for ; Sun, 22 Apr 2012 08:11:19 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id E97FA21F85D6 for ; Sun, 22 Apr 2012 08:11:18 -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 q3MFBEAx023694 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sun, 22 Apr 2012 08:11:15 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 08:11:14 -0700 From: "Burleigh, Scott C (313B)" To: "Ivancic, William D. (GRC-RHN0)" , "bill@immerman-inc.com" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGoABdXOAgAFdcRCAAKEagIAADqUAgAJZnKA= Date: Sun, 22 Apr 2012 15:11:14 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> In-Reply-To: <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.113] 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@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 22 Apr 2012 15:11:21 -0000 Will, a couple more thoughts along the lines of Eric's comments. Scott -----Original Message----- From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Friday, April 20, 2012 12:29 PM To: bill@immerman-inc.com Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 On Apr 20, 2012, at 2:36 PM, Bill Immerman wrote: > I'm sure I'm missing something, and the discussion of storage=20 > management in custody transfer is very interesting wrt implementation=20 > issues, but in terms of the original comment about custody transfer being= =20 > about getting a "warm and fuzzy" and whether the node will "do its=20 > best to forward anyway" Yes that was sort of my question. Actually, all the implementations I have= seen WILL do its best to forward a bundle if received. Custody just provi= des a priority of some sort (implementation dependent) - not that it has b= een fully tested in any or all implementations. ----- Not priority, really; the custody procedures are mainly rules restric= ting the node's authorization to discard a bundle for which custody has bee= n accepted (leaving up to the implementation the decision on just how those= rules will be accommodated). And actually I think those procedures have b= een fully tested in several implementations. > isn't connection opportunity at least as significant a resource in DTN=20 > as storage, Most likely depends on the deployment scenario. But, yes, connection opport= unity is something to consider. You may know it a-priori as with contract = graph routing (as least you sort of know), or you may not have much clue as= with opportunistic totally random, or you may have some clue via past hist= ory build up (Prophet) ----- I don't think it's really so dependent on the deployment scenario: if= a node under-utilizes its transmission and reception opportunities then it= is simply underperforming, regardless of how it becomes aware of those opp= ortunities. > and isn't the point of > custody transfer to move the chains forward when that opportunity=20 > exists? Sort of, but maybe not when the first opportunity exists. For example, wha= t if I have a bundle with no custody but has 1 day to live and I have anoth= er bundle with custody that has 1 YEAR to live? You may decide to forward = the custody bundle first and then the Non-custody bundle dies. Hence my or= iginal question. Does custody transfer really help? Or perhaps hurt? or pe= rhaps a wash (in which case you have expended a lot of energy for no gain)? ----- This is a fair question, worth studying. Custody transfer is an oper= ational option like any other; it's not magic, it doesn't guarantee deliver= y success, but it forces some behavior that can confer some advantage. On = the other hand, it imposes some cost and there are other ways to obtain som= e of the advantage it confers. It might be good to see some serious resear= ch here, starting with a definition of the exact metrics on which we'd meas= ure the degree to which custody transfer "helps" or "hurts". > I would think that at least as significant a reason to transfer=20 > custody would be the reverse (acknowledgement) traffic: I think in CCSDS CFDP, custody sort of was as much an Ack that the File was= receive by Node B from Node A and Node A could release if from memory. Wi= th DTN it is a little more abstracted. The interface between the Bundling = Agent and convergence layer Ack that the bundle was fully or partially rece= ived (DTN2 does reactive fragmentation in the TCP convergence layer). This= Ack is NOT tthe same a accepting custody. Node B can the forward to Node = C which accepts Custody and (if at all possible) notifies A (and perhaps t= hat notification goes through a different path entirely). http://public.ccsds.org/publications/archive/727x0b4.pdf See section 2.3.4 and 2.4 Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very clos= ely matching the transport part of CFDP. (Interestingly, if I read it correctly, CFDP allows one to receive part of = a file and begin moving it forward. DTN, particularly with security or CRC= checks does not really lend itself to such.) ----- Not really a problem, I think. Basic "class 2" CFDP doesn't support = this incremental forwarding, only the rarely implemented Extended Procedure= s do. But DTN provides this capability quite easily: if you use DTN as the= "UT layer" underlying CFDP then you wrap each CFDP file data PDU in its ow= n Bundle, and from that point on all of these different portions of the fil= e travel independently through the network until the file is reassembled at= the final destination. > if I > transfer custody when an opportunity exists, downstream the receiving=20 > node should only have to acknowledge to a node that is closer and more=20 > likely to be available than the node that transferred custody. Careful - "closer" assumes a particular topology, and/or what does "closer"= mean? ----- I think "closer" has a clear topology-independent meaning here, thoug= h: it simply means fewer hops along the path, right? The node that accepted custody has to notify the node that requested releas= e of custody (granted custody). Otherwise, the requesting release of custo= dy has no clue that the bundle was successfully transmitted AND received AN= D accepted. I'm not sure that is what you stated above. ----- Which I think is the cost that Bill was alluding to: the less promptl= y some downstream node formally accepts custody of the bundle, the longer t= he custodian has to devote resources to it. > I would > guess that typically the node granting custody might be more likely to=20 > be able to receive acknowledgement shortly after transmitting the=20 > bundle, but in the worst case might be unable for some substantial=20 > time after becoming disconnected to be reached for acknowledgement. > Maybe forever. Correct. - Will _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest From william.d.ivancic@nasa.gov Mon Apr 23 05:54:57 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 CAE6B21F8633 for ; Mon, 23 Apr 2012 05:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 s2+CQOL2xQfc for ; Mon, 23 Apr 2012 05:54:56 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1685121F84EC for ; Mon, 23 Apr 2012 05:54:56 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 3A92826047F; Mon, 23 Apr 2012 07:54:55 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NCsstf004602; Mon, 23 Apr 2012 07:54:55 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 23 Apr 2012 07:54:55 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "Burleigh, Scott C" Date: Mon, 23 Apr 2012 07:55:08 -0500 Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: Ac0hUEeZi17TT3exT82Fbu54R64FbQ== Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-23_02:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 23 Apr 2012 12:54:58 -0000 >=20 >> I would think that at least as significant a reason to transfer=20 >> custody would be the reverse (acknowledgement) traffic: >=20 > I think in CCSDS CFDP, custody sort of was as much an Ack that the File w= as receive by Node B from Node A and Node A could release if from memory. = With DTN it is a little more abstracted. The interface between the Bundlin= g Agent and convergence layer Ack that the bundle was fully or partially re= ceived (DTN2 does reactive fragmentation in the TCP convergence layer). Th= is Ack is NOT tthe same a accepting custody. Node B can the forward to Nod= e C which accepts Custody and (if at all possible) notifies A (and perhaps= that notification goes through a different path entirely). >=20 > http://public.ccsds.org/publications/archive/727x0b4.pdf > See section 2.3.4 and 2.4 > Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very cl= osely matching the transport part of CFDP. > (Interestingly, if I read it correctly, CFDP allows one to receive part o= f a file and begin moving it forward. DTN, particularly with security or C= RC checks does not really lend itself to such.) >=20 > ----- Not really a problem, I think. Basic "class 2" CFDP doesn't suppor= t this incremental forwarding, only the rarely implemented Extended Procedu= res do. But DTN provides this capability quite easily: if you use DTN as t= he "UT layer" underlying CFDP then you wrap each CFDP file data PDU in its = own Bundle, and from that point on all of these different portions of the f= ile travel independently through the network until the file is reassembled = at the final destination. Care must be taken that bundle forward tables don't explode. Consider 3 mu= lti-Gbyte files from 3 going from 3 different sources to 3 different destin= ations. If you break those down into small bundles - say 64 Kbtyes - and t= hen add stuff like BAB, you may find your bundle tables are unmanagable. A= lso, you will be ACKing each small bundle which may congest the back channe= l. - No free lunch. >=20 >> if I >> transfer custody when an opportunity exists, downstream the receiving=20 >> node should only have to acknowledge to a node that is closer and more=20 >> likely to be available than the node that transferred custody. >=20 > Careful - "closer" assumes a particular topology, and/or what does "close= r" mean? >=20 > ----- I think "closer" has a clear topology-independent meaning here, tho= ugh: it simply means fewer hops along the path, right? >=20 I think so. But in a DTN, less hops may not be better. =20 - Will From scott.c.burleigh@jpl.nasa.gov Mon Apr 23 07:51:02 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 5301121F85DB for ; Mon, 23 Apr 2012 07:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=0.532, 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 tLO1t85+C5HX for ; Mon, 23 Apr 2012 07:50:55 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3459D21F84A0 for ; Mon, 23 Apr 2012 07:50:53 -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 q3NEonQE032258 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 23 Apr 2012 07:50:50 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.238]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 07:50:49 -0700 From: "Burleigh, Scott C (313B)" To: "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGoABdXOAgAFdcRCAAKEagIAADqUAgAJZnKCAAe89AP//p/gw Date: Mon, 23 Apr 2012 14:50:48 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <7A1B9532DA609B46927331283910A4C40AE86BF6@IMCMBX02.MITRE.ORG> <31F94597-5F68-49E5-BE66-E9A2EC320510@nasa.gov> 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: 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@irtf.org" Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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, 23 Apr 2012 14:51:02 -0000 Will, of course you're right, resource management is one of the most challe= nging aspects of DTN, maybe in some ways the most challenging. But you can= design for it, and if you are careful about configuration you can do quite= a lot even with limited memory and storage. In the specific case of CFDP over DTN, you're again correct that splitting = multi-gigabyte files into 64-Kbyte file data segments will result in a whol= e lot of bundles to manage and -- if you're using custody transfer -- a who= le lot of acknowledgment traffic. Nobody was thinking about multi-gigabyte= files back when CFDP was designed, and CCSDS is now beginning the process = of revisiting and upgrading CFDP to address this requirement and several ot= hers that have emerged over the past few years. The limit on CFDP file dat= a segment size will likely increase by many binary orders of magnitude. Scott -----Original Message----- From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]=20 Sent: Monday, April 23, 2012 5:55 AM To: Burleigh, Scott C (313B) Cc: bill@immerman-inc.com; dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 >=20 >> I would think that at least as significant a reason to transfer=20 >> custody would be the reverse (acknowledgement) traffic: >=20 > I think in CCSDS CFDP, custody sort of was as much an Ack that the File w= as receive by Node B from Node A and Node A could release if from memory. = With DTN it is a little more abstracted. The interface between the Bundlin= g Agent and convergence layer Ack that the bundle was fully or partially re= ceived (DTN2 does reactive fragmentation in the TCP convergence layer). Th= is Ack is NOT tthe same a accepting custody. Node B can the forward to Nod= e C which accepts Custody and (if at all possible) notifies A (and perhaps= that notification goes through a different path entirely). >=20 > http://public.ccsds.org/publications/archive/727x0b4.pdf > See section 2.3.4 and 2.4 > Remember DTN RFC5050 has heritage in CFDP with Liklider Transport very cl= osely matching the transport part of CFDP. > (Interestingly, if I read it correctly, CFDP allows one to receive=20 > part of a file and begin moving it forward. DTN, particularly with=20 > security or CRC checks does not really lend itself to such.) >=20 > ----- Not really a problem, I think. Basic "class 2" CFDP doesn't suppor= t this incremental forwarding, only the rarely implemented Extended Procedu= res do. But DTN provides this capability quite easily: if you use DTN as t= he "UT layer" underlying CFDP then you wrap each CFDP file data PDU in its = own Bundle, and from that point on all of these different portions of the f= ile travel independently through the network until the file is reassembled = at the final destination. Care must be taken that bundle forward tables don't explode. Consider 3 mu= lti-Gbyte files from 3 going from 3 different sources to 3 different destin= ations. If you break those down into small bundles - say 64 Kbtyes - and t= hen add stuff like BAB, you may find your bundle tables are unmanagable. A= lso, you will be ACKing each small bundle which may congest the back channe= l. - No free lunch. From william.d.ivancic@nasa.gov Mon Apr 23 08:01: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 AA21821F85B9 for ; Mon, 23 Apr 2012 08:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145, 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 cEAoNiQWaKCE for ; Mon, 23 Apr 2012 08:01:40 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9D821F846A for ; Mon, 23 Apr 2012 08:01:39 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id BE12732869F for ; Mon, 23 Apr 2012 10:01:38 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NF1ch4029910 for ; Mon, 23 Apr 2012 10:01:38 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 23 Apr 2012 10:01:38 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: "dtn-interest@irtf.org" Date: Mon, 23 Apr 2012 10:01:36 -0500 Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0A== Message-ID: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_18DC5255BE5F4579952EEDF4D8E48063nasagov_" 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-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Subject: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:01:40 -0000 --_000_18DC5255BE5F4579952EEDF4D8E48063nasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro * Why BP-Tables 2. IP-Tables * What does IP-tables do 3. BP-Tables * What is different * What is similar * What it should do * What it can do 4. Items of interest * URI vs. identity * URI vs. application/service * How do we identify application/service 5. ICMP -> BCMP * Status replies 6. Network management and BP-Tables 7. Security Section * BAB, PIB, and PCB key distribution - Will --_000_18DC5255BE5F4579952EEDF4D8E48063nasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A small team at NASA = Glenn Research Center is looking at implementing the equivalent of IP-Table= s for Store-Carry-and-Forward  (Disconnected) Networking
The following are some rough notes from our kickoff brainstormi= ng session.  Anyone who has some ideas on what they might like to see,= we would love to hear from you.  

We plan to= put together an internet draft document some of our thoughts.  
=

A couple of things that sort of stood out:
*  We probably need something like ICMP (BCMP) to return = status (with every node listening for this service
* It really wo= uld be nice to have services/applications separate from URI 
* A more consistant/uniform naming scheme would be very useful
*= It would be useful to be able to filer on something like organization (get= s into a lot of mixing of Security/keys with identity verification)



Filtering on:
Size
Source URI
Destination URI
Lifetime (TTL) (limi= t acceptance of bundle based on time). 
Hop Count (???)
Service (application =3D= =3D IP port) (how to determine???)

Should service be separate from URI?  (n= ot currently possible in RFC 5050)
Key to deployment is Identity-based, not addr= ess-based - So do we need PIB to implement?
In RFC5050 - there is no addressing.=   IP-tables are address-based.
Allocate resources (size, etc.) by URI.
Bundling = needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?)
IP-Tables ca= n filter on all fields, BP-Tables (should it also do equivalent?)
BP-Tables= may help manage resource allocation for quality of service (50% "bulk" bun= dles, 50% "scheduled service" for example).

=
= ID BP-Tables
  1. Intro
    • Why BP-Tables
    <= li style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-= left: 0px; font: normal normal normal 12px/normal Helvetica; ">IP-Tables
    • What = does IP-tables do
  2. BP-Tables
    • What is different
    • What is similar
    • What it should do
    • What it can do
    • <= /ul>
    • Items o= f interest
      • URI vs. identity
      • URI vs. application/service
      • How do we identify application/servi= ce
    • ICMP -> BCMP
      • Status replies
    • Network management and BP-Tables
    • Security Section
      • BAB, P= IB, and PCB key distribution

- Will=
= --_000_18DC5255BE5F4579952EEDF4D8E48063nasagov_-- From marc.blanchet@viagenie.ca Mon Apr 23 08:35:20 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 A7F0F21F86A2 for ; Mon, 23 Apr 2012 08:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cs6PagPomIMz for ; Mon, 23 Apr 2012 08:35:20 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C48A221F85E4 for ; Mon, 23 Apr 2012 08:35:19 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 06BF440064; Mon, 23 Apr 2012 11:35:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_6039CCEC-E9C6-4F70-99E1-A49D02FF46D4" From: Marc Blanchet In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> Date: Mon, 23 Apr 2012 11:35:17 -0400 Message-Id: <8CF3CAE1-5EEA-4BFF-B82C-3F3651D87D40@viagenie.ca> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> To: "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1257) Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:35:20 -0000 --Apple-Mail=_6039CCEC-E9C6-4F70-99E1-A49D02FF46D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 - good idea! - you should look at draft-blanchet-dtnrg-bp-app-framework as a way to = identify service id in a normalized way. Marc. Le 2012-04-23 =E0 11:01, Ivancic, William D. (GRC-RHN0) a =E9crit : > A small team at NASA Glenn Research Center is looking at implementing = the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) = Networking >=20 > The following are some rough notes from our kickoff brainstorming = session. Anyone who has some ideas on what they might like to see, we = would love to hear from you. =20 >=20 > We plan to put together an internet draft document some of our = thoughts. =20 >=20 > A couple of things that sort of stood out: >=20 > * We probably need something like ICMP (BCMP) to return status (with = every node listening for this service > * It really would be nice to have services/applications separate from = URI=20 > * A more consistant/uniform naming scheme would be very useful > * It would be useful to be able to filer on something like = organization (gets into a lot of mixing of Security/keys with identity = verification) >=20 >=20 >=20 > Filtering on: > Size > Source URI > Destination URI > Lifetime (TTL) (limit acceptance of bundle based on time).=20 > Hop Count (???) > Service (application =3D=3D IP port) (how to determine???) >=20 > Should service be separate from URI? (not currently possible in RFC = 5050) > Key to deployment is Identity-based, not address-based - So do we need = PIB to implement? > In RFC5050 - there is no addressing. IP-tables are address-based. > Allocate resources (size, etc.) by URI. > Bundling needs the equivalent of IP-ICMP. (Bundle Control Message = Protocol?) > IP-Tables can filter on all fields, BP-Tables (should it also do = equivalent?) > BP-Tables may help manage resource allocation for quality of service = (50% "bulk" bundles, 50% "scheduled service" for example). >=20 >=20 > ID BP-Tables > Intro > Why BP-Tables > IP-Tables > What does IP-tables do > BP-Tables > What is different > What is similar > What it should do > What it can do > Items of interest > URI vs. identity > URI vs. application/service > How do we identify application/service > ICMP -> BCMP > Status replies > Network management and BP-Tables > Security Section > BAB, PIB, and PCB key distribution >=20 > - Will > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest --Apple-Mail=_6039CCEC-E9C6-4F70-99E1-A49D02FF46D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
A small team at = NASA Glenn Research Center is looking at implementing the equivalent of = IP-Tables for Store-Carry-and-Forward  (Disconnected) = Networking

The following are some rough notes = from our kickoff brainstorming session.  Anyone who has some ideas = on what they might like to see, we would love to hear from you. =  

We plan to put together an internet = draft document some of our thoughts.  

A = couple of things that sort of stood out:

* =  We probably need something like ICMP (BCMP) to return status (with = every node listening for this service
* It really would be = nice to have services/applications separate from URI 
* A = more consistant/uniform naming scheme would be very useful
* = It would be useful to be able to filer on something like organization = (gets into a lot of mixing of Security/keys with identity = verification)



Filtering = on:
Source URI
Destination URI
Hop Count (???)
Service (application =3D=3D = IP port) (how to determine???)

Should service be separate = from URI?  (not currently possible in RFC 5050)
In RFC5050 - there is no addressing.  = IP-tables are address-based.
Allocate resources (size, etc.) = by URI.
Bundling needs the equivalent of IP-ICMP. = (Bundle Control Message Protocol?)
IP-Tables can filter on all = fields, BP-Tables (should it also do equivalent?)


ID = BP-Tables
  1. Why BP-Tables
  2. IP-Tables
    • BP-Tables
      • What is similar
      • What it should do
      • Items of interest
        • URI vs. application/service
        • ICMP -> = BCMP
          • Status replies
        • Network management and = BP-Tables
        • Security Section
          • BAB, PIB, and PCB key = distribution

- = Will
_______________________________________________
dtn-int= erest mailing list
dtn-interest@irtf.org
https:/= /www.irtf.org/mailman/listinfo/dtn-interest

= --Apple-Mail=_6039CCEC-E9C6-4F70-99E1-A49D02FF46D4-- From simon.perreault@viagenie.ca Mon Apr 23 08:42:31 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 E2D5D21F870B for ; Mon, 23 Apr 2012 08:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 I-vGc0nGeAGH for ; Mon, 23 Apr 2012 08:42:30 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D7CEA21F870F for ; Mon, 23 Apr 2012 08:42:27 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:1466:2a58:f88d:fd6e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EDE6D40064 for ; Mon, 23 Apr 2012 11:42:26 -0400 (EDT) Message-ID: <4F957862.6020702@viagenie.ca> Date: Mon, 23 Apr 2012 11:42:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: dtn-interest@irtf.org References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:42:31 -0000 On 2012-04-23 11:01, Ivancic, William D. (GRC-RHN0) wrote: > A small team at NASA Glenn Research Center is looking at implementing > the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) > Networking Cool! > The following are some rough notes from our kickoff brainstorming > session. Anyone who has some ideas on what they might like to see, we > would love to hear from you. One thing that comes to mind and that I don't see in your list is statefulness. How would a stateful firewall work in DTN? Is it even possible/desirable? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From william.d.ivancic@nasa.gov Mon Apr 23 08:43: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 ED20D21F8715 for ; Mon, 23 Apr 2012 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, 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 h+n3WLAqVgcE for ; Mon, 23 Apr 2012 08:43:14 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 72CAC21F850C for ; Mon, 23 Apr 2012 08:43:14 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 10C3D10840B; Mon, 23 Apr 2012 10:43:10 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NFh8qp009293; Mon, 23 Apr 2012 10:43:09 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 23 Apr 2012 10:43:09 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Marc Blanchet Date: Mon, 23 Apr 2012 10:43:07 -0500 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0hZ8gKT1VDet/BT+K3KJ5eq82mAQ== Message-ID: <71676B3E-A1BC-4B42-B279-9750342CD6E2@nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <8CF3CAE1-5EEA-4BFF-B82C-3F3651D87D40@viagenie.ca> In-Reply-To: <8CF3CAE1-5EEA-4BFF-B82C-3F3651D87D40@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_71676B3EA1BC4B42B2799750342CD6E2nasagov_" 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-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:43:16 -0000 --_000_71676B3EA1BC4B42B2799750342CD6E2nasagov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Marc. I was looking for that. I saw the IANN document, but not t= his in the DTRNG wiki. Perhaps you can put it on DTNRG wiki documents? If= not, let me know and I'll put in on. I think in the long run, we are going to find that putting the service as p= art of the URI is not desirable. It may be OK for a research protocol, but= probably not beyond. Thinks like BP-Table sort of make this apparent. - Will On Apr 23, 2012, at 11:35 AM, Marc Blanchet wrote: - good idea! - you should look at draft-blanchet-dtnrg-bp-app-framework as a way to iden= tify service id in a normalized way. Marc. Le 2012-04-23 =E0 11:01, Ivancic, William D. (GRC-RHN0) a =E9crit : A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro * Why BP-Tables 2. IP-Tables * What does IP-tables do 3. BP-Tables * What is different * What is similar * What it should do * What it can do 4. Items of interest * URI vs. identity * URI vs. application/service * How do we identify application/service 5. ICMP -> BCMP * Status replies 6. Network management and BP-Tables 7. Security Section * BAB, PIB, and PCB key distribution - Will _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_71676B3EA1BC4B42B2799750342CD6E2nasagov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks,  Marc.  = I was looking for that.  I saw the IANN document, but not this in the = DTRNG wiki.  Perhaps you can put it on DTNRG wiki documents?  If = not, let me know and I'll put in on.

I think in the long= run, we are going to find that putting the service as part of the URI is n= ot desirable.  It may be OK for a research protocol, but probably not = beyond.  Thinks like BP-Table sort of make this apparent.

- Will


=
On Apr 23, 2012, at 11:35 AM, Marc Blanchet wrote:

- good idea!
- you should look at draft-blanchet-d= tnrg-bp-app-framework as a way to identify service id in a normalized way.<= div>
Marc.

Le 2012-04-23 =E0 11:01, I= vancic, William D. (GRC-RHN0) a =E9crit :

A s= mall team at NASA Glenn Research Center is looking at implementing the equi= valent of IP-Tables for Store-Carry-and-Forward  (Disconnected) Networ= king

The following are some rough notes from our k= ickoff brainstorming session.  Anyone who has some ideas on what they = might like to see, we would love to hear from you.  

We plan to put together an internet draft document some of our thou= ghts.  

A couple of things that sort of stood= out:

*  We probably need something like ICMP= (BCMP) to return status (with every node listening for this service
<= div>* It really would be nice to have services/applications separate from U= RI 
* A more consistant/uniform naming scheme would be very = useful
* It would be useful to be able to filer on something like= organization (gets into a lot of mixing of Security/keys with identity ver= ification)



Filtering on:
Size
Source URI
Destination UR= I
Lif= etime (TTL) (limit acceptance of bundle based on time). 
Hop Count (???)
Service= (application =3D=3D IP port) (how to determine???)

Should service be separate f= rom URI?  (not currently possible in RFC 5050)
Key to deployment is Identit= y-based, not address-based - So do we need PIB to implement?
In RFC5050 - there = is no addressing.  IP-tables are address-based.
Allocate resources (size, e= tc.) by URI.
Bundling needs the equivalent of IP-ICMP. (Bundle Control Message P= rotocol?)
IP-Tables can filter on all fields, BP-Tables (should it also do = equivalent?)
BP-Tables may help manage resource allocation for quality of servic= e (50% "bulk" bundles, 50% "scheduled service" for example).
<= br>

ID BP-Tables
  1. Intro
  2. =
    • Why BP-= Tables
  3. IP-Tables
    • What does IP-tables do
  4. BP-Tables
    • What is different
    • What is similar
    • What it should = do
    • What= it can do
  5. Items of interest
    • URI vs. identity
    • URI vs. application/service
    • How do we identify a= pplication/service
  6. ICMP -> BCMP
    • Status replies
  7. Network management and BP-Tables=
  8. Securi= ty Section
    • BAB, PIB, and PCB key distribution

- Will
_______________________________________________dtn-interest mailing list
dtn= -interest@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-interest


******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne= tworking Lab 216-433-2620
Mobile = 440-503-4892
http://roland.grc.nasa.gov/~ivancic

= --_000_71676B3EA1BC4B42B2799750342CD6E2nasagov_-- From scott.c.burleigh@jpl.nasa.gov Mon Apr 23 08:47:11 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 21F6521F86BE for ; Mon, 23 Apr 2012 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.425, 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 aVWSwrp3zX1C for ; Mon, 23 Apr 2012 08:47:09 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 10B2C21F86B4 for ; Mon, 23 Apr 2012 08:47:08 -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 q3NFl7rs008477 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 23 Apr 2012 08:47:08 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 08:47:07 -0700 From: "Burleigh, Scott C (313B)" To: "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfw Date: Mon, 23 Apr 2012 15:47:07 +0000 Message-ID: References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> 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_A5BEAD028815CB40A32A5669CF737C3B04123Capembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:47:11 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B04123Capembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will, is it really important to manage service/application separate from en= dpoint ID (which is what I think you are saying when you say URI)? I can s= ee why you need to be able to identify the service/application that charact= erizes a bundle, but I think you're okay so long as you can always triviall= y infer service/application from the EID. Certainly that's already easy to= do if you're using "ipn"-scheme EIDs, according to the formal definition o= f the scheme, but it ought to be easy to tweak the "dtn" scheme definition = for this purpose as well if necessary. Scott From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Monday, April 23, 2012 8:02 AM To: dtn-interest@irtf.org Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro o Why BP-Tables 2. IP-Tables o What does IP-tables do 3. BP-Tables o What is different o What is similar o What it should do o What it can do 4. Items of interest o URI vs. identity o URI vs. application/service o How do we identify application/service 5. ICMP -> BCMP o Status replies 6. Network management and BP-Tables 7. Security Section o BAB, PIB, and PCB key distribution - Will --_000_A5BEAD028815CB40A32A5669CF737C3B04123Capembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will, is it really import= ant to manage service/application separate from endpoint ID (which is what = I think you are saying when you say URI)?  I can see why you need to be able to identify the service/application that characterizes= a bundle, but I think you’re okay so long as you can always triviall= y infer service/application from the EID.  Certainly that’s alre= ady easy to do if you’re using “ipn”-scheme EIDs, according to the formal definition of the scheme, but it ought to be easy = to tweak the “dtn” scheme definition for this purpose as well i= f necessary.

 <= /p>

Scott

 <= /p>

From: dtn-inte= rest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8:02 AM
To: dtn-interest@irtf.org
Subject: [dtn-interest] BP-Tables

 

A small team at NASA Glenn Research Center is lookin= g at implementing the equivalent of IP-Tables for Store-Carry-and-Forward &= nbsp;(Disconnected) Networking

 

The following are some rough notes from our kickoff = brainstorming session.  Anyone who has some ideas on what they might l= ike to see, we would love to hear from you.  

 

We plan to put together an internet draft document s= ome of our thoughts.  

 

A couple of things that sort of stood out:

 

*  We probably need something like ICMP (BCMP) = to return status (with every node listening for this service

* It really would be nice to have services/applicati= ons separate from URI 

* A more consistant/uniform naming scheme would be v= ery useful

* It would be useful to be able to filer on somethin= g like organization (gets into a lot of mixing of Security/keys with identi= ty verification)

 

 

 

Filtering on:

Size

Source URI

Destination URI

Lifetime (TTL) (limit acceptance of bu= ndle based on time). 

Hop Count (???)

Service (application =3D=3D IP port) (= how to determine???)

 

Should service be separate from URI?&n= bsp; (not currently possible in RFC 5050)

Key to deployment is Identity-based, n= ot address-based - So do we need PIB to implement?

In RFC5050 - there is no addressing.&n= bsp; IP-tables are address-based.

Allocate resources (size, etc.) by URI= .

Bundling needs the equivalent of IP-IC= MP. (Bundle Control Message Protocol?)

IP-Tables can filter on all fields,&nb= sp;BP-Tables (should it also do equivalent?)

BP-Tables may help manage resource all= ocation for quality of service (50% "bulk" bundles, 50% "sch= eduled service" for example).

 

 

ID BP-Tables

1.     Intro

o    Why BP-Tables

2.     IP-Tables

o    What does IP-tables do

3.     BP-Tables

o    What is different

o    What is similar

o    What it should do

o    What it can do

4.     Items of interest

o    URI vs. identity

o    URI vs. application/service

o    How do we identify application= /service

5.     ICMP -> BCMP

o    Status replies

6.     Network management and BP-Tabl= es

7.     Security Section

o    BAB, PIB, and PCB key distribu= tion

 

- Will

--_000_A5BEAD028815CB40A32A5669CF737C3B04123Capembxsp40RESADJP_-- From william.d.ivancic@nasa.gov Mon Apr 23 08:49:35 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 77A6C21F8747 for ; Mon, 23 Apr 2012 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 fd9V2iybxTiS for ; Mon, 23 Apr 2012 08:49:35 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id E3BFE21F8744 for ; Mon, 23 Apr 2012 08:49:34 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 433FB2D8409; Mon, 23 Apr 2012 10:49:34 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NFnXtP008788; Mon, 23 Apr 2012 10:49:33 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 23 Apr 2012 10:49:33 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Simon Perreault Date: Mon, 23 Apr 2012 10:49:32 -0500 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0haKz70wBhn+4ISQuw4HJFjftLdg== Message-ID: References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <4F957862.6020702@viagenie.ca> In-Reply-To: <4F957862.6020702@viagenie.ca> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:49:35 -0000 >=20 > One thing that comes to mind and that I don't see in your list is=20 > statefulness. How would a stateful firewall work in DTN? Is it even=20 > possible/desirable? >=20 > Simon Simon, =20 'm not sure what you are asking? =20 Are you asking about something like NATing/Masquerading? =20 or Something else? Can you please clarify? =20 We sort of briefly discussed Masquerading, but not with a lot of thought ye= t. We are not sure of its usefulness yet. Thanks, - Will From alan.g.hylton@nasa.gov Mon Apr 23 08:58:34 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 9B64C21F8741 for ; Mon, 23 Apr 2012 08:58:33 -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 tSCeUBFH0QjM for ; Mon, 23 Apr 2012 08:58:27 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6253F21F8721 for ; Mon, 23 Apr 2012 08:58:25 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id ACFDAA84E7; Mon, 23 Apr 2012 10:58:24 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NFwHTd028383; Mon, 23 Apr 2012 10:58:24 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 23 Apr 2012 10:58:17 -0500 From: "Hylton, Alan G. (GRC-RHN0)" To: "Burleigh, Scott C" , "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Date: Mon, 23 Apr 2012 10:58:16 -0500 Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfwAABwCKA= Message-ID: <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BBFF2424089F04FB7D62F800895E2B629F36161D4NDJSSCC07ndcn_" 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-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:58:34 -0000 --_000_7BBFF2424089F04FB7D62F800895E2B629F36161D4NDJSSCC07ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, I think that this gets at a need for standardization of services. Also, as an illustration, 3.3 might listen to 4.whatever, and 3.4 might lis= ten to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 get= s 2GB when receiving data. Part of the need for BP Tables is to have resour= ce management in a general network setting. This guarantees that several sc= ience missions attached to a non-earth hub (a future TDRSS might be an axle= between several hub-n-spokes) do not fight each other. Alan From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Burleigh, Scott C (313B) Sent: Monday, April 23, 2012 11:47 AM To: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org Subject: Re: [dtn-interest] BP-Tables Will, is it really important to manage service/application separate from en= dpoint ID (which is what I think you are saying when you say URI)? I can s= ee why you need to be able to identify the service/application that charact= erizes a bundle, but I think you're okay so long as you can always triviall= y infer service/application from the EID. Certainly that's already easy to= do if you're using "ipn"-scheme EIDs, according to the formal definition o= f the scheme, but it ought to be easy to tweak the "dtn" scheme definition = for this purpose as well if necessary. Scott From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] = On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Monday, April 23, 2012 8:02 AM To: dtn-interest@irtf.org Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro o Why BP-Tables 2. IP-Tables o What does IP-tables do 3. BP-Tables o What is different o What is similar o What it should do o What it can do 4. Items of interest o URI vs. identity o URI vs. application/service o How do we identify application/service 5. ICMP -> BCMP o Status replies 6. Network management and BP-Tables 7. Security Section o BAB, PIB, and PCB key distribution - Will --_000_7BBFF2424089F04FB7D62F800895E2B629F36161D4NDJSSCC07ndcn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Howdy,

 

=

I think that this gets at a need for standardiz= ation of services.

&n= bsp;

Also, as an illustration, = 3.3 might listen to 4.whatever, and 3.4 might listen to 5.whatever. Say you= want to assure 4 that 1GB is set aside and 5 gets 2GB when receiving data.= Part of the need for BP Tables is to have resource management in a general= network setting. This guarantees that several science missions attached to= a non-earth hub (a future TDRSS might be an axle between several hub-n-spo= kes) do not fight each other.

 

Alan=

 

<= div>

From: dtn-interest-bounces@irtf.org [mailto= :dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B= )
Sent: Monday, April 23, 2012 11:47 AM
To: Ivancic, Wi= lliam D. (GRC-RHN0); dtn-interest@irtf.org
Subject: Re: [dtn-inte= rest] BP-Tables

=  

Will, is it really important to= manage service/application separate from endpoint ID (which is what I thin= k you are saying when you say URI)?  I can see why you need to be able= to identify the service/application that characterizes a bundle, but I thi= nk you’re okay so long as you can always trivially infer service/appl= ication from the EID.  Certainly that’s already easy to do if yo= u’re using “ipn”-scheme EIDs, according to the formal def= inition of the scheme, but it ought to be easy to tweak the “dtn̶= 1; scheme definition for this purpose as well if necessary.

 

Scott

 

From: dtn-intere= st-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of = Ivancic, William D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8= :02 AM
To: dtn-interest@irtf.org
Subject: [dtn-interest= ] BP-Tables

&nbs= p;

A small team at NASA Glenn Research C= enter is looking at implementing the equivalent of IP-Tables for Store-Carr= y-and-Forward  (Disconnected) Networking

 

The f= ollowing are some rough notes from our kickoff brainstorming session.  = ;Anyone who has some ideas on what they might like to see, we would love to= hear from you.  

&= nbsp;

We plan to put together an i= nternet draft document some of our thoughts.  

 

A couple of things that sort of stood out:

 

*  = ;We probably need something like ICMP (BCMP) to return status (with every n= ode listening for this service

* It really would be nice to have services/applications separate from URI=  

* A more consistant/un= iform naming scheme would be very useful

* It would be useful to be able to filer on something like org= anization (gets into a lot of mixing of Security/keys with identity verific= ation)

 

<= /div>

 

 

Filtering on:=

Size

<= /div>

Source URI

Destination URI

Life= time (TTL) (limit acceptance of bundle based on time). 

Hop Count (???)

Service (application =3D=3D IP port) (how to determine= ???)

 

Should service be separate from URI?  (= not currently possible in RFC 5050)

Key to deployment is Identity-based, not address-based - So do we n= eed PIB to implement?

= In RFC= 5050 - there is no addressing.  IP-tables are address-based.

Allocate resources (size, etc.) by UR= I.

Bundling needs the equiva= lent of IP-ICMP. (Bundle Control Message Protocol?)

IP-Tables can filter on all fields, BP-Tables = (should it also do equivalent?)

BP-Tables may help manage resource allocation for quality of service (5= 0% "bulk" bundles, 50% "scheduled service" for example)= .

 

 

ID BP-Tables

1.   Intro

<= p class=3DMsoNormal style=3D'margin-left:1.0in;text-indent:-.25in;mso-list:= l0 level2 lfo2'>o  Why BP-Tables

2.   IP-Tables

o&= nbsp; What does IP-tables do

=

3.   BP= -Tables

o  = What is different

o=   What is similar

o  What it should do

o  Wha= t it can do

4. &= nbsp; Items of interest

o  URI vs. identity

o  URI= vs. application/service

o&nbs= p; How do we identify application/service

5.   = ICMP -> BCMP

o&= nbsp; Status replies

6.   Network ma= nagement and BP-Tables

= 7.   Security Section

o  BAB, PIB, and= PCB key distribution

=  

- Will

<= /div>
= --_000_7BBFF2424089F04FB7D62F800895E2B629F36161D4NDJSSCC07ndcn_-- From dennis.c.iannicca@nasa.gov Mon Apr 23 08:58: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 23CE521F8773 for ; Mon, 23 Apr 2012 08:58:54 -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 rsmM0CJP7Mdl for ; Mon, 23 Apr 2012 08:58:53 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id BD9A921F8760 for ; Mon, 23 Apr 2012 08:58:51 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 47170D8014; Mon, 23 Apr 2012 10:58:51 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NFwp80030632; Mon, 23 Apr 2012 10:58:51 -0500 Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Mon, 23 Apr 2012 10:58:50 -0500 From: "Iannicca, Dennis C. (GRC-RHN0)" To: "Ivancic, William D. (GRC-RHN0)" Date: Mon, 23 Apr 2012 10:58:50 -0500 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0hafnA50aVzLkDTsWvf0dxZjNQTA== Message-ID: <29EB96D0-88F0-4775-B078-41B0F90D6E23@nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <4F957862.6020702@viagenie.ca> In-Reply-To: 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 15:58:54 -0000 On Apr 23, 2012, at 11:49 AM, Ivancic, William D. (GRC-RHN0) wrote: >>=20 >> One thing that comes to mind and that I don't see in your list is=20 >> statefulness. How would a stateful firewall work in DTN? Is it even=20 >> possible/desirable? >>=20 >> Simon >=20 > Simon, =20 >=20 > 'm not sure what you are asking? =20 >=20 > Are you asking about something like NATing/Masquerading? =20 > or Something else? > Can you please clarify? =20 >=20 >=20 > We sort of briefly discussed Masquerading, but not with a lot of thought = yet. We are not sure of its usefulness yet. >=20 =09 I'm not sure that BP should necessarily care about maintaining a state as = there is no inherent acknowledgements (unless we start talking about conver= gence layers). I would think it's either going to be a convergence layer p= roblem or an application layer problem to worry about keeping state. = From simon.perreault@viagenie.ca Mon Apr 23 09:00: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 7618A21F8781 for ; Mon, 23 Apr 2012 09:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 qSCPTOCrkx+G for ; Mon, 23 Apr 2012 09:00:12 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 072A621F876C for ; Mon, 23 Apr 2012 09:00:12 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:1466:2a58:f88d:fd6e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7832E40099; Mon, 23 Apr 2012 12:00:11 -0400 (EDT) Message-ID: <4F957C8A.1040508@viagenie.ca> Date: Mon, 23 Apr 2012 12:00:10 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <4F957862.6020702@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 16:00:14 -0000 On 2012-04-23 11:49, Ivancic, William D. (GRC-RHN0) wrote: > Are you asking about something like NATing/Masquerading? > or Something else? Not necessarily. > Can you please clarify? > > > We sort of briefly discussed Masquerading, but not with a lot of thought yet. We are not sure of its usefulness yet. Agreed. I'm thinking about the kind of firewall that tracks flows to ensure that flags make sense with the current state of the flow, to allow return packets, etc. With iptables, the conntrack module handles statefulness. IMHO the best example of a stateful firewall is pf, the one from OpenBSD and FreeBSD. In pf, everything is stateful by default, so you can just say things such as pass out on em0 proto tcp to any port 80 and have it pass inbound packets associated with an established outbound flow. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gc355804@ohio.edu Mon Apr 23 09:02:27 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 7AB3721F8731 for ; Mon, 23 Apr 2012 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6] 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 GayvxUP-Pl3Q for ; Mon, 23 Apr 2012 09:02:27 -0700 (PDT) Received: from mx2.oit.ohio.edu (mx2.oit.ohio.edu [132.235.51.19]) by ietfa.amsl.com (Postfix) with ESMTP id B3F6321F8705 for ; Mon, 23 Apr 2012 09:02:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALN8lU+E6who/2dsb2JhbAA6AQmxUYEHggkBBicTUQEIEQMBAh9CHQgBAQQBEAKID7FiiQmEF4ZXAQMBhlwElXqQPoMFIoEWAQ Received: from exht1.oit.ohio.edu ([132.235.8.104]) by smtpout2.oit.ohio.edu with ESMTP; 23 Apr 2012 12:02:18 -0400 Received: from exmail1.ohio.edu ([10.13.10.1]) by exht1.oit.ohio.edu ([10.13.10.31]) with mapi; Mon, 23 Apr 2012 12:01:56 -0400 From: "Clark, Gilbert" To: "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Date: Mon, 23 Apr 2012 12:02:16 -0400 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0haoW/VstECsPZQgOk5B53Dmydxg== Message-ID: In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 16:02:27 -0000 Cool stuff. A few thoughts: * YMMV, but I really believe that actively querying a DTN node has limited applicability in the general case. Thus, BCMP's interactivity might be better defined as an interface by which to add new information to heartbeat messages and / or define new triggers upon which to send data. (Full disclosure: that's a shameless plug for stuff I'm working on. Sorry :) * I like the idea of divorcing services / applications from the URL, but that would probably necessitate some kind of IDL that could describe the services / applications available at a certain endpoint. When we start doing that, it seems to me we've arrived back at problems that HTTP / WSDL were designed to solve. Am I missing something there? * Regex would be *really*, *really* useful. * Eventually, I could see a list of these definitions handling all the *local* routing on the node, not just firewall rules. For example: bptables --src source.dtn --endpoint-match ^/my/service/.* --route-to local:1234=20 bptables --src source.dtn --endpoint-match ^/diagnostics/.* --route-to local:1235 Just my $0.02; hope something in there is useful food for thought. --Gilbert From: "Ivancic, William D. (GRC-RHN0)" Date: Mon, 23 Apr 2012 11:01:36 -0400 To: "dtn-interest@irtf.org" Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networking The following are some rough notes from our kickoff brainstorming session. Anyone who has some ideas on what they might like to see, we would love to hear from you. =20 We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (gets into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent?) BP-Tables may help manage resource allocation for quality of service (50% "bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro * Why BP-Tables 2. IP-Tables * What does IP-tables do 3. BP-Tables * What is different * What is similar * What it should do * What it can do 4. Items of interest * URI vs. identity * URI vs. application/service * How do we identify application/service 5. ICMP -> BCMP * Status replies 6. Network management and BP-Tables 7. Security Section * BAB, PIB, and PCB key distribution - Will From simon.perreault@viagenie.ca Mon Apr 23 09:02: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 7989A21F8705 for ; Mon, 23 Apr 2012 09:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 LkCCxfhRyyBw for ; Mon, 23 Apr 2012 09:02:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D2D0421F86C7 for ; Mon, 23 Apr 2012 09:02:51 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:1466:2a58:f88d:fd6e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2480840099; Mon, 23 Apr 2012 12:02:51 -0400 (EDT) Message-ID: <4F957D2A.40903@viagenie.ca> Date: Mon, 23 Apr 2012 12:02:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Iannicca, Dennis C. (GRC-RHN0)" References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <4F957862.6020702@viagenie.ca> <29EB96D0-88F0-4775-B078-41B0F90D6E23@nasa.gov> In-Reply-To: <29EB96D0-88F0-4775-B078-41B0F90D6E23@nasa.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 16:02:55 -0000 On 2012-04-23 11:58, Iannicca, Dennis C. (GRC-RHN0) wrote: > I'm not sure that BP should necessarily care about maintaining a state as there is no inherent acknowledgements (unless we start talking about convergence layers). I would think it's either going to be a convergence layer problem or an application layer problem to worry about keeping state. UDP also doesn't have inherent acknowledgements yet many firewalls operate statefully on UDP flows, including iptables. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From scott.c.burleigh@jpl.nasa.gov Mon Apr 23 09:12:08 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 0CC6621F8720 for ; Mon, 23 Apr 2012 09:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.354, 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 itvMdn+vW8aX for ; Mon, 23 Apr 2012 09:12:05 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6FE21F8582 for ; Mon, 23 Apr 2012 09:12:05 -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 q3NGC3U2023310 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 23 Apr 2012 09:12:04 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.238]) with mapi id 14.01.0355.002; Mon, 23 Apr 2012 09:12:03 -0700 From: "Burleigh, Scott C (313B)" To: "Hylton, Alan G (313B-NASA)" , "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfwAABwCKAAAHsTwA== Date: Mon, 23 Apr 2012 16:12:03 +0000 Message-ID: References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov> In-Reply-To: <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov> 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_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 16:12:08 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alan, I certainly agree about the need for standardization of service ident= ifiers. FWIW, I believe CCSDS is already working on standardizing ipn-sche= me service numbers through IANA. I'm less clear on your illustration, though. What you're describing sounds= to me more like QoS than the sort of thing I usually think of a firewall s= upporting. What's the argument for performing this function in bptables ra= ther than in, say, routing? Scott From: Hylton, Alan G. (GRC-RHN0) [mailto:alan.g.hylton@nasa.gov] Sent: Monday, April 23, 2012 8:58 AM To: Burleigh, Scott C (313B); Ivancic, William D. (GRC-RHN0); dtn-interest@= irtf.org Subject: RE: BP-Tables Howdy, I think that this gets at a need for standardization of services. Also, as an illustration, 3.3 might listen to 4.whatever, and 3.4 might lis= ten to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 get= s 2GB when receiving data. Part of the need for BP Tables is to have resour= ce management in a general network setting. This guarantees that several sc= ience missions attached to a non-earth hub (a future TDRSS might be an axle= between several hub-n-spokes) do not fight each other. Alan From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) Sent: Monday, April 23, 2012 11:47 AM To: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org Subject: Re: [dtn-interest] BP-Tables Will, is it really important to manage service/application separate from en= dpoint ID (which is what I think you are saying when you say URI)? I can s= ee why you need to be able to identify the service/application that charact= erizes a bundle, but I think you're okay so long as you can always triviall= y infer service/application from the EID. Certainly that's already easy to= do if you're using "ipn"-scheme EIDs, according to the formal definition o= f the scheme, but it ought to be easy to tweak the "dtn" scheme definition = for this purpose as well if necessary. Scott From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Monday, April 23, 2012 8:02 AM To: dtn-interest@irtf.org Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro o Why BP-Tables 2. IP-Tables o What does IP-tables do 3. BP-Tables o What is different o What is similar o What it should do o What it can do 4. Items of interest o URI vs. identity o URI vs. application/service o How do we identify application/service 5. ICMP -> BCMP o Status replies 6. Network management and BP-Tables 7. Security Section o BAB, PIB, and PCB key distribution - Will --_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan, I certainly agree a= bout the need for standardization of service identifiers.  FWIW, I bel= ieve CCSDS is already working on standardizing ipn-scheme service numbers through IANA.

 <= /p>

I’m less clear on y= our illustration, though.  What you’re describing sounds to me m= ore like QoS than the sort of thing I usually think of a firewall supportin= g.  What’s the argument for performing this function in bptables rather = than in, say, routing?

 <= /p>

Scott

 <= /p>

From: Hylton, = Alan G. (GRC-RHN0) [mailto:alan.g.hylton@nasa.gov]
Sent: Monday, April 23, 2012 8:58 AM
To: Burleigh, Scott C (313B); Ivancic, William D. (GRC-RHN0); dtn-in= terest@irtf.org
Subject: RE: BP-Tables

 

Howdy,<= /p>

 <= /p>

I think that this gets at= a need for standardization of services.

 <= /p>

Also, as an illustration,= 3.3 might listen to 4.whatever, and 3.4 might listen to 5.whatever. Say yo= u want to assure 4 that 1GB is set aside and 5 gets 2GB when receiving data. Part of the need for BP Tables is to have resource ma= nagement in a general network setting. This guarantees that several science= missions attached to a non-earth hub (a future TDRSS might be an axle betw= een several hub-n-spokes) do not fight each other.

 <= /p>

Alan

 <= /p>

From: dtn-interest-bounces@irtf.= org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Sc= ott C (313B)
Sent: Monday, April 23, 2012 11:47 AM
To: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org
Subject: Re: [dtn-interest] BP-Tables

 

Will, is it really import= ant to manage service/application separate from endpoint ID (which is what = I think you are saying when you say URI)?  I can see why you need to be able to identify the service/application that characterizes= a bundle, but I think you’re okay so long as you can always triviall= y infer service/application from the EID.  Certainly that’s alre= ady easy to do if you’re using “ipn”-scheme EIDs, according to the formal definition of the scheme, but it ought to be easy = to tweak the “dtn” scheme definition for this purpose as well i= f necessary.

 <= /p>

Scott

 <= /p>

From: dtn-interest-bounces@irtf.= org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Ivancic, Wil= liam D. (GRC-RHN0)
Sent: Monday, April 23, 2012 8:02 AM
To: dtn-interest@irtf.org
Subject: [dtn-interest] BP-Tables

 

A small team at NASA Glenn Research Center is lookin= g at implementing the equivalent of IP-Tables for Store-Carry-and-Forward &= nbsp;(Disconnected) Networking

 

The following are some rough notes from our kickoff = brainstorming session.  Anyone who has some ideas on what they might l= ike to see, we would love to hear from you.  

 

We plan to put together an internet draft document s= ome of our thoughts.  

 

A couple of things that sort of stood out:

 

*  We probably need something like ICMP (BCMP) = to return status (with every node listening for this service

* It really would be nice to have services/applicati= ons separate from URI 

* A more consistant/uniform naming scheme would be v= ery useful

* It would be useful to be able to filer on somethin= g like organization (gets into a lot of mixing of Security/keys with identi= ty verification)

 

 

 

Filtering on:

Size

Source URI

Destination URI

Lifetime (TTL) (limit acceptance of bu= ndle based on time). 

Hop Count (???)

Service (application =3D=3D IP port) (= how to determine???)

 

Should service be separate from URI?&n= bsp; (not currently possible in RFC 5050)

Key to deployment is Identity-based, n= ot address-based - So do we need PIB to implement?

In RFC5050 - there is no addressing.&n= bsp; IP-tables are address-based.

Allocate resources (size, etc.) by URI= .

Bundling needs the equivalent of IP-IC= MP. (Bundle Control Message Protocol?)

IP-Tables can filter on all fields,&nb= sp;BP-Tables (should it also do equivalent?)

BP-Tables may help manage resource all= ocation for quality of service (50% "bulk" bundles, 50% "sch= eduled service" for example).

 

 

ID BP-Tables

1.   Intro

o  Why BP-Tables

2.   IP-Tables

o  What does IP-tables do

3.   BP-Tables

o  What is different

o  What is similar

o  What it should do

o  What it can do

4.   Items of interest

o  URI vs. identity

o  URI vs. application/service

o  How do we identify application= /service

5.   ICMP -> BCMP

o  Status replies

6.   Network management and BP-Tabl= es

7.   Security Section

o  BAB, PIB, and PCB key distribu= tion

 

- Will

--_000_A5BEAD028815CB40A32A5669CF737C3B041335apembxsp40RESADJP_-- From dennis.c.iannicca@nasa.gov Mon Apr 23 10:28: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 922DA21F8772 for ; Mon, 23 Apr 2012 10:28: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 UikqQOVKDh9q for ; Mon, 23 Apr 2012 10:28:46 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 143E221F873C for ; Mon, 23 Apr 2012 10:28:45 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 5AF772D82EF; Mon, 23 Apr 2012 12:28:45 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NHSjSE003816; Mon, 23 Apr 2012 12:28:45 -0500 Received: from NDJSSCC04.ndc.nasa.gov ([10.58.58.14]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Mon, 23 Apr 2012 12:28:45 -0500 From: "Iannicca, Dennis C. (GRC-RHN0)" To: Simon Perreault Date: Mon, 23 Apr 2012 12:28:44 -0500 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0hdojFd1YdqUo8SyugKSPhf06FKg== Message-ID: <0167E1D1-7CBA-463D-8DEA-C8848FFD1B39@nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <4F957862.6020702@viagenie.ca> <29EB96D0-88F0-4775-B078-41B0F90D6E23@nasa.gov> <4F957D2A.40903@viagenie.ca> In-Reply-To: <4F957D2A.40903@viagenie.ca> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 17:28:47 -0000 On Apr 23, 2012, at 12:02 PM, Simon Perreault wrote: > On 2012-04-23 11:58, Iannicca, Dennis C. (GRC-RHN0) wrote: >> I'm not sure that BP should necessarily care about maintaining a state = as there is no inherent acknowledgements (unless we start talking about con= vergence layers). I would think it's either going to be a convergence laye= r problem or an application layer problem to worry about keeping state. >=20 > UDP also doesn't have inherent acknowledgements yet many firewalls=20 > operate statefully on UDP flows, including iptables. True. It's something to consider. I'm just thinking that once you start t= reating a series of bundles as an associated session which may or may not c= ontain reply bundles you will need to worry about synchronizing state table= s between forwarding nodes since the reply could take another path back. P= erhaps we should call this BP-chains at first. ;-)= From alan.g.hylton@nasa.gov Mon Apr 23 10:34:32 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 E256421F86B4 for ; Mon, 23 Apr 2012 10:34:32 -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 5hwZEZmlnFtm for ; Mon, 23 Apr 2012 10:34:28 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id 83EF221F85BD for ; Mon, 23 Apr 2012 10:34:28 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 0AD712D80A7; Mon, 23 Apr 2012 12:34:28 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NHYQaj030348; Mon, 23 Apr 2012 12:34:27 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 23 Apr 2012 12:34:27 -0500 From: "Hylton, Alan G. (GRC-RHN0)" To: "Burleigh, Scott C" , "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Date: Mon, 23 Apr 2012 12:34:27 -0500 Thread-Topic: BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AABTJfwAABwCKAAAHsTwAACzYsQ Message-ID: <7BBFF2424089F04FB7D62F800895E2B629F3616243@NDJSSCC07.ndc.nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> <7BBFF2424089F04FB7D62F800895E2B629F36161D4@NDJSSCC07.ndc.nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BBFF2424089F04FB7D62F800895E2B629F3616243NDJSSCC07ndcn_" 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-04-23_04:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 17:34:33 -0000 --_000_7BBFF2424089F04FB7D62F800895E2B629F3616243NDJSSCC07ndcn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see a lot of overlap between what BP Tables would/should offer with other= networking concepts. Indeed, there is some QoS here and network management= . It still seems appropriate to me to have one table to rule them all, so t= o speak. Ensuring that there is enough resources left to get all of the sci= ence data is necessary for scientists to be on board with DTN both for spac= e and earth missions. Having policies at the node level is the first step t= owards this form of control over the entire network as a system. It makes t= he most sense to me to have these policies consolidated as I see the role o= f BP Tables being bigger to DTNs than IP Tables to non-tolerant networks. T= his is just me, of course, which is why this is brought before the group. It occurs to me that having policies spread out over many separate entities= does not scale with large networks and would make it tougher to maintain c= onsistency. I see the routers as complex enough to stand alone. To include the capabili= ty to pick apart bundles and determine if they meet certain policies would = make them overweight. That being said, I would expect BP Tables to consult = with the router at some point. I would not be surprised if ultimately BP Ta= bles would talk to a BCMP (ICMP counterpart). For now, I think the least invasive way of adding to DTN is to add one sect= ion that manages these concerns. If the BP Tables implementation is flexibl= e enough it can handle a host of policies (to be pruned, eventually, I am s= ure) rather than modifying and adding. This makes it easier to have ION and= DTN2 (hopefully, IBR someday?) implementations. Alan From: Burleigh, Scott C (313B) [mailto:scott.c.burleigh@jpl.nasa.gov] Sent: Monday, April 23, 2012 12:12 PM To: Hylton, Alan G. (GRC-RHN0); Ivancic, William D. (GRC-RHN0); dtn-interes= t@irtf.org Subject: RE: BP-Tables Alan, I certainly agree about the need for standardization of service ident= ifiers. FWIW, I believe CCSDS is already working on standardizing ipn-sche= me service numbers through IANA. I'm less clear on your illustration, though. What you're describing sounds= to me more like QoS than the sort of thing I usually think of a firewall s= upporting. What's the argument for performing this function in bptables ra= ther than in, say, routing? Scott From: Hylton, Alan G. (GRC-RHN0) [mailto:alan.g.hylton@nasa.gov] Sent: Monday, April 23, 2012 8:58 AM To: Burleigh, Scott C (313B); Ivancic, William D. (GRC-RHN0); dtn-interest@= irtf.org Subject: RE: BP-Tables Howdy, I think that this gets at a need for standardization of services. Also, as an illustration, 3.3 might listen to 4.whatever, and 3.4 might lis= ten to 5.whatever. Say you want to assure 4 that 1GB is set aside and 5 get= s 2GB when receiving data. Part of the need for BP Tables is to have resour= ce management in a general network setting. This guarantees that several sc= ience missions attached to a non-earth hub (a future TDRSS might be an axle= between several hub-n-spokes) do not fight each other. Alan From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (313B) Sent: Monday, April 23, 2012 11:47 AM To: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org Subject: Re: [dtn-interest] BP-Tables Will, is it really important to manage service/application separate from en= dpoint ID (which is what I think you are saying when you say URI)? I can s= ee why you need to be able to identify the service/application that charact= erizes a bundle, but I think you're okay so long as you can always triviall= y infer service/application from the EID. Certainly that's already easy to= do if you're using "ipn"-scheme EIDs, according to the formal definition o= f the scheme, but it ought to be easy to tweak the "dtn" scheme definition = for this purpose as well if necessary. Scott From: dtn-interest-bounces@irtf.org [= mailto:dtn-interest-bounces@irtf.org] On Behalf Of Ivancic, William D. (GRC-RHN0) Sent: Monday, April 23, 2012 8:02 AM To: dtn-interest@irtf.org Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1.Intro o Why BP-Tables 2.IP-Tables o What does IP-tables do 3.BP-Tables o What is different o What is similar o What it should do o What it can do 4.Items of interest o URI vs. identity o URI vs. application/service o How do we identify application/service 5.ICMP -> BCMP o Status replies 6.Network management and BP-Tables 7.Security Section o BAB, PIB, and PCB key distribution - Will --_000_7BBFF2424089F04FB7D62F800895E2B629F3616243NDJSSCC07ndcn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see a l= ot of overlap between what BP Tables would/should offer with other networki= ng concepts. Indeed, there is some QoS here and network management. It stil= l seems appropriate to me to have one table to rule them all, so to speak. = Ensuring that there is enough resources left to get all of the science data= is necessary for scientists to be on board with DTN both for space and ear= th missions. Having policies at the node level is the first step towards th= is form of control over the entire network as a system. It makes the most s= ense to me to have these policies consolidated as I see the role of BP Tabl= es being bigger to DTNs than IP Tables to non-tolerant networks. This is ju= st me, of course, which is why this is brought before the group.=

 

It occurs to me that having policies spread out over ma= ny separate entities does not scale with large networks and would make it t= ougher to maintain consistency.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

I see the rou= ters as complex enough to stand alone. To include the capability to pick ap= art bundles and determine if they meet certain policies would make them ove= rweight. That being said, I would expect BP Tables to consult with the rout= er at some point. I would not be surprised if ultimately BP Tables would ta= lk to a BCMP (ICMP counterpart).

=  

For now, I t= hink the least invasive way of adding to DTN is to add one section that man= ages these concerns. If the BP Tables implementation is flexible enough it = can handle a host of policies (to be pruned, eventually, I am sure) rather = than modifying and adding. This makes it easier to have ION and DTN2 (hopef= ully, IBR someday?) implementations.

 

Alan

 

<= p class=3DMsoNormal> 

 

 =

From: Burleigh, = Scott C (313B) [mailto:scott.c.burleigh@jpl.nasa.gov]
Sent: Mond= ay, April 23, 2012 12:12 PM
To: Hylton, Alan G. (GRC-RHN0); Ivanc= ic, William D. (GRC-RHN0); dtn-interest@irtf.org
Subject: RE: BP-= Tables

 

Alan, I certainly agree about the need f= or standardization of service identifiers.  FWIW, I believe CCSDS is a= lready working on standardizing ipn-scheme service numbers through IANA.

 

=

I’m less clear on your illustration, thou= gh.  What you’re describing sounds to me more like QoS than the = sort of thing I usually think of a firewall supporting.  What’s = the argument for performing this function in bptables rather than in, say, = routing?

 =

Scott

 

From: Hylton, Alan G. (GRC-RHN0) [mailto:alan.g.hylton@nasa.gov]
= Sent: Monday, April 23, 2012 8:58 AM
To: Burleigh, Scott C= (313B); Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org
Subjec= t: RE: BP-Tables

=  

Howdy,

 

I think that this gets at a need for standardization of services= .

 =

Also, as an illustration, 3.3 might listen = to 4.whatever, and 3.4 might listen to 5.whatever. Say you want to assure 4= that 1GB is set aside and 5 gets 2GB when receiving data. Part of the need= for BP Tables is to have resource management in a general network setting.= This guarantees that several science missions attached to a non-earth hub = (a future TDRSS might be an axle between several hub-n-spokes) do not fight= each other.

 

Alan

 

From: dtn-i= nterest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On Behalf Of = Burleigh, Scott C (313B)
Sent: Monday, April 23, 2012 11:47 AMTo: Ivancic, William D. (GRC-RHN0); dtn-interest@irtf.org
Subject: Re: [dtn-interest] B= P-Tables

 <= /o:p>

Will, is it really important to manage= service/application separate from endpoint ID (which is what I think you a= re saying when you say URI)?  I can see why you need to be able to ide= ntify the service/application that characterizes a bundle, but I think you&= #8217;re okay so long as you can always trivially infer service/application= from the EID.  Certainly that’s already easy to do if you’= ;re using “ipn”-scheme EIDs, according to the formal definition= of the scheme, but it ought to be easy to tweak the “dtn” sche= me definition for this purpose as well if necessary.

<= p class=3DMsoNormal> 

Scott

 <= /o:p>

From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounce= s@irtf.org] On Behalf Of Ivancic, William D. (GRC-RHN0)
Se= nt: Monday, April 23, 2012 8:02 AM
To: dtn-interest@irtf.org
Subject: [dtn-intere= st] BP-Tables

&n= bsp;

A small team at NASA Glenn Research= Center is looking at implementing the equivalent of IP-Tables for Store-Ca= rry-and-Forward  (Disconnected) Networking

 

The= following are some rough notes from our kickoff brainstorming session. &nb= sp;Anyone who has some ideas on what they might like to see, we would love = to hear from you.  

 

We plan to put together an= internet draft document some of our thoughts.  

<= div>

 

A couple of things that sort of stood out:

 

* &nb= sp;We probably need something like ICMP (BCMP) to return status (with every= node listening for this service

* It really would be nice to have services/applications separate from U= RI 

* A more consistant/= uniform naming scheme would be very useful

* It would be useful to be able to filer on something like or= ganization (gets into a lot of mixing of Security/keys with identity verifi= cation)

 

=

 

 

Filtering on:=

Size

<= /div>

Source URI

Destination URI

Life= time (TTL) (limit acceptance of bundle based on time). 

Hop Count (???)

Service (application =3D=3D IP port) (how to determine= ???)

 

Should service be separate from URI?  (= not currently possible in RFC 5050)

Key to deployment is Identity-based, not address-based - So do we n= eed PIB to implement?

= In RFC= 5050 - there is no addressing.  IP-tables are address-based.

Allocate resources (size, etc.) by UR= I.

Bundling needs the equiva= lent of IP-ICMP. (Bundle Control Message Protocol?)

IP-Tables can filter on all fields, BP-Tables = (should it also do equivalent?)

BP-Tables may help manage resource allocation for quality of service (5= 0% "bulk" bundles, 50% "scheduled service" for example)= .

 

 

ID BP-Tables

1.Intro<= /span>

o Why BP-Tables<= o:p>

2.IP-Tables

o What does IP-tables do

3.BP-Tables

o What is different

o What is similar

o What it should do

o What it can = do

4.Items of interest

o URI vs. identity<= /span>

o URI vs. applic= ation/service

o = How do we identify application/service

5.= ICMP -> BCMP

o = Status replies

6.Network manag= ement and BP-Tables

7.Security Section

o BAB, PIB, an= d PCB key distribution

 

- Will

=
= --_000_7BBFF2424089F04FB7D62F800895E2B629F3616243NDJSSCC07ndcn_-- From gdt@ir.bbn.com Mon Apr 23 10:40: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 9CD2C21F8751 for ; Mon, 23 Apr 2012 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 JnaYqSZSbVCp for ; Mon, 23 Apr 2012 10:40:13 -0700 (PDT) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [IPv6:2001:4978:1fb:6400::d2]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEA21F874A for ; Mon, 23 Apr 2012 10:40:12 -0700 (PDT) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id EE4785466; Mon, 23 Apr 2012 13:40:10 -0400 (EDT) From: Greg Troxel To: "Ivancic\, William D. \(GRC-RHN0\)" References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> OpenPGP: id=32611E25 X-Hashcash: 1:20:120423:william.d.ivancic@nasa.gov::ynpxltxaKB2CXspU:000000000000000000000000000000000002aKh X-Hashcash: 1:20:120423:dtn-interest@irtf.org::EPLfG/fTmoUMUDqt:00000000000000000000000000000000000000005cRc Date: Mon, 23 Apr 2012 13:40:10 -0400 In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> (William D. Ivancic's message of "Mon, 23 Apr 2012 10:01:36 -0500") Message-ID: User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 17:40:13 -0000 --=-=-= Content-Type: text/plain A small team at NASA Glenn Research Center is looking at implementing the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networking I would suggest that you also look at other-than-Linux firewall implementations (ipfilter, ipfw, pf, npf) as part of the early stages of investigation. One issue in IP firewalling that has been muddled in at least several implementations is separating: - controlling what traffic can transit a router, and - controlling what traffic can access a host This seems important in BP as well. Another thing to think about early is how firewalls relate to opportunistic transfer over wireless -- what are you trying to protect, and why? With BP, the traditional notion of "inside the firewall" seems harder to pin down, and if that notion is unsound, controlling transit traffic becomes less interesting. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (NetBSD) iEYEARECAAYFAk+Vk/oACgkQ+vesoDJhHiXQBACfWmZ4D7985BBRa7QytG0Rw/yE QX8An0sSIT9y/ht1feYZBn95o9B6WdgT =d7Hi -----END PGP SIGNATURE----- --=-=-=-- From kfall@qualcomm.com Mon Apr 23 10:49:31 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 68A9B21F8720 for ; Mon, 23 Apr 2012 10:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HizPf3zKhQOJ for ; Mon, 23 Apr 2012 10:49:30 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 63B3C21F873C for ; Mon, 23 Apr 2012 10:49:30 -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=1335203370; x=1366739370; h=from:to: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:mime-version; bh=/GergWMLZmSFZ5KeGx+CPOiKdBxAl4QbJ66IUXwEer0=; b=eXE45kyxmTnBEulekYvMrHAnsNLI4Po/Z5Co/jKZbIE2jHEUBumOhihC T5YII5aFX2q+3OiiVckf0L5sPG8Ggw0yLl3Yb5h3nfnnGHc2qjGoCbeu7 ajx+qpVdGvvCLziKjTb7ODUh6ItZmuXCAXDXia6bqeA0gzhKw4fiu5/r3 M=; X-IronPort-AV: E=McAfee;i="5400,1158,6690"; a="184166009" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 23 Apr 2012 10:49:27 -0700 X-IronPort-AV: E=Sophos;i="4.75,467,1330934400"; d="scan'208,217";a="239827953" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Apr 2012 10:49:27 -0700 Received: from NASANEXD01E.na.qualcomm.com ([169.254.5.81]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.02.0283.003; Mon, 23 Apr 2012 10:49:27 -0700 From: "Fall, Kevin" To: "Ivancic, William D. (GRC-RHN0)" , "dtn-interest@irtf.org" Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0hYft/z/qt3pRgTjGxOQiWFjlm0AAF3EUA Date: Mon, 23 Apr 2012 17:49:27 +0000 Message-ID: In-Reply-To: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> 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: multipart/alternative; boundary="_000_CBBAE0B73507Fkfallqualcommcom_" MIME-Version: 1.0 Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 17:49:31 -0000 --_000_CBBAE0B73507Fkfallqualcommcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few thoughts- Regarding the 'things that sort of stood out': * I'd say the Internet experience of ICMP is that we'd prefer to have s= ignaling coupled with the data transfer. The bundle protocol does this I b= elieve. * It was intended to combine the services/applications in the URI; this= is extremely useful for web apps for example, where a service may wish to = eat variable amounts of the URI as arguments. It also comes up in cache co= ntrol. This generalizes where different location in the topology may be in= terested in different prefixes of the URI. Further, it would seem to me th= at the "bad traffic" is unlikely to arrange the service/app ID they way you= 'd like it to be. * Yes, I agree that more consistent/uniform naming for at least a few s= chemes would be good * Sure, it could be. But more useful may be something related the type= of content or the tags on the content. So, most of the "filtering on" items in the list don't seem fundamental (or= maybe even that useful). The architecture describes 'security gateways' t= hat might check various credentials at interesting locations in the network= . That could use some investigation, imho. - K From: "Ivancic, William D. (GRC-RHN0)" > Date: Mon, 23 Apr 2012 10:01:36 -0500 To: "dtn-interest@irtf.org" > Subject: [dtn-interest] BP-Tables A small team at NASA Glenn Research Center is looking at implementing the e= quivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networki= ng The following are some rough notes from our kickoff brainstorming session. = Anyone who has some ideas on what they might like to see, we would love to= hear from you. We plan to put together an internet draft document some of our thoughts. A couple of things that sort of stood out: * We probably need something like ICMP (BCMP) to return status (with every= node listening for this service * It really would be nice to have services/applications separate from URI * A more consistant/uniform naming scheme would be very useful * It would be useful to be able to filer on something like organization (ge= ts into a lot of mixing of Security/keys with identity verification) Filtering on: Size Source URI Destination URI Lifetime (TTL) (limit acceptance of bundle based on time). Hop Count (???) Service (application =3D=3D IP port) (how to determine???) Should service be separate from URI? (not currently possible in RFC 5050) Key to deployment is Identity-based, not address-based - So do we need PIB = to implement? In RFC5050 - there is no addressing. IP-tables are address-based. Allocate resources (size, etc.) by URI. Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= ) IP-Tables can filter on all fields, BP-Tables (should it also do equivalent= ?) BP-Tables may help manage resource allocation for quality of service (50% "= bulk" bundles, 50% "scheduled service" for example). ID BP-Tables 1. Intro * Why BP-Tables 2. IP-Tables * What does IP-tables do 3. BP-Tables * What is different * What is similar * What it should do * What it can do 4. Items of interest * URI vs. identity * URI vs. application/service * How do we identify application/service 5. ICMP -> BCMP * Status replies 6. Network management and BP-Tables 7. Security Section * BAB, PIB, and PCB key distribution - Will _______________________________________________ dtn-interest mailing list d= tn-interest@irtf.org https://www.irtf.org/mai= lman/listinfo/dtn-interest --_000_CBBAE0B73507Fkfallqualcommcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2E9EF665AE06AF428D4536B14D9ACF17@qualcomm.com> Content-Transfer-Encoding: quoted-printable
A few thoughts-

Regarding the 'things that sort of stood out':

  • I'd say the Internet experience of ICMP is that we'd prefer to have sig= naling coupled with the data transfer.  The bundle protocol does this = I believe.
  • It was intended to combine the services/applications in = the URI; this is extremely useful for web apps for example, where a service= may wish to eat variable amounts of the URI as arguments.  It also co= mes up in cache control.  This generalizes where different location in the topology may be interested in different prefixes of the UR= I.  Further, it would seem to me that the "bad traffic" is u= nlikely to arrange the service/app ID they way you'd like it to be.
  • Yes, I agree that more consistent/uniform naming for at least a few scheme= s would be good
  • Sure, it could be.  But more useful may be som= ething related the type of content or the tags on the content.

So, most of the "filtering on" items in the list don't seem = fundamental (or maybe even that useful).  The architecture describes '= security gateways' that might check various credentials at interesting loca= tions in the network.  That could use some investigation, imho.

- K

From: "Ivancic, William D. (GR= C-RHN0)" <william.d.i= vancic@nasa.gov>
Date: Mon, 23 Apr 2012 10:01:36 -05= 00
To: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: [dtn-interest] BP-Tables

A small team at NASA Glenn Research Center is looking at implementing = the equivalent of IP-Tables for Store-Carry-and-Forward  (Disconnected= ) Networking

The following are some rough notes from our kickoff brainstorming sess= ion.  Anyone who has some ideas on what they might like to see, we wou= ld love to hear from you.  

We plan to put together an internet draft document some of our thought= s.  

A couple of things that sort of stood out:

*  We probably need something like ICMP (BCMP) to return status (= with every node listening for this service
* It really would be nice to have services/applications separate from = URI 
* A more consistant/uniform naming scheme would be very useful
* It would be useful to be able to filer on something like organizatio= n (gets into a lot of mixing of Security/keys with identity verification)



Filterin= g on:
Size
Source URI
Destination URI
Lifetime (TTL) (limit acceptance of bundle based on time). 
Hop Count (???)
Service (application =3D=3D IP port) (how to determine???)

Should service be separate from URI?  (not currently possible in RFC 5= 050)
Key to deployment is Identity-based, not address-based - So do we need PIB = to implement?
In RFC5050 - there is no addressing.  IP-tables are address-based.
Allocate resources (size, etc.) by URI.
Bundling needs the equivalent of IP-ICMP. (Bundle Control Message Protocol?= )
IP-Tables can filter on all fields, BP-Tables (should it also do equiv= alent?)
BP-Tables may help manage resource allocation for quality of service (50% &= quot;bulk" bundles, 50% "scheduled service" for example).


ID BP-Tables
  1. Intro
    • Why BP-Tables
  2. IP-Tables
    • What does IP-tables do
  3. BP-Tables
    • What is different
    • What is similar
    • What it should do
    • What it can do
  4. Items of interest
    • URI vs. identity
    • URI vs. application/service
    • How do we identify application/service
  5. ICMP -> BCMP
    • Status replies
  6. Network management and BP-Tables
  7. Security Section
    • BAB, PIB, and PCB key distribution

- Will
_______________________________________________ dtn-interest mailing list <= a href=3D"mailto:dtn-interest@irtf.org"> dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_CBBAE0B73507Fkfallqualcommcom_-- From william.d.ivancic@nasa.gov Mon Apr 23 11:04: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 1BA8521F8623 for ; Mon, 23 Apr 2012 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 CMMlrCdTra5O for ; Mon, 23 Apr 2012 11:04:43 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 387AD21F8619 for ; Mon, 23 Apr 2012 11:04:43 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 205BC183C8E; Mon, 23 Apr 2012 13:04:42 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3NI4fje011110; Mon, 23 Apr 2012 13:04:41 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Mon, 23 Apr 2012 13:03:50 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Greg Troxel Date: Mon, 23 Apr 2012 13:03:49 -0500 Thread-Topic: [dtn-interest] BP-Tables Thread-Index: Ac0he2+nWjIR9dTmQ16/3ISNy30uOQ== Message-ID: <487DCF0D-981A-4E66-84FE-691BD26DEBCA@nasa.gov> References: <18DC5255-BE5F-4579-952E-EDF4D8E48063@nasa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_487DCF0D981A4E6684FE691BD26DEBCAnasagov_" 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-04-23_05:2012-04-23, 2012-04-23, 1970-01-01 signatures=0 Cc: "dtn-interest@irtf.org" Subject: Re: [dtn-interest] BP-Tables 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, 23 Apr 2012 18:04:44 -0000 --_000_487DCF0D981A4E6684FE691BD26DEBCAnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe a better term (for generic) than BP-Tables would be BP-Firewall -Will On Apr 23, 2012, at 1:40 PM, Greg Troxel wrote: A small team at NASA Glenn Research Center is looking at implementing the equivalent of IP-Tables for Store-Carry-and-Forward (Disconnected) Networking I would suggest that you also look at other-than-Linux firewall implementations (ipfilter, ipfw, pf, npf) as part of the early stages of investigation. One issue in IP firewalling that has been muddled in at least several implementations is separating: - controlling what traffic can transit a router, and - controlling what traffic can access a host This seems important in BP as well. Another thing to think about early is how firewalls relate to opportunistic transfer over wireless -- what are you trying to protect, and why? With BP, the traditional notion of "inside the firewall" seems harder to pin down, and if that notion is unsound, controlling transit traffic becomes less interesting. ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic --_000_487DCF0D981A4E6684FE691BD26DEBCAnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maybe a better term (for g= eneric)  than BP-Tables would be BP-Firewall

-Will<= /div>


On Apr 23, 2012, at 1:40 PM, Greg Tr= oxel wrote:




 A small team at NASA Glenn Research Cente= r is looking at implementing
 the equivalent of IP-Tables for Stor= e-Carry-and-Forward (Disconnected)
 Networking

I would sugg= est that you also look at other-than-Linux firewall
implementations (ipf= ilter, ipfw, pf, npf) as part of the early stages of
investigation.
<= br>One issue in IP firewalling that has been muddled in at least severalimplementations is separating:

 - controlling what traffic ca= n transit a router, and
 - controlling what traffic can access a h= ost

This seems important in BP as well.

Another thing to thin= k about early is how firewalls relate to
opportunistic transfer over wir= eless -- what are you trying to protect,
and why?  With BP, the tra= ditional notion of "inside the firewall" seems
harder to pin down, and i= f that notion is unsound, controlling transit
traffic becomes less inter= esting.

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Ne= tworking Lab 216-433-2620
Mobile = 440-503-4892
http://roland.grc.nasa.gov/~ivancic

= --_000_487DCF0D981A4E6684FE691BD26DEBCAnasagov_-- From kscott@mitre.org Thu Apr 26 07:00:51 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 9981B21E8064 for ; Thu, 26 Apr 2012 07:00:51 -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 tNoMyen8Wrh5 for ; Thu, 26 Apr 2012 07:00:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B88C521E802C for ; Thu, 26 Apr 2012 07:00:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 628AF21B0B56; Thu, 26 Apr 2012 10:00:48 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5C6F521B0963; Thu, 26 Apr 2012 10:00:48 -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; Thu, 26 Apr 2012 10:00:48 -0400 From: "Scott, Keith L." To: "sis-dtn@mailman.ccsds.org" , "dtn-interest (dtn-interest@irtf.org)" Thread-Topic: DTN-related patent Thread-Index: Ac0jtPi3FgnHPSHiRoygB27KAYaprQ== Date: Thu, 26 Apr 2012 14:00:47 +0000 Message-ID: <5EE81C5C4CFFF4418C5EAD12F49D64EE1FC8C3@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.29.23.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dtn-interest] DTN-related patent 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, 26 Apr 2012 14:00:51 -0000 Bob Durst notes that the patent "Interface for a Delay-Tolerant Network" (h= ttp://www.freepatentsonline.com/7930379.html, April 19, 2011, Intel Corpora= tion) would seem to apply to a large portion of DTN work. Technically (the= way I read it, though I'm almost sure that makes no legal difference) the = patent is for a filesystem-based transfer mechanism (essentially a file tra= nsfer convergence layer) though the patent also states that "Of course, add= itional embodiments, variations and modifications are possible without depa= rting from this embodiment". There are things I'll need to do on the CCSDS side to contact these people,= but if anyone else has useful inputs about this, I'd be interested in hear= ing them. --keith Dr. Keith Scott Office: +1.703.983.6547 Principal Engineer, E535 kscott@mitre.org The MITRE Corporation M/S H300 7515 Colshire Drive McLean, VA 22102 Area Director, CCSDS Space Internetworking Services From stephen.farrell@cs.tcd.ie Thu Apr 26 07:39:58 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 C1F1621E8043 for ; Thu, 26 Apr 2012 07:39:58 -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 PtXYTh57oCvb for ; Thu, 26 Apr 2012 07:39:57 -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 B14F121F8646 for ; Thu, 26 Apr 2012 07:39:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E93F4171472; Thu, 26 Apr 2012 15:39:56 +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=1335451195; bh=o5j/Tffs8dpjch 18tGav7+sG6mMwlsXdTS9PBTEarJ0=; b=JBcf0zlM154SDvfSE1aHjeq6EoTX38 B6ZAVmST1Try+Z8ouZZW9qJSKUhUeU3FoaI3a7Jth47aM20hD+j1AejlGYRS7+p7 Wrx9ukPxwGpq+0AhAzyuw12jvlmMXtOBI6Tmf5VRAr3qSLISsgzyM4t4XdquLC2w 6N4/52kCvphRI6vVTd66KzU1Rngy7IDaVLgTz4ZgoBcl3Qcj98aX8jO/e6r/NDjo kVRn2sKj2c0CqEq9D3N/nOlvydpyjkX/MNKE9vdn89NQckfZrGRRjaPPYU6x/itH DyvPEwEeLPoRew3EAyVa+WjOISC5N912G80SH8k4fheBjnrSU+Of8dgQ== 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 OwnAS2CyLNTr; Thu, 26 Apr 2012 15:39:55 +0100 (IST) Received: from [10.87.48.5] (unknown [86.44.73.48]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1018E1714DF; Thu, 26 Apr 2012 15:39:52 +0100 (IST) Message-ID: <4F995E38.80202@cs.tcd.ie> Date: Thu, 26 Apr 2012 15:39:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120423 Thunderbird/12.0 MIME-Version: 1.0 To: "Scott, Keith L." References: <5EE81C5C4CFFF4418C5EAD12F49D64EE1FC8C3@IMCMBX01.MITRE.ORG> In-Reply-To: <5EE81C5C4CFFF4418C5EAD12F49D64EE1FC8C3@IMCMBX01.MITRE.ORG> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sis-dtn@mailman.ccsds.org" , "dtn-interest \(dtn-interest@irtf.org\)" Subject: Re: [dtn-interest] DTN-related patent 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, 26 Apr 2012 14:39:58 -0000 Wonderful. Ask them if they're embarrassed if you find them. I guess this doesn't need an IPR disclosure for DNTRG because it makes no reference to any I-Ds or RFCs but OTOH it does refer to presentations made at DTNRG meetings two years before they filed their superb invention, so maybe I'd better check if we ought do that. (Sigh.) S On 04/26/2012 03:00 PM, Scott, Keith L. wrote: > Bob Durst notes that the patent "Interface for a Delay-Tolerant Network" (http://www.freepatentsonline.com/7930379.html, April 19, 2011, Intel Corporation) would seem to apply to a large portion of DTN work. Technically (the way I read it, though I'm almost sure that makes no legal difference) the patent is for a filesystem-based transfer mechanism (essentially a file transfer convergence layer) though the patent also states that "Of course, additional embodiments, variations and modifications are possible without departing from this embodiment". > > There are things I'll need to do on the CCSDS side to contact these people, but if anyone else has useful inputs about this, I'd be interested in hearing them. > > --keith > > > Dr. Keith Scott Office: +1.703.983.6547 > Principal Engineer, E535 kscott@mitre.org > The MITRE Corporation > M/S H300 > 7515 Colshire Drive > McLean, VA 22102 > > Area Director, CCSDS Space Internetworking Services > > > _______________________________________________ > dtn-interest mailing list > dtn-interest@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-interest > > From valerio.arnaboldi@iit.cnr.it Sat Apr 28 02: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 C0D6721F86F4 for ; Sat, 28 Apr 2012 02:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.22 X-Spam-Level: **** X-Spam-Status: No, score=4.22 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 Z7QbxGS79mDH for ; Sat, 28 Apr 2012 02:07:35 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id 47BCA21F870E for ; Sat, 28 Apr 2012 02:07:33 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id 74BCC3D8238; Sat, 28 Apr 2012 11:07:01 +0200 (CEST) Date: Sat, 28 Apr 2012 11:07:01 +0200 From: Valerio Arnaboldi To: dtn-interest@irtf.org Message-ID: <4f9bb335.11W+DRurjLslxvmi%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] CfP: SustainIT 2012 - Submission deadline approaching: MAY 3 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: Sat, 28 Apr 2012 09:07:36 -0000 [Apologies for possible multiple copies] ------------------------------------------------------------------------ CALL FOR PAPERS 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 Sponsored by the IFIP TC6 WG 6.3, Performance of Communication Systems Technically co-sponsored by IEEE Computer Society Technical Committee on Computer Communications (TCCC) In cooperation with IEEE Communications Society Technical Subcommittee on Green Communications and Computing (TSCGCC) Supported by COST Action IC0804 - Energy Efficiency in Large-Scale Distributed Systems EINS: The Network of Excellence in Internet Science TREND: The Network of Excellence on Energy Efficient Networking ------------------------------------------------------------------------ ******* PAPER SUBMISSION DEADLINE EXTENDED TO: MAY 3, 2012 ******* BEST PAPER AWARD SPECIAL ISSUE of Selected Papers in COMPUTER COMMUNICATIONS Conference proceedings in IEEE Xplore ------------------------------------------------------------------------ In the last years, the increasing social awareness about the need for containing energy consumption within sustainable rates has caught the interest of both the industrial and academic communities. In this scenario, Internet - and more generally ICT - may play a twofold role, being both a significant energy consumer and a potential actor in steering a more clever usage of energy resources. Both aspects of the problem raise interesting scientific challenges, and require a comprehensive effort and inter-disciplinary research at all levels of abstraction. The goal of this conference is to bring together people from different research areas, and provide a forum to exchange ideas, discuss solutions, and share experiences among researchers, professionals, and application developers both from industry and academia. Original papers addressing both theoretical and practical aspects of energy-awareness for Internet-based systems, and the design of ICT solutions for eco-sustainability are solicited. Papers of interest should point out the expected long-term benefits to eco-sustainability. 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 EDITORIAL FOLLOW-UP ------------------------------------------------------------------------ The best paper presented at the conference will receive the Best Paper Award. Papers of particular merit will be considered for a SPECIAL ISSUE in the Elsevier Journal of COMPUTER COMMUNICATIONS. PAPER SUBMISSION ------------------------------------------------------------------------ All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Papers must be submitted electronically through EDAS (http://edas.info/newPaper.php?c=12373). Detailed submission instructions for manuscript preparation and submission are available on the conference website (http://cnd.iit.cnr.it/sustainit2012/). ************************************************************************* Submission implies the willingness of, at least, one author to register and attend the conference to present the paper. The organizers reserve the right to exclude a paper from distribution after the conference if the paper is not presented at the conference. ************************************************************************* TENTATIVE DATES ------------------------------------------------------------------------ - Paper registration deadline: EXTENDED TO May 3, 2012 - Paper submission deadline: EXTENDED TO May 3, 2012 - Acceptance/Reject notification: June 30, 2012 - Camera Ready Due: July 30, 2012 CONTACTS ------------------------------------------------------------------------ For further information, please visit the conference website (http://cnd.iit.cnr.it/sustainit2012/), or send an e-mail message to giuseppe.anastasi@iet.unipi.it. ORGANIZING COMMITTEE ------------------------------------------------------------------------ GENERAL CO-CHAIRS Marco Conti, IIT-CNR, Italy Jon Crowcroft, University of Cambridge, UK PROGRAM CO-CHAIRS Giuseppe Anastasi, University of Pisa, Italy Ken Christensen, University of South Florida, USA DEMO CHAIR Giuseppe Lo Re, University of Palermo, Italy Ph.D. FORUM CO-CHAIRS Franco Davoli, University of Genova, Italy Brunilde Sanso, Ecole Polytechnique de Montreal, Canada FINANCE AND REGISTRATION CHAIR Marco Ortolani, University of Palermo, Italy PUBLICATION CHAIR Emilio Ancillotti, IIT-CNR, Italy PUBLICITY CHAIR Valerio Arnaboldi, IIT-CNR, Italy Xuefeng Liu, Honk Kong Polytechnic University, China WEB MANAGER Maria Bucci, IIT-CNR, Italy TECHNICAL PROGRAM COMMITTEE Yuvraj Agarwal, University of California at San Diego, USA Marco Ajmone Marsan, Politecnico di Torino, Italy Lachlan Andrew, Swinburne University of Technology, Australia Albert Banchs, University Carlos III of Madrid, Spain Luca Benini, University of Bologna, Italy Raffaelle Bolla, University of Genoa, Italy Raffaele Bruno, IIT-CNR, Italy Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Antonio Capone, Politecnico di Milano, Italy Franco Davoli, University of Genoa, Italy Hermann de Meer, University of Passau, Germany Jose Neuman de Souza, Federal University of Ceara, Brazil Lars Dittmann, Technical University of Denmark, Denmark Jaafar Elmirghani, University of Leeds, UK Sebastia Galmes, Universitat de les Illes Balears, Spain Carlo Ghezzi, Politecnico di Milano, Italy Isabelle Guerin Lassous, Universite de Lyon - LIP, France Rune Gustavsson , Royal Institute of Technolgy (KTH), Sweeden Helmut Hlavacs, University of Vienna, Austria Karin Hummel, ETH, Zurich, Switzerland David Hutchison, Lancaster University, UK Yusheng Ji, National Institute of Informatics, Japan Krishna Kant, National Science Foundation, USA Dan Kilper, Bell Laboratories, USA Bart Lannoo, Ghent University, Belgium Laurent Lefevre, INRIA, France Francesco Marcelloni,University of Pisa, Italy Alan Marchiori, United Technologies Research Center, USA Tommaso Melodia, State University of New York at Buffalo, USA Michela Meo, Politecnico di Torino, Italy Enzo Mingozzi, University of Pisa, Italy Daniele Miorandi, Create-net, Italy Archan Misra, Singapore Management University, Singapore Sandor Molnar, Budapest University of Technology and Economics, Hungary Bruce Nordman, Lawrence Berkeley National Laboratory, USA Jitendra Padhye, Microsoft Research, USA Andrea Passarella, IIT-CNR, Italy Marcelo Pias, Cambridge University, UK Mario Pickavet, Ghent University, Belgium Jean-Marc Pierson, University Paul Sabatier, Toulouse, France Daniele Puccinelli, SUPSI, Switzerland Antonio Puliafito, University of Messina, Italy Pedro Reviriego, Universidad Antonio de Nebrija, Spain Brunilde Sanso, Ecole Polytechnique de Montreal, Canada Behrooz Shirazi, Washington State University, USA Domenico Talia, University of Calabria, Italy Luca Valcarenghi, Scuola Superiore S. Anna, Italy Adam Wolisz, Technical University of Berlin, Germany Weigang Wu, Sun Yat-sen University, China Moshe Zukerman, City University of Hong Kong, Hong Kong ============================================== 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