[Sis-dtn] [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & Custody Transfer
Sanchez Net, Marc (US 332H)
marc.sanchez.net at jpl.nasa.gov
Mon Sep 13 22:27:54 UTC 2021
Hi Felix,
Interesting, I see your use case. So we are essentially achieving "semi-automatic" retransmission of data across multiple (possibly consecutive) ground passes, which is something that we could do in BPv6 because the custody transfer signals were routed with CGR (i.e., they were aware of disconnections and the fact that some links were downlink-only), whereas with BIBE they are not (since BIBE is a convergence layer).
Looking forward to discussing this more over the CCSDS fall meetings.
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650<tel:(818)%20393-5840> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------
From: Felix.Flentge at esa.int <Felix.Flentge at esa.int>
Sent: Monday, September 6, 2021 4:47 AM
To: Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov>
Cc: Dr. Keith L Scott <kscott at mitre.org>; Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <robert.l.pitts at nasa.gov>; Simon Singh <simon.singh at eknoworks.com>; sis-dtn at mailman.ccsds.org
Subject: RE: [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & Custody Transfer
Hi Marc,
1. We would use an administrative record. If it would be included in some other way in the payload block, we would need to have something (a new bundle processing flag?) to indicate that it's not data. If it would be an extension block, we would have the additional processing at intermediate nodes (as pointed out by Simon) and I am not sure about a clean way to deliver the information to the application.
2. Yes, we are pushing the problem of re-transmission to the application (agent). For our scenarios, I am thinking of a specific command to re-transmit all bundles that have not been reported as 'received', yet. This would work for example in situations with receive only ground stations (which would generate CRS and forward them to a central node at mission control for eventual uplink). Once there is a pass over an uplink ground station, first the CRS would be uplinked and then a TC to re-transmit missing data would be sent. Of course, depending on the situations, other mechanisms would be feasible (even having timers again).
Regards,
Felix
From: "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>
To: "Simon Singh" <simon.singh at eknoworks.com<mailto:simon.singh at eknoworks.com>>, "Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>" <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Cc: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>>, "Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>, "Dr. Keith L Scott" <kscott at mitre.org<mailto:kscott at mitre.org>>
Date: 02/09/2021 18:00
Subject: RE: [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & Custody Transfer
________________________________
Hi Felix,
Just reading your email, a couple of questions popped up:
1. How is the CRS sent? Is it its own bundle, or can it be carried as an extension block too?
2. You said "no timers", and I understand what you mean. But how would the application handle the fact that it has not received a CRS for a bundle that requested it? In fact, how does it know that it is not just in transit? The reason I ask is because I it seems to me we may be just pushing the problem up one layer in the protocol stack, from bundle to application.
I agree that if we move forward with this, it would be great to design the protocol so that DTPC can just use it for end-to-end reliability.
Looking forward to discussing more on this topic.
Thanks,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650<tel:(818)%20393-5840> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------
From: Simon Singh <simon.singh at eknoworks.com<mailto:simon.singh at eknoworks.com>>
Sent: Thursday, September 2, 2021 10:38 AM
To: Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>
Cc: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>>; Sanchez Net, Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>; Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>; Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Subject: [EXTERNAL] Re: Compressed Bundle Reporting (CBR) & Custody Transfer
Hi Felix,
I had been thinking about compressing BSR to combat the problem of proliferation of the BSRs, again along the same approach as used in Custody Signal. However, BSR would still go to the report_to EID, as originally intended (note that it could source_EID as well).
I see that your primary focus is towards some mechanism similar to custody transfer, though not replacing CT, as you already noted. Looks like things can be improved by compressing BSR.
There is also a somewhat related problem where BSR is needed but there is no need for multiple BSR. E.g. when a node is not capable of processing a new extension block (just like a new defined CREB - Compressed Reporting Extension Block ) and extension block is requesting a BSR (see below for requesting flag definition). Once we know that the node can't process this kind of block, there is no need for BSR for each bundle containing the offending extension block.
// for reference
. Bit 1(0x02): transmission of a status report is requested if block can't be processed.
Another suggestion would be to see if Custody Signal can be improved by including more than one Disposition Codes. Currently, it is confined to one Disposition Code. So, if the next custodian wants to send back two different disposition codes (e.g. it accepted some bundles, but then ran out space and rejected custody for the rest of the bundles), then it would need to send two different CSs.
There is also a problem of losing a CS. It can trigger a number of retransmissions. The problem is that the reliability of the CS is the same as the reliability of a normal bundle.
I look forward to your presentation.
Best regards
Simon Singh
+1 443 538 7176 Cell
On Thu, Sep 2, 2021 at 9:38 AM <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>> wrote:
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<mailto:kscott at mitre.org>>
To: "Sanchez Net, Marc (US 332H)" <marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>>, "Simon Singh" <simon.singh at eknoworks.com<mailto:simon.singh at eknoworks.com>>, "Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>
Cc: "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>>
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<mailto: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<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of Sanchez Net, Marc (US 332H) via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Date: Friday, August 20, 2021 at 11:41 AM
To: Simon Singh <simon.singh at eknoworks.com<mailto:simon.singh at eknoworks.com>>, Pitts, Robert L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <robert.l.pitts at nasa.gov<mailto:robert.l.pitts at nasa.gov>>
Cc: 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: 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<tel:(818)%20393-5840> | Email: marc.sanchez.net at jpl.nasa.gov<mailto:marc.sanchez.net at jpl.nasa.gov>
-----------------------------------------------------------------------------------------------------------------------
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto: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<mailto:robert.l.pitts at nasa.gov>>
Cc: sis-dtn at mailman.ccsds.org<mailto: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<mailto: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<mailto: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<mailto:beau.t.blanding at nasa.gov>>; sis-dtn at mailman.ccsds.org<mailto: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<mailto: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<mailto:beau.t.blanding at nasa.gov>
-----Original Appointment-----
From: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Sent: Wednesday, April 7, 2021 9:47 AM
To: Dr. Keith L Scott; sis-dtn at mailman.ccsds.org<mailto: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<mailto:Gian.Paolo.Calzolari at esa.int>; Felix.Flentge at esa.int<mailto: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<mailto: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<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/ap/t-59584e83/?url=https*3A*2F*2Fteams.microsoft.com*2Fl*2Fmeetup-join*2F19*253ameeting_ZTYwZDliYzUtNGFiOS00N2MwLTg1ZGYtNTU2NWY2NjdkMGYz*2540thread.v2*2F0*3Fcontext*3D*257b*2522Tid*2522*253a*2522c620dc48-1d50-4952-8b39-df4d54d74d82*2522*252c*2522Oid*2522*253a*2522ce1a1a67-2690-4431-9ee8-aa55d8855316*2522*257d&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517331361*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=6paoOQYlympQGHQJMpoFYnWkVhX8Dh*2BihGPayt4ZHPg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx92Q7coo$>
Join with a video conferencing device
teams at vc.mitre.org<mailto:teams at vc.mitre.org>
Video Conference ID: 111 714 557 8
Alternate VTC dialing instructions<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmeet*40vc.mitre.org*2Fteams*2F*3Fconf*3D1117145578*26d*3Dvc.mitre.org*26ivr*3Dteams*26ip*3D198.49.146.246*26test*3Dtest_call*26w&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517331361*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=cVA036lwh55*2Fx1YR1*2B8XEIDDJXq9p87NbdVcRMB*2Fs70*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx8yip60K$>
Or call in (audio only)
+1 540-492-5664,,269972841#<tel:+15404925664,,269972841> United States, Roanoke
Phone Conference ID: 269 972 841#
Find a local number<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdialin.teams.microsoft.com*2Ff5bf125e-1b0d-470e-aae7-f8fc6f64035e*3Fid*3D269972841&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517341316*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=r*2FfQXMQ*2B5D7C*2BsLBPQoVTZmnsS8SnRC7i*2BkbcEHMGIo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx_iexYF7$> | Reset PIN<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmysettings.lync.com*2Fpstnconferencing&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517341316*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=NnFrl2Jdp7GrdXQ0p0IMCnYYBD3RgGJVqdrObA7Ha8Q*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx9VxOouf$>
Learn More<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Faka.ms*2FJoinTeamsMeeting&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517351275*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=JC3vkfbSfVqNbnl9TGeFe6ZsAoIR*2Fxyt47*2FkYQ2dtnI*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx_LLiZRg$> | Meeting options<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fteams.microsoft.com*2FmeetingOptions*2F*3ForganizerId*3Dce1a1a67-2690-4431-9ee8-aa55d8855316*26tenantId*3Dc620dc48-1d50-4952-8b39-df4d54d74d82*26threadId*3D19_meeting_ZTYwZDliYzUtNGFiOS00N2MwLTg1ZGYtNTU2NWY2NjdkMGYz*40thread.v2*26messageId*3D0*26language*3Den-US&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517351275*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2BVKyGxinwwpOBdT1ZLxLZKAO29ttvsDMXBRRATli5OQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-JxynXiYRc$>
________________________________________________________________________________
_______________________________________________
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://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fmailman.ccsds.org*2Fcgi-bin*2Fmailman*2Flistinfo*2Fsis-dtn&data=04*7C01*7Crobert.l.pitts*40nasa.gov*7C6ebc85dc7a9e4385411308d963a7140a*7C7005d45845be48ae8140d43da96dd17b*7C0*7C0*7C637650391517361232*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=RXC70U7zlr6nh5ie2yXyQNHklO*2Frn7IK*2BoeWp*2B*2FX878*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!bbanjnFcGoz3smEvpMoKd5dhVLg0OXN-kz_VOp8hAwyD3fSBA0qhCyB3g15UGE-Jx6d7hW6m$>_______________________________________________
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://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!euxPVaR6TbjuSrFoZ6G9PMEtsWPPSd-pda08JwU5cslZDbpHtnyNHBaNl1Wa3B9-w7oQCF1z$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20210913/10db8285/attachment-0001.htm>
More information about the SIS-DTN
mailing list