Re: [dtn] DTN neighbor discovery

[[e-mail]]

Hi,

Agreed; I am also willing to bet that there are going to be multiple ways to solve this. Service discovery in IP networks is a largely-solved problems, even in light of changing network topologies. I don't think this is a problem that deserves a solution specifically designed for DTN; if you told me to integrate neighbor discovery into a DTN network across a single controlled LAN, I would probably just use Consul/DNS/ZeroConf as an ancillary service,  and let the network nodes query the service mesh for endpoint:IP mappings.


For WAN-scale applications, centralized registries of "known entities" are generally dangerous, since they inherently require intense authentication requirements. If we had a XMPP Server with a schema to define visible nodes, the question always becomes: "How do you validate my identity, i.e. how do you know that I'm actually JPL as opposed to an imposter". In a semi-controlled WAN environment (such as a large network amongst vetted peers), you can treat the network as an egalitarian commune and establish identity via n:m vetting and/or a centralized identity manager. That being said, for less controlled environments, the work done by the ICN folks may be appropriate to the DTN world.


Once you've established a connection between two nodes, then a generic version of IPND might be appropriate. In other words, the CL should be able to announce which nodes/regions are "behind" it.


In summary, I totally agree with Will here: we're poking a bear if we start to come up with solutions without a thorough analysis of the "where/what/whys" of DTN neighbor discovery, and an equally robust (set of) interoperable solutions across the various parts of this problem space.


Thanks,

Jeremy

________________________________
From: dtn <[e-mail]> on behalf of William Ivancic <[e-mail]>
Sent: Friday, May 28, 2021 11:04:04 PM
To: Nordgren, Bryce -FS; [e-mail]
Subject: Re: [dtn] DTN neighbor discovery


Sorry to spoil the party, but, IMHO, if we truly want to make progress on neighbor discovery, we need a Concept or Concepts of Operations (what environments DTN is going to operate in), a Problems Statement (based on the Concepts of Operations) and then a Requirements Document including definitions of terms such as what is a neighbor?  Without this homework, individuals will constantly be talking past each other and the problem will be unbounded and therefore have a near zero solution space.

Cheers,

Will
From: dtn <[e-mail]> on behalf of "Nordgren, Bryce -FS" <bryce.l.nordgren=[e-mail]>
Date: Friday, May 28, 2021 at 4:27 PM
To: "[e-mail]" <[e-mail]>
Subject: Re: [dtn] DTN neighbor discovery

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 <[e-mail]>
Sent: Friday, May 28, 2021 11:47 AM
To: Nordgren, Bryce -FS <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: DTN neighbor discovery

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 [[e-mail]] per conto di Nordgren, Bryce -FS [bryce.l.nordgren=[e-mail]]
Inviato: venerdì 28 maggio 2021 17:44
A: [e-mail]
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 <[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://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<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%3chttps://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<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%3chttps://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>>




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.
_______________________________________________ dtn mailing list [e-mail] https://www.ietf.org/mailman/listinfo/dtn