<HTML>
<HEAD>
<TITLE>Re: [Sls-slp] RE: TC commanding</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>True enough. SLE is an application layer protocol that provides a link layer tunnel. Not unlike a VPN application layer service in that regard.<BR>
<BR>
Cheers, Peter<BR>
<BR>
<BR>
<BR>
On 10/19/09 7:18 AM, "<a href="L.Wood@surrey.ac.uk">L.Wood@surrey.ac.uk</a>" <<a href="L.Wood@surrey.ac.uk">L.Wood@surrey.ac.uk</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Minor nit in the below - SLE isn't a transport. SLE runs over TCP, which<BR>
provides reliable transport (while limiting overall throughput) - though<BR>
you'd have to read the SLE specification quite closely to notice that it<BR>
runs over TCP.<BR>
<BR>
SLE is really an application-layer protocol.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: <a href="sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a> on behalf of Hooke, Adrian J (9000)<BR>
Sent: Mon 2009-10-19 13:09<BR>
To: Shames, Peter M (3130); SLS-SLP WG<BR>
Subject: [Sls-slp] RE: TC commanding<BR>
<BR>
Peter wrote:<BR>
<BR>
> Actually, according to the definition of "Network Layer" in the ISO BRM, 7498,<BR>
<BR>
> the SPP is NOT a network layer service since it does not exhibit most of the<BR>
<BR>
> properties defined in a network layer. ......<BR>
<BR>
> Accordingly the SPP should either be:<BR>
<BR>
> A) Treated as the application layer data structure that it actually is, or<BR>
<BR>
> B) Be redefined and extended to include all of the attributes that a true network layer service must have.<BR>
<BR>
> Doing A) makes sense.<BR>
<BR>
<BR>
<BR>
Absolutely right. The SPP is an Application layer protocol and should remain as such. We have actually tied to use it as an Application support service (APID, length delimitation, sequence are of significance to the application), as a Transport service (sequence count), as a Network service ("Path ID") and as a Link multiplexing service (APID = link port ID, length delimitation). As a consequence we have over-used and under-specified it. It's time to run it as an Application service over underlying Transport, Network and Link services.<BR>
<BR>
<BR>
<BR>
In the Forward Space Packet configuration, the SPP runs over SLE and IP as its Transport and Network layers in order to get to the space Link terminus. If there is then just a single hop into space, this sort of works. However, if there is more than one hop then the SPP is "naked" and can't go any further without a Network layer. So why don't we just get it over with and put one in for all SPP data transfers??<BR>
<BR>
<BR>
<BR>
///a<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><SPAN STYLE='font-size:11pt'><FONT FACE="Helvetica, Verdana, Arial">_______________________________________________________<BR>
<BR>
Peter Shames<BR>
Manager - JPL Data Systems Standards Program<BR>
InterPlanetary Network Directorate<BR>
Jet Propulsion Laboratory, MS 301-230<BR>
California Institute of Technology<BR>
Pasadena, CA 91109 USA <BR>
<BR>
Telephone: +1 818 354-5740, Fax: +1 818 393-0584<BR>
<BR>
Internet: <a href="Peter.M.Shames@jpl.nasa.gov">Peter.M.Shames@jpl.nasa.gov</a><BR>
________________________________________________________<BR>
"We shall not cease from exploration, and the end of all our exploring<BR>
will be to arrive at where we started, and know the place for the first time"<BR>
<BR>
T.S. Eliot<BR>
<BR>
<BR>
</FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN>
</BODY>
</HTML>