[Sis-dtn] [EXTERNAL] IPN Node Number Assignment

Thu Jan 19 17:48:33 UTC 2023

Whatever you do now may not survive IETF.. There have been substantial questions about CBHE conventions within the IETF (reference IETF 115, https://www.youtube.com/watch?v=kqA-19a_XQY), and at least one IETF draft is proposing that the CBHE numbering scheme be changed to include constructs like ipn:Authority#.node#.service#. See https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/00/

We need a hierarchical name space, and the current proposal is less complicated than the first draft that was put out (which proposed ipn:Authority#.Subauthority#.node#.service#, which I rather liked because Authority could be mapped to space agency or commercial program, subauthority could be mapped to missions, and that would push the assignment of node numbers down to the mission level, where they may need to add, remove or rename nodes at their convenience.)

The problem with the IETF proposal is that it is NOT backwards compatible – Scott Burleigh maintains it is, but his definition of backwards-compatible is that NEW DTN implementations could be written to accept the current ipn: scheme. That’s not my definition of backwards compatible – I mean that CURRENT implementations of DTN (such as the NASA ION baseline software, cFS, and other ION-based flight software as flown now (KPLO for instance) or planning to be flown need to be able to accept and route on a new ipn:# -- maybe the node couldn’t parse the hierarchical content that will help automated routing in the future, but by user configuration of the contact plans, that could be handled, as long as whatever new number still fit in the current CBOR definition of ipn:# so the current fielded code doesn’t break..

(We lost the opportunity to have DTN specified for the Artemis missions because there was NO formal specification to define BPv7 in time for the contract documents to go out with the Bluebook number. So my other warning to IETF is that if they impose this on DTN, or if CCSDS drags their feet in updating the Bluebook or whatever is necessary, we’ll have the same “lack of specification” problem in putting out contracts for the next round of lunar missions, and further delay the use of DTN at the moon. If we wait long enough, an infrastructure based on udp/ip and homegrown store and forward and routing methods will take root and DTN will be unnecessary in the minds of many..)

Anyway, whatever CCSDS decides, just be aware that there may be issues with commercial participation in CCSDS missions if the commercial users have adopted a new IETF ipn: scheme.

Leigh

J. Leigh Torgerson
Space Communications Networking Architect
Protocol Technology Lab Manager
Communications Architectures & Research (332)
Jet Propulsion Laboratory
4800 Oak Grove Drive M/S: 238-420
Pasadena, CA 91109
Office: (818) 393-0695
Email: ltorgerson at jpl.nasa.gov<mailto:ltorgerson at jpl.nasa.gov>

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org>
Reply-To: Felix Flentge <Felix.Flentge at esa.int>
Date: Wednesday, January 18, 2023 at 11:37 PM
To: "Dr. Keith L Scott via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Cc: Harald Ernst <Harald.Ernst at esa.int>
Subject: [EXTERNAL] [Sis-dtn] IPN Node Number Assignment

Hi,

I would like to discuss today or soon assignment of CBHE node numbers. As we get more and more (semi-)operational deployment, I think we all should make an effort to use assigned numbers (and not just numbers < 100 for convenience).

According to Bundle Protocol (iana.org)<https://urldefense.us/v3/__https:/www.iana.org/assignments/bundle/bundle.xhtml*cbhe-node-numbers__;Iw!!PvBDto6Hs4WbVuu7!aus8_8Czlwnvg_vsQQav8CzUDSLldmCy-F_CzsFkKVePeqbLlKCbaEi05rDxMwClKRr1SQ$> SANA is managing the range 16384-2097151.

In the (valuable) 2 byte range we have in SANA currently only one allocation:

32768 - 33791

NASA George C. Marshall Space Flight Center [1.3.112.4.1.19.3]<https://urldefense.us/v3/__https:/sanaregistry.org/r/organizations/records/53__;!!PvBDto6Hs4WbVuu7!aus8_8Czlwnvg_vsQQav8CzUDSLldmCy-F_CzsFkKVePeqbLlKCbaEi05rDxMwC45THA5w$>

As we are deploying more nodes operationally, I would like to discuss the allocation of these 2 bytes node numbers (I understand it may be a SANA thing but I would prefer to have some consensus in the DTN WG first before grabbing some numbers.

I could imagine to assign the lower allocation (16384 – 32767) for private use (ie non-interoperable mission use; bundles using these numbers shall never cross the border between networks under different operational authority).

For the higher 2-byte range, I would propose handing out blocks of 1024 numbers (like for MSFC) to CCSDS member agencies. 1024 numbers may seem a lot but it would allow to have some internal logic for assignment (e.g., a block for Earth-bound nodes; obviously such information shall not be used for routing)

Some questions:

  *   Could an Agency request more than one block? Maybe only if well justified, e.g. if the other allocation is used up.
  *   Should we have rules that at least some numbers in an allocation have to be used, otherwise the allocation will be freed up again (like frequencies)?
  *   What about commercial entities that would like to deploy nodes?

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: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230119/a4218a41/attachment-0001.htm>