[Sls-slp] RE: TC commanding

[L.Wood at surrey.ac.uk]

Minor nit in the below - SLE isn't a transport. SLE runs over TCP, which
provides reliable transport (while limiting overall throughput) - though
you'd have to read the SLE specification quite closely to notice that it
runs over TCP.

SLE is really an application-layer protocol.



-----Original Message-----
From: sls-slp-bounces at mailman.ccsds.org on behalf of Hooke, Adrian J (9000)
Sent: Mon 2009-10-19 13:09
To: Shames, Peter M (3130); SLS-SLP WG
Subject: [Sls-slp] RE: TC commanding
 
Peter wrote:

> Actually, according to the definition of "Network Layer" in the ISO BRM, 7498,

> the SPP is NOT a network layer service since it does not exhibit most of the

> properties defined in a network layer. ......

> Accordingly the SPP should either be:

> A) Treated as the application layer data structure that it actually is, or

> B) Be redefined and extended to include all of the attributes that a true network layer service must have.

> Doing A) makes sense.



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.



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??



///a



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091019/39aa3160/attachment.html>