[Sls-slp] Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Wed Jan 31 14:30:32 UTC 2018

John,
        I think that Packet channel multiplexing is still needed and 
surely implemented by space agencies.
The point is that those implementation are not exposed and I find this 
correct.
Let's say that we should keep the same approach we have had in the past; 
i.e. SPP book shall mention that Packet channel multiplexing is to be 
performed but leaving the implementation to users as loong as there no for 
a commen service (either SLS or CSTS).
If you think this is the same that happened with the TC standard and FSP.
The TC Standard mentioned that TC Frames were multiplexed over VCs/MAPs 
but gave no definition.
When SLE FSP was done it was realised that the TC Frame multiplexing 
required to be defined and in fact you have relevant clauses and an Annex 
in FSP.

The same for TM frame, they are multiplexed over a Master Channel and 
their multiplexing is mentioned but not defined (specially because that 
multiplexing is normally done on board a spacecrat :o).

Regards

Gian Paolo

From:   John Pietras <john.pietras at gst.com>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
Cc:     "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP 
<sls-slp-bounces at mailman.ccsds.org>
Date:   30/01/2018 19:06
Subject:        Re: [Sls-slp] Results of Discussion with Takahiro Yamada 
on Revising SPP Blue Book
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>

All,
In an earlier email in this thread, Greg commented that he understood that 
many missions multiplex different “packet channels” into the same VC, but 
that he did not see this happening in an interoperable way. I think that 
Greg has hit on the important factor here – what is exposed in an 
interoperable, cross-supported way?

Back when we wrote the original AOS book, we had the notion that “cross 
support” users would be able to access individual packet channels via 
standard intefaces. This notion was formalized in the Cross Support 
Reference Model, Part 1 – Space Link Extension Services Blue Book 
(colloquially known as the “SLE Ref Model”), which envisioned two 
“flavors” of Forward Space Packet (TC and AOS) and one Return Space Packet 
service. Those services would have allowed multiple FSP instances to carry 
packete channels all destined for the same VC.

As it turned out, only the TC flavor of the Forward Space Packet service 
was ever realized.  Different instances of the (TC) FSP service are indeed 
capable of carrying different packet channels destined for the same VC. 
The FSP service uses MAP, so the necessary packet channel multiplexing 
into VCs is accomplished (indirectly) through MAP Multiplexing. 

But had the AOS FSP been realized, it *would* have required the packet 
channel muxing that currently resides in the SPP. But since it wasn’t 
realized, the main use case (that I know of) disappears, and perhaps 
packet channel multiplexing is indeed no longer needed at a cross-support 
interoperability level, which I agree with Greg is the important factor in 
considering whether to retain the specification in the SPP (or migrate it 
back into one or more of the SDLP books). 

Best regards,
John

From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] 
Sent: Tuesday, January 30, 2018 8:55 AM
To: Kazz, Greg J (312B)
Cc: John Pietras; sls-slp at mailman.ccsds.org; SLS-SLP
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on 
Revising SPP Blue Book

Greg, 
        what we have to be sure it captured in our CCSDS  books is the 
following situation (e.g. for a TM/AOS link) 
There multiple sources generating packet contents and asking creation of 
packets 
Those packets are created with different APIDs depending on the source 
Those different APIDs shall be multiplexed to produce a single packet 
stream: 
This single packet stream is then injected in in a VC 

It is then correct that "The current AOS SDLP version i.e., CCSDS 
732.0-B-3 Sept 2015 is agnostic about “packet channels”  and “Individual 
CCSDS packets from multiple sources” (implying multiple APIDs). It is 
really only concerned about multiplexing of packets with different PVNs 
onto VCs." In fact AOS would only see that single stream. 

All the rest shall be done above the SDLP. 

We shall check also what we lost with respect to CCSDS 103.0-B-2 (now 
silver) where there was a nice picture for which I attach a detail. 
Another document to be checked for losses is CCSDS 203.0-B-2 and even FSP 
that mention APID multiplexing if I remember well. 

Finally we shall verify all fits within the encapsulation service. 

Ciao 

Gian Paolo 

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
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/20180131/1f44d7f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21544 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/1f44d7f9/attachment.gif>