<span style=" font-size:10pt;font-family:sans-serif">Dear Greg,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">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>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">NOTE
– The Virtual Channel Multiplexing Function may put the multiplexed Transfer
Frames into a queue.</span>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The same applies
to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION stating</span>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">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>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">NOTE
– The Virtual Channel Multiplexing Function may put the multiplexed Transfer
Frame into a queue.</span>
<br><span style=" font-size:10pt;color:blue;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">However FSP -
had to be more specific and it includes many more details for VC
multiplexing.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">FSP also mention
sets of APIDs assigned to VCs.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Going back to
AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it is stated that
</span>
<br><span style=" font-size:10pt;color:#ff00ff;font-family:sans-serif">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>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Another point
that does show what we need to keep both services is given by the primitives.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">In the Space Data
Link Protocol (e.g. for AOS) we have that "</span><span style=" font-size:10pt;color:blue;font-family:sans-serif">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:sans-serif">"
and "</span><span style=" font-size:10pt;color:blue;font-family:sans-serif">The
VCP.request primitive shall provide parameters as follows: VCP.request
(Packet, GVCID, Packet Version Number)</span><span style=" font-size:10pt;font-family:sans-serif">"</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Conversely in
SPP "</span><span style=" font-size:10pt;color:blue;font-family:sans-serif">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:sans-serif">"
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>
<br><span style=" font-size:10pt;font-family:sans-serif">Of course we also
have the possibility that there is Encapsulation of top of SDLP.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Last question.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Do we want to
rule out packets from Proximity-1 forever?</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<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>
<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>