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

[Dr. Keith L Scott]

Comments inline (>> and in blue) below.


                                v/r,

                                --keith

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Date: Wednesday, November 16, 2022 at 7:35 PM
To: Dr. Keith L Scott <kscott at mitre.org>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Cc: Howie Weiss <howard.weiss at parsons.com>, Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov>, EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane at jhuapl.edu>
Subject: Re: [EXTERNAL] New version of CCSDS BPv7 document
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.
>> OK, so some statement in D2 to the effect of: When instantiating a new BP Node at a sites, the Agency Representative MAY request additional node IDs from SANA if needed.  Once an agency has received node assignments is then the responsibility of the agency to internally manage the node numbers assigned to it.  When a new node is to be instantiated at a site, the agency should internally assign one of its node IDs and add it to the list of NodeIDs for the site.

>> My thought was that the proposed BP Node IDs portion of the SS&A registry would *be* the globally (for folks who have access to the SS&A registry) way to document allocation of nodes and the binding between node IDs and sites.  If one were to query the SS&A registry for all the node ID assignments, that would effectively be the hosts file.  External entities really don’t need to (I don’t think) have visibility into what’s happening with ALL the nodes allocated to an agency, but just those that show up in the SS&A registry (assumed to be potential connectivity opportunities).  Allowing agencies to get ranges and then manage those ranges internally, exposing those that need exposure through the SS&A registry, seems like it would be more efficient.

>> Are you saying that you want to document ALL of the node IDs assigned to a particular agency?  So that if an agency is allocated #s X—Y we have an ‘operational’ POC for every node in that range?

>> Am I misunderstanding your request?

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/61e1d816/attachment-0001.htm>