[Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet Service

[Kazz, Greg J (312B)]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/e7a70406/attachment.html>