<html 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;}
@font-face
{font-family:"Helvetica Neue";
panose-1:2 0 5 3 0 0 0 2 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.p1, li.p1, div.p1
{mso-style-name:p1;
margin-top:12.0pt;
margin-right:0in;
margin-bottom:3.75pt;
margin-left:0in;
font-size:9.0pt;
font-family:"Helvetica Neue";}
p.p2, li.p2, div.p2
{mso-style-name:p2;
margin:0in;
font-size:9.0pt;
font-family:"Helvetica Neue";}
p.p3, li.p3, div.p3
{mso-style-name:p3;
margin:0in;
font-size:9.0pt;
font-family:"Helvetica Neue";}
p.p4, li.p4, div.p4
{mso-style-name:p4;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:14.85pt;
font-size:9.0pt;
font-family:"Helvetica Neue";}
p.p5, li.p5, div.p5
{mso-style-name:p5;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:26.1pt;
font-size:9.0pt;
font-family:"Helvetica Neue";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.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;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi folks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Just as a matter of clarification, I must say that Scott Burleigh didn’t change the definition of a “region” per se – that erroneously attributes a change to Scott, who no-doubt always implicitly thought of
a “region” being defined by a tractable Contact Plan that everyone shares. The concept of a region has been kicked around a lot at JPL between mission planners, network analysts, etc., and it (in my mind) was never something that was specifically defined as
“the set of nodes that all share the same contact plan”, but that was the way it was defined for the creation of the Inter Regional Routing (IRR) ION software, which makes sense, and should be a great starting point for exploring how to manage expanding DTN
networks in a scalable fashion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We had conceived of a region being, say, something like a “Surface Operations Region”, where there would likely be a hybrid collection of routing methods (mobile routing over 5G, mesh networks on the surface,
etc., all of which would interface with a lander with surface to Gateway relay capabilities using CGR, or into a Commercial Relay Satellite network that may or may not use CGR for internal relay s/c to relay s/c crosslink routing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">There are many many different possible topologies and methods, and only one word to describe them all – that the problem with language! Maybe Lunar Surface Ops is a Realm which contains a set of Regions (defined
by their CGR plans or other routing plans) that may interconnect but are all owned by the same King.
</span><span style="font-size:11.0pt;font-family:"Apple Color Emoji"">😊</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(all that being said, don’t even TRY to read the AMS spec at this point…)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Leigh<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">FYI, attached is the presentation & discussion slides I used last May to present our DTN DNS ideas to the IPNSIG. Lots of questions remain of course, and since Scott Burleigh has changed the definition of
a “region” to be a collection of nodes that all have the same contact plan, some additional things have to be considered in the next to the last slide. In any case, this is what I’ve been working on to support an initial prototype of an AMMOS Mars DTN Relay
network, as well as something to test out with both IPNSIG and the DEN if we can generate interest in re-awakening the DTN Readiness Program’s DTN Engineering Network.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Leigh<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:black">J. Leigh Torgerson<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Space Communications Networking Architect<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Protocol Technology Lab Manager
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Communications Architectures & Research (332)<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:black">Jet Propulsion Laboratory</span></b><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:black">4800 Oak Grove Drive M/S: 238-420</span></b><span style="font-size:11.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;color:black">Pasadena, CA 91109</span></b><span style="font-size:11.0pt;color:black">
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Office: (818) 393-0695<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Email: <a href="mailto:ltorgerson@jpl.nasa.gov">
ltorgerson@jpl.nasa.gov</a></span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> on behalf of "Dr. Keith L Scott via SIS-DTN" <sis-dtn@mailman.ccsds.org><br>
<b>Reply-To: </b>"Scott, Keith L." <kscott@mitre.org><br>
<b>Date: </b>Thursday, July 28, 2022 at 10:28 AM<br>
<b>To: </b>"Tomaso.deCola@dlr.de" <Tomaso.deCola@dlr.de><br>
<b>Cc: </b>"sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org><br>
<b>Subject: </b>[EXTERNAL] Re: [Sis-dtn] [EXT] RE: Telecon 20220728<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Concur. I *<b>think</b>* those will ‘fall out of’ the BPsec and NM discussions, but yes, we should ensure that we have a comprehensive architecture / plan that all hangs together.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> --keith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><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">Tomaso.deCola@dlr.de <Tomaso.deCola@dlr.de><br>
<b>Date: </b>Thursday, July 28, 2022 at 12:13 PM<br>
<b>To: </b>Dr. Keith L Scott <kscott@mitre.org><br>
<b>Cc: </b>sis-dtn@mailman.ccsds.org <sis-dtn@mailman.ccsds.org><br>
<b>Subject: </b>[EXT] RE: Telecon 20220728<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt">As to the “homework” “what to do next”, we should also address at some point the remarks made by Peter Shames also in relation to the considerations drawn in IOAG about the overall security framework
in CCSDS and missing elements in DTN (i.e. those going beyond BPSEC). Specifically he pointed in a presentation shared in June to: “Key management and identity mechanisms need to be defined,
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt">Secure network management framework for multi-agency interoperability needs to be defined”.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt">Tomaso<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt"> <o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt">From:</span></b><span style="font-size:11.0pt"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Dr. Keith L Scott via SIS-DTN<br>
<b>Sent:</b> Donnerstag, 28. Juli 2022 17:56<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> [Sis-dtn] Telecon 20220728</span><span lang="EN-GB" style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="p1"><b>SIS-DTN</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p1"><b>IETF DTN WG Meeting</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">CCSDS:<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• Talked about our ‘requirements’ for auditing / accounting / reliability<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• Plan forward: do work, ensure that IETF DTN WG is cognizant of it; coordinate as makes sense<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">Naming:<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• I wasn’t able to make the second half of the DTN WG meeting where naming was discussed<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• Apparently Airbus has some needs that aren’t well-met by ‘just’ an IPN Node #, looking for something more<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• Scott proposed using ‘just’ IPN node numbers as the identification mechanism and developing ‘DNS-like’ and ‘whois-like’ services:<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p5">• DNS-like: transforms mnemonics into IPN node numbers<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p5">• whois-like: translates IPN node numbers into points-of-contact<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p5">• Need to secure both of these services (obviously)<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p1"><b>LTP Orange:</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">Need use cases / metrics for when orange is a win.<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• E.g. with a latency of xxx and an LTP segment loss rate of yyy, using the metrics: (total memory*time used by receiver, total memory*time used by transmitter) ...<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">If we can’t find a use case that is compelling, we shouldn’t include Orange (keep the protocol as simple as possible).<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p1"><b>Jonathan’s bit ordering question</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">In RFC9171, things like the Bundle Processing Control Flags refer to the ‘least significant bit’.<span class="apple-converted-space">
</span>Note that the BPCF is a bit field represented by a CBOR unsigned integer.<span class="apple-converted-space">
</span>In the integer representation of the CBOR unsigned int, ‘least significant bit’ is unambiguous (It’s the bit that determines whether the integer is odd or even).<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">We don’t really care how the link layer might mangle things for transmission, so long as what is received is interpretable as (the same) CBOR unsigned integer, so the LSB makes sense.<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p1"><b>Homework</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• LTP Orange Question<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p4">• What to do next?<span class="apple-converted-space"> </span>BPsec Green, NM (Blue, Green), LTP<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p1"><b>Simon’s question about ADMs</b><span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">We pushed a lot of things out of the BPv7 profile for expediency.<span class="apple-converted-space">
</span>Many of those SHOULD be addressable via network management.<span class="apple-converted-space">
</span>We should work a set of ADMs (e.g. BPv7, ION, LTPv2, ...) in concert with the ‘base’ NM protocol work as a sanity-check to ensure that the NM protocol will in fact support what we need.<span class="apple-converted-space">
</span>Use these to address the issues we pushed out of the base CCSDS BPv7 profile.<span lang="EN-GB"><o:p></o:p></span></p>
<p class="p2"> <span lang="EN-GB"><o:p></o:p></span></p>
<p class="p3">There’s an (old) draft BP ADM here: <a href="https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/draft-birrane-dtn-adm-bp/__;!!PvBDto6Hs4WbVuu7!YBcwEKvxai6h74R_WFOq89JGPuwabmY9je1xfMHbcbWdT4w5bGba2JH_Mlr3N9pNHkPGEg$">
https://datatracker.ietf.org/doc/draft-birrane-dtn-adm-bp/</a> (thanks Sarah, for pointing this out).<span lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><span lang="EN-GB" style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
</body>
</html>