Subject: Re: [dtn] DTN neighbor discovery

From: William Ivancic <[email-masked]>
Date: Fri, 28 May 2021 17:04:04 -0400

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 <[email-masked]> on behalf of "Nordgren, Bryce -FS" <bryce.l.nordgren=[email-masked]>
Date: Friday, May 28, 2021 at 4:27 PM
To: "[email-masked]" <[email-masked]>
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 <[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,
       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

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,
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>
[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>

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 [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: <[email-masked]>
Date: Sat, 29 May 2021 06:56:14 +0000

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 <[email-masked]> on behalf of William Ivancic <[email-masked]>
Sent: Friday, May 28, 2021 11:04:04 PM
To: Nordgren, Bryce -FS; [email-masked]
Subject: Re: [dtn] DTN neighbor discovery

Cheers,

Will

Reading a little closer:

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<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>>

---

From: Loiseau lucien <[email-masked]>
Date: Sun, 30 May 2021 12:19:42 +0200

DTN being transport agnostic, maybe we should try first to reach an
agreement on how to present neighboring information to the DTN layer in a
way that doesn't make assumptions on the underlying cla.

I did write something about convergence layer specific eids (cla-eid) a few
years ago [1]

The idea was to agree on a way to represent a 1-hop neighbor generically.
For instance, a tcpcl neighbor on an IP network would be represented with a
specific eid (something like dtn://tcpcl:192.168.1.2:1234). Such EID would
be fed by a tcpcl specific neighbor discovery protocol (for instance such
as the one described above with zero conf).

Why an EID to represent a dtn neighbor would you ask ? Because by
abstracting the neighborhood in such a way, it would be possible to write
generic link-local dtn application. For instance a dtn routing protocol
could exchange the list of application agent registered on each neighbour
(dtn://tcpcl:192.168.1.2:1234/registered-agents) or the list of all EID
accessible from this neighbour, etc.

We could  propose that every dtn implementation must present a linklayer
table filled only with such cla-eids, then each discovery protocol
implementation would simply maintain/update this table.

[1] https://tools.ietf.org/id/draft-loiseau-dtn-cla-eid-00.html

On Sat, 29 May 2021, 08:56 , <[email-masked]> wrote:

> 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 <[email-masked]> on behalf of William Ivancic <
> [email-masked]>
> *Sent:* Friday, May 28, 2021 11:04:04 PM
> *To:* Nordgren, Bryce -FS; [email-masked]
> *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 <[email-masked]> on behalf of "Nordgren, Bryce -FS"
> <bryce.l.nordgren=[email-masked]>
> *Date: *Friday, May 28, 2021 at 4:27 PM
> *To: *"[email-masked]" <[email-masked]>
> *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:
>
>
>
> 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,
>        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]]
> 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
> 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:
>
> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>
>