[Sis-dtn] [EXT] Re: Clean version of the CCSDS BPv7 Red Book draft

Fri May 13 15:49:23 UTC 2022

If you’re talking about APPLICATIONS A and B I concur.

The bundle *node* serving application A absolutely does (IMHO) need to understand the ‘local’ communications characteristics and to choose an (appropriate) CLA for transmission.  TCP could very well be the right answer (node A is a payload on Gateway sending to the bundle node that serves as the Gateway gateway, sending over 1Gbps Ethernet).

                                --keith

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of sburleig.sb--- via SIS-DTN <sis-dtn at mailman.ccsds.org>
Date: Friday, May 13, 2022 at 9:46 AM
To: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>, Felix.Flentge at esa.int <Felix.Flentge at esa.int>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] Re: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book draft
Thanks, Tomaso, I think this raises an extremely important point.

Suppose entity A, located somewhere in the Solar System Internet, wants to send a message to entity B, likewise located somewhere in the Solar System Internet.  I believe we do not want to require that A always know in advance the location of B (or, worse, be required to query for the location of B) in order to send the message.

If this is the case, then A does not know whether B is 43 light minutes away or in the next room.  All it knows is which topologically adjacent node it will initially forward the message to (which might actually be B or might be the first of N routers and/or relay nodes on the path to B).

So A shouldn’t be required to decide whether or not B is most efficiently reachable by TCP.  Entity A should leave that determination to the network.

If this is the case, then A should simply send the message via Bundle Protocol and let BP determine how best to forward the message to B – maybe via LTP over a 43-minute OWLT, maybe via TCP to the next room.

Finally, if all this makes sense, then BP/TCP might very well be operating at the nodes of a lunar habitat, a terrestrial ground station, a Mars-orbiting space station, etc.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Tomaso de Cola via SIS-DTN
Sent: Friday, May 13, 2022 4:20 AM
To: Felix.Flentge at esa.int; sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book draft

Hi Felix,

I think you raised a very valid point, i.e. to possibly restrict to scenarios that are of interest for planned or future space missions. In addition to UDPCL, I’m also wondering whether we are going to have missions planning to use BP/TCP in space. Any thoughts on it?

Tomaso

From: Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int> <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Sent: Freitag, 13. Mai 2022 12:10
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Cc: beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>; Cola, Tomaso de <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Subject: Re: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book draft

Hi,

the situations regarding UDPCL is unfortunately a bit messy. We have:

1) Annex B4 in CCSDS 734.2-B-1
2) there is RfC 7122 in IRTF
3) expired UDPCL draft in IETF draft-sipos-dtn-udpcl-01 - Delay-Tolerant Networking UDP Convergence Layer Protocol (ietf.org)<https://datatracker.ietf.org/doc/draft-sipos-dtn-udpcl/>

In terms of BP encoding, they are basically the same (just put a bundle in UDP datagram payload, called unframed transfer in the IETF draft). 3) goes beyond that as it also includes DTLS / Keep-alive / CL-Layer fragmentation).

I think we really need to understand the 'space use cases' to make a good decision what to include (or wait for UDPCL in IETF). In general, it does not appear to me to useful in (most) space scenarios (besides testing) as at least the simple approach has some limitation (bundle sizes should be small to avoid IP fragmentation, need for explicit congestion control). I think what we should try to avoid is that we get protocol stacks like BP / UDPCL / UDP / IPE / EPP  when BP / EPP would be enough.

Regards,
Felix

From:        "Tomaso de Cola via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
To:        <beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>>
Cc:        sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Date:        13/05/2022 09:59
Subject:        Re: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book draft
Sent by:        "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>>
________________________________

Dear Beau,

Thank you for sharing the clean version. Just a few quick comments on the CLA annex:

1.        For UDPCLA, shall we point to RFC 7122?
2.        As mentioned by Felix, we should have dedicated text for EPP and SPP. Let’s take also into account (probably with a note) that with the new version of SPP there exists no dedicated APID for BP or LTP. On the contrary, EPP has dedicated protocol identifiers (available also in SANA) for pointing to BP or LTP.
3.        I’m not quite sure that we can add a USLPCLA since so far (i.e. for what available in the current USLP spec), the UPID defined in USLP TFZ points only to EPP or SPP. Then BP/LTP has to be encapsulated over either of these two, but cannot go directly into USLP. If we see relevant to have direct encapsulation, I think we should pass this requirement to Greg and the SLP folks to see if they can accommodate this into a new version of USLP. After that we can have a dedicated USLPCLA, otherwise I’m afraid the BPv7 would be inconsistent with the current USLP spec in this respect.
4.        It is stated that the largest bundle over LTP cannot be more than 4GB: where does this requirement come from?

Thank you for the clarification,

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] via SIS-DTN
Sent: Donnerstag, 12. Mai 2022 21:43
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book draft

Hello all,

Attached is the clean version of the BPv7 Red Book, where most of the changes present have been accepted. I unfortunately do not have access to the google box right now, so there is one place that has not been completely cleaned up according to the edits that were made on the google box version (beginning of section 2.1). I was able to take the proper notes on everything else and apply it to the clean version.

Thank you,

Beau Blanding

HOSC Systems Engineer

MSFC 4663, Office C121

beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>

 _______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220513/695ae3e6/attachment-0001.htm>