[Sis-dtn] Compressed Bundle Reporting (CBR) & Custody Transfer

Thu Sep 2 13:45:25 UTC 2021

Dear All,

just to let you know: we have started discussing/working/prototyping a 
'Compressed Bundle Reporting' mechanism which we intend to use as a 
replacement for BPv6 custody transfer in some scenarios. The basic idea is 
to define:

a) a Compressed Reporting Extension Block (CREB) which allows to request 
reporting of bundle reception, delivery, forwarding or deletion
b) a Compressed Reporting Signal (CRS) administrative record to 
efficiently report of reception/delivery/forwarding/deletion as requested 
(using a similar transmission ID approach as in BIBE)

The reporting signals will be provided to the sending application which 
could eg keep a record which bundles have been received by an intermediate 
node.
In our scenarios, we would trigger re-sending of bundles which have not 
been reported as received by an explicit application level command (thus 
avoiding the timers).

I assume such a mechanism could be useful to others as well in scenarios 
where one would have applied BPv6 custody transfers. The difference to 
BIBE-CT is mainly:
no timers; no re-transmission as part of the protocol (the application 
decides what to do)
we do not need to know in advance which node will send a response; in our 
case, we are just interested to know whether a bundle has been received by 
some ground node as we can assume terrestrial bundle transfer to be 
reliable (based on TCPCL).

I should maybe stress that this mechanism does not allow for a real 
replacement of BPv6 custody transfer as re-transmission would be always 
done from the source node (intermediate nodes do not take custody; at 
least, unless specific applications for that would be implemented). In 
this sense, there is some similarity with DTPC Transmission Service 
without in-sequence delivery but getting reporting signals from 
intermediate nodes (actually, it may be interesting to see whether an 
updated DTCP could make use of CRS containing delivery signals).

Anyway, I would suggest to present and discuss these ideas in more detail 
in one of the next WG meetings.

Regards,
Felix

From:   "Dr. Keith L Scott" <kscott at mitre.org>
To:     "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov>, 
"Simon Singh" <simon.singh at eknoworks.com>, "Pitts, Robert L. 
(MSFC-HP27)[HOSC SERVICES CONTRACT]" <robert.l.pitts at nasa.gov>
Cc:     "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date:   01/09/2021 19:30
Subject:        Re: [Sis-dtn] [EXTERNAL]  Custody Transfer query
Sent by:        "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>

A little expansion;

1.      With BPv6 custody transfer, nodes are not REQUIRED to take 
custody; a node may simply forward a bundle without taking custody, 
leaving the current custodian alone.  This exacerbates the problem of 
trying to set a retransmission timer since the current custodian doesn?t 
have a protocol-enforced contract for who the next custodian will be.
2.      The above problem is FURTHER exacerbated by fragmentation (though 
*I* believe this is largely semantic and that workable solutions exist). 
The ideas is that if I?m the custodian for a 1,000-byte bundle, and 
somebody downstream fragments it without taking custody, I can now get 
custody-acceptance signals for pieces of that bundle ? pieces I never knew 
existed.  So what do I do, especially if the retransmission timer (that I 
had trouble setting inf the first place) goes off?  Do I retransmit the 
entire bundle, do I make fragments out of the bundle I have and retransmit 
all the un-custody-acked pieces?

So, in lieu of trying to solve the above, we opted for an approach where 
the custodian gets to affirmatively KNOW who?s going to take custody, and 
as a side-effect of BIBE-tunneling the custodial bundle to the next 
custodian, we can assert that the next custodial can/will take custody of 
the ENTIRE bundle.

Not *my* favorite solution, but there are definitely benefits.

                                v/r,

                                --keith

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Sanchez 
Net, Marc (US 332H) via SIS-DTN <sis-dtn at mailman.ccsds.org>
Date: Friday, August 20, 2021 at 11:41 AM
To: Simon Singh <simon.singh at eknoworks.com>, Pitts, Robert L. 
(MSFC-HP27)[HOSC SERVICES CONTRACT] <robert.l.pitts at nasa.gov>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXTERNAL] Custody Transfer query
I believe one of the main reasons for the switch of custody transfer to 
BIBE is the inability to meaningfully/properly set the custody transfer 
retransmission timer in BPv6. This happens because at the Bundle Layer 
there is no way to tell which route a bundle will take to destination, or 
whether it will be fragmented on its way to it, so it is impossible to 
figure out what is a good value of the retransmit timer.

BIBE is supposed to be a convergence layer for the Bundle Protocol which 
acts as a hop-to-hop protocol rather than an end-to-end protocol. 
Therefore, since in BIBE you know explicitly which is the destination node 
to which the bundle will be sent, and there is no possibility for further 
fragmentation, you can have a better idea of the correct value for the 
retransmission timer (much like in LTP).

BIBE?s other motivation is security. By allowing you to encapsulate a 
bundle within another bundle, you can achieve functionality that is 
similar to a VPN in which encapsulated bundles are fully encrypted and 
possibly authenticated (fully meaning that both the payload and the header 
are encrypted).

