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&data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&reserved=0 > <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&reserved=0%3chttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-irtf-dtnrg-ipnd-03&data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gOg070dsNhFV2V65JdIMteVy4GgG6b7y%2Bs2jjay2u18%3D&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&data=04%7C01%7C%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%3D&reserved=0<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%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%3D&reserved=0 > <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%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%3D&reserved=0%3chttps://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%7Ca0893e1f5d8f46fe7a3508d92200a014%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637578208355382317%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=121T6RxBA9GpqmaIHnQbWZnfjFkgUFfgYitQYVbK8Xk%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. > > _______________________________________________ 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 > >
- [dtn] DTN neighbor discovery Brian Sipos
- Re: [dtn] DTN neighbor discovery Nordgren, Bryce -FS
- Re: [dtn] DTN neighbor discovery Carlo Caini
- Re: [dtn] DTN neighbor discovery Nordgren, Bryce -FS
- Re: [dtn] DTN neighbor discovery William Ivancic
- Re: [dtn] DTN neighbor discovery Brian Sipos
- Re: [dtn] DTN neighbor discovery Jeremy.Mayer
- Re: [dtn] DTN neighbor discovery Loiseau lucien
- Re: [dtn] DTN neighbor discovery Velt, R. (Ronald) in 't