[Sis-dtn] IPN Node Number Assignment

Fri Jan 20 07:12:32 UTC 2023

All,

Thanks for clarifying the SANA - CCSDS relationship. I know there is always some uncertainty.

I am aware about the discussions in IETF and fully support the idea of introducing (sub-)authorities. I think Ed's distinction between backward-compatibility (ie, the new scheme will be able to understand the old one) and forward-compatibility (ie, nodes supporting the old scheme do not understand the new scheme) is correct. [This is why I would find it cleaner to give a new scheme number and specify the mapping / translation but that's another discussion).

So, I don't see a reason why we should currently not discuss IPN node number assignment policies in the CCSDS WG. Of course, getting an overview about the pending changes in IETF in one of the next DTN WG meeting is very much appreciated.

>From my point of view, it is something we should at least address partially right now. The background is that we are deploying nodes in (operational) networks in the next months and I would like these nodes to use assigned numbers right from the start. It is more difficult to change later once these numbers have found their way into ICDs, configuration, etc.

I have checked the current policy is (734.2-B1):
"The registration policy for the registry shall be: no engineering review required; request must come from an identified CCSDS representative of a member, observer, or affiliate organization."

So, I guess we could just go ahead and ask for an allocation (in the 2-byte range)?

Unfortunately, the new CCSDS draft does not contain a SANA registration policy anymore (it has some text that assigned CBHE node numbers shall be used). Is this a problem (or something we may be able to address via Pink Sheets later)? Having said this, the last thing I want to do is to introduce any delay in publication of the standard.

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Marc Blanchet via SIS-DTN
Sent: 20 January 2023 04:35
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] IPN Node Number Assignment

BTW, I wrote that note below because when I was interacting with CCSDS people, specially in the early years of SANA, and even up to recently, people were not that used to registries and their management and the "interaction" with protocol specifications. This type of work is more "in place" and known in IETF.  So during CCSDS meetings, I often had to tell people that registries are there for the community and that all the rules are defined by and for the community. I found often that people did not know it and were taking everything that they see on the SANA web site as granted.  Hence my note. Again, if the current policy is not good enough, change it as you see fit.

Marc.

Le 19 janv. 2023 à 22:26, Marc Blanchet <marc.blanchet at viagenie.ca<mailto:marc.blanchet at viagenie.ca>> a écrit :

Le 19 janv. 2023 à 21:08, Vint Cerf <vint at google.com<mailto:vint at google.com>> a écrit :

this is a lot like IANA rules.

Exactly! One can only inspire from the great minds! ;-)

Marc.

v

On Thu, Jan 19, 2023 at 3:02 PM Marc Blanchet via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> wrote:
FYI, I'm the "creator"  (I defined the idea (inspired by IANA), wrote the YB, be contracted to implement it) and have been the manager of SANA from the beginning until last year. So I'm not responding on behalf of SANA, but I can give some background...

All registries managed by SANA have an allocation/assignment policy. That policy is not defined by SANA but by the community (aka ccsds area or working group). In some ways, the wg who defines the registry is the "owner" of the registry; SANA is just the custodian: receive the requests, and apply the policy for allocations. So it is up to the working group to define or modify the policies. If the wg prefers an allocation by 5 and that the requestor has to send a banana to SANA, then it will be done that way ;-).  So if the current allocation policy is not good, make a resolution and modify it as you see fit.

Regards, Marc.

Le 19 janv. 2023 à 02:36, Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>> a écrit :

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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbundle%2Fbundle.xhtml%23cbhe-node-numbers&data=05%7C01%7CFelix.Flentge%40esa.int%7C92d189a02f624d20e87108dafa9767cd%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638097825438231290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bRsdG6dschILZFC9jgLck0Em3ufMuURlvM6XHbbB%2F5U%3D&reserved=0> 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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsanaregistry.org%2Fr%2Forganizations%2Frecords%2F53&data=05%7C01%7CFelix.Flentge%40esa.int%7C92d189a02f624d20e87108dafa9767cd%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638097825438231290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ktRP5z71MQQaZxABTrpF4h5K11%2BJlMwdNvypIk90gR4%3D&reserved=0>

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<mailto:dpo at esa.int>). _______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn&data=05%7C01%7CFelix.Flentge%40esa.int%7C92d189a02f624d20e87108dafa9767cd%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638097825438231290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M4ZeiUPopsd9xjWINTrE5rHHgD%2BSPUKy%2Bqys2rO%2ByrE%3D&reserved=0>

_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn&data=05%7C01%7CFelix.Flentge%40esa.int%7C92d189a02f624d20e87108dafa9767cd%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638097825438231290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M4ZeiUPopsd9xjWINTrE5rHHgD%2BSPUKy%2Bqys2rO%2ByrE%3D&reserved=0>

--
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice

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/20230120/51c43008/attachment-0001.htm>