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

Fri May 13 15:52:11 UTC 2022

Keith, yes, this is exactly what I mean.

Scottt

From: Dr. Keith L Scott <kscott at mitre.org> 
Sent: Friday, May 13, 2022 8:49 AM
To: sburleig.sb at gmail.com; Tomaso.deCola at dlr.de; Felix.Flentge at esa.int;
sis-dtn at mailman.ccsds.org
Subject: Re: [EXT] Re: [Sis-dtn] Clean version of the CCSDS BPv7 Red Book
draft

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
<mailto:sis-dtn-bounces at mailman.ccsds.org> > on behalf of sburleig.sb--- via
SIS-DTN <sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> >
Date: Friday, May 13, 2022 at 9:46 AM
To: Tomaso.deCola at dlr.de <mailto:Tomaso.deCola at dlr.de>
<Tomaso.deCola at dlr.de <mailto:Tomaso.deCola at dlr.de> >, Felix.Flentge at esa.int
<mailto:Felix.Flentge at esa.int>  <Felix.Flentge at esa.int
<mailto:Felix.Flentge at esa.int> >, sis-dtn at mailman.ccsds.org
<mailto:sis-dtn at mailman.ccsds.org>  <sis-dtn at mailman.ccsds.org
<mailto: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
<mailto: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 <mailto:Felix.Flentge at esa.int> ;
sis-dtn at mailman.ccsds.org <mailto: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
<https://datatracker.ietf.org/doc/draft-sipos-dtn-udpcl/>
draft-sipos-dtn-udpcl-01 - Delay-Tolerant Networking UDP Convergence Layer
Protocol (ietf.org) 

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

 <mailto:beau.t.blanding at nasa.gov> 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>
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/bb051d73/attachment-0001.htm>