<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div style="color: rgb(0, 0, 0);">Yikes!! </div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"> I agree that there needs to be an OSI stack that shows a network / transport layer, but I do not think that every link layer doc needs to show this. All of the ABA configurations operate without a network / transport layer
and will continue to do so. The SSI configs, however, do have such a network / transport layer. And note that the SCCS-ARD and the SLS OSLP both show how all of this stuff is intended to work together. We do not need to invent something new in this case,
we need to finish what we started.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">I do agree that there is some “CCSDS angst” having to do with the existing application layer standards, like CFDP and AMS, and the relationship to other application layer standards like MOIMS apps and SOIS apps. That is a
key subject on the current “CCSDS Reference Architecture” discussions that are really focussed upon MOIMS & SOIS and how they use underlying communications / transport services, including SLS, SIS and CSS. The position that has been agreed to date in the
CESG and in the reference architetcure discussions is that MOIMS & SOIS rely upon these underlying layers. Having said that there are more than a few murky application layer corners where details will need to be worked out.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">My “Yikes” comment was directly prompted by this statement:</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;">
<div><font color="#ff0000"><b>We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard <u>application</u>’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere
else. </b></font></div>
</blockquote>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">It will probably not come as a surprise to anyone if I point out that this is a total “layer violation”. I know you SIS guys just love to tunnel DTN over IP, so tunneling seems natural, but in this case I not only think this
is a really bad idea, but that it violates what has been agreed to in IOAG and CCSDS and what has been documented in the SCCS-ARD. So think of this as the “layering police” blowing a whistle on this one.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">What has been agreed and documents, in no uncertain terms, is that DTN (preferentially) and IP (where feasible) would be used as the network / transport service for all SSI deployments. At the end nodes, and for emergency
support, we defined a “Last Hop” and “First Hop” application layer service that would, based on meta-data instructions, accept data delivered over the forward path and squirt it out at link layer. It does the reverse in the return direction and also is to
handle open loop and radiometric data. This is “tunneling” of a sort, but it is what has been defined and agreed to. </div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">These “last hop” and “first hop” services are documented in the IOAG SISG study report and in the SCCS-ARD/ADD. May I suggest that if SIS wants to develop an application layer tunneling service (that uses, bye the bye, CFDP
and DTN) that you focus upon carefully defining these first hop and last hop services. You will find the architecture, services, and protocol stacks carefully documented in SCCS-ADD, CCSDS 901.0-G-1, in Sec 4.3.2, 4.4, and particularly in 6.5.3 and in the
SCCS-ARD, CCSDS 901.1-M-1, in Sec 4.3.4 and 6.2.4.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">As for USLP and link layer multiplexing, far as I understand what USLP is trying to do it is to provide link layer “trunk” multiplexing. This is to multiplex several streams of link layer data,
<u>over a single hop</u>, which would typically be between a single ground station and some sort of layer 2 space relay asset. The TDRS fleet is an example of this now and it works in that way. The new optical data link discussions also include such trunking
for exactly the same sorts of relay spacecraft deployments. These data links may well carry SIS DTN (or IP) traffic, and it is in discusison as to whether or not these relay assets are also layer 3 routing nodes and not just layer 2 switching nodes. I personally
think that developing layer 3 routing nodes makes a whole lot of sense if we are talking about routing nodes around distant planets, like Mars. </div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">As a final note, just as I recommend that you SIS guys should stay away from link layer tunneling, that I would say to the SLS guys that they should stick to services that make sense in their layer, which are data links over
a single hop, and that when routing services are required that SIS services should be invoked.</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">So, can we stick to what we have agreed and get the SIS guys to define these last hop & first hop services and not some new, “uncooked” link layer tunneling scheme?</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);">Thanks, Peter</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<div style="color: rgb(0, 0, 0);"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0);">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a>> on behalf of Keith Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>><br>
<span style="font-weight:bold">Date: </span>Friday, October 23, 2015 at 9:18 AM<br>
<span style="font-weight:bold">To: </span>Greg Kazz <<a href="mailto:Greg.J.Kazz@jpl.nasa.gov">Greg.J.Kazz@jpl.nasa.gov</a>>, "<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:sis-dtn-owner@mailman.ccsds.org">sis-dtn-owner@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn-owner@mailman.ccsds.org">sis-dtn-owner@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div>Some comments on the draft USLP book:</div>
<div><br>
</div>
<div><b>Figure 2-1: Relationship with OSI Layers</b></div>
<ul>
<li>The OSI stack has a Network Layer between Data Link and Transport, and I would argue that the CCSDS Layers do as well (that being either IP or BP).</li><li>I’d also like to make an argument for showing up to the application layer, since I think that a lot of CCSDS’ angst comes from not actually thinking that we HAVE applications.</li></ul>
<div><b>General: What the heck is the tunneling service?</b></div>
<div>
<ul>
<li><span style="background-color: rgb(255, 255, 0);">If this really is intended to be tunneling frames across multiple links, we probably need to have a chat between SLP and DTN</span>. We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard
<u>application</u>’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. The receiving application would then extract the frames and instructions and emit them towards
a destination. The motivation for this is to be able to send link-layer commands to a spacecraft with which you (as the ground, e.g.) do not have direct link-layer connectivity. A similar setup would work in the reverse direction, tunneling frames back from
a spacecraft. We (in DTN) have always envisioned these as ‘emergency’ applications, since I’m not keen on what would be essentially extending CSTS across multiple space links!
<ul>
<li>The point is, if you really mean to tunnel across multiple links, it might be better to get the tunnel service from the network.</li></ul>
</li><li>Didn’t seem to me that the description in the book was complete? 4.1.5.1.6 didn’t seem complete, but maybe it’s a nascent idea?</li></ul>
<div><br>
</div>
</div>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b>SCIDs in General</b></div>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<li>To Gian Paolo’s comment about putting the SCID as early as possible in the frame: does putting the SCID early do any good unless you also have the Source/Destination indicator bit?</li><li>Not having the ability to put BOTH a source and destination address in the frame means that
<ul>
<li>When I receive transmissions to ME (Source/Destination bit indicates destination SCID in frame), I don’t know where they came from. Sure, this information may be implied, but what if I’m receiving from someone and there could be multiple senders (I’m thinking
multiple rovers hearing from orbiters on Mars, or a similar situation on the Moon)?
<ul>
<li>Would the ability to include both source and destination addresses allow us to simplify the Mars hailing procedures?</li></ul>
</li><li>This pretty much ensures that it would be really hard to use USLP for anything involving dynamic link discovery (I’m thinking mostly human spaceflight stuff), since dynamic discovery methods generally need both a broadcast address (which I suppose we could
define) and the ability to know who transmitted. This might not be a problem — anything dynamic might be the realm of something that looks a lot more like an adaptation of a terrestrial data link protocol.</li></ul>
</li></ul>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b>3.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU)</b></div>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<li>Is this heading title a misnomer? It seems like you’re mainly describing the TFDF Service Data Unit, which might CONTAIN a TFDF Tunneling Data Unit (?)</li></ul>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b>3.5 TFDF Tunneling Service</b></div>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<li>Same question here. The text seems to deal much more with a TFDF SDU than anything to do with tunneling.</li></ul>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b>6.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU)</b></div>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<li><span style="background-color: rgb(255, 255, 0);">Is Section 6 where section 3 went?</span> Seems like section 6 (Annex) is a repeat of Section 3…</li></ul>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<b>TFDF Header Always Present?</b></div>
<ul style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<li>Is the TFDF header always present whenever the length of the TFDF_SDU > 0?</li></ul>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
====</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<span class="Apple-tab-span" style="white-space:pre"></span>—keith</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div>
<div id="MAC_OUTLOOK_SIGNATURE">
<div><span class="Apple-tab-span" style="white-space: pre;"><u></u></span></div>
<div>
<div id="">
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<b><span style="font-size: 9pt; color: rgb(89, 89, 89);">Dr. Keith Scott</span></b><span style="font-size: 9pt; color: rgb(89, 89, 89);"> <span class="Apple-tab-span" style="white-space: pre;"></span>Office:
+1.703.983.6547<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">Chief Engineer, J86A <span class="Apple-tab-span" style="white-space: pre;"></span>Fax: +1.703.983.7142<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">Communications Network Engineering & Analysis<span class="Apple-tab-span" style="white-space: pre;"></span>Email: <a href="mailto:kscott@mitre.org" style="color: rgb(149, 79, 114);">kscott@mitre.org</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt;"><a href="http://www.mitre.org/" style="color: rgb(149, 79, 114);">The MITRE Corporation</a></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt;"><span style="color: rgb(89, 89, 89);">M/S H300<o:p></o:p></span></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">7515 Colshire Drive<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">McLean, VA 22102<o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);"> </span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">Area Director,</span><span style="font-size: 9pt;"> <a href="http://www.ccsds.org/" style="color: rgb(149, 79, 114);">CCSDS</a> <a href="http://cwe.ccsds.org/sis/default.aspx" style="color: rgb(149, 79, 114);">Space
Internetworking Services</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt;"> </span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
<span style="font-size: 9pt; color: rgb(89, 89, 89);">MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from <a href="http://www.mitre.org/tech/mii/pki/" style="color: rgb(149, 79, 114);">http://www.mitre.org/tech/mii/pki/</a></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri;">
</p>
<p class="inlinegraphic" style="margin: 12pt 0in; line-height: 12pt; font-size: 11pt; font-family: Calibri;">
<span style="color: windowtext; text-decoration: none;"><a href="http://www.mitre.org/"><img border="0" width="168" height="29" src="cid:62DF199A-3B64-4F9A-AA4D-FDB0DA4D46DC" v:shapes="_x0000_i1025" type="image/png"></a></span></p>
<p class="inlinegraphic" style="margin: 12pt 0in; line-height: 12pt; font-size: 11pt; font-family: Calibri;">
<br>
</p>
</div>
</div>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt;"><span style="font-size: 9pt; color: rgb(89, 89, 89);"></span></p>
<p class="MsoNormal" style="margin: 0in 0in 0.0001pt; font-size: 11pt;"><span style="font-size: 9pt; color: rgb(89, 89, 89);"></span></p>
</div>
</div>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a>> on behalf of Greg Kazz <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, October 22, 2015 at 4:25 PM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>[Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
Dear SLP members,</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL:</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<a href="http://tiny.cc/goc14x">http://tiny.cc/goc14x</a></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<u>Note that the filename contains the date of: 10-22-15gk_clean2</u></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<u><br>
</u></div>
<div><u><font face="Calibri,sans-serif">However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried
to be more consistent with the outlines followed by TC, TM, and AOS where applicable.</font></u></div>
<div><u><font face="Calibri,sans-serif"><br>
</font></u></div>
<div><font face="Calibri,sans-serif">B</font><font face="Calibri,sans-serif">est regards,</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">Greg </font></div>
<div><font face="Calibri,sans-serif">Chairman SLP WG</font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 20px;">
<br>
</div>
<br>
</div>
</div>
</span></div>
</div>
</blockquote>
</span>
</body>
</html>