[Sis-dtn] [EXTERNAL] [BULK] Re: BPv7 RIDs and Updates

Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] jonathan.w.jackson at nasa.gov
Fri Jun 28 14:58:41 UTC 2024


Makes sense...will update.

Thanks,
Jonathan

From: Felix Flentge <Felix.Flentge at esa.int>
Sent: Friday, June 28, 2024 9:37 AM
To: Singh, Somendra {Simon} (GSFC-5820) <simon.singh at nasa.gov>; Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov>; sis-dtn at mailman.ccsds.org
Subject: RE: [EXTERNAL] [BULK] 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.


Ah, yes (I hate fragmentation):

We can use the phrasing from RfC 9171:

NOTE: Implementations may choose to manage a single, global timestamp sequence counter or manage individual timestamp sequence counters for disjunct sets of source node IDs . Sequence counters may be reset to zero whenever the current time advances by one millisecond. The combination of source node ID and bundle creation time stamp can serve as a unique ID for single bundle transmission request.

Regards,
Felix

From: Singh, Somendra {Simon} (GSFC-5820) <simon.singh at nasa.gov<mailto:simon.singh at nasa.gov>>
Sent: Friday, June 28, 2024 4:25 PM
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov<mailto:jonathan.w.jackson at nasa.gov>>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [EXTERNAL] [BULK] Re: [Sis-dtn] BPv7 RIDs and Updates

Hi,


?  "The combination of source node ID and bundle creation time stamp can serve as a unique ID for an individual bundle."

However, this is only true for unfragmented bundles. So, there is need to qualify with fragment offset and Total ADU Length, when the bundle is fragment.

Best regards
Simon Singh
Simon.Singh at nasa.gov<mailto:Simon.Singh at nasa.gov>
443 538 7176 c

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Felix Flentge via SIS-DTN
Sent: Friday, June 28, 2024 2:23 AM
To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov<mailto:jonathan.w.jackson at nasa.gov>>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [EXTERNAL] [BULK] 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.

Hi,

I would propose the following wording (making clear that we are not deviating from RfC 9171 and aligning terminology):

NOTE: Implementations may choose to use to manage a single, global timestamp sequence counter or manage individual timestamp sequence counters for disjunct sets of source node IDs . Sequence counters may be reset to zero whenever the current time advances by one millisecond. The combination of source node ID and bundle creation time stamp can serve as a unique ID for an individual bundle.

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN
Sent: Thursday, June 27, 2024 6:44 PM
To: sis-dtn at mailman.ccsds.org<mailto: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've drafted the following note for RID 115 based on our discussion during today's 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
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240628/22a04965/attachment-0001.htm>


More information about the SIS-DTN mailing list