[Sis-dtn] [EXTERNAL] IPN URI Scheme Service Numbers

Wed May 24 02:17:47 UTC 2023

I agree with Torgerson's reasoning.
v

On Tue, May 23, 2023 at 11:40 PM Torgerson, J. Leigh (US 332C) via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> I generally agree with the proposal Ed outlines (though I would like to
> reserve all 1 or 2 byte SN’s as standards, and leave the private use
> service numbers for the 3 or 4-byte encodings, much like the convention of
> the first 1024 IP well-known ports, since everyone should want to be using
> standard application services like bping, other snmp-like applications, and
> for deep space use, CDFP at least.. Standard 1 or 2 byte service numbers
> for the most common applications would be more efficient.
>
>
>
> Why not all private? If a program (say, the Mars program) wants all nodes
> to be able to host a CFDP client that identifies itself as service number
> 65, then if a mission is launched later, and it wants to relay CFDP data
> through one of the other Mars nodes, then it will have to use service
> number 65, or arrange with other nodes to use some other service number,
> which will take intervention by the operators of the other nodes.
>
>
>
> This is the primary operational need to agree on some standard conventions
> for service numbers. I don’t think you want every DTN node in an IPN
> network to be able to pick its own service number for each application.
> (Some underlying convergence layer choices in a relay situation may depend
> on knowledge of the application so the correct convergence layer may be
> chosen for the next hop, and if the service numbers aren’t standardized, it
> will be a crap shoot at any relay node.)
>
>
>
> We’re trying to create an easily-interoperable DTN-enabled network, and I
> don’t see why standardized service numbers are controversial.  Is it a
> matter of food-fights between “registry organizations”? Is it a matter of
> how many bytes you use because of the CBOR encoding? IDK, but I do think
> making service numbers all “private” is a really bad idea – it just kicks
> the can down the road and leaves room for a lot of chaos as the SSI and DTN
> scale up.
>
>
>
> Leigh
>
>
>
>
>
>
>
> On 5/22/23, 5:49 AM, "SIS-DTN on behalf of Birrane, Edward J. via
> SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org <mailto:
> sis-dtn-bounces at mailman.ccsds.org> on behalf of sis-dtn at mailman.ccsds.org
> <mailto:sis-dtn at mailman.ccsds.org>> wrote:
>
>
>
>
>
> 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 <(443)%20778-7423> / (F) 443-228-3839 <(443)%20228-3839>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> SIS-DTN mailing list
>
> SIS-DTN at mailman.ccsds.org <mailto:SIS-DTN at mailman.ccsds.org>
>
>
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$
> <
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$>
>
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230524/ed32aa98/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230524/ed32aa98/attachment.bin>