<span style=" font-size:10pt;font-family:sans-serif">Dear All,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
in the attached file you find my considerations over
Greg's input and Ed's comments (marked red).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I converted Ed's
e-mail below to a Word File to be able to use WinWord comments etc.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">If required I
can provide the original WinWord file, while I attach here the pdf for
easier reading.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Comments are welcome.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Regards</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo</span>
<br>
<br>
<br>
<br>
<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">"Greenberg,
Edward (312B)" <edward.greenberg@jpl.nasa.gov></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Kazz,
Greg J (312B)" <greg.j.kazz@jpl.nasa.gov>, "Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int>, John Pietras <john.pietras@gst.com></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></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">01/02/2018
07:17</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] Packet channel multiplexing no longer needed? : 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;font-family:Calibri">My
comments are in </span><span style=" font-size:11pt;color:red;font-family:Calibri">red
in the text </span><span style=" font-size:11pt;font-family:Calibri">below.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
SLS-SLP [</span><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><span style=" font-size:11pt;font-family:Calibri">mailto:sls-slp-bounces@mailman.ccsds.org</span></a><span style=" font-size:11pt;font-family:Calibri">]
<b>On Behalf Of </b>Kazz, Greg J (312B)<b><br>
Sent:</b> Wednesday, January 31, 2018 3:39 PM<b><br>
To:</b> Gian.Paolo.Calzolari@esa.int; John Pietras <john.pietras@gst.com><b><br>
Cc:</b> sls-slp@mailman.ccsds.org<b><br>
Subject:</b> Re: [Sls-slp] Packet channel multiplexing no longer needed?
: 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:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">All,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Here
is a follow on to the telecon that occurred today between myself, Gian-Paolo,
Stefan Veit, and Ed Greenberg. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
are searching for the right approach to revise the SPP.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
are still in the brainstorming part of development. All inquiries and ideas
are most invited!</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">As
we discussed in the Haag in Nov. 2017, the Space Packet provides a duality
of functionality: It is both an Application Layer (AP) Data Structure and
Format as well as a data link layer transport mechanism i.e. it is transported
within the frame data field of CCSDS transfer frames.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
all seem to agree that there should be no mention of multiple subnetworks
and routing in the future SPP. These things are handled much better by
DTN, IP, etc.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
go back to the basic structure of what we shall describe in the SPP Blue
Book: (<b>This is where I would like to get consensus on</b> <b>first</b>)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">In
the Application Layer, there are multiple users (data sources) including
the SPP Packet Assembly Function (out of strings it makes packets) that
request the <i>transfer </i>of Space Packets out of the Application Layer
by supplying the </span><span style=" font-size:11pt;color:red;font-family:Calibri"><i><strike>APID</strike></i></span><span style=" font-size:11pt;font-family:Calibri"><i>,
APID_Qualifier (optional), QoS Rqmt (optional) – </i>as currently defined
by the SPP. This is accomplished by generating the <i>packet.request </i>primitive
in SPP. So multiple users are producing packets with different APIDs under
management control and outside the purview of CCSDS. </span><span style=" font-size:11pt;color:red;font-family:Calibri">APID
is already in the packet thus it need not be supplied externally.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">2.
</span><span style=" font-size:11pt;font-family:Calibri">In
the Application Layer, those packets provided by those multiple users and
SPP Packet Assembly Function, shall be multiplexed to produce a <i>single
packet stream</i> in the appropriate order set by management whose algorithm
is not specified by CCSDS – as currently defined by SPP. (SPP talks about
a single Queue, but use of the term “stream” is better because it is
implementation agnostic). </span><span style=" font-size:11pt;color:red;font-family:Calibri">There
is a packet stream to each VC SAP. If there is only one packet stream then
the transfer protocol must include the <i>VCID</i> along with the <i>QoS</i>
desired. I don’t understand <i>APID_Qualifier</i>.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">3.
</span><span style=" font-size:11pt;font-family:Calibri">NOW
HERE COMES SOME CONTENTION – Do we want the SPP to have the capability
of <i>forwarding data</i> (not routing data) on-board (mostly envisioned
for on-board the spacecraft) within a single closed subnetwork in an A-B-A
configuration ? If the answer is yes (I think it is yes), then <i>APID_Qualifier
</i>needs to be well and unambiguously defined for SPP. I can supply a
use case from the ISS. For Telecommand, Space Station uses Logical Data
Path – Endpoint as the <i>APID_Qualifier</i> (this field occurs in the
packet 2<sup>nd</sup> Header, which is currently non-compliant with SPP
because there is currently no standard packet 2<sup>nd</sup> header defined)
to forward commands to user modules on-board the ISS. In this case, Logical
Data Path is short circuited to be a Logical Data Path Endpoint. OR Gian
Paolo contents that we should retire the concept of Logical Data Path completely,
and only leave a historical note in SPP about its previous existence? </span><span style=" font-size:11pt;color:red;font-family:Calibri">I’m
not quite sure what you mean by data forwarding. The Logical Data
Path concept that was defined in the otiginal Source Packet sped was for
a single link. That could be a local network addressing scheme or
a remote addressing scheme across a single link. This later scheme
is what is used almost totally by non-manned missions. The use of
a standard set of labels within the secondary header is a fine use of the
current packet format for multiple things but the current users use
the secondary header flag for non-standard secondary headers.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
may need to hold open the possibility of Logical Data Path Endpoint or
something similar until we get clarification from all agencies and the
SIS area about their desires for eventually modifying the SPP packet 2<sup>nd</sup>
header in order to accomplish data forwarding on-board a spacecraft. Does
this data forwarding function take place in the application layer ?
</span><span style=" font-size:11pt;color:red;font-family:Calibri">We may
not need to modify the current format if we set a few constraints(i.e.
we could define a single APID in the packet header as a flag signaling
the inclusion of standard labels in the secondary header. These standard
labels could provide the true <i>APID, APID_Qualifier( whatever this is),
QoS Rqmt, time of generation, time to live, priority for delivery, global
source and destination addresses, packet security parameters. Etc. This
methodology would have little effect on today’s usage of the Packet Format
and Link layer Packet service.</i></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">4.
</span><span style=" font-size:11pt;font-family:Calibri">In
the Data Link Layer, the <i>transfer across the space link</i> of those
Space Packets is requested. Here an additional multiplexing step <i>may
</i>take place, packets of multiple PVNs are multiplexed into the stream,
before packets are placed into the transfer frame data fields of frames.
Each single packet stream is then injected into the TF data field of a
specific VC frame by sending it to the instance of the Packet Processing
Function for that VC that transports packets as defined in the appropriate
<i>SDLP Packet Processing Function</i>. The most generic way of expressing
this primitive is to use Encapsulation.request (Data Unit, SDLP_Channel,
PVN, EPI). Of course, one could also accomplish this transfer by using
VCP.request (only for AOS or TM) or MAPP.request (TC) or (USLP) or Packet
Service in Prox-1.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Makes
sense ?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks!</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Greg</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Chairman
SLP WG</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>"</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></span></a><span style=" font-size:12pt;font-family:Calibri">"
<</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Date: </b>Wednesday, January 31, 2018 at 6:30 AM<b><br>
To: </b>John Pietras <</span><a href=mailto:john.pietras@gst.com><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>john.pietras@gst.com</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Cc: </b>Greg Kazz <</span><a href=mailto:greg.j.kazz@jpl.nasa.gov><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>greg.j.kazz@jpl.nasa.gov</u></span></a><span style=" font-size:12pt;font-family:Calibri">>,
"</span><a href="mailto:sls-slp@mailman.ccsds.org"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>sls-slp@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">"
<</span><a href="mailto:sls-slp@mailman.ccsds.org"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>sls-slp@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">><b><br>
Subject: </b>Packet channel multiplexing no longer needed? : [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:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><a name=_MailOriginalBody></a><span style=" font-size:10pt;font-family:Arial">John,</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
I think that Packet channel multiplexing is
still needed and surely implemented by space agencies.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
The point is that those implementation are not exposed and I find this
correct.</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
If you think this is the same that happened with the TC standard and FSP.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
The TC Standard mentioned that TC Frames were multiplexed over VCs/MAPs
but gave no definition.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Regards</span><span style=" font-size:11pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Gian Paolo</span><span style=" font-size:11pt;font-family:Calibri"> <br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
From: </span><span style=" font-size:9pt;font-family:Arial">John
Pietras <</span><a href=mailto:john.pietras@gst.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>john.pietras@gst.com</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Gian.Paolo.Calzolari@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Gian.Paolo.Calzolari@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
"Kazz, Greg J (312B)" <</span><a href=mailto:greg.j.kazz@jpl.nasa.gov><span style=" font-size:9pt;color:blue;font-family:Arial"><u>greg.j.kazz@jpl.nasa.gov</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Cc: </span><span style=" font-size:9pt;font-family:Arial">"</span><a href="mailto:sls-slp@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sls-slp@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href="mailto:sls-slp@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sls-slp@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
SLS-SLP <</span><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sls-slp-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">30/01/2018
19:06</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">Re:
[Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue
Book</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:9pt;font-family:Arial">"SLS-SLP"
<</span><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sls-slp-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">All,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">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:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080">John</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:#004080"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Tahoma"><b>From:</b>
</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:10pt;color:blue;font-family:Tahoma"><u>Gian.Paolo.Calzolari@esa.int</u></span></a><span style=" font-size:10pt;font-family:Tahoma">
[</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:10pt;color:blue;font-family:Tahoma"><u>mailto:Gian.Paolo.Calzolari@esa.int</u></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; </span><a href="mailto:sls-slp@mailman.ccsds.org"><span style=" font-size:10pt;color:blue;font-family:Tahoma"><u>sls-slp@mailman.ccsds.org</u></span></a><span style=" font-size:10pt;font-family:Tahoma">;
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">
<br>
</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">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<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">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Finally we shall verify all fits within the encapsulation service.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Ciao</span><span style=" font-size:12pt;font-family:Times New Roman"> </span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Gian Paolo</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><img src=cid:_1_11B4515C11B448D00050D8EEC1258227 alt=cid:image001.gif@01D399A9.B32BEF00 style="border:0px solid;"><span style=" font-size:10pt;font-family:Courier New"><br>
This message and any attachments are intended for the use of the addressee
or addressees only.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
content is not permitted.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
If you received this message in error, please notify the sender and delete
it from your system.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Courier New"><br>
Please consider the environment before printing this email.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Courier New"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span>
<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:240px"><span style=" font-size:10pt;font-family:Courier New"><br>
_______________________________________________<br>
SLS-SLP mailing list</span><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href="mailto:SLS-SLP@mailman.ccsds.org"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>SLS-SLP@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp</u></span></a></p>
<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>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New"> </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>