<span style=" font-size:10pt;font-family:sans-serif">John,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
I think that Packet channel multiplexing is still
needed and surely implemented by space agencies.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The point is that
those implementation are not exposed and I find this correct.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">If you think this
is the same that happened with the TC standard and FSP.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The TC Standard
mentioned that TC Frames were multiplexed over VCs/MAPs but gave no definition.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><br>
Regards</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">John
Pietras <john.pietras@gst.com></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int>, "Kazz, Greg J (312B)" <greg.j.kazz@jpl.nasa.gov></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"sls-slp@mailman.ccsds.org"
<sls-slp@mailman.ccsds.org>, SLS-SLP <sls-slp-bounces@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">30/01/2018
19:06</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue
Book</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SLS-SLP"
<sls-slp-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">All,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">But
had the AOS FSP been realized, it *<b>would</b>* 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). </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">John</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Tahoma"><b>From:</b>
Gian.Paolo.Calzolari@esa.int [</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:10pt;font-family:Tahoma">mailto:Gian.Paolo.Calzolari@esa.int</span></a><span style=" font-size:10pt;font-family:Tahoma">]
<b><br>
Sent:</b> Tuesday, January 30, 2018 8:55 AM<b><br>
To:</b> Kazz, Greg J (312B)<b><br>
Cc:</b> John Pietras; sls-slp@mailman.ccsds.org; SLS-SLP<b><br>
Subject:</b> Re: [Sls-slp] Results of Discussion with Takahiro Yamada on
Revising SPP Blue Book</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Greg,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
what we have to be sure it captured in our
CCSDS books is the following situation (e.g. for a TM/AOS link)</span><span style=" font-size:12pt;font-family:Times New Roman">
</span></p>
<ul>
<li><span style=" font-size:10pt;font-family:Arial">There multiple sources
generating packet contents and asking creation of packets</span><span style=" font-size:12pt;font-family:Times New Roman">
</span>
<li><span style=" font-size:10pt;font-family:Arial">Those packets are created
with different APIDs depending on the source</span><span style=" font-size:12pt;font-family:Times New Roman">
</span>
<li><span style=" font-size:10pt;font-family:Arial">Those different APIDs
shall be multiplexed to produce a single packet stream:</span><span style=" font-size:12pt;font-family:Times New Roman">
</span>
<li><span style=" font-size:10pt;font-family:Arial">This single packet
stream is then injected in in a VC</span><span style=" font-size:12pt;font-family:Times New Roman">
</span>
<li><span style=" font-size:12pt;font-family:Times New Roman"> </span></ul><span style=" font-size:10pt;font-family:Arial">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.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:10pt;font-family:Arial"><br>
All the rest shall be done above the SDLP.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Another document to be checked for losses is CCSDS 203.0-B-2 and even FSP
that mention APID multiplexing if I remember well.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Finally we shall verify all fits within the encapsulation service.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Ciao</span><span style=" font-size:12pt;font-family:Times New Roman"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Gian Paolo</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><img src=cid:_1_0A8C79C80A8C70FC004FB30AC1258226 alt=cid:image001.gif@01D399A9.B32BEF00 style="border:0px solid;">
<br><span style=" font-size:10pt;font-family:Courier New">This message
and any attachments are intended for the use of the addressee or addressees
only.</span>
<br><span style=" font-size:10pt;font-family:Courier New">The unauthorised
disclosure, use, dissemination or copying (either in whole or in part)
of its</span>
<br><span style=" font-size:10pt;font-family:Courier New">content is not
permitted.</span>
<br><span style=" font-size:10pt;font-family:Courier New">If you received
this message in error, please notify the sender and delete it from your
system.</span>
<br><span style=" font-size:10pt;font-family:Courier New">Emails can be
altered and their integrity cannot be guaranteed by the sender.</span>
<br><span style=" font-size:10pt;font-family:Courier New"> </span>
<br><span style=" font-size:10pt;font-family:Courier New">Please consider
the environment before printing this email.</span>
<br><span style=" font-size:10pt;font-family:Courier New"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<br><tt><span style=" font-size:10pt">_______________________________________________<br>
SLS-SLP mailing list<br>
SLS-SLP@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt>
<br>
<br>
<PRE>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.
</PRE>