<div dir="ltr">Interesting point. In the Internet space, we ended up with "well-known ports" as a way of registering standard services.<div>Not every host runs all services (ie has an active process servicing a particular port or, for that matter, protocol). </div><div>Connection attempts to unserved ports get rejected. Connection attempts to unserved protocols, ditto (I think). </div><div><br></div><div>Registration would not be a guarantee of service but might avoid useless attempts to reach a particular EID with any particular port or protocol.</div><div><br></div><div>Changes to service support would need to be registered - a procedural detail we would likely need to instantiate along with a sort of manual of operations for BP - if BP operation becomes widespread, we should be asking ourselves how the operational aspects will scale and what infrastructure we will need to achieve that.</div><div><br></div><div>v</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 28, 2018 at 8:39 AM, Scott, Keith L. <span dir="ltr"><<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_6947685029728358351WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt">Greetings,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt">Peter Shames noted that while there are registries for SANA CBHE Node and Service numbers that will allow us to deconflict node EIDs and have a uniform interpretation of the service numbers, there is nothing that says WHICH services are running at WHICH node, OR anything that associates BP Nodes (in our case identified by CBHE Node IDs) and the services they’re running with ‘Sites’ (using the Service and Site Aperture Registry definition) such as ground stations, spacecraft, etc. This kind of information, while not technically required to make BP work, is part of the administration/operation of the network, and would be expected to change infrequently (and so at least feasible to maintain in a registry).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt">The desire is for the DTN WG to identify changes / augmentations to the SANA registries to provide the information above. The attached Registry Management Policy deck includes an overview of the Service Site & Aperture structure on slides 21—23.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt">I propose the following strawman for discussion:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">Change the <span style="color:#4472c4">Network Services</span> under <span style="color:#00b050">Site Service Info</span> on slide 22 to be a ‘<span style="color:#c55a11">mayInclude (0..*)</span> – i.e. allow for possibly multiple network services. This would allow sites that have multiple BP routers, which I’ll admit might be unusual but certainly possible.<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">Define a <span style="color:#4472c4">BP_Network_Service </span>element (registry) that is a logical subclass of the <span style="color:#4472c4">Network_Services</span> listed on slide 22 as:<u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><b><span style="font-size:11.0pt">CBHE Node #,</span></b><span style="font-size:11.0pt"> the CBHE Node Number of the BP Node, hyperlinked to the node number allocation range in the CBHE Node Number Registry<u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><b><span style="font-size:11.0pt">POC</span></b><span style="font-size:11.0pt">: a link to the appropriate SANA registry entry for who to talk to about connecting with this node (e.g. routing through it) [Could be a person or an organization?]<u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><b><span style="font-size:11.0pt">List of CBHE Service #s</span></b><span style="font-size:11.0pt">: A list of CBHE service numbers that can be expected to be running on the node (e.g. CFDP) – hyperlinked to their corresponding entries in the CBHE Service # registry.<u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.0in"><u></u><span style="font-size:11.0pt;font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><b><span style="font-size:11.0pt">List of convergence layers and their information</span></b><span style="font-size:11.0pt">: so for example, if the node is running a TCPCL on IP address <a href="http://10.1.2.3:1234" target="_blank">10.1.2.3:1234</a>, a UDP CL on port address <a href="http://10.1.2.6:5678" target="_blank">10.1.2.6:5678</a>, and an LTP/Encap CL on virtual channel 3, those would be listed.<u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.5in"><u></u><span style="font-size:11.0pt;font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;color:red">Maybe listing the VC isn’t appropriate here? That’s more a function of the mission configuration (e.g. each mission could use a different VC even if all share the same aperture and site, I think)</span><span style="font-size:11.0pt"><u></u><u></u></span></p><p class="m_6947685029728358351MsoListParagraph" style="margin-left:1.5in"><u></u><span style="font-size:11.0pt;font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;color:red">I’d vote for the CL info being a free text field with a convention for entries like TCP:1234:4556 rather than trying to generate a whole sub-structure for CL entries – thoughts?</span><span style="font-size:11.0pt"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt">Somebody should probably also define an <span style="color:#4472c4">IP_Network_Service</span> element. That may fall to us as well but could pretty much mirror the BP one (but without CL info).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt">Thoughts on this?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"> <wbr> v/r,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"> <wbr> --keith<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><u><span style="font-size:10.0pt;color:black"><u></u><span style="text-decoration:none"> </span><u></u></span></u></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">Dr. Keith Scott <wbr> Office: +1.703.983.6547</span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">Chief Engineer, Communications Network Engineering & Analysis Fax: +1.703.983.7142</span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">Advanced Data Transport Capability Area Lead <wbr> Email: <a href="mailto:kscott@mitre.org" target="_blank"><span style="color:#7f7f7f">kscott@mitre.org</span></a></span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#474747"> </span></b><span style="font-size:10.0pt;color:black"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><span style="font-size:10.0pt;color:black"><a href="http://www.mitre.org/" target="_blank"><b><span style="color:blue">The MITRE Corporation</span></b></a><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">M/S J500</span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">7515 Colshire Drive</span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f">McLean, VA 22102</span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7f7f7f"> </span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;color:#7f7f7f">MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from <a href="https://www.mitre.org/tech/mii/pki/" target="_blank"><span style="color:#7f7f7f">https://www.mitre.org/<wbr>tech/mii/pki/</span></a></span></b><span style="font-size:10.0pt;color:#7f7f7f"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p></div></div>
<br>______________________________<wbr>_________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn" rel="noreferrer" target="_blank">https://mailman.ccsds.org/cgi-<wbr>bin/mailman/listinfo/sis-dtn</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">New postal address:<div>Google<br><div>1875 Explorer Street, 10th Floor</div><div>Reston, VA 20190</div></div></div></div>
</div>