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

Mon Jan 29 20:44:00 UTC 2018

Greg,
Your first paragraph states my case exactly, where you strike out APIDs and put in PVNs. The SPP give the functionality of multiplexing by APIDs, which is *not* covered by the current AOS, TC, or TM SDLP books.

I have only paper copies of the AOS 701.0 Blue Books, so I can’t cut and paste all of the relevant sections from that document, but here’s section 2.4.1.5.b from 701.0-B-2 (Nov. 1992), which explains the gist of the capability that will lost if the SPP is scrapped: “Individual CCSDS Packets from multiple sources [underline mine]are concatenated together into a contiguous string of Packets, which is then broken into blocks whose length is arranged such that they may be loaded exactly into the fixed-length CVCDU Data Unit Zone. Several individual “Packet Channels” may thus concurrently share one VC using the [packet] Multiplexing functions. Each Packet Channel is locally identified using the “Application Process ID” (APID) field contained in the CCSDS Packet header [underline again mine].”

Looking past the “packet channel” and “subnet” terminology, the idea was that different applications (i.e., different APIDs) could share the same VC. E.g., several sources of low-rate, sporadic data could share the same VC. This is *different from* the PVN multiplexing that is in the current SDLP books, which to my understanding is there mainly to accommodate mixing version 1 and version 2 Space Packets with Encapsulation packets in a single VC.

Just to be clear -  I’m not insisting that muxing of different packet channels (APIDs) into a single VC has to be retained – there may be good reasons why no one would ever actually want to do it and/or it may never actually have been used. My only reason to bring this up is to point out that there *is*  a difference between the “APID muxing” provided by the SPP and the “PVN muxing” provided by the current SDLP books, and that the WG should consider whether they want to deprecate that capability (probably with clarification to eliminate implications of end-to-end “routing”, etc.). Also, you might want to check with ISS, since they implemented AOS even before it was completely Blue – they may very well have multiple APIDs carried in a single VC.

Unfortunately, I have a doctor’s appoint on Wednesday morning. I may get back in time to call into the telecon, and will do so if possible. But if I don’t, I think/hope that I’ve explained the situation well enough that the WG can deliberate on the merits of my observations (or lack thereof).

Best regards,
John

From: Kazz, Greg J (312B) [mailto:greg.j.kazz at jpl.nasa.gov]
Sent: Monday, January 29, 2018 2:59 PM
To: Gian.Paolo.Calzolari at esa.int; John Pietras
Cc: sls-slp at mailman.ccsds.org
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

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<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of "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>>
Date: Saturday, January 27, 2018 at 11:00 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto: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.

________________________________

Spam<https://filter.gst.com/canit/b.php?c=s&i=01V4jXOp8&m=1a3091b1c61c>
Not spam<https://filter.gst.com/canit/b.php?c=n&i=01V4jXOp8&m=1a3091b1c61c>
Forget previous vote<https://filter.gst.com/canit/b.php?c=f&i=01V4jXOp8&m=1a3091b1c61c>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/070ada1f/attachment.html>