Re: [dtn] DTN neighbor discovery

Loiseau lucien <loiseau.lucien@gmail.com> Sun, 30 May 2021 10:20 UTC

Return-Path: <loiseau.lucien@gmail.com>
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 A04153A3755 for <dtn@ietfa.amsl.com>; Sun, 30 May 2021 03:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.254
X-Spam-Level:
X-Spam-Status: No, score=-0.254 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1, WEIRD_PORT=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 D9rGgwtDJf0O for <dtn@ietfa.amsl.com>; Sun, 30 May 2021 03:19:55 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC5C3A3752 for <dtn@ietf.org>; Sun, 30 May 2021 03:19:55 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id l18-20020a1c79120000b0290181c444b2d0so4808091wme.5 for <dtn@ietf.org>; Sun, 30 May 2021 03:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFbd+cGK90MvW+te9wM5dGRSl7nSXNgdABZNzNKm5JI=; b=X60OOInHVFx64WR5DF1fpeRN2CF0VImu/U/MdoE0fyfrI3pD8q/GxzxQHy6XW80Eil Mv3P9NiuysoB8p7gVoyMySiGFdHEyVODgEB5LtvCM+o1XwkOY0zPucZYfokLjRiaa4eo muZrNmTb6RKQVgNhxLthZ7BdZtJE4SMpEsecM387QTZmOTzxvF9N3UALCJGKi+rXJSJP ZHfn7gbZoQaOg/6FGUSp0KriuuQdOnpijOBHysvzvMiTCLCsC200H3yQsDI1WbeQBilL swJTXVVISp8wON9rjwe2C2ubYXZh7TYJjB1eEZNGZT/w7xUz+IFliRGG9uEFAN2BkstE I7JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sFbd+cGK90MvW+te9wM5dGRSl7nSXNgdABZNzNKm5JI=; b=OT+Np6Np/6vGmMBXtBSSbvZb1XvI7gjUXtbpgDMKbvTRJ/4of6JEnctwcf0vUU8GwW G5Jr8sA0LFeuSPdx01iLjWJ5CbWGgwI28zfmWdRqnqgZMSgX4MV7ngaoyZvKN0XnbTVs 0InThIKKg3FDXj0Gj+2AlbKGMZdf3JiX6mrjZWUSiJZu938hp+FriBVusmrNHU8rlaUO TBqjRWFTWnIokA9uW2Feg4xtY5YrBTUlGpbn+BLN/f/A7wbtDJmaAti4ONbPFReoTgjK PeZWfKL26v/aoAfLyGxSwj/kdcxx8CrZCAbwjv9G/YjQjyt+4Lm6BoJIeUnruA47J7J1 Nslg==
X-Gm-Message-State: AOAM530mEzZUjbED/ayy3AOsoFazCaWDg2/jDe0zv84d7rmZAbTvNRfC jWqCviQFlXp7HJpazwrsV12anQJC9/nV+Jvz1m0=
X-Google-Smtp-Source: ABdhPJw7M++xnDeAogdnWs25FpjHVn6S6pY5lnOvXwE6oA4yHizz+u97UptKidNY6ZrcsL32xVJ0ehFEk4uVqCJA3+E=
X-Received: by 2002:a05:600c:4e90:: with SMTP id f16mr12636905wmq.116.1622369993108; Sun, 30 May 2021 03:19:53 -0700 (PDT)
MIME-Version: 1.0
References: <91F2A11F-7442-41C3-98D7-516563F30A32@syzygyengineering.com> <3cefe47a6c284d09854808d4a7159cfa@dlr.de>
In-Reply-To: <3cefe47a6c284d09854808d4a7159cfa@dlr.de>
From: Loiseau lucien <loiseau.lucien@gmail.com>
Date: Sun, 30 May 2021 12:19:42 +0200
Message-ID: <CANoKrvYzUWT1puKR8CHHExpVwfuf0wtaVxFAyE==VTQVbuqyxg@mail.gmail.com>
To: Jeremy.Mayer@dlr.de
Cc: ivancic@syzygyengineering.com, bryce.l.nordgren=40usda.gov@dmarc.ietf.org, dtn@ietf.org
Content-Type: multipart/alternative; boundary="00000000000022325105c389736f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/iAuir5IxyZ_CSVIL4J-Niul6MwU>
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: Sun, 30 May 2021 10:20:01 -0000

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 , <Jeremy.Mayer@dlr.de> 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 <dtn-bounces@ietf.org> on behalf of William Ivancic <
> ivancic@syzygyengineering.com>
> *Sent:* Friday, May 28, 2021 11:04:04 PM
> *To:* Nordgren, Bryce -FS; dtn@ietf.org
> *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 <dtn-bounces@ietf.org> on behalf of "Nordgren, Bryce -FS"
> <bryce.l.nordgren=40usda.gov@dmarc.ietf.org>
> *Date: *Friday, May 28, 2021 at 4:27 PM
> *To: *"dtn@ietf.org" <dtn@ietf.org>
> *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 <carlo.caini@unibo.it>
> *Sent:* Friday, May 28, 2021 11:47 AM
> *To:* Nordgren, Bryce -FS <bryce.l.nordgren@usda.gov>; dtn@ietf.org <
> dtn@ietf.org>
> *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 [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://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
> dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>
>