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

[Felix.Flentge at esa.int]

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) 

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>
To:     <beau.t.blanding at nasa.gov>
Cc:     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>



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> 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
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
 _______________________________________________
SIS-DTN mailing list
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/a9de3189/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220513/a9de3189/attachment-0001.bin>