Subject: [dtn] DTN neighbor discovery

From: Brian Sipos <[email-masked]>
Date: Fri, 28 May 2021 01:57:57 +0000

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
[2] https://briansipos.github.io/dtn-neighbor-msg/draft-sipos-dtn-neighbor-msg.html

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Fri, 28 May 2021 15:44:26 +0000

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 <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Thursday, May 27, 2021 7:57 PM
To: Velt, R. (Ronald) in 't <[email-masked]>; [email-masked] <[email-masked]>
Subject: [dtn] DTN neighbor discovery

Ronald,

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.

---

From: Carlo Caini <[email-masked]>
Date: Fri, 28 May 2021 17:47:01 +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 [[email-masked]] per conto di Nordgren, Bryce -FS [bryce.l.nordgren=[email-masked]]
Inviato: venerdì 28 maggio 2021 17:44
A: [email-masked]
Oggetto: Re: [dtn] DTN neighbor discovery

Bryce

Ronald,

Thanks,
Brian S.

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Fri, 28 May 2021 20:26:38 +0000

The neighbor discovery draft is titled "Internet Protocol Neighbor Discovery" and seems largely based on the notion of sending Beacons as UDP packets. It's assuming you have IP nodes.

Reading a little closer:

Broadcast beacons are designed to reach unknown neighbors in
   neighborhoods within the local network broadcast domain.

It seems this draft is trying to focus on "neighbors" defined as BP nodes on the same LAN, unless I'm reading it wrong. I still think a local XMPP server could perhaps serve the "Discovery" purpose.

It does not seem that this draft could scale to all internet-connected BP nodes (and therefore allow your computer to discover JPL's node). A publicly hosted XMPP server, however, could...

________________________________
From: Carlo Caini <[email-masked]>
Sent: Friday, May 28, 2021 11:47 AM
To: Nordgren, Bryce -FS <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: DTN neighbor discovery

Dear Nordgren,

Bryce

Ronald,

Thanks,
Brian S.

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&amp;data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&amp;data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&amp;reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbriansipos.github.io%2Fdtn-neighbor-msg%2Fdraft-sipos-dtn-neighbor-msg.html&amp;data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbriansipos.github.io%2Fdtn-neighbor-msg%2Fdraft-sipos-dtn-neighbor-msg.html&amp;data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%3D&amp;reserved=0>

---

From: Brian Sipos <[email-masked]>
Date: Fri, 28 May 2021 21:49:35 +0000

Bryce,
This document is attempting to steal nomenclature from MANET NHDP, but certainly is missing a lot of introductory "meat" and definition of terms. In that sense a DTN "neighbor" is a node which can be reached in one hop of some CL, as you described. There's no reason why they need to be on the same LAN, but when using UDPCL as CL they would need to be in the same IP multicast group (which can span IP routing boundaries, depending on how routers are configured).
This is another way I think lifting up DTN neighbor messaging on top of BPv7 is useful: (DTNRG's) IPND will be confounded by some types of routers and firewalls while DTN-ND can cross IP routing, NAT, and (BP-allowing) firewall boundaries using non-UDP-multicast CLs.

Again stealing from the NHDP, this current document restricts a "neighborhood" to mean a two-hop topological region; there's no intrinsic reason for limiting to two hops but it does reduce the size and rate of discovery messaging.

One thing to be careful of when thinking of DTNs is that CLs can be unidirectional, or asymmetric in connectivity or throughput. So a neighbor really just means "a node you have directly heard from on a CL," not necessarily one you can directly transfer bundles to. It seems like MANET NHDP also captures this kind of asymmetry well (i.e., HEARD vs SYMMETRIC contact) so stealing terms from there seems useful.

________________________________
From: dtn <[email-masked]> on behalf of Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>
Sent: Friday, May 28, 2021 11:44
To: [email-masked] <[email-masked]>
Subject: Re: [dtn] DTN neighbor discovery

Bryce

Ronald,

Thanks,
Brian S.

[1] https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-ipnd-03<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&data=04%7C01%7CBSipos%40rkf-eng.com%7C215bdc6e99a943f1268508d921ef8442%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637578135345837216%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6UZqD9tLrWVaonbMLUxHuiEefSQg%2BblMuU8fHcc4%2By8%3D&reserved=0>
[2] https://briansipos.github.io/dtn-neighbor-msg/draft-sipos-dtn-neighbor-msg.html<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbriansipos.github.io%2Fdtn-neighbor-msg%2Fdraft-sipos-dtn-neighbor-msg.html&data=04%7C01%7CBSipos%40rkf-eng.com%7C215bdc6e99a943f1268508d921ef8442%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637578135345847209%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oG3Ds98mmFJStXUK45rvCG4y2nkksW0b1DKf9BYNBe8%3D&reserved=0>