<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">G.P.,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the good forensic work. <span style="font-size:14.0pt">
<br>
I am aware of the differences between in the “Packet” primitives in the SDLP and SPP cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Greg<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">SLS-SLP <sls-slp-bounces@mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari@esa.int" <Gian.Paolo.Calzolari@esa.int><br>
<b>Date: </b>Tuesday, January 30, 2018 at 9:22 AM<br>
<b>To: </b>Greg Kazz <greg.j.kazz@jpl.nasa.gov><br>
<b>Cc: </b>"sls-slp@mailman.ccsds.org" <sls-slp@mailman.ccsds.org>, SLS-SLP <sls-slp-bounces@mailman.ccsds.org><br>
<b>Subject: </b>[Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet Service<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a name="_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear Greg,</span></a><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",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></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",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></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">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><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">NOTE – The Virtual Channel Multiplexing Function may put the multiplexed Transfer Frames into a queue.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">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><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION stating</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">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><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">NOTE – The Virtual Channel Multiplexing Function may put the multiplexed Transfer Frame into a queue.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:blue">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><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">However FSP - had to be more specific and it includes many more details for VC multiplexing.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">FSP also mention sets of APIDs assigned to VCs.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it is stated that
</span></span><span style="mso-bookmark:_MailOriginalBody"><br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:fuchsia">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><span style="mso-bookmark:_MailOriginalBody"> <br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">In other words it looks fully correct that only one SPP user can provide packets (with SAP Address =
</span></span><span style="mso-bookmark:_MailOriginalBody"><span style="font-family:"Arial",sans-serif">GVCID + Packet Version Number) to an instance of the VCP Service
</span></span><span style="mso-bookmark:_MailOriginalBody"><br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",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></span><span style="mso-bookmark:_MailOriginalBody"><br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Another point that does show what we need to keep both services is given by the primitives.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">In the Space Data Link Protocol (e.g. for AOS) we have that "<span style="color:blue">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>" and "<span style="color:blue">The VCP.request primitive shall provide parameters as follows: VCP.request
(Packet, GVCID, Packet Version Number)</span>"</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Conversely in SPP "<span style="color:blue">The PACKET.request primitive shall provide parameters as follows: PACKET.request (Space Packet, APID,
APID Qualifier (optional), QoS Requirement (optional))</span>" 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><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Of course we also have the possibility that there is Encapsulation of top of SDLP.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Last question.</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Do we want to rule out packets from Proximity-1 forever?</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",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></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards</span></span><span style="mso-bookmark:_MailOriginalBody">
<br>
<br>
</span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Gian Paolo</span></span><span style="mso-bookmark:_MailOriginalBody">
<o:p></o:p></span></p>
<pre><span style="mso-bookmark:_MailOriginalBody">This message and any attachments are intended for the use of the addressee or addressees only.<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody">The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody">content is not permitted.<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody">If you received this message in error, please notify the sender and delete it from your system.<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody">Emails can be altered and their integrity cannot be guaranteed by the sender.<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody">Please consider the environment before printing this email.<o:p></o:p></span></pre>
<pre><span style="mso-bookmark:_MailOriginalBody"><o:p> </o:p></span></pre>
</div>
</body>
</html>