-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650 | Email: marc.sanchez.net at jpl.nasa.gov
-----------------------------------------------------------------------------------------------------------------------

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Simon Singh
Sent: Friday, August 20, 2021 8:09 AM
To: Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT] 
<robert.l.pitts at nasa.gov>
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] Custody Transfer query

Thanks Lee.

I came across this, probably from Scott Burleigh. Any idea about "serious 
potential operational anomalies."

"·         The ?custody transfer? function is removed from BP and is 
defined instead in a new bundle-in-bundle encapsulation specification, to 
improve its efficiency and address several serious potential operational 
anomalies."

Best regards
Simon Singh
+1 443 538 7176 Cell

On Fri, Aug 20, 2021 at 8:16 AM Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES 
CONTRACT] <robert.l.pitts at nasa.gov> wrote:
I don?t know the exact reason but it was initiated in the IETF.   Scott 
may be a better source.

Lee

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Simon Singh
Sent: Friday, August 20, 2021 1:52 AM
To: Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <
beau.t.blanding at nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: [EXTERNAL] [Sis-dtn] Custody Transfer query

Hi,

I would appreciate it if someone can provide insight regarding the 
following query.. Thanks

What was the motivation to move from BP6 style of custody transfer to one 
using BIBE?

Best regards
Simon Singh
+1 443 538 7176 Cell

On Thu, Aug 12, 2021 at 7:58 AM Blanding, Beau T. (MSFC-HP27)[HOSC 
SERVICES CONTRACT] via SIS-DTN <sis-dtn at mailman.ccsds.org> wrote:
Good morning all,

Attached are BPv7 Red Book Discussion Topics from MSFC. We (MSFC) provide 
our opinions on how the topics listed within should be managed. Please 
provide your input via email on these topics so that we may take them into 
account as we write sections for the BPv7 book. If we run into a 
discussion that isn?t resolving over email, we will resolve in the SIS-DTN 
forum.

Regards,

Beau Blanding
HOSC Systems Engineer
MSFC 4663, Office C121
beau.t.blanding at nasa.gov

-----Original Appointment-----
From: Dr. Keith L Scott <kscott at mitre.org> 
Sent: Wednesday, April 7, 2021 9:47 AM
To: Dr. Keith L Scott; sis-dtn at mailman.ccsds.org
Cc: Navas, Tiffany A. (GSFC-581.0)[MTI SYSTEMS, INC.]; Torgerson, J. Leigh 
(JPL-332C)[JPL Employee]; HAMILTON, PAUL A. (JSC-EV811); Matusow, Carla L. 
(GSFC-4502); Strege, Susanne L. (GSFC-5830); LACY, SETH L DR-04 USAF AFMC 
AFRL/RVEN; Mayer, Jeremy P. (JSC-OT/ESA)[EUROPEAN SPACE AGENCY]; Burleigh, 
Scott C (JPL-312B)[JPL Employee]; Deaton, Joshua E. (MSFC-HP27)[HOSC 
SERVICES CONTRACT]; Gian.Paolo.Calzolari at esa.int; Felix.Flentge at esa.int; 
Bryant, Deann (MSFC-HP27); Wright, James R. (MSFC-HP27)[BIOSERVE Univ of 
CO]; George, Sandy (MSFC-IS40)[NICS]; Heiner, Sarah E.; Kazmi, Syeda A. 
(GSFC-5830); Tomaso.deCola at dlr.de; Durkin, Alexander E. (GSFC-5830)
Subject: [EXTERNAL] [Sis-dtn] SIS-DTN Telecon
When: Wednesday, August 11, 2021 11:00 AM-12:00 PM (UTC-05:00) Eastern 
Time (US & Canada).
Where: Microsoft Teams Meeting

20210407 ? Just refreshing the calendar invite in case it got dropped 
somewhere.

Folks,

I?d like to set up some recurring SIS-DTN meetings to talk about our 
current work items.  I?ve set these for every 2 weeks; if it looks like we 
don?t need to meet that often I?ll drop it down to monthly.

I?m proposing Wednesdays 11am; I get that this time won?t work for 
everyone, but let?s see how many can make it and if we have to we?ll hunt 
for a different time.

                                v/r,

                                --keith
________________________________________________________________________________ 

Microsoft Teams meeting 
Join on your computer or mobile app 
Click here to join the meeting 
Join with a video conferencing device 
teams at vc.mitre.org 
Video Conference ID: 111 714 557 8 
Alternate VTC dialing instructions 
Or call in (audio only) 
+1 540-492-5664,,269972841#   United States, Roanoke 
Phone Conference ID: 269 972 841# 
Find a local number | Reset PIN 
Learn More | Meeting options 
________________________________________________________________________________ 

_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn

Disclaimer
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210902/fc389cb1/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/20210902/fc389cb1/attachment-0001.bin>