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

[Gian.Paolo.Calzolari at esa.int]

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/b98a449f/attachment.html>