[Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.

Tue Aug 28 16:43:54 UTC 2018

Comments in line

Regards,
Leigh

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Scott, Keith L." <kscott at mitre.org>
Date: Tuesday, August 28, 2018 at 5:42 AM
To: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Cc: "Shames, Peter M (312B)" <Peter.M.Shames at jpl.nasa.gov>, "Burleigh, Scott C (312B)" <Scott.C.Burleigh at jpl.nasa.gov>, SANA Group <ssg at mailman.ccsds.org>
Subject: [Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.

 CBHE Node #, the CBHE Node Number of the BP Node, hyperlinked to the node number allocation range in the CBHE Node Number Registry

Depending on my spacecraft, its architecture, and the presence or absence of DTN-enabled instruments etc., I might have many CHBE node #s, and trying to put them all in a registry tied to a given spacecraft will be cumbersome, and somewhat akin to trying to register NAT’d IP addresses in someone’s LAN.

·         POC: a link to the appropriate SANA registry entry for who to talk to about connecting with this node (e.g. routing through it) [Could be a person or an organization?]

Sorry, you get to connect with my spacecraft by asking the mission ops team, not some higher organization. And I’m not publishing anything in public except that which is needed to deconflict potential telemetry link layer issues, like spacecraft ID.

·         List of CBHE Service #s: A list of CBHE service numbers that can be expected to be running on the node (e.g. CFDP) – hyperlinked to their corresponding entries in the CBHE Service # registry.

Conventions that are akin to the lower range of internet well-known ports are probably a good idea.. at least I see no harm in doing that.

·         List of convergence layers and their information: so for example, if the node is running a TCPCL on IP address 10.1.2.3:1234, a UDP CL on port address 10.1.2.6:5678, and an LTP/Encap CL on virtual channel 3, those would be listed.

No, I would push back on this. When I register an IP address, I don’t tell you what services I have running, what ports I happen to be using or anything else – you may assume that if I am running a web server you might try to hit me on port 80 and so forth, but I don’t have to register that anywhere.  CCSDS could specify what information a mission would need to make available to other missions (in the vein of “if you want to talk to me using DTN, I have CFDP running as this EID, my comm links support X, Y or Z link layer, and if you want to talk to mission ops computers, use STCP on this network and port”) – but trying to put that information into some sort of international registry is doomed to failure.  (For instance, we have to change your example TCPCL info quite often in practice, as terrestrial IP network security dictates – we have established firewall port and protocol conventions between centers and organizations that are SBU information, and I’m not going to put my project at risk by letting all my DTN BP contact information / EIDs and services be part of some public registry. For non-NASA folks, SBU is a NASA security classification meaning “Sensitive But Unclassified” and us used to protect agency information that shouldn’t be released to the public, sent over unencrypted channels, etc. The Department of Defense and Department of Energy use actual classifications like Confidential, Secret, Top Secret – but since NASA isn’t part of the DoD or DoE, they just have SBU which I always take as sort of a military “Confidential” or even “Secret” classification.)

In any case, I don’t believe we should go overboard in trying to put everything anyone does with DTN in space into some public CCSDS registry – let’s just put in things that are absolutely necessary to deconflict links.. Remember that BP isn’t a link layer protocol, and RF links don’t need any DTN EID information to establish contact with a spacecraft.

o   Maybe listing the VC isn’t appropriate here?  That’s more a function of the mission configuration (e.g. each mission could use a different VC even if all share the same aperture and site, I think)

o   I’d vote for the CL info being a free text field with a convention for entries like TCP:1234:4556 rather than trying to generate a whole sub-structure for CL entries – thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20180828/92c9ce0d/attachment.html>