<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hmm,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">What I would expect missions to come up with is something like:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">1 – essential HK TM in packets (e.g., ESA PUS format)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">2- TC packets for immediate execution (e.g., ESA PUS)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">3 – CFDP Uplink<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">4 – CFDP house-keeping downlink<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">5 – CFDP payload downlink<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">(or some combination of the CFDP stuff but we may have different CFDP entities for uplink/house-keeping/payload)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Human spaceflight might add something for voice and video.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Now the question would be for me whether we consider this private use (I would think so), or if we would standardise e.g, SN 1 = essential housekeeping TM but leave the format open?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I don’t fully understand that for relaying CFDP data we would need to have a standardised service number unless we want to implement network policies based on service numbers (e.g., priorities or
convergence layer choices). I am not sure whether this would be a good generic approach (could make sense for limited networks but these could define their own service number assignments within their policies). For a more generic approach, I would prefer having
explicit BP extensions for QoS.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Having said this, I believe having standardised service numbers for generic, ‘network-related’ services makes a lot of sense to me, e.g. bpecho (to allow using bping for connectivity testing) and
network management related functionalities (e.g., provision of contact information, network management, registries, DNS-like functionalities, …).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Felix<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Torgerson, J. Leigh (US 332C) via SIS-DTN<br>
<b>Sent:</b> Tuesday, May 23, 2023 10:40 PM<br>
<b>To:</b> EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane@jhuapl.edu>; sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] IPN URI Scheme Service Numbers<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<span style="color:#2F5597"><o:p></o:p></span></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.
<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.)<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Leigh<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">On 5/22/23, 5:49 AM, "SIS-DTN on behalf of Birrane, Edward J. via SIS-DTN" <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org%20%3cmailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org
<mailto:sis-dtn-bounces@mailman.ccsds.org</a>> on behalf of <a href="mailto:sis-dtn@mailman.ccsds.org">
sis-dtn@mailman.ccsds.org</a> <<a href="mailto:sis-dtn@mailman.ccsds.org">mailto:sis-dtn@mailman.ccsds.org</a>>> wrote:<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">WG,<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Last week at the SIS-DTN weekly meeting we had a good discussion on allocation strategies for IPN service numbers.
<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">IIRC, there were three major areas of discussion related to these numbers: encoding size, allocation policy, and registry ownership.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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).<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">At the end of the discussion the following proposal was put forward:<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">1 byte service numbers (1-23) will be private use .<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">2 byte service numbers (24-255) will be expert review with a 64-id chunk allocated to SANA.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">4 byte will have a chunk of experimental.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">4+bytes is unassigned.
<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">-Ed<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">---<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Edward J. Birrane, III, Ph.D. (he/him/his)<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Chief Engineer, Space Constellation Networking<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Supervisor, Embedded Applications Group<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Space Exploration Sector<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">Johns Hopkins Applied Physics Laboratory<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">(W) 443-778-7423 / (F) 443-228-3839<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">_______________________________________________<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US">SIS-DTN mailing list<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a> <<a href="mailto:SIS-DTN@mailman.ccsds.org">mailto:SIS-DTN@mailman.ccsds.org</a>><o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><a href="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$</a>
<<a href="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$</a>>
<o:p></o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoPlainText" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
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@esa.int).
</body>
</html>