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

[Kazz, Greg J (312B)]

John and Gian Paolo,

It is always worthwhile to ensure we are doing this update correctly.
But I think in this case, it is the SDLPs (AOS, TM, TC, and the emerging USLP, not Prox-1 because there are no services defined) that provide the Packet Service with the functionality of muxing/demuxing Packets with different APIDs PVNs into/out of a single VC and NOT the SPP Packet Service.

So I still agree with Takahiro, that CCSDS should delete the SPP Packet Service but keep all of the SDLP Packet Services as currently defined in the SDLP blue books. The additional benefit of removing the SPP Packet Service is removing the confusion of having “yet another Packet Service” as defined in SPP.

Below is my analysis:

Packet Service as defined in 3.3.1 Overview of Packet Service in SPP is:

The Packet Service shall transfer Space Packets, pre-formatted by the service user, intact through the LDP.
The service user must generate Space Packets according to the specification given in section 4 of this Recommendation.
Space Packets supplied by the service user shall be transferred by the service provider without further formatting.

*** N.B. There is no mention of muxing/demuxing Packets with different PVNs into/out of a single VC  … in the SPP document **


I reviewed the AOS SDLP. Below I have cut out a portion of Section 2.2.3.2 Virtual Channel Packet Service and 3.3.1 Overview of VCP Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

The exact same words are used in the TM SDLP, because the VCP Service is defined. See Sections 2.2.3.2 VCP Service and 3.3.1. Overview of VCP Service

A user of this service is a protocol entity that ends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

Very similar for TC SDLP; except for TC, we define the MAP Packet Service.  See 2.2.3.3 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity identified with the PVN and a GMAP ID (i.e., a
GVCID and a MAP ID) that sends or receives Packets with a single PVN. Different users
(i.e., Packets with different versions) can share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.

We define MAP Packet Service in USLP SDLP to be the same as the one in TC SDLP. See 2.2.3.2 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN and identified with the PVN and a GMAP ID.
Different users (i.e., Packets with different PVNs) may share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.


Regards,
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: Saturday, January 27, 2018 at 11:00 AM
To: John Pietras <john.pietras at gst.com>
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

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.


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