[Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet Service
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Wed Jan 31 11:31:11 UTC 2018
Greg,
interoperability is one target but proper design is another one.
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.
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.
I think it is fully correct that "missions come up with their own ways of
assigning APIDs to VCIDs".
There is no fixed rule in this (more than spacecraft architecture etc).
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)
There multiple sources generating packet contents and asking transmission
of packets with a given APID (as per PACKET.request primitive)
Those different APIDs shall be multiplexed to produce a single packet
stream per VC
EACH single packet stream is then injected in in a VC by sending it to the
instance of the Packet Processing Function for that Virtual Channel that
carries Packets
[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]
As far as I know nothing prevents a source application form asking two
packets with the same APID to be transmitted over different VCs.
Basically we should refine the description (in 133.0-B) of the so called
(in 132.0-B) "Packet Service User with PVN = SPP".
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.
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
PACKET.request (Space Packet, APID, APID Qualifier (optional), QoS
Requirement (optional))
VCP.request (Packet, GVCID, Packet Version Number)
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).
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".
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) ,
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.
This consistency check shall not be neglected.
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).
Actually it looks as one main topic will be redefining clause "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. " to make clear that it shall generate a suitable VCP.request
fore either TM, AOS or TC (the one with more parameters),
BTW for TC I see that the PACKET TRANSFER should be able to generate
either a VCP.request or a MAPP.request.
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).
Regards
Gian Paolo
From: "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
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:12
Subject: Re: [Sls-slp] Virtual Channel Packet (VCP) Service vs
(SPP) Packet Service
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
G.P.,
Thanks for the good forensic work.
I am aware of the differences between in the “Packet” primitives in the
SDLP and SPP cases.
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.
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.
Greg
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, January 30, 2018 at 9:22 AM
To: Greg Kazz <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>
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet
Service
Dear Greg,
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.
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
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.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed
Transfer Frames into a queue.
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.
The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION
stating
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.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed
Transfer Frame into a queue.
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.
However FSP - had to be more specific and it includes many more details
for VC multiplexing.
FSP also mention sets of APIDs assigned to VCs.
Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it
is stated that
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.
In other words it looks fully correct that only one SPP user can provide
packets (with SAP Address = GVCID + Packet Version Number) to an instance
of the VCP Service
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
Another point that does show what we need to keep both services is given
by the primitives.
In the Space Data Link Protocol (e.g. for AOS) we have that "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." and "The
VCP.request primitive shall provide parameters as follows: VCP.request
(Packet, GVCID, Packet Version Number)"
Conversely in SPP "The PACKET.request primitive shall provide parameters
as follows: PACKET.request (Space Packet, APID, APID Qualifier (optional),
QoS Requirement (optional))" and you see the difference for the parameters
that the upper layer (SPP on top of SDLP / AP on top of SPP) shall
provide.
Of course we also have the possibility that there is Encapsulation of top
of SDLP.
Last question.
Do we want to rule out packets from Proximity-1 forever?
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?
Regards
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/e1540797/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 15546 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/e1540797/attachment.gif>
More information about the SLS-SLP
mailing list