[Sis-dtn] IP networking within DTN-based protocol architectures
Tomaso.deCola at dlr.de
Tomaso.deCola at dlr.de
Mon Mar 11 11:39:18 UTC 2024
Hi Felix,
I also agree with you on the fact that the reference is the e2e BP-based architecture with possible IP isolated networks (i.e. islands). As to objective of this discussion, my understanding is that a target could be a SIG (either in SIS or in SEA as from your suggestion). I also think the idea of a WG is not really suitable. Then as to running terrestrial services or even making use of terrestrial standards (wifi, 3gpp, etc.), this is something being addressed in SOIS, so probably not so suitable for SIS. Actual transportation of “terrestrial” services such as http, email, etc. over BP (though certainly interesting) I don’t see as real mission of CCSDS standardization process, maybe for IETF.
Just for the sake of the discussion, the colleagues from Nanjing University could say a few words more about their idea so that can exactly see whether and how to move on.
Best Regards,
Tomaso
Von: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> Im Auftrag von Felix Flentge via SIS-DTN
Gesendet: Montag, 11. März 2024 11:40
An: sburleig.sb at gmail.com; Mayer, Jeremy <Jeremy.Mayer at dlr.de>; vint at google.com
Cc: sis-dtn at mailman.ccsds.org
Betreff: Re: [Sis-dtn] IP networking within DTN-based protocol architectures
Hi,
On the the IP / BP Networking discussion:
1. I believe from CCSDS / IOAG / IPNSIG perspective (please correct me if I am wrong), we see BP as the E2E (inter-)networking protocol (see, eg IOAG Recommendations on the Selection of ETE Space Internetworking Protocol (002).pdf<https://www.ioag.org/Public%20Documents/IOAG%20Recommendations%20on%20the%20Selection%20of%20ETE%20Space%20Internetworking%20Protocol%20(002).pdf>). As such, I would see IP networks eg on lunar surface as isolated Local Area Networks without IP routing into other IP networks. As pointed out by Jeremy, we should avoid (naïve) IP / BP encapsulation.
2. For CCSDS / IOAG we should focus on the near- to medium-term use case. For me this means mainly spacecraft M&C, bulk data downlink, voice&video, teleoperations, last-hop/first-hop, messaging. Of course, it is interesting to think and experiment with terrestrial applications over BP but I don’t believe this should be an CCSDS / IOAG task priority right now.
3. We need to be aware of the on-going activities, in particular LunaNet Interoperability Specification and IOAG Work (SC#2 update; I will present at spring meeting). IMHO, we might already have to many WG related, so I am not in favour of creating a new one.
4. It certainly would make sense to consider the IP / BP networking case in the SEA architectures (with support from DTN WG)
Regards,
Felix
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of sburleig.sb--- via SIS-DTN
Sent: Saturday, March 9, 2024 6:56 PM
To: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>; vint at google.com<mailto:vint at google.com>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] IP networking within DTN-based protocol architectures
Thanks for that analysis, Jeremy. We’ve been talking about at least since STINT several years ago, and I really think it’s an idea whose time has come.
Scott
From: Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de> <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Sent: Saturday, March 9, 2024 8:01 AM
To: vint at google.com<mailto:vint at google.com>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>
Cc: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] IP networking within DTN-based protocol architectures
Hi,
That’s a fair point. Generally, I’d say that BP-POSIX could work with the following:
· Bind – works: sets source EID.
· Listen – works; sets source EID and opens reception.
· Connect – UDP style, sets default destination address.
· Send – only valid for connected bundlesocks.
· Sendto/sendmsg – works.
· Recv – works.
· Recvfrom/recvmsg – works, probably should support “wildcard” EIDs, at least for services.
· Getaddrinfo and friends – not required
· Select – Works, highly implementation dependent.
BSD sockets really do work for everything!
Thanks,
Jeremy
From: Vint Cerf <vint at google.com<mailto:vint at google.com>>
Sent: Samstag, 9. März 2024 16:51
To: Scott Burleigh <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>
Cc: Mayer, Jeremy <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>; de Cola, Tomaso <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>; Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: Re: [Sis-dtn] IP networking within DTN-based protocol architectures
Yes generally speaking
On Sat, Mar 9, 2024, 10:43 <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>> wrote:
I think we get closer to BSD/POSIX if we use UDP as a model. The attenuated UDP notion of connect() would work for BP, I think.
Scott
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Jeremy Mayer via SIS-DTN
Sent: Saturday, March 9, 2024 12:35 AM
To: vint at google.com<mailto:vint at google.com>; Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] IP networking within DTN-based protocol architectures
Hi,
I’m tempted to agree. I’ve seen limited utility in IP->BP encap, as (other than some unidirectional UDP-based applications), the assumptions made in IP networks (especially TCP) do not scale well to DTN environments. The two largest issues I see are:
A. The assumption that relatively low-latency and bidirectional communication is available.
B. The layering of stream and message-based semantics.
Almost every TCP-ish application which I’ve seen run over BP winds up with exceptionally low performance, unless some sort of PEP is integrated, which adds complexity, failure points, and fragility.
+1 for the notion of a standard API though, with the additional caveat that we should standardize nomenclature across implementations. We could likely reuse about 80% of the BSD/POSIX interface for BP, with the notable exception of connect.
Thanks,
Jeremy
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Vint Cerf via SIS-DTN
Sent: Freitag, 8. März 2024 12:31
To: de Cola, Tomaso <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] IP networking within DTN-based protocol architectures
The more I think about this, the less I like trying to manage off-Earth IP networks remotely. I think I would much rather see native applications running over BP. In any case we need to develop standard APIs for BP, such as the Sockets interface for Linux/Unix/Posix.
We do need to figure out how IP-based and BP-based applications interwork. What do Domain Names mean in the BP context for example.
v
On Fri, Mar 8, 2024 at 4:24 AM Tomaso de Cola via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> wrote:
Dear All,
as mentioned yesterday during our DTN weekly, during the past Fall meeting a presentation was given by University of Nanjing with the support of Chinese agency about IP-networking within DTN-based protocol stacks, especially for planetary network segments (i.e. what is often referred to as IP-islands).
The link to that presentation is as follows:
https://cwe.ccsds.org/sis/docs/SIS-DTN/Meeting%20Materials/2023/Fall%202023%20SIS-DTN/Possible%20BOF%20Discussion.pptx?d=w44d31f0b3be649e4bf24ec4ae50479a1
The proposal made there was for a BOF (i.e. towards a WG formation), which I see however too premature. On the contrary, I’d be more in favour for a SIG (Special Interest Group), happening outside the DTN WG.
As discussed yesterday, key points to clarify/agree are:
1. Is the proposal sound and meaningful to be addressed?
2. Is appropriate for the SIS area or should be better addressed at architectural level in SEA (maybe it can be even a cross-area initiative)?
3. In the case of SIS, is there significant support to start this? In other words, which agencies have interest in contributing to this activity?
Thank you for sharing comments/objections/suggestions.
Have a nice weekend,
Tomaso
————————————————————————
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D. | Integrated Satellite Systems (INS) Team Leader
Telefon +49 8153 28-2156<tel:+49%208153%20282156> | Telefax +49 8153 28-2844<tel:+49%208153%20282844> | tomaso.decola at dlr.de<mailto:sandro.scalise at dlr.de>
http://www.dlr.de/kn/institut/abteilungen/san
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346
until further notice
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240311/c79c4a5f/attachment-0001.htm>
More information about the SIS-DTN
mailing list