From durst at mitre.org Mon Jul 1 13:24:49 2024 From: durst at mitre.org (Robert C Durst) Date: Mon, 1 Jul 2024 13:24:49 +0000 Subject: [Sis-dtn] SIS-DTN Telecon Message-ID: ALL: Thursday, July 4, is a US federal holiday, and NASA centers will be closed. I?m cancelling Thursday?s meeting in anticipation of very limited participation (i.e., none) from the US side. Best, Bob CCSDS SIS DTN weekly telecon for October 23-Sep 24. Thanks! Bob Durst ________________________________________________________________________________ Microsoft Teams meeting Join on your computer, mobile app or room device Click here to join the meeting Meeting ID: 218 733 158 227 Passcode: CJ8Lfg Download Teams | Join on the web Join with a video conferencing device teams at vc.mitre.org Video Conference ID: 113 120 954 4 Alternate VTC instructions Or call in (audio only) +1 540-492-5664,,766714811# United States, Roanoke Phone Conference ID: 766 714 811# Find a local number | Reset PIN Learn More | Meeting options ________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 9832 bytes Desc: not available URL: From durst at mitre.org Mon Jul 1 13:28:56 2024 From: durst at mitre.org (Robert C Durst) Date: Mon, 1 Jul 2024 13:28:56 +0000 Subject: [Sis-dtn] Canceled: SIS-DTN Telecon Message-ID: ALL: Thursday, July 4, is a US federal holiday, and NASA centers will be closed. I?m cancelling Thursday?s meeting in anticipation of very limited participation (i.e., none) from the US side. Best, Bob CCSDS SIS DTN weekly telecon for October 23-Sep 24. Thanks! Bob Durst ________________________________________________________________________________ Microsoft Teams meeting Join on your computer, mobile app or room device Click here to join the meeting Meeting ID: 218 733 158 227 Passcode: CJ8Lfg Download Teams | Join on the web Join with a video conferencing device teams at vc.mitre.org Video Conference ID: 113 120 954 4 Alternate VTC instructions Or call in (audio only) +1 540-492-5664,,766714811# United States, Roanoke Phone Conference ID: 766 714 811# Find a local number | Reset PIN Learn More | Meeting options ________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 9693 bytes Desc: not available URL: From durst at mitre.org Fri Jul 5 12:41:52 2024 From: durst at mitre.org (Robert C Durst) Date: Fri, 5 Jul 2024 12:41:52 +0000 Subject: [Sis-dtn] SIS-DTN Telecon Message-ID: Update to distribution and end date: CCSDS SIS DTN weekly telecon for July 2024 through early January 2025. Thanks! Bob Durst ________________________________________________________________________________ Microsoft Teams meeting Join on your computer, mobile app or room device Click here to join the meeting Meeting ID: 218 733 158 227 Passcode: CJ8Lfg Download Teams | Join on the web Join with a video conferencing device teams at vc.mitre.org Video Conference ID: 113 120 954 4 Alternate VTC instructions Or call in (audio only) +1 540-492-5664,,766714811# United States, Roanoke Phone Conference ID: 766 714 811# Find a local number | Reset PIN Learn More | Meeting options ________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4451 bytes Desc: not available URL: From morinaga.yu at jaxa.jp Tue Jul 9 12:26:05 2024 From: morinaga.yu at jaxa.jp (morinaga.yu at jaxa.jp) Date: Tue, 9 Jul 2024 12:26:05 +0000 Subject: [Sis-dtn] BPv7 RIDs and Updates In-Reply-To: References: Message-ID: Dear all In RID No.99, ANNEX C is made informative. However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory". Is it mistake? I think the status should be made "optional" instead of "mandatory". Thanks, Yu From: SIS-DTN On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Friday, June 28, 2024 2:44 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] BPv7 RIDs and Updates Importance: High Hello All, Attached is the updated BPv7 book and RID spreadsheet for Final Reviews. We?e drafted the following note for RID 115 based on our discussion during today? telecon: RID# Paragraph Number RID Short Title From To Supporting Analysis 115 4.3.4 Creation Timestamp Sequence Number Clarification The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible. Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior. Please let me know if you have any comments or questions. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.w.jackson at nasa.gov Tue Jul 9 19:29:41 2024 From: jonathan.w.jackson at nasa.gov (Jackson, Jonathan W. (MSFC-HP27)[MOSSI2]) Date: Tue, 9 Jul 2024 19:29:41 +0000 Subject: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates In-Reply-To: References: Message-ID: Thanks Yu! Fair point?if everyone agrees will update these to ?optional.? Thanks again! Jonathan From: morinaga.yu at jaxa.jp Sent: Tuesday, July 9, 2024 7:26 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] ; sis-dtn at mailman.ccsds.org Subject: [EXTERNAL] RE: [Sis-dtn] BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear all In RID No.99, ANNEX C is made informative. However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory". Is it mistake? I think the status should be made "optional" instead of "mandatory". Thanks, Yu From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Friday, June 28, 2024 2:44 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] BPv7 RIDs and Updates Importance: High Hello All, Attached is the updated BPv7 book and RID spreadsheet for Final Reviews. We?e drafted the following note for RID 115 based on our discussion during today? telecon: RID# Paragraph Number RID Short Title From To Supporting Analysis 115 4.3.4 Creation Timestamp Sequence Number Clarification The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible. Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior. Please let me know if you have any comments or questions. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Wed Jul 10 07:47:29 2024 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Wed, 10 Jul 2024 07:47:29 +0000 Subject: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates In-Reply-To: References: Message-ID: <57503f762c4b4fa88d4eaa3d46a4da46@dlr.de> But if the annex has become informative, practically speaking it does not belong to the specification and as such it won?t be in any case part of any interoperability. As such I don?t see how we could indicate a corresponding item (i.e. coming from an informative annex) in the NPICS and label it as ?optional?. My understand it is that we have to refer to items (i.e. functionalities, capabilities, etc.) which are defined in the normative part of the document only and if not relevant for the interoperability label as ?optional?. Am I missing something here? Tomaso From: SIS-DTN On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Dienstag, 9. Juli 2024 21:30 To: morinaga.yu at jaxa.jp; sis-dtn at mailman.ccsds.org Subject: Re: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates Thanks Yu! Fair point?if everyone agrees will update these to ?optional.? Thanks again! Jonathan From: morinaga.yu at jaxa.jp > Sent: Tuesday, July 9, 2024 7:26 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] >; sis-dtn at mailman.ccsds.org Subject: [EXTERNAL] RE: [Sis-dtn] BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear all In RID No.99, ANNEX C is made informative. However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory". Is it mistake? I think the status should be made "optional" instead of "mandatory". Thanks, Yu From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Friday, June 28, 2024 2:44 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] BPv7 RIDs and Updates Importance: High Hello All, Attached is the updated BPv7 book and RID spreadsheet for Final Reviews. We?e drafted the following note for RID 115 based on our discussion during today? telecon: RID# Paragraph Number RID Short Title From To Supporting Analysis 115 4.3.4 Creation Timestamp Sequence Number Clarification The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible. Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior. Please let me know if you have any comments or questions. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.w.jackson at nasa.gov Thu Jul 11 14:39:02 2024 From: jonathan.w.jackson at nasa.gov (Jackson, Jonathan W. (MSFC-HP27)[MOSSI2]) Date: Thu, 11 Jul 2024 14:39:02 +0000 Subject: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates In-Reply-To: <57503f762c4b4fa88d4eaa3d46a4da46@dlr.de> References: <57503f762c4b4fa88d4eaa3d46a4da46@dlr.de> Message-ID: Thanks Tomaso, We have requirements in annex B (CLs) that reference BP MIB in the requirements (e.g., LTP parameters). If we remove these references in the PICS, should they be replaced with something else to ensure Annex B? Or are we covered with the other features listed? Regards, Jonathan From: Tomaso.deCola at dlr.de Sent: Wednesday, July 10, 2024 2:47 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] ; morinaga.yu at jaxa.jp Cc: sis-dtn at mailman.ccsds.org Subject: RE: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. But if the annex has become informative, practically speaking it does not belong to the specification and as such it won?t be in any case part of any interoperability. As such I don?t see how we could indicate a corresponding item (i.e. coming from an informative annex) in the NPICS and label it as ?optional?. My understand it is that we have to refer to items (i.e. functionalities, capabilities, etc.) which are defined in the normative part of the document only and if not relevant for the interoperability label as ?optional?. Am I missing something here? Tomaso From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Dienstag, 9. Juli 2024 21:30 To: morinaga.yu at jaxa.jp; sis-dtn at mailman.ccsds.org Subject: Re: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates Thanks Yu! Fair point?if everyone agrees will update these to ?optional.? Thanks again! Jonathan From: morinaga.yu at jaxa.jp > Sent: Tuesday, July 9, 2024 7:26 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] >; sis-dtn at mailman.ccsds.org Subject: [EXTERNAL] RE: [Sis-dtn] BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear all In RID No.99, ANNEX C is made informative. However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory". Is it mistake? I think the status should be made "optional" instead of "mandatory". Thanks, Yu From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Friday, June 28, 2024 2:44 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] BPv7 RIDs and Updates Importance: High Hello All, Attached is the updated BPv7 book and RID spreadsheet for Final Reviews. We?e drafted the following note for RID 115 based on our discussion during today? telecon: RID# Paragraph Number RID Short Title From To Supporting Analysis 115 4.3.4 Creation Timestamp Sequence Number Clarification The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible. Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior. Please let me know if you have any comments or questions. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Thu Jul 11 14:45:15 2024 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Thu, 11 Jul 2024 14:45:15 +0000 Subject: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates In-Reply-To: References: <57503f762c4b4fa88d4eaa3d46a4da46@dlr.de> Message-ID: <825ded99a2064d19a224c57d9e18cdf9@dlr.de> If we are all available, let?s discuss the way forward at the DTN telco in 15?. Tomaso From: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] Sent: Donnerstag, 11. Juli 2024 16:39 To: de Cola, Tomaso ; morinaga.yu at jaxa.jp Cc: sis-dtn at mailman.ccsds.org Subject: RE: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates Thanks Tomaso, We have requirements in annex B (CLs) that reference BP MIB in the requirements (e.g., LTP parameters). If we remove these references in the PICS, should they be replaced with something else to ensure Annex B? Or are we covered with the other features listed? Regards, Jonathan From: Tomaso.deCola at dlr.de > Sent: Wednesday, July 10, 2024 2:47 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] >; morinaga.yu at jaxa.jp Cc: sis-dtn at mailman.ccsds.org Subject: RE: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. But if the annex has become informative, practically speaking it does not belong to the specification and as such it won?t be in any case part of any interoperability. As such I don?t see how we could indicate a corresponding item (i.e. coming from an informative annex) in the NPICS and label it as ?optional?. My understand it is that we have to refer to items (i.e. functionalities, capabilities, etc.) which are defined in the normative part of the document only and if not relevant for the interoperability label as ?optional?. Am I missing something here? Tomaso From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Dienstag, 9. Juli 2024 21:30 To: morinaga.yu at jaxa.jp; sis-dtn at mailman.ccsds.org Subject: Re: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates Thanks Yu! Fair point?if everyone agrees will update these to ?optional.? Thanks again! Jonathan From: morinaga.yu at jaxa.jp > Sent: Tuesday, July 9, 2024 7:26 AM To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] >; sis-dtn at mailman.ccsds.org Subject: [EXTERNAL] RE: [Sis-dtn] BPv7 RIDs and Updates CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear all In RID No.99, ANNEX C is made informative. However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory". Is it mistake? I think the status should be made "optional" instead of "mandatory". Thanks, Yu From: SIS-DTN > On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN Sent: Friday, June 28, 2024 2:44 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] BPv7 RIDs and Updates Importance: High Hello All, Attached is the updated BPv7 book and RID spreadsheet for Final Reviews. We?e drafted the following note for RID 115 based on our discussion during today? telecon: RID# Paragraph Number RID Short Title From To Supporting Analysis 115 4.3.4 Creation Timestamp Sequence Number Clarification The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number. NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible. Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior. Please let me know if you have any comments or questions. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithlscott at gmail.com Thu Jul 11 15:55:12 2024 From: keithlscott at gmail.com (Keith Scott) Date: Thu, 11 Jul 2024 17:55:12 +0200 Subject: [Sis-dtn] Notes 20240711 Message-ID: *SIS-DTN Telecom* Discuss the RID that makes annex C (Managed Information) Optional Make Annex C informative - Remove PICS references to Annex C - Remove other MIB references (LTP engine IDs, APID settings, Encapsulation Protocol) Simon may draft some extra text for the top of Annex C Jonathan Jackson to post revised copy on CWE https://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2Fsis%2Fdocs%2FSIS%2DDTN%2FDraft%20Documents%2FBPv7%20for%20CCSDS&FolderCTID=0x012000050F193BA5186E4497F14E97DBA90814&View=%7B679CC4EC%2D20EF%2D4AB6%2D9FF7%2DD851E088D6B8%7D --- Interoperability Testing ION -- Mark to find someone DTNME -- Ask Josh ESA -- Ask Felix --keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithlscott at gmail.com Fri Jul 12 06:47:51 2024 From: keithlscott at gmail.com (Keith Scott) Date: Fri, 12 Jul 2024 08:47:51 +0200 Subject: [Sis-dtn] Latest copies of BPv7 Doc and RID spreadsheet from Jonathan Message-ID: Are in CWE under "Draft Documents:BPv7 for CCSDS : Review 1 RID Resolutions -- 2024" https://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2Fsis%2Fdocs%2FSIS%2DDTN%2FDraft%20Documents%2FBPv7%20for%20CCSDS%2FReview%201%20RID%20Resolutions%20%2D%2D%202024&FolderCTID=0x012000050F193BA5186E4497F14E97DBA90814&View=%7B679CC4EC%2D20EF%2D4AB6%2D9FF7%2DD851E088D6B8%7D --keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From Felix.Flentge at esa.int Sat Jul 13 14:38:18 2024 From: Felix.Flentge at esa.int (Felix Flentge) Date: Sat, 13 Jul 2024 14:38:18 +0000 Subject: [Sis-dtn] BPv7 Custody Transfer Progress Message-ID: Dear All, Alice has made a lot of progress on the BPv7 Custody Transfer (based on common concepts with compressed status reporting). We have a working prototype and can demonstrate the approach in simple scenarios (we are still working on the reference scenarios). We would like to present, discuss and demo the approach in the weekly DTN WG meeting on 25 July. Ideally, we would get some consent regarding the extension block, the administrative record (including CBOR encodings), and the general mechanism, so that we can update the Orange Book accordingly. Regards, Felix 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: From keithlscott at gmail.com Thu Jul 18 15:46:54 2024 From: keithlscott at gmail.com (Keith Scott) Date: Thu, 18 Jul 2024 17:46:54 +0200 Subject: [Sis-dtn] Sis-dtn telecon Notes - sorry about format Message-ID: Sis dtn telecon Jonathan: custody transfer in bpv6 ? Nodes not required to take custody ? Fragmentation: taking custody of fragments not same as taking custody of bundle ? No negative acknowledgement; have to retransmit all of a lost bundle >From last week ? Simon to draft some text for start of informational annex ? Insert ?formal terms? before ?logical data types? in paragraph c1 ? Track issue of what got deleted from pics and mins in convergence layers and should go into network management ? Simon to build issue list in GitHub and send an email to the list Custody transfer ? Bibe - ietf and MSFC ? Esa Interoperability testing ? Marc: jay gao put together a document for ion against the pics; other NASA implementations should have those, bob should have that info ? Jay Wyatt asked all implementations to send in their pics? GRC (Rachel) might be willing to do it and may have some funding to do it. Wyatt has been asking for a test rig. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.singh at nasa.gov Thu Jul 18 17:39:04 2024 From: simon.singh at nasa.gov (Singh, Somendra {Simon} (GSFC-5820)) Date: Thu, 18 Jul 2024 17:39:04 +0000 Subject: [Sis-dtn] [EXTERNAL] [BULK] BPv7 Custody Transfer Progress In-Reply-To: References: Message-ID: Hi Felix, Would it possible to change the date? July 25th was ok when it was initially proposed, but due to rescheduling of a CDR (Critical Design Review) at GSFC, a number of NASA DTN personnel would be busy with the CDR. Many of us would like to attend your custody presentation, but would not be able to. I am hoping that you will be able to change the dates. I am sorry for the inconvenience. Thank you. Best regards Simon Singh Simon.Singh at nasa.gov 443 538 7176 c From: SIS-DTN On Behalf Of Felix Flentge via SIS-DTN Sent: Saturday, July 13, 2024 10:38 AM To: Dr. Keith L Scott via SIS-DTN Cc: Alice Le Bihan Subject: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear All, Alice has made a lot of progress on the BPv7 Custody Transfer (based on common concepts with compressed status reporting). We have a working prototype and can demonstrate the approach in simple scenarios (we are still working on the reference scenarios). We would like to present, discuss and demo the approach in the weekly DTN WG meeting on 25 July. Ideally, we would get some consent regarding the extension block, the administrative record (including CBOR encodings), and the general mechanism, so that we can update the Orange Book accordingly. Regards, Felix 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: From Felix.Flentge at esa.int Thu Jul 18 17:55:19 2024 From: Felix.Flentge at esa.int (Felix Flentge) Date: Thu, 18 Jul 2024 17:55:19 +0000 Subject: [Sis-dtn] [EXTERNAL] [BULK] BPv7 Custody Transfer Progress In-Reply-To: References: Message-ID: Hi Simon, I would like to keep the date because otherwise it would need to slip to September and it would be good to get some feedback to Alice. We can record the presentation. We could also try to have an additional meeting to discuss any comments you might have. Regards, Felix From: Singh, Somendra {Simon} (GSFC-5820) Sent: Thursday, July 18, 2024 7:39 PM To: Felix Flentge ; Dr. Keith L Scott via SIS-DTN Cc: Alice Le Bihan ; Joe.nathan.wilmot at gmail.com Subject: RE: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress Hi Felix, Would it possible to change the date? July 25th was ok when it was initially proposed, but due to rescheduling of a CDR (Critical Design Review) at GSFC, a number of NASA DTN personnel would be busy with the CDR. Many of us would like to attend your custody presentation, but would not be able to. I am hoping that you will be able to change the dates. I am sorry for the inconvenience. Thank you. Best regards Simon Singh Simon.Singh at nasa.gov 443 538 7176 c From: SIS-DTN > On Behalf Of Felix Flentge via SIS-DTN Sent: Saturday, July 13, 2024 10:38 AM To: Dr. Keith L Scott via SIS-DTN > Cc: Alice Le Bihan > Subject: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear All, Alice has made a lot of progress on the BPv7 Custody Transfer (based on common concepts with compressed status reporting). We have a working prototype and can demonstrate the approach in simple scenarios (we are still working on the reference scenarios). We would like to present, discuss and demo the approach in the weekly DTN WG meeting on 25 July. Ideally, we would get some consent regarding the extension block, the administrative record (including CBOR encodings), and the general mechanism, so that we can update the Orange Book accordingly. Regards, Felix 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). 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: From sburleig.sb at gmail.com Thu Jul 18 20:01:42 2024 From: sburleig.sb at gmail.com (sburleig.sb at gmail.com) Date: Thu, 18 Jul 2024 13:01:42 -0700 Subject: [Sis-dtn] HPRP Message-ID: <041401dad94d$4f895380$ee9bfa80$@gmail.com> Just to refresh everyone's memory, I think the current draft of the HPRP specification is at https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.singh at nasa.gov Fri Jul 19 13:57:56 2024 From: simon.singh at nasa.gov (Singh, Somendra {Simon} (GSFC-5820)) Date: Fri, 19 Jul 2024 13:57:56 +0000 Subject: [Sis-dtn] [EXTERNAL] [BULK] BPv7 Custody Transfer Progress In-Reply-To: References: Message-ID: Thanks Felix! It would be nice to record the meeting on 25th. Additional meeting would also be appreciated. Best regards Simon Singh Simon.Singh at nasa.gov 443 538 7176 c From: Felix Flentge Sent: Thursday, July 18, 2024 1:55 PM To: Singh, Somendra {Simon} (GSFC-5820) ; Dr. Keith L Scott via SIS-DTN Cc: Alice Le Bihan ; Joe.nathan.wilmot at gmail.com Subject: RE: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Hi Simon, I would like to keep the date because otherwise it would need to slip to September and it would be good to get some feedback to Alice. We can record the presentation. We could also try to have an additional meeting to discuss any comments you might have. Regards, Felix From: Singh, Somendra {Simon} (GSFC-5820) > Sent: Thursday, July 18, 2024 7:39 PM To: Felix Flentge >; Dr. Keith L Scott via SIS-DTN > Cc: Alice Le Bihan >; Joe.nathan.wilmot at gmail.com Subject: RE: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress Hi Felix, Would it possible to change the date? July 25th was ok when it was initially proposed, but due to rescheduling of a CDR (Critical Design Review) at GSFC, a number of NASA DTN personnel would be busy with the CDR. Many of us would like to attend your custody presentation, but would not be able to. I am hoping that you will be able to change the dates. I am sorry for the inconvenience. Thank you. Best regards Simon Singh Simon.Singh at nasa.gov 443 538 7176 c From: SIS-DTN > On Behalf Of Felix Flentge via SIS-DTN Sent: Saturday, July 13, 2024 10:38 AM To: Dr. Keith L Scott via SIS-DTN > Cc: Alice Le Bihan > Subject: [EXTERNAL] [BULK] [Sis-dtn] BPv7 Custody Transfer Progress CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. Dear All, Alice has made a lot of progress on the BPv7 Custody Transfer (based on common concepts with compressed status reporting). We have a working prototype and can demonstrate the approach in simple scenarios (we are still working on the reference scenarios). We would like to present, discuss and demo the approach in the weekly DTN WG meeting on 25 July. Ideally, we would get some consent regarding the extension block, the administrative record (including CBOR encodings), and the general mechanism, so that we can update the Orange Book accordingly. Regards, Felix 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). 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: From Jeremy.Mayer at dlr.de Fri Jul 19 05:11:05 2024 From: Jeremy.Mayer at dlr.de (Jeremy.Mayer at dlr.de) Date: Fri, 19 Jul 2024 05:11:05 +0000 Subject: [Sis-dtn] HPRP In-Reply-To: <041401dad94d$4f895380$ee9bfa80$@gmail.com> References: <041401dad94d$4f895380$ee9bfa80$@gmail.com> Message-ID: Hi, Indeed, that is the most recent one. We'd like to discuss it further at the next meeting, if there is time. Thanks, Jeremy From: SIS-DTN On Behalf Of sburleig.sb--- via SIS-DTN Sent: Donnerstag, 18. Juli 2024 22:02 To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] HPRP Just to refresh everyone's memory, I think the current draft of the HPRP specification is at https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkoo at kari.re.kr Tue Jul 23 02:38:09 2024 From: chkoo at kari.re.kr (=?ks_c_5601-1987?B?sbjDtsi4?=) Date: Tue, 23 Jul 2024 02:38:09 +0000 Subject: [Sis-dtn] Some thoughts to the current HPRP draft (Section 1 - 4) Message-ID: <50cdb3b6270b4394b222e5720f2783c4@kari.re.kr> Hi, colleagues. I just read the current HPRP draft and let me share some thoughts from me on the contents of Section 1 to 4. 1) 4.1 HPRP Segment It could be informative if we add a ?Data Segment Section (Optional, variable)? after ?Header Extensions? field. Refer the figure on page. 10 of RFC 5326 ?LTP - Specification?. 2) 4.1 HPRP Segment Segment Type ID (bit field of 4 - 5) could be extended to ?bit field of 4 - 7? to hold an indication of the ?end of reliable data transmission in current session? like EORP or EOB in LTP (RFC-5326). Why are the EORP and EOB field deprecated in HPRP? Unlikely CP (Checkpoint), these are useful for space saving and good match with FPGA, e.g., a fastest way of generating an interrupt for this event. IMO, removing the descriptor of the ?EORP? or ?EOB? does not bring much benefit. Sending the DAR (Data Acknowledgement Request) at the edge of the data transmission may not be efficient although DAR is quite good message scheme for asynchronous state check of data reception. I think DAR is better way than ?CP? in LTP spec for this purpose. 3) 4.1.8.3 The value session number length --> The value of the session number (Q) The session number can be 0? I think it should be non-zero because 0 means, generally, the first index of an array or indicator that means no actions required. 4) 4.2.8.2.2.1 Data Acknowledgement extensions must be acknowledged by the receiving (--> sending) engine via a metadata acknowledgment message. 5) 4.3.2.2 Client Service ID It could be informative if we add a description about how this field relate RFC-7116. Also, we may need to update this RFC-7116 document for adapting HPRP. 6) 5.2.3 Upon the end of reception --> Upon the reception of un-successful data acknowledgement 7) 5.2.4 Transmit Acknowledgement Request IMO, ?Timeout? could be more semantically appropriate word than ?Interval? in this context. Best, Cheol -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Tue Jul 23 07:59:36 2024 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Tue, 23 Jul 2024 07:59:36 +0000 Subject: [Sis-dtn] HPRP In-Reply-To: References: <041401dad94d$4f895380$ee9bfa80$@gmail.com> Message-ID: Hi Jeremy, all, Just two minor remarks from my side: 1. NPICS are typically not part of an orange book, so that probably Annex A can be removed. 2. Two annexes about Security and Prototyping are instead necessary. I'll also try to check the content of the book in the next days and place comments directly within the document. Thank you all for great work, Tomaso From: SIS-DTN On Behalf Of Jeremy Mayer via SIS-DTN Sent: Freitag, 19. Juli 2024 07:11 To: sburleig.sb at gmail.com; sis-dtn at mailman.ccsds.org Subject: Re: [Sis-dtn] HPRP Hi, Indeed, that is the most recent one. We'd like to discuss it further at the next meeting, if there is time. Thanks, Jeremy From: SIS-DTN > On Behalf Of sburleig.sb--- via SIS-DTN Sent: Donnerstag, 18. Juli 2024 22:02 To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] HPRP Just to refresh everyone's memory, I think the current draft of the HPRP specification is at https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithlscott at gmail.com Fri Jul 26 08:13:34 2024 From: keithlscott at gmail.com (Keith Scott) Date: Fri, 26 Jul 2024 10:13:34 +0200 Subject: [Sis-dtn] Notes from yesterday's telecom Message-ID: *SIS-DTN Telecom 20240725* deepspace mailing list meeting yesterday - See https://deepspaceip.github.io/ - Presentation on using Segment Routing version 6 (SRV6 )as a replacement for / alternative to BP Simon?s putting together an issues list on GitHub *Everybody needs to send their GitHub ID to Simon* IETF DTN WG meeting (in 1.5 hrs?) - Will have a rechartering discussion - Will likely bring in work from deepspace mailing list ESA: Custody Mechanisms Stuff: - Bundle Sequence Number - Bundle Sequence ID (may be zero) - Xxx Custody Transfer Extension Block - 1 - 2 - 3 Custodians remove any previous CTEB and generate a new one with new sequence number and ID Sequence of signals: CBOR array [start, length, ident] Could use more ?codes? to signal things like: ?this node is NOT taking custody but is going to forward the bundle?. This signal would allow the current custodian to commute a NEW retransmission timeout (based on the custodian?s notion of where the bundle would be forwarded given the contact plan -- could do a better job if provided with information about which outgoing contact the bundle would be scheduled to but that would probably blow the ?compressed? notion out of the water since you?d need one entry per bundle -- probably better to just say ?I?m forwarding this??) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Felix.Flentge at esa.int Fri Jul 26 09:02:18 2024 From: Felix.Flentge at esa.int (Felix Flentge) Date: Fri, 26 Jul 2024 09:02:18 +0000 Subject: [Sis-dtn] Notes from yesterday's telecom In-Reply-To: References: Message-ID: Hi, I have uploaded the Custody presentation to CWE under 'Draft Documents/Compressed Bundle Reporting': https://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/Compressed%20Bundle%20Reporting/Compressed%20Custody%20Signalling.pptx?d=w1144cf3aeff947a691490b30cabeda08 Regarding your point below of including additional information in the custody signal (upcoming contacts, etc): this is certainly an option which could be studied in more detail. However, I would keep this currently out of the Orange Book. The current target I to have something which is at least as good as the ACS we had for BPv6 (as missions love to use this). What we could do though is to improve the signal code themselves a bit. Currently, we see the following cases: * Custody Accepted (node keeps a copy of a bundle and applies re-transmission in case no other nodes signals custody) * Custody Already Accepted (node already has a copy of that bundle and accepted custody, eg if re-transmission has been too early --> this allows to adjust re-transmission timers) * Custody Rejected but bundle will be forwarded (--> this allows to adjust re-transmission timers) * Custody Rejected and bundle dropped One way to encode this would be to use positive integers for accepted custody and negative integers for rejected cases. I would probably not include reason codes for the time being to keep it simple (and rely on Network Management to eg detect depleted storage). Alternative would be to have ranges for the cases above, eg 'Custody Rejected / Bundle Dropped) would be -12 to -23 with different reason codes. Regards, Felix From: SIS-DTN On Behalf Of Keith Scott via SIS-DTN Sent: Friday, July 26, 2024 10:14 AM To: sis-dtn at mailman.ccsds.org Subject: [Sis-dtn] Notes from yesterday's telecom SIS-DTN Telecom 20240725 deepspace mailing list meeting yesterday o See https://deepspaceip.github.io/ o Presentation on using Segment Routing version 6 (SRV6 )as a replacement for / alternative to BP Simon's putting together an issues list on GitHub Everybody needs to send their GitHub ID to Simon IETF DTN WG meeting (in 1.5 hrs?) o Will have a rechartering discussion o Will likely bring in work from deepspace mailing list ESA: Custody Mechanisms Stuff: o Bundle Sequence Number o Bundle Sequence ID (may be zero) o Xxx Custody Transfer Extension Block o 1 o 2 o 3 Custodians remove any previous CTEB and generate a new one with new sequence number and ID Sequence of signals: CBOR array [start, length, ident] Could use more 'codes' to signal things like: "this node is NOT taking custody but is going to forward the bundle". This signal would allow the current custodian to commute a NEW retransmission timeout (based on the custodian's notion of where the bundle would be forwarded given the contact plan -- could do a better job if provided with information about which outgoing contact the bundle would be scheduled to but that would probably blow the 'compressed' notion out of the water since you'd need one entry per bundle -- probably better to just say 'I'm forwarding this'?) 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: From Jeremy.Mayer at dlr.de Mon Jul 29 12:26:26 2024 From: Jeremy.Mayer at dlr.de (Jeremy.Mayer at dlr.de) Date: Mon, 29 Jul 2024 12:26:26 +0000 Subject: [Sis-dtn] Some thoughts to the current HPRP draft (Section 1 - 4) In-Reply-To: <50cdb3b6270b4394b222e5720f2783c4@kari.re.kr> References: <50cdb3b6270b4394b222e5720f2783c4@kari.re.kr> Message-ID: Hi Cheol, Comments inlined ? Thanks, Jeremy From: ??? Sent: Dienstag, 23. Juli 2024 04:38 To: Felix Flentge Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com; Mayer, Jeremy Subject: Some thoughts to the current HPRP draft (Section 1 - 4) Hi, colleagues. I just read the current HPRP draft and let me share some thoughts from me on the contents of Section 1 to 4. 1) 4.1 HPRP Segment It could be informative if we add a ?Data Segment Section (Optional, variable)? after ?Header Extensions? field. Refer the figure on page. 10 of RFC 5326 ?LTP ? Specification?. JPM: Added ?segment body? 2) 4.1 HPRP Segment Segment Type ID (bit field of 4 ? 5) could be extended to ?bit field of 4 ? 7? to hold an indication of the ?end of reliable data transmission in current session? like EORP or EOB in LTP (RFC-5326). Why are the EORP and EOB field deprecated in HPRP? Unlikely CP (Checkpoint), these are useful for space saving and good match with FPGA, e.g., a fastest way of generating an interrupt for this event. IMO, removing the descriptor of the ?EORP? or ?EOB? does not bring much benefit. Sending the DAR (Data Acknowledgement Request) at the edge of the data transmission may not be efficient although DAR is quite good message scheme for asynchronous state check of data reception. I think DAR is better way than ?CP? in LTP spec for this purpose. JPM: Those fields are deprecated to simplify the interfaces required for hardware acceleration; We made a simplifying assumption that, in an FPGA-accelerated implementation, the user would implement all the complex state-keeping stuff within a CPU instead of an FPGA fabric. Therefore, we aimed to optimize the transfer of real-time signaling data between the CPU and FPGA. By simply copying the entire extension field (if it exists, and optionally only if it?s a system extension), you facilitate use of DMA for transfers and allow a single interrupt (DMA transfer completed) to signal any and all protocol signaling. 3) 4.1.8.3 The value session number length --> The value of the session number (Q) The session number can be 0? I think it should be non-zero because 0 means, generally, the first index of an array or indicator that means no actions required. JPM: It can be, or randomly generated. In the existing implementation, we basically just used whatever was available (e.g. a potentially uninitialized variable) 4) 4.2.8.2.2.1 Data Acknowledgement extensions must be acknowledged by the receiving (--> sending) engine via a metadata acknowledgment message. JPM: Updated text to clarify. 5) 4.3.2.2 Client Service ID It could be informative if we add a description about how this field relate RFC-7116. Also, we may need to update this RFC-7116 document for adapting HPRP. JPM: I think this needs to be discussed. 6) 5.2.3 Upon the end of reception --> Upon the reception of un-successful data acknowledgement JPM; Minor update bade 7) 5.2.4 Transmit Acknowledgement Request IMO, ?Timeout? could be more semantically appropriate word than ?Interval? in this context. JPM: We?re using the same value as the transmission interval on the Tx side, so I think this can stay unless someone has strong opinions about it. Best, Cheol -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkoo at kari.re.kr Tue Jul 30 00:38:57 2024 From: chkoo at kari.re.kr (=?ks_c_5601-1987?B?sbjDtsi4?=) Date: Tue, 30 Jul 2024 00:38:57 +0000 Subject: [Sis-dtn] Some thoughts to the current HPRP draft (Section 1 - 4) In-Reply-To: <1083130401.173549.1722294819500.JavaMail.WIN-HQOEE85J08J$@WIN-HQOEE85J08J> References: <1083130401.173549.1722294819500.JavaMail.WIN-HQOEE85J08J$@WIN-HQOEE85J08J> Message-ID: <03a59fa3f06349259623c543aab64de9@kari.re.kr> Hi, Jeremy. Thanks for the feedback. IMO, the hardware acceleration on the generation of data acknowledgment (DA) rather than by CPU can be useful. In my experience of developing LTP, the hardest thing and time consuming parts were generating RS (Report Segment) and aligning out-of-order data in order. Best, Cheol From: Jeremy.Mayer at dlr.de Sent: Monday, July 29, 2024 9:26 PM To: ??? ; Felix.Flentge at esa.int Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com Subject: RE: Some thoughts to the current HPRP draft (Section 1 - 4) Hi Cheol, Comments inlined :) Thanks, Jeremy From: ??? > Sent: Dienstag, 23. Juli 2024 04:38 To: Felix Flentge > Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com; Mayer, Jeremy > Subject: Some thoughts to the current HPRP draft (Section 1 - 4) Hi, colleagues. I just read the current HPRP draft and let me share some thoughts from me on the contents of Section 1 to 4. 1) 4.1 HPRP Segment It could be informative if we add a ?Data Segment Section (Optional, variable)? after ?Header Extensions? field. Refer the figure on page. 10 of RFC 5326 ?LTP - Specification?. JPM: Added ?segment body? 2) 4.1 HPRP Segment Segment Type ID (bit field of 4 - 5) could be extended to ?bit field of 4 - 7? to hold an indication of the ?end of reliable data transmission in current session? like EORP or EOB in LTP (RFC-5326). Why are the EORP and EOB field deprecated in HPRP? Unlikely CP (Checkpoint), these are useful for space saving and good match with FPGA, e.g., a fastest way of generating an interrupt for this event. IMO, removing the descriptor of the ?EORP? or ?EOB? does not bring much benefit. Sending the DAR (Data Acknowledgement Request) at the edge of the data transmission may not be efficient although DAR is quite good message scheme for asynchronous state check of data reception. I think DAR is better way than ?CP? in LTP spec for this purpose. JPM: Those fields are deprecated to simplify the interfaces required for hardware acceleration; We made a simplifying assumption that, in an FPGA-accelerated implementation, the user would implement all the complex state-keeping stuff within a CPU instead of an FPGA fabric. Therefore, we aimed to optimize the transfer of real-time signaling data between the CPU and FPGA. By simply copying the entire extension field (if it exists, and optionally only if it?s a system extension), you facilitate use of DMA for transfers and allow a single interrupt (DMA transfer completed) to signal any and all protocol signaling. 3) 4.1.8.3 The value session number length --> The value of the session number (Q) The session number can be 0? I think it should be non-zero because 0 means, generally, the first index of an array or indicator that means no actions required. JPM: It can be, or randomly generated. In the existing implementation, we basically just used whatever was available (e.g. a potentially uninitialized variable) 4) 4.2.8.2.2.1 Data Acknowledgement extensions must be acknowledged by the receiving (--> sending) engine via a metadata acknowledgment message. JPM: Updated text to clarify. 5) 4.3.2.2 Client Service ID It could be informative if we add a description about how this field relate RFC-7116. Also, we may need to update this RFC-7116 document for adapting HPRP. JPM: I think this needs to be discussed. 6) 5.2.3 Upon the end of reception --> Upon the reception of un-successful data acknowledgement JPM; Minor update bade 7) 5.2.4 Transmit Acknowledgement Request IMO, ?Timeout? could be more semantically appropriate word than ?Interval? in this context. JPM: We?re using the same value as the transmission interval on the Tx side, so I think this can stay unless someone has strong opinions about it. Best, Cheol -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeremy.Mayer at dlr.de Tue Jul 30 04:52:35 2024 From: Jeremy.Mayer at dlr.de (Jeremy.Mayer at dlr.de) Date: Tue, 30 Jul 2024 04:52:35 +0000 Subject: [Sis-dtn] Some thoughts to the current HPRP draft (Section 1 - 4) In-Reply-To: <03a59fa3f06349259623c543aab64de9@kari.re.kr> References: <1083130401.173549.1722294819500.JavaMail.WIN-HQOEE85J08J$@WIN-HQOEE85J08J> <03a59fa3f06349259623c543aab64de9@kari.re.kr> Message-ID: Hi, You mean running the DA processing loop within the FPGA fabric? When the FPGA side of HPRP was being developed, our largest issue was supporting multiple parallel sessions within the FPGA, which was massively simplified by putting all the complicated stuff (e.g DA) into the CPU :D Thanks, Jeremy From: ??? Sent: Dienstag, 30. Juli 2024 02:39 To: Mayer, Jeremy ; Felix.Flentge at esa.int Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com Subject: RE: Some thoughts to the current HPRP draft (Section 1 - 4) Hi, Jeremy. Thanks for the feedback. IMO, the hardware acceleration on the generation of data acknowledgment (DA) rather than by CPU can be useful. In my experience of developing LTP, the hardest thing and time consuming parts were generating RS (Report Segment) and aligning out-of-order data in order. Best, Cheol From: Jeremy.Mayer at dlr.de > Sent: Monday, July 29, 2024 9:26 PM To: ??? >; Felix.Flentge at esa.int Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com Subject: RE: Some thoughts to the current HPRP draft (Section 1 - 4) Hi Cheol, Comments inlined ? Thanks, Jeremy From: ??? > Sent: Dienstag, 23. Juli 2024 04:38 To: Felix Flentge > Cc: sis-dtn at mailman.ccsds.org; sburleig.sb at gmail.com; Mayer, Jeremy > Subject: Some thoughts to the current HPRP draft (Section 1 - 4) Hi, colleagues. I just read the current HPRP draft and let me share some thoughts from me on the contents of Section 1 to 4. 1) 4.1 HPRP Segment It could be informative if we add a ?Data Segment Section (Optional, variable)? after ?Header Extensions? field. Refer the figure on page. 10 of RFC 5326 ?LTP ? Specification?. JPM: Added ?segment body? 2) 4.1 HPRP Segment Segment Type ID (bit field of 4 ? 5) could be extended to ?bit field of 4 ? 7? to hold an indication of the ?end of reliable data transmission in current session? like EORP or EOB in LTP (RFC-5326). Why are the EORP and EOB field deprecated in HPRP? Unlikely CP (Checkpoint), these are useful for space saving and good match with FPGA, e.g., a fastest way of generating an interrupt for this event. IMO, removing the descriptor of the ?EORP? or ?EOB? does not bring much benefit. Sending the DAR (Data Acknowledgement Request) at the edge of the data transmission may not be efficient although DAR is quite good message scheme for asynchronous state check of data reception. I think DAR is better way than ?CP? in LTP spec for this purpose. JPM: Those fields are deprecated to simplify the interfaces required for hardware acceleration; We made a simplifying assumption that, in an FPGA-accelerated implementation, the user would implement all the complex state-keeping stuff within a CPU instead of an FPGA fabric. Therefore, we aimed to optimize the transfer of real-time signaling data between the CPU and FPGA. By simply copying the entire extension field (if it exists, and optionally only if it?s a system extension), you facilitate use of DMA for transfers and allow a single interrupt (DMA transfer completed) to signal any and all protocol signaling. 3) 4.1.8.3 The value session number length --> The value of the session number (Q) The session number can be 0? I think it should be non-zero because 0 means, generally, the first index of an array or indicator that means no actions required. JPM: It can be, or randomly generated. In the existing implementation, we basically just used whatever was available (e.g. a potentially uninitialized variable) 4) 4.2.8.2.2.1 Data Acknowledgement extensions must be acknowledged by the receiving (--> sending) engine via a metadata acknowledgment message. JPM: Updated text to clarify. 5) 4.3.2.2 Client Service ID It could be informative if we add a description about how this field relate RFC-7116. Also, we may need to update this RFC-7116 document for adapting HPRP. JPM: I think this needs to be discussed. 6) 5.2.3 Upon the end of reception --> Upon the reception of un-successful data acknowledgement JPM; Minor update bade 7) 5.2.4 Transmit Acknowledgement Request IMO, ?Timeout? could be more semantically appropriate word than ?Interval? in this context. JPM: We?re using the same value as the transmission interval on the Tx side, so I think this can stay unless someone has strong opinions about it. Best, Cheol -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Baumgaertner at esa.int Tue Jul 30 12:20:29 2024 From: Lars.Baumgaertner at esa.int (Lars Baumgaertner) Date: Tue, 30 Jul 2024 12:20:29 +0000 Subject: [Sis-dtn] FW: DTN/BPSEC Key Management prototype In-Reply-To: References: Message-ID: Dear all, We are giving a brief presentation of a prototype for a BPsec key management and distribution solution for near- and midterm DTN deployments using asymmetric keys as well as symmetric session keys on Aug 30 (see forwarded mail). This work is complementary to the work on Intergovernmental Certification Authority (IGCA) and related to the DTKA RFC draft. We look forward to getting any feedback and input from the CCSDS DTN & Security working groups. Kind regards, Lars -----Original Appointment----- From: Marcus Wallum > Sent: Monday, July 29, 2024 1:49 PM To: Marcus Wallum; SEA-SEC at mailman.ccsds.org Cc: Felix Flentge; Matthes Wurbs; Lars Baumgaertner; matthew.cosby at goonhilly.org; Moury Gilles; Daniel Fischer; Yohann Roiron; Joost Oranje; Alex Kanaouris Subject: DTN/BPSEC Key Management prototype When: 30 August 2024 16:30-18:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna. Where: Microsoft Teams Meeting Dear All, My ESA colleagues have been elaborating on a key management scheme for BPSEC, including preliminary prototyping. They would like to present the concept, which builds on the DTKA draft, in order to receive any comment or feedback from the Security and DTN WGs. Looking forward to discussing with you. Best regards, Marcus ________________________________________________________________________________ Microsoft Teams Need help? Join the meeting now Meeting ID: 328 250 038 738 Passcode: pEDfZN ________________________________ Dial in by phone +49 69 667737678,,858944323# Germany, Frankfurt am Main Find a local number Phone conference ID: 858 944 323# Join on a video conferencing device Tenant key: teams at meet.esa.int Video ID: 128 440 547 6 More info For organizers: Meeting options | Reset dial-in PIN [https://esamultimedia.esa.int/docs/corporate/ESA_logo_2020_Deep_167x60px.png] Org help | Privacy and security ________________________________________________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 7883 bytes Desc: not available URL: