[Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Kazz, Greg J (312B) greg.j.kazz at jpl.nasa.gov
Mon Jan 29 20:34:05 UTC 2018


The SPP “Packet Service” as currently defined lightly touches upon APID multiplexing within some “subnet”  in the actual primitives (Packet Request, Packet Indication) but not in the overview. It is very open ended and so much so that there is really no interoperability here.
Data Encapsulation Service for CCSDS Packets is defined in the separate Encapsulation Service Blue Book.
Multiplexing Packets with different PVNs into VCs is covered by the SDLPs except Prox-1.

We will further discuss this during the Telecon on Wed.
To me one of the questions is: Is there any merit in keeping the “APID Multiplexing within some subnet” Packet Service in SPP ?  Clearly the way it is defined today, no. Could it be redefined to be interoperable and useful ? Perhaps, but only if it is restricted to a single closed subnet within an A-B-A configuration.

Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Monday, January 29, 2018 at 11:28 AM
To: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Peter, i did not refer to VC multiplexing, fully defined in the soace data link protocols, but to the APID miltiplexing or similar issues.
Ciao
Gian Paoli
Sent from my iPhone

On 29. Jan 2018, at 20:20, Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
I think John is right.  The distinction is between a “Space Packet Service “ that is a data encapsulation and multiplexing service within some “subnet”  and a Packet Transfer Service that is the way Space Packets are transferred over an SDL.  This does include the SPP muxing into an SDL VC.  SPP itself cannot assert responsibility for this since it has only virtual (or managed) knowledge of how the packets will be transferred over the subnet.

Regards, Peter
Sent from Peter's JPL iPhone 7

Everything should be made as simple as possible,
but not simpler.

~Albert Einstein

On Jan 27, 2018, at 11:00 AM, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>> wrote:
Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo
Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:
Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

Best regards,
Greg
CCSDS SLP WG Chairman

Greg Kazz
Principal Engineer
Technical Group Supervisor,
Project Software and End-to-End Information Systems Engineering (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>


This message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its

content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.



Please consider the environment before printing this email.


_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org<mailto:SLS-SLP at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp

This message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its

content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.



Please consider the environment before printing this email.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/3206d7d9/attachment.html>


More information about the SLS-SLP mailing list