<span style=" font-size:10pt;font-family:sans-serif">Greg,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
interoperability is one target but proper design
is another one.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I disagree that
we should delete the SPP primitives while I think we shall shed light on
the unvcleear items of the phantasy world as required going back to what
we know being reality.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The ECSS PUS (ECSS-E-ST-70-41C)
is fully based on the Space Packet and represent a good example for common
design and , somehow, interoperability.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">I think it is
fully correct that "missions come up with their own ways of assigning
APIDs to VCIDs".</span>
<br><span style=" font-size:10pt;font-family:sans-serif">There is no fixed
rule in this (more than spacecraft architecture etc).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">We shall remember
the basic structure we shall describe in the SPP book; i.e. (with some
additions with resect to what I wrote yesterday) </span>
<ul>
<li><span style=" font-size:10pt;font-family:sans-serif">There multiple
sources generating packet contents and asking <b>transmission </b>of packets<b>
with a given APID (as per PACKET.request primitive)</b></span>
<li><span style=" font-size:10pt;font-family:sans-serif">Those different
APIDs shall be multiplexed to produce a single packet stream <b>per VC</b></span>
<li><span style=" font-size:10pt;font-family:sans-serif"><b>EACH </b>single
packet stream is then injected in in a VC <b>by sending it to the instance
of the Packet Processing Function for that Virtual Channel that carries
Packets</b></span></ul>
<br><span style=" font-size:10pt;font-family:sans-serif">[note that I removed
the step "Those packets are created with different APIDs depending
on the source " as I understand the complete space packet is passed
from the requesting source application]</span>
<br><span style=" font-size:10pt;font-family:sans-serif">As far as I know
nothing prevents a source application form asking two packets with the
same APID to be transmitted over different VCs.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Basically we should
refine the description (in 133.0-B) of the so called (in 132.0-B) "Packet
Service User with PVN = SPP".</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I do concur with
you about the fact that " APID Qualifier is totally left up to the
user to define." and looking at the VCP.request primitive I
think we have an opportunity for some clean up.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Basically we have
the problem of identifying the SPP processing (by the PACKET TRANSFER FUNCTION
defined in 4.2.3) bridging between the following two primitives</span>
<br><span style=" font-size:10pt;font-family:sans-serif">PACKET.request
(Space Packet, APID, APID Qualifier
(optional), QoS Requirement (optional)) </span>
<br><span style=" font-size:10pt;font-family:sans-serif">VCP.request
(Packet,
GVCID, Packet Version Number) </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">As I think that
you are also right saying that "Maybe in SPP we simply need to acknowledge
and document that these steps are done outside of CCSDS services."
our opportunity can be to state that some behaviour are left to individual
implementation (it would not be the first time in CCSDS :o).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">In our case I
think that we can mention that the GVCID that SPP shall put in the VCP.request
can either be part of the APID Qualifier or managed (indeed in section
5.2 we have already the managed parameter "Packet Multiplexing Scheme".</span>
<br><span style=" font-size:10pt;font-family:sans-serif">An alternative
may be looking at some harmonisation with the Encapsulation service defined
in CCSDS 133.1-B-2 where the ENCAPSULATION.request actually contains
the SDLP_Channel completely defined in section 3.2.2 with respect to the
individual packet services of the lower layer (VCP Service of TM/AOS/TC,
MAPP Service of TC, Packet Service of Proximity-1) , </span>
<br><span style=" font-size:10pt;font-family:sans-serif">In fact a user
can ask to transmit a packet also with an ENCAPSULATION.request and we
should make sure the involved processing is consistent.</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><b>This consistency
check shall not be neglected.</b></span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I think that for
the OCTET_STRING.request with parameters (Octet String, APID,
APID Qualifier (optional), Secondary Header Indicator, QoS Requirement
(optional)) we will just need to apply the same considerations as
eventualy everything goes into the PACKET TRANSFER FUNCTION as shown in
Figure 4-4: Internal Organization of Protocol Entity (Sending
End).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Actually it looks
as one main topic will be redefining clause "</span><span style=" font-size:10pt;color:blue;font-family:sans-serif">4.2.3.3
The Packet Transfer Function, then, shall examine the Path ID of each Packet
in the queue to identify the next protocol
entity in the LDP of the Packet
and shall transfer the Packet using
a service of the underlying subnetwork.
The Packet Transfer Function may transfer
the Packet to multiple protocol entities
which are not necessarily on the same
subnetwork; i.e., it may perform a multicast function.</span><span style=" font-size:10pt;font-family:sans-serif">
" to make clear that it shall generate a suitable VCP.request fore
either TM, AOS or TC (the one with more parameters),</span>
<br><span style=" font-size:10pt;font-family:sans-serif">BTW for TC I see
that the PACKET TRANSFER should be able to generate either a VCP.request
or a MAPP.request.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Of course we should
also include USLP where I see that the VCP Service is not used as only
MAPP Service exist (with relevant MAPP.request). </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><img src=cid:_1_0CC818E40CC81160003F479BC1258226 style="border:0px solid;">
<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">"Kazz,
Greg J (312B)" <greg.j.kazz@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">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></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:12</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] Virtual Channel Packet (VCP) Service vs (SPP) Packet Service</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">G.P.,</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
for the good forensic work. </span><span style=" font-size:14pt;font-family:Calibri"><br>
I am aware of the differences between in the “Packet” primitives in the
SDLP and SPP cases.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri">However,
my problem with the SPP primitives as currently defined, is that they describe
a kind of fantasy world in fact worse than that they are specious. They
give the appearance that one can actually do something and achieve interoperability,
but in reality it is not the case. In that sense, I say, if we cannot more
concretely define these primitives (SPP Packet .request and .indication),
then we are better off deleting them. For example, one problem is that
APID Qualifier is totally left up to the user to define. This is part of
the discussion Scott Burleigh, Jonathan Wilmot, Keith Scott, all, etc from
SIS were discussing in the Haag. In reality, missions come up with their
own ways of assigning APIDs to VCIDs. Maybe in SPP we simply need to acknowledge
and document that these steps are done outside of CCSDS services. One way
to consider at least.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri">Concerning
your Prox-1 questions: Packets are defined data types in Prox-1. Prox-1
is like TC due to the variable frame length and the frame length field
in the transfer frame header. I think the real solution is for missions
to eventually migrate to USLP.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:14pt;font-family:Calibri">Greg</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>SLS-SLP <sls-slp-bounces@mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Tuesday, January 30, 2018 at 9:22 AM<b><br>
To: </b>Greg Kazz <greg.j.kazz@jpl.nasa.gov><b><br>
Cc: </b>"sls-slp@mailman.ccsds.org" <sls-slp@mailman.ccsds.org>,
SLS-SLP <sls-slp-bounces@mailman.ccsds.org><b><br>
Subject: </b>[Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet
Service</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">Dear
Greg,</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
first of all I think that a few years years
we decided to rename the Packet Service in the Space Data Link Protocols
books to Virtual Channel Packet (VCP) Service to avoid confusion wit the
service defined in SPP.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
We shall also keep in mind that almost often the SDLP books leave undefined
some details of procedures left to "management". An example is
AOS section 4.2.5 VIRTUAL CHANNEL MULTIPLEXING FUNCTION only says (among
other things that</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
4.2.5.2 The Virtual Channel Multiplexing Function shall multiplex Transfer
Frames received from the instances of the Virtual Channel Generation Function
and, if present, the Virtual Channel Frame Service users, in an appropriate
order that is set by management.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed
Transfer Frames into a queue.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
4.2.5.3 The algorithm used to order the Transfer Frames is not specified
by CCSDS, but shall be defined by project organizations considering factors
such as priority, release rate, isochronous timing requirements, etc.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION
stating</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
4.3.6.2 The Virtual Channel Multiplexing Function shall multiplex Transfer
Frames received from the instances of the Virtual Channel Generation Function
and, if present, the Virtual Channel Frame Service users, in an appropriate
order set by management.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed
Transfer Frame into a queue.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;color:blue;font-family:Arial"><br>
4.3.6.3 The algorithm to be used to order the Transfer Frames is not specified
by CCSDS, but shall be defined by project organizations considering factors
such as priority, release rate, isochronous timing requirements, etc.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
However FSP - had to be more specific and it includes many more details
for VC multiplexing.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
FSP also mention sets of APIDs assigned to VCs.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service,
it is stated that </span><span style=" font-size:10pt;color:#ff00ff;font-family:Arial"><br>
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.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
In other words it looks fully correct that only one SPP user can provide
packets (with SAP Address = </span><span style=" font-size:11pt;font-family:Arial">GVCID
+ Packet Version Number) to an instance of the VCP Service </span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
On the other end we shall also make sure that we have consistency with
CCSDS 133.1-B-2 that is the service able to create Space/Encapsulation
Packets </span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Another point that does show what we need to keep both services is given
by the primitives.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
In the Space Data Link Protocol (e.g. for AOS) we have that "</span><span style=" font-size:10pt;color:blue;font-family:Arial">At
the sending end, the VCP Service user shall pass a VCP.request primitive
to the service provider to request that a Packet be transferred to the
user at the receiving end through the specified Virtual Channel.</span><span style=" font-size:10pt;font-family:Arial">"
and "</span><span style=" font-size:10pt;color:blue;font-family:Arial">The
VCP.request primitive shall provide parameters as follows: VCP.request
(Packet, GVCID, Packet Version Number)</span><span style=" font-size:10pt;font-family:Arial">"</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Conversely in SPP "</span><span style=" font-size:10pt;color:blue;font-family:Arial">The
PACKET.request primitive shall provide parameters as follows: PACKET.request
(Space Packet, APID, APID Qualifier (optional), QoS Requirement (optional))</span><span style=" font-size:10pt;font-family:Arial">"
and you see the difference for the parameters that the upper layer (SPP
on top of SDLP / AP on top of SPP) shall provide.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Of course we also have the possibility that there is Encapsulation of top
of SDLP.</span><span style=" font-size:11pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Last question.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Do we want to rule out packets from Proximity-1 forever?</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Of course there is nothing preventing a Proximity-1 frame from carrying
one or more Packets and I think only spill over would be prohibited by
the absence of a first header pointer in the Proximity-1 frame?</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><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"> </span></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>
<br><span style=" font-size:10pt;font-family:Courier New"> </span>
<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>