<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:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
{font-family:"Open Sans";
panose-1:2 11 6 6 3 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1406104749;
mso-list-template-ids:-955861798;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:1979724445;
mso-list-type:hybrid;
mso-list-template-ids:-977209182 2063527496 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Whatever you do now may not survive IETF.. There have been substantial questions about CBHE conventions within the IETF (reference IETF 115,
<a href="https://www.youtube.com/watch?v=kqA-19a_XQY">https://www.youtube.com/watch?v=kqA-19a_XQY</a>), and at least one IETF draft is proposing that the CBHE numbering scheme be changed to include constructs like ipn:Authority#.node#.service#. See
<a href="https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/00/">https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/00/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We need a hierarchical name space, and the current proposal is less complicated than the first draft that was put out (which proposed ipn:Authority#.Subauthority#.node#.service#, which I rather liked because Authority could be mapped to
space agency or commercial program, subauthority could be mapped to missions, and that would push the assignment of node numbers down to the mission level, where they may need to add, remove or rename nodes at their convenience.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The problem with the IETF proposal is that it is NOT backwards compatible – Scott Burleigh maintains it is, but his definition of backwards-compatible is that NEW DTN implementations could be written to accept the current ipn: scheme. That’s
not my definition of backwards compatible – I mean that CURRENT implementations of DTN (such as the NASA ION baseline software, cFS, and other ION-based flight software as flown now (KPLO for instance) or planning to be flown need to be able to accept and
route on a new ipn:# -- maybe the node couldn’t parse the hierarchical content that will help automated routing in the future, but by user configuration of the contact plans, that could be handled, as long as whatever new number still fit in the current CBOR
definition of ipn:# so the current fielded code doesn’t break.. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(We lost the opportunity to have DTN specified for the Artemis missions because there was NO formal specification to define BPv7 in time for the contract documents to go out with the Bluebook number. So my other warning to IETF is that
if they impose this on DTN, or if CCSDS drags their feet in updating the Bluebook or whatever is necessary, we’ll have the same “lack of specification” problem in putting out contracts for the next round of lunar missions, and further delay the use of DTN
at the moon. If we wait long enough, an infrastructure based on udp/ip and homegrown store and forward and routing methods will take root and DTN will be unnecessary in the minds of many..)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Anyway, whatever CCSDS decides, just be aware that there may be issues with commercial participation in CCSDS missions if the commercial users have adopted a new IETF ipn: scheme.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Leigh<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><b><span style="color:black">J. Leigh Torgerson</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Space Communications Networking Architect<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Protocol Technology Lab Manager <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Communications Architectures & Research (332)<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">Jet Propulsion Laboratory</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">4800 Oak Grove Drive M/S: 238-420</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">Pasadena, CA 91109</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Office: (818) 393-0695<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Email: <a href="mailto:ltorgerson@jpl.nasa.gov" title="mailto:ltorgerson@jpl.nasa.gov">ltorgerson@jpl.nasa.gov</a><b>
</b><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:12.0pt;color:black">From:
</span></b><span lang="EN-GB" style="font-size:12.0pt;color:black">SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> on behalf of Felix Flentge via SIS-DTN <sis-dtn@mailman.ccsds.org><br>
<b>Reply-To: </b>Felix Flentge <Felix.Flentge@esa.int><br>
<b>Date: </b>Wednesday, January 18, 2023 at 11:37 PM<br>
<b>To: </b>"Dr. Keith L Scott via SIS-DTN" <sis-dtn@mailman.ccsds.org><br>
<b>Cc: </b>Harald Ernst <Harald.Ernst@esa.int><br>
<b>Subject: </b>[EXTERNAL] [Sis-dtn] IPN Node Number Assignment<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">According to <a href="https://urldefense.us/v3/__https:/www.iana.org/assignments/bundle/bundle.xhtml*cbhe-node-numbers__;Iw!!PvBDto6Hs4WbVuu7!aus8_8Czlwnvg_vsQQav8CzUDSLldmCy-F_CzsFkKVePeqbLlKCbaEi05rDxMwClKRr1SQ$">
Bundle Protocol (iana.org)</a> SANA is managing the range </span><span lang="EN-GB" style="font-size:10.0pt;font-family:"Open Sans",sans-serif;color:black">16384-2097151.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;font-family:"Open Sans",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">In the (valuable) 2 byte range we have in SANA currently only one allocation:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<table class="MsoNormalTable" border="1" cellpadding="0" width="1440" style="width:15.0in;background:white;border:solid #DDDDDD 1.0pt;border-bottom:solid #111111 1.0pt">
<tbody>
<tr>
<td valign="top" style="border:solid #DDDDDD 1.0pt;background:#F9F9F9;padding:6.0pt 7.5pt 6.0pt 7.5pt">
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:7.5pt;margin-left:0in">
<span style="font-size:10.5pt;font-family:Helvetica;color:#333333">32768 - 33791<o:p></o:p></span></p>
</td>
<td valign="top" style="border:solid #DDDDDD 1.0pt;background:#F9F9F9;padding:6.0pt 7.5pt 6.0pt 7.5pt;box-sizing: content-box;display:table-cell;cursor:pointer">
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:7.5pt;margin-left:0in;box-sizing: border-box">
<span style="font-size:10.5pt;font-family:Helvetica;color:#333333"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/organizations/records/53__;!!PvBDto6Hs4WbVuu7!aus8_8Czlwnvg_vsQQav8CzUDSLldmCy-F_CzsFkKVePeqbLlKCbaEi05rDxMwC45THA5w$"><span style="color:#337AB7">NASA
George C. Marshall Space Flight Center [1.3.112.4.1.19.3]</span></a><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Some questions:<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span lang="EN-GB">Could an Agency request more than one block? Maybe only if well justified, e.g. if the other allocation is used up.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span lang="EN-GB">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)?<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo3"><span lang="EN-GB">What about commercial entities that would like to deploy nodes?<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-GB">Felix<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">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).
<o:p></o:p></span></p>
</div>
</body>
</html>