[Sis-dtn] [EXTERNAL] New version of CCSDS BPv7 document

Thu Nov 17 00:33:32 UTC 2022

Keith, et al,

As promised I have read through the revised CCSDS BPv7 document.  Most of my concerns have been satisfactorily addressed by these changes.  Thanks.  There are still a few dangling participles, highlighted in yellow.  In some cases these are items that appear in a sidebar note, but do not appear to have been addressed in the revised text.  Perhaps they are still under discussion?

There is still, in my mind, something of a disconnect in the text, and in the SANA registries, between the CBHE Node Numbers registry (https://beta.sanaregistry.org/r/bp_cbhe_node_numbers/) , which records a CCSDS org that has been assigned a block of what are potentially thousands of node numbers, and the specific node ID assigned to a unique, deployed, node.  This version of the doc states (in revised sec D2) that the node ID(s) for any node that offers DTN services shall be registered, by the SANA, in the Site Services portion of the Service Site and Apertures (SS&A) Registry entry for that Site.  This does require action by the Agency Representative for that Service Site and this must be clarified.

However, what is missing is the linkage between the specific Node ID, allocated within the CBHE block of Node IDs assigned to an Agency, and the association of that specific Node ID with the SS&A entry.  Someone has to make that allocation of the Node ID from the block and associate it with the deployed Node, as registered in the SS&A registry.  This could, in these early days, be the equivalent of the HOSTS.TXT file that was used in the early Internet, but it seems prudent to have some globally accessible way to document which Node IDs have been assigned and the SS&A entries they are associated with.  This role could be assigned to the SANA, or it could be required of each of the Agencies assigned CBHE Node ID blocks, but IMHO someone ought to do it and curate it in some globally accessible location.  Presumably, at least in the early days, this will be a slowly moving target.

Regards, Peter

From: Keith Scott <kscott at mitre.org>
Date: Wednesday, November 16, 2022 at 1:41 PM
To: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov>, Howie Weiss <howard.weiss at parsons.com>, Leigh Torgerson <jordan.l.torgerson at jpl.nasa.gov>, "EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <Edward.Birrane at jhuapl.edu>
Subject: [EXTERNAL] New version of BPv7 document

All,

After some discussions w/ Peter and emails w/ Ignacio,I propose we use the current version of the document from the Google Drive site to close out the PIDs and to be the object of a resolution to put the document out for another round of CESG review.  I unfortunately did NOT turn on ‘suggesting’ mode (track changes) but the differences between this and the last versions we discussed are small and summarized here.

  1.  There is a new subsection at the end of section 2 (after the other 2 new subsections for BPsec and Network Management) that is the roadmap for ‘how to add a new BP node into an existing network’.  This subsection is designed to address Peter’s concerns that we be up-front with folks that there is a fair amount of human-in-the-loop coordination / configuration needed to stand up a new node and get it stitched into the network.  The procedure in the new subsection leverages extensions to the SANA Service Site and Apertures registry to include a list of BP Node Identifiers in the Site portions of the registry for those sites that support BP services.

  1.  Annex C has also been modified to include the request that SANA include a list of Node Identifiers for such sites in the SS&A registry.  I *think* we’ll need to wait for SANA to add that field to the BETA registries before the document can go out for re-poll to the CESG (at least that’s how I recall the rules).

  1.  There was a fair amount of discussion about anonymous bundles and why one would ever have such a thing.  I believe that the primary motivation for dtn:none was left over from custody transfer in bpv6 where the current custodian was a mandatory part of the primary block, so we needed a way to say ‘there is no current custodian’.  There was desire to remove support for dtn:none entirely; I’ve sort of loathe to do that because we may be (hopefully eventually WILL be) part of a larger DTN network that includes all sorts of folks who MIGHT be using dtn:none for something useful (though I have no idea what that might be).  I ended up with the following:

3.2.2 Implementations of this specification are not required to support bundles whose source, destination, or report-to endpoint identifiers use the dtn URI scheme in RFC 9171.

I also fixed the text of 2-1 (tenth paragraph) per Ignacio’s suggestion.  It now says:
Deep space missions often carry constraints regarding the amount of equipment they can support on the satellite.  Spacecraft telecommunication resources are generally optimized to ensure the prevailing instrument data download requirements.  The result of this resource optimization is an asymmetric, sometimes even simplex, link between the satellite and the receiver.

Let’s see if we can nail these down on tomorrow’s call.

                        v/r,

                        --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221117/ef3df67b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BPv7 734x2p10_CESG_Approval-SEA 16Nov22.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 480783 bytes
Desc: BPv7 734x2p10_CESG_Approval-SEA 16Nov22.docx
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221117/ef3df67b/attachment-0001.docx>