[Sis-dtn] BPv7/LTP binding issues

Thu Mar 14 18:13:08 UTC 2024

Since current BP implementations are already using code point 1 for BPv6 and
BPv7, that one is already spoken for (though BPv7-over-LTP was never
formally specified anywhere). The new sequence-of-bundle-byte-strings would
come from SANA reserved range.

For the BPv7 blue book this means four changes:

Under Section B2.1.4 "LTP Convergence Layer Adapter" a requirement similar
to:

When sending bundles according to this specification an LTP CLA shall use
Client Service ID for "BPv7 Byte String Sequence" as specified in the SANA
LTP Client Service Identifiers registry (reference [XXX]).

The BPv6 document in Section B3.1 has similar statements for red and green
blocks separately. This specific service name doesn't really matter, just
that it's short but understandable enough.

Under Section B2.1.4.2 "Length, Value Encoding of Bundles in LTP Blocks" a
change similar to:

Each bundle in an LTP block shall be represented as a CBOR byte string
(major type 2) having a definite length of the encoded bundle (including all
blocks) in octets.

This is the same information encoding and same size as current draft, just
with a different major type which is more friendly to CBOR codec libraries
(and to diagnostic tools).

In Section D2 "SANA Considerations" a new statement similar to:

This document requests that SANA add a record to the LTP  Client Service
Identifiers registry (reference [XXX]) with value 4 and description "BPv7
Byte String Sequence" referencing this specification.

A new reference [XXX] to "Licklider Transmission Protocol Client Service
Identifiers." Space Assigned Numbers Authority.
https://sanaregistry.org/r/ltp_serviceid/ 

From: Felix Flentge <Felix.Flentge at esa.int> 
Sent: Tuesday, March 12, 2024 5:32 AM
To: Sipos, Brian J. <Brian.Sipos at jhuapl.edu>; sis-dtn at mailman.ccsds.org
Subject: [EXT] RE: BPv7/LTP binding issues

APL external email warning: Verify sender Felix.Flentge at esa.int
<mailto:Felix.Flentge at esa.int>  before clicking links or attachments

Hi Brian & All,

Good point: currently we have in IANA:

And SANA:

We may be able to argue that '1' is BPv6 as it points to RfC 5050, so maybe
it is possible to have '4' for aggregated BPv7 bundles (or 4 for
non-aggregated and 5 for aggregated bundles?).

'1' would mean LTP according to CCSDS 734.2-B-1 and 4 (+5?) would be defined
in CCSDS 734.2-B-2 (I think IETF never formally standardised LTPCL, or?).

I probably also need to define to use '3' in the updated CFDP UT Layer
Magenta Book (also, to my knowledge, nothing has been formally syandardised
before, so it should be fine to have aggregation of CFDP PDU there).

And yes, makes sense to have the bundles as definite-length CBOR Byte
Strings.

Regards,

Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org
<mailto:sis-dtn-bounces at mailman.ccsds.org> > On Behalf Of Sipos, Brian J.
via SIS-DTN
Sent: Monday, March 11, 2024 1:56 PM
To: sis-dtn at mailman.ccsds.org <mailto:sis-dtn at mailman.ccsds.org> 
Subject: [Sis-dtn] BPv7/LTP binding issues

All,

I hadn't looked into the convergence layers section of the draft BPv7 blue
book [1] earlier, and understand that these comments are coming late in the
draft process.

The requirements in Section B2.1.4 "LTP Convergence Layer Adapter" currently
don't actually specify which LTP Client Service ID is to be used for this
CLA and because this "multiple bundles within a block" encoding scheme is
different than what is defined for Client Service code point 1, I think that
a new Client Service code point needs to be allocated for this encoding. It
would also be valuable for a decoder to understand whether this encoding
form allows only BPv7 bundles to be present or also v6 (or even a mix of the
two). These are all considerations that if left unspecified will lead to
interoperability failures.

Separate from the Client Service ID, the notion of a "length prefixed set of
bytes" within CBOR is actually how the byte string major type [4] operates
and this encoding seems like it would be better understood by encoders and
decoders as a byte string type. In fact, this pattern of
CBOR-within-byte-string is common enough that there is both CDDL schema for
it as well as CBOR diagnostic notation for it. This second comment is less
of an interoperability issue and more of a way to stick to existing tooling
conventions for handling bstr-embedded CBOR.

The CDDL for this would be something like:

bp-in-block = (+bundle-bytes) ; encoded as a CBOR sequence

bundle-bytes = bstr .cbor bundle

; where "bundle" symbol is from Appendix B of RFC 9171

and the diagnostic notation is to enclose items with "<<" and ">>" brackets
[5].

Thanks for any consideration,

Brian S.

[1] https://public.ccsds.org/review/CCSDS%20734.2-P-1.1/734x2p11e1.pdf

[2]
https://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml#client-
service-ids

[3] https://sanaregistry.org/r/ltp_serviceid/

[4] https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1-2.5

[5] https://www.rfc-editor.org/rfc/rfc8610#appendix-G.3

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/20240314/51bf2087/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 73000 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240314/51bf2087/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 22316 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240314/51bf2087/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6540 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240314/51bf2087/attachment-0001.bin>