[Sis-dtn] IPN URI Scheme Service Numbers

[Felix Flentge]

Hi,

Seems to be a very sensible proposal to me. For the more immediate future, I assume that there will be only limited need for interoperable use of service numbers (ie, an application of one agency communicating to an application of another agency) and I would expect missions to pick the low service numbers for their (private) M&C and payload needs anyway. What we might want to agree on are service numbers used for network management and diagnostic needs (e.g., bpecho).

Regards,
Felix

-----Original Message-----
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Birrane, Edward J. via SIS-DTN
Sent: Monday, May 22, 2023 2:38 PM
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] IPN URI Scheme Service Numbers

WG,

  Last week at the SIS-DTN weekly meeting we had a good discussion on allocation strategies for IPN service numbers.

  IIRC, there were three major areas of discussion related to these numbers: encoding size, allocation policy, and registry ownership.

  The encoding size discussion noted that the CBOR encoding of service numbers creates a very small allocation of 1-byte encodings (0-23), a small allocation of 2-byte encodings (24-155), a moderate size allocation of 3-byte encodings (256-65,535), and then 4+ byte encodings that give us the remainder of the 64bit service number space.

  The allocation policy discussion noted that there was a good case for "private use" service numbers for mission-specific use cases (commanding, telemetry) that do not otherwise map to a standardized protocol. These mission specific service numbers should not be standardized (they are mission specific) and there should be some allowance for them in the small encoding space since they will be used by missions often (perhaps most often).

  The registry ownership discussion noted that IANA is creating (updating really..) a registry for service numbers and should there be a SANA allocation in that registry.

  At the end of the discussion the following proposal was put forward:

1 byte service numbers (1-23) will be private use .
2 byte service numbers (24-255) will be expert review with a 64-id chunk allocated to SANA.
3 byte service numbers (256-65k) will be cut 1/3 private use, 1/3 IANA managed and 1/3 IANA managed but given to SANA.
4 byte will have a chunk of experimental.
4+bytes is unassigned.

  This continues to be an area of active discussion in the IETF mailing list. Some IETF participants are proposing that all service numbers be private-use and there be no standard service numbers since service discovery is better done today independent of port numbers. I disagree with this position - service numbers are not port numbers - but that case needs to be made, for those interested in following the discussion on the IETF mailing list.

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space Constellation Networking Supervisor, Embedded Applications Group Space Exploration Sector Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839



_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
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).