Re: [dtn] DTN neighbor discovery

Carlo Caini <carlo.caini@unibo.it> Fri, 28 May 2021 17:47 UTC

Return-Path: <carlo.caini@unibo.it>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6523A2FDD for <dtn@ietfa.amsl.com>; Fri, 28 May 2021 10:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unibo.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N5DP2OnuJ75 for <dtn@ietfa.amsl.com>; Fri, 28 May 2021 10:47:05 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2136.outbound.protection.outlook.com [40.107.20.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8943A2FDC for <dtn@ietf.org>; Fri, 28 May 2021 10:47:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hoFftgGtuzcv6uB3qjxipfLpjRxlNAOqKX80vPhYO2DQ4X+ciPRq7J+tvfhBuxFnxHBwN6T4SLx87C8p4uOWx7PC5J/6mY8o938gVxaC4eGMc56YkS0ky5VnUxQvpom1DwhNrW7wWAodldQepHJoh4bGyawvKaJAaoIxGPP2zj4ztuJvHFxuyApCDyqkTLtGpjMPcVNdBKbK+5X4ufe0inP3g5ZSRyArsT+Mi3GT9iLHFg79ctGyyQlBIsuoSeSPH0fqvX8qhwoEdOtLdUhBn7w5VUEI7bEXVMokueKiFWXv/q0nj612UtbfnYkq+7EyGrPwuUPJ/g5KxdO8FNqwsA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vonTPCx6Nb02AjTyoPcWDsSVxd1YuOnJetdUWTgCu20=; b=egOy0nZtk0YtRORszXAoCuYtRIS9LXpJaPSKjI8G9WPuC4Hz2yMkzDN/UKpc17ORa7WNURMwWur/9OWAxVs7xEVs7A4xidGoSKKVlt1BgdjgsQ/eClFS788BstumH0uRknjLupcVBvAfW5BxuKMTZWyQpjg9QVPUd4YYZX/2iNt10lLuFRjIryMXaF5n7E9mkE1OFD1ofzT2ZTaumO1nXufIUbkNGCF9lXASH1rh+9pyRNs3WA+oANJzhvkdZgXFGtMtFKQyI+Pv2NcLqSlLYoMrMhY/5jrRrX+2TxvarGzirIQvZgUQuHQBD1AjkhX40OKeap+afWekBrpn46la+A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=unibo.it; dmarc=pass action=none header.from=unibo.it; dkim=pass header.d=unibo.it; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unibo.it; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vonTPCx6Nb02AjTyoPcWDsSVxd1YuOnJetdUWTgCu20=; b=cR9tm3g5XGaEqx2EOvu+OVctDH3dp6VMxEEFiT/GbnLVMP+yN5ahv/F6qkiawJ80kdtMWPR+vM5WOgNlkx+VQoHkRAxvaL5JiXD7/R6L1FZbeyH77viNLsIVnRBsKgvg5oP1yXYosQPKf+yukM9RsB804qJXDSABTePHteG0U2A=
Received: from AM8PR01MB8134.eurprd01.prod.exchangelabs.com (2603:10a6:20b:325::20) by AM9PR01MB8152.eurprd01.prod.exchangelabs.com (2603:10a6:20b:413::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Fri, 28 May 2021 17:47:02 +0000
Received: from AM8PR01MB8134.eurprd01.prod.exchangelabs.com ([fe80::55f2:b76f:f73f:826f]) by AM8PR01MB8134.eurprd01.prod.exchangelabs.com ([fe80::55f2:b76f:f73f:826f%5]) with mapi id 15.20.4129.036; Fri, 28 May 2021 17:47:02 +0000
From: Carlo Caini <carlo.caini@unibo.it>
To: "Nordgren, Bryce -FS" <bryce.l.nordgren=40usda.gov@dmarc.ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: DTN neighbor discovery
Thread-Index: AQHXU1HsQHbPMm3+K0+bDTwooa6nBar4+ui/gAAsS18=
Date: Fri, 28 May 2021 17:47:01 +0000
Message-ID: <AM8PR01MB8134D4AB1457707114BE0F8B87229@AM8PR01MB8134.eurprd01.prod.exchangelabs.com>
References: <MN2PR13MB3567435F3FFEA4BFE65EF4E39F239@MN2PR13MB3567.namprd13.prod.outlook.com>, <MN2PR09MB6011373E82C903AD18269EA1A3229@MN2PR09MB6011.namprd09.prod.outlook.com>
In-Reply-To: <MN2PR09MB6011373E82C903AD18269EA1A3229@MN2PR09MB6011.namprd09.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=unibo.it;
x-originating-ip: [137.204.143.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1b0cd213-fd7a-406a-9d0d-08d922009984
x-ms-traffictypediagnostic: AM9PR01MB8152:
x-microsoft-antispam-prvs: <AM9PR01MB81524936BC79EE23AF56F80B87229@AM9PR01MB8152.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: f4gQmX9LBwQjim5Tm0lSRfe9203A9+GpD3fsQ9dt45FXz2+sMenUdsHQ5WoC5XLy9+TdM400iQm4t1NOcbL1lVZ5NcmsroKZHPA3C2SBMdHTTJkomNJZ4nialeMzRyHIOM0lOvyqf2yrxSVOF+425U9nXZgwf/Goj1ms/21c/ruSpV0cnbgOtLvku86BMyp/qm+bxEu1WMar3BLaPlazxkK4QGzhNS1fMWEUS94z3/A3QStaP1qIZhKFQCwereU5ZGuYMQ38OkLKzPQM6Rf3QGJaIseH5C8P9FP0Fvt02CCrwogsKnol3bGx/HOhfaHOV9+64TnVCphWJ2jtDSbk15uOlb/HXIkcJBnlIsV4EQtaih5qVDMy+WsQ68SBDsditGS/5exaPce3TcrAa8yYFuhu0sZ5qonEqnSTZySONrDQgLFcyQJqWzOAOKCzmUjp5uuiIuaZeHcvFm+IHGiJIIbVSBGUQwl/6+TcWYrKuNCS/MXgS+erTDl4jH5nd8drnrlszpSfUNG+9IKAhbA9IdGQ0KomyaM78IKA5Jd1sQhrsF1oCK8brUAiDd5wBiC8j5wtJ87HUMITdg4N8fJ3pAUhQWZjyDNxroQqeR/3JDMncPXJehf11+nRgsitvzEQY0Vchl0QGHr8M1d9w3ZNpinSHCOuPTBTU5tambiOvkOK12RFaAD4qosLjnW2XqoK6eAeNRCFjiI4QKtUWvUV+A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR01MB8134.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(396003)(366004)(346002)(44832011)(8676002)(76116006)(66946007)(66556008)(64756008)(66446008)(66574015)(66476007)(7116003)(83380400001)(71200400001)(33656002)(122000001)(478600001)(3480700007)(38100700002)(5660300002)(966005)(86362001)(186003)(2906002)(6506007)(53546011)(52536014)(8936002)(26005)(55016002)(316002)(9686003)(110136005)(7696005)(786003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 0MZunAw19X+LupYzJ4mDv6hZP0XTsB1N76KnQxF+M1XpW1j/yn53lJROGf4c4RpmM7QPtYPMZ9d1Q85E8Aw0FMoFFbuVZ5VfXfrDf4X8nW5hIm8wUxSEl39CB+5u5meQA7loNmzYqQMSpWX4jW5VsTcBOJHzmQtfwGJg9LuhmT1xlP8fD0xfJlKk75ww/mvgKmlbubUmQWI9UOez7lkX8HYBLb+5JqWfpM6ExYRUJDQVtLdGON0cED8YFfRMxNiIKOszBsc7zEJ6fFJS1qN12J648XgBtW0CqhOS2XE2l2xZLBVY4A5UMOitDF847msTILoXArMxZcEZTvGYQnTI6aNiLZ356Y7Y+xlrKQd/yr4ZaXqda4ZD9UXQgVMkfQCPm1cT418+QoeiMJJ4GhiCQd8BltBgQKDjNaS5+lsTIxyP75EeciLk5XGALmI9dlIklUxA06AZfYEKOuTIm5wFvAQXuiPp2a8u1ooGReH3p5hL5GbM0SwjtHlQlgbY+mRuEz0xu6si2Nphtz91NLpxuNGt5cR3zRCU8jHdNwJNJRkdoRxMZlISH1uSWUi34IyRWD2uj+aTgOjZI186ScMXz6qYFKkjKfQAB9FEryIq9YQuX3JFtSJeOc5Oz2OVR1jPDdygouG5Iz0mc8YNluDCO3fymfa4VI2RF6eYyL8wUgJC3L5REcHoacYhVnFGKeiXXb4lsP751HnSG5C1X6Br5A9GCm55Cpzp/1per5jPQRKDKX5YZT1fjrj+HcrCEsDcs1sGhNWLI8utOSrVw3CRM4KeRd8dK0ZA/1FzD4czNKD7aOWxnh9jD4o3EKFyOg4U2lfv6/K0DUEuvuSDR1spfSYbYMqDiMU1c+Z7uGs1enA4mo0ujM42xFtIBf38qwcfRhhBn0m1P7LMzpkkp0tlcuf2EKajFG8gsQyopUdWX8WchfhLd+iGdHWvU8mJMZBv6JN0FbdcwnZC7lSmeNEt9qR0Yzcv+tCCVxvUWCgOitw9MrMGlAseIF+ZHbNLqhQ6TmiCEtMqsbA+qZecg/G833GDzxxQmGxAZPGFRlxdy9M1G/zzq9pSFXq9ZDjo/Blcp2mtuDDnga1qgLHSWV5Lzffqr7maHRIOu/jqWOHeo4S3TJ+zgrLnDs9Qj2G5p9x196m9fyld0I+1irmxw7GcXZkMZPc9Q36reEAlGRRNw8Aaq4XdCQsZzqC4lQEssuT+sB0/HEyEQAoB4uIUDcKUkiiKbCDq1Zd+DTkAqPZNl8VHvwYlB7ZhYYs59G+MixCqXZH5Qgn8JbrU/nHEojVi87AKCbqYpRboWrDkhivNFDCBfnM1diSta+Rzzn0jljBw
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: unibo.it
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8PR01MB8134.eurprd01.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b0cd213-fd7a-406a-9d0d-08d922009984
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 17:47:01.9509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e99647dc-1b08-454a-bf8c-699181b389ab
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Kz3XIDQfAmoqNUVVmCPIHXM0gXSiOqla1zIGzPIuaBF94nQ2JEdq13FyccarAC0tXHwk45Mq+3+bpBkekgghBQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR01MB8152
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/VCKjkvJz77SSmpEZ472a4Wh0swY>
Subject: Re: [dtn] DTN neighbor discovery
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 17:47:11 -0000

Dear Nordgren,
       in my uderstanding, neighors are nodes that can be reached in one DTN hop, which may coincides or not with an IP hop (provided you have IP nodes). A DTN hop is defined as the segment of a path between two consecutive DTN nodes. 
Let me introduce an example: my PC could be a DTN node (BP running on it), NASA-JPL another, a Lander on Mars a third, a rover on Mars the fourth.
We would have 3 DTN hops, the first terrestrial, between my PC and NASA-JPL, the second in space (NASA-JPL-Lander), the last on Mar (Lander-Rover).
That said, my PC, in Italy, and NASA-JPL, in LA, do not obviously belong to the same LAN (they arec quite far away, indeed) , but NASA-JPL could be a proximate node to my PC, as it could be reached in one DTN hop (e.g. by means of TCPCL). One DTN hop and not many, because not all IP nodes (Internet routers) are necessarily DTN nodes. It would be useless, and in fact they are not.
In space you can perhaps assume that all nodes are DTN nodes (e.g. they have a BP agent). However, in this case you cannot assume that delay is short, an/or that you have no disruptions, a huge bandwith etc.
E.g. on the second leg, between NASA-JPL and the Lander, you cannot use TCPCL, have likley limited and asymmetric bandwith, a few minutes of delay, possibly losses, intermittent connectivity, i.e. all challenges for which DTN have been designed.
Yours,
   Carlo
 

________________________________________
Da: dtn [dtn-bounces@ietf.org] per conto di Nordgren, Bryce -FS [bryce.l.nordgren=40usda.gov@dmarc.ietf.org]
Inviato: venerdì 28 maggio 2021 17:44
A: dtn@ietf.org
Oggetto: Re: [dtn] DTN neighbor discovery

Correct me if I'm wrong...because I've no prior exposure to that ID and just learned about it with your message.

My assumption (because the document on Neighbor Discovery does not appear to define the term "neighbor") is that the "neighborhood" would be the LAN and the "neighbors" are BP nodes locally attached to the LAN and communicating via either TCP or UDP. The neighborhood may support permanent residents as well as transients popping up on the WiFi or wired ethernet. The discovery protocol is primarily useful for letting the permanent residents and the transients connect with each other without a priori configuration.

So, "neighbors" are locally attached nodes with high bandwidth, low latency, always-on connections. "Neighboring towns" are those locations where the defining characteristics of BP's environment apply: low bandwidth, high latency, scheduled, opportunistic or intermittent communications, or bundle delivery by physical transport. "Permanent residents" include local services as well as BP nodes attached to some kind of communication infrastructure (i.e., the Internet, one end of a point-to-point link, etc.) "Transients" include BP nodes used as data mules to physically carry bundles. The objective of having these different types of neighbors talk to each other is that they can cooperate to move bundles closer to their destination using whatever mode each node is capable of.

If this is the case, might it be advantageous to leverage the infrastructure around XMPP or something similar? Set up a discoverable XMPP server to serve as a town square, and let the messaging draft define things which would appear on a "ride board".  (i.e. BP nodes can declare their intentions to travel to neighboring towns; or an ability to communicate directly with other places--continuously or on a schedule.) Transient nodes can be confident that they will travel on a reliable schedule, such as devices attached to trains or busses. Or they can advertise a list of places they believe it likely they will visit, such as smartphones belonging to personnel in an incident command post, who may travel to any of a number of incident sites depending on what is needed that day. If XMPP is used for presence, perhaps the pubsub protocol extension could serve to disseminate bundles to all BP nodes advertising an intention to visit the desired neighboring town?

Just spitballing. Seems like neighbor discovery, as defined above, has already been done, and what's needed here is a clearer picture of how neighbors, once discovered, cooperate to move them bundles.

Bryce
________________________________
From: dtn <dtn-bounces@ietf.org> on behalf of Brian Sipos <BSipos@rkf-eng.com>
Sent: Thursday, May 27, 2021 7:57 PM
To: Velt, R. (Ronald) in 't <ronald.intvelt@tno.nl>; dtn@ietf.org <dtn@ietf.org>
Subject: [dtn] DTN neighbor discovery

Ronald,
As a follow-on to the interest in advancing IRTF IPND [1] to an IETF document, I was looking at this earlier and think it would be beneficial to separate the concerns of:

  1.  The neighbor messaging payload with discovery information
  2.  Framing of the payload with security (e.g., source signing), data lifetime, etc.
  3.  The transport of that packet via broadcast, multicast, or even unicast

If layer #2 is performed by BPv7, then BPSec provides security and #3 can be done with a BP convergence layer. This gives a huge benefit that all of the mechanisms of BP, BPSec, and CLs can be leveraged. It also avoids needing a separate UDP port or broadcast address assignment for DTN neighbor messaging and allows the neighbor messaging to apply to IP and any other network type usable by BP.

I have a very rough draft of layer #1 in a public repository [2], nothing in there is settled at this point other than "it uses BPv7 as framing/security and UDPCL for transport" so it's not submitted as an actual I-D. Let me know what you think about this. If it's worth progressing you're welcome to comment and/or contribute to the draft.

Thanks,
Brian S.

[1] https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-ipnd-03<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&data=04%7C01%7C%7Cc53afe844a5745b1fe4d08d9217c12a6%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637577639038189958%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ju549SdklB0Bk4uQ27wxAKWg5RPiVk7cBCglnuZ7lJ4%3D&reserved=0>
[2] https://briansipos.github.io/dtn-neighbor-msg/draft-sipos-dtn-neighbor-msg.html<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbriansipos.github.io%2Fdtn-neighbor-msg%2Fdraft-sipos-dtn-neighbor-msg.html&data=04%7C01%7C%7Cc53afe844a5745b1fe4d08d9217c12a6%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637577639038199915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8XKxyaUR2hMmBULyB2v8u9wisi3VQS0kVmaZ%2Bkasp0o%3D&reserved=0>




This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.