Re: [dtn] DTN neighbor discovery

[Brian Sipos <[e-mail]>]

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 <[e-mail]> on behalf of Nordgren, Bryce -FS <bryce.l.nordgren=[e-mail]>
Sent: Friday, May 28, 2021 11:44
To: [e-mail] <[e-mail]>
Subject: 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 <[e-mail]> on behalf of Brian Sipos <[e-mail]>
Sent: Thursday, May 27, 2021 7:57 PM
To: Velt, R. (Ronald) in 't <[e-mail]>; [e-mail] <[e-mail]>
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://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>




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.