<html xmlns:v="urn:schemas-microsoft-com:vml" 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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma",sans-serif;}
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;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma",sans-serif;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.begin-antispam-voting-links
{mso-style-name:begin-antispam-voting-links;}
span.end-antispam-voting-links
{mso-style-name:end-antispam-voting-links;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle28
{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><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">John,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for this follow on explanation – it helps a lot.<o:p></o:p></p>
<p class="MsoNormal">I think the restructuring in 2000 removed that underlined bit of information you mentioned here. The current AOS SDLP version i.e., CCSDS 732.0-B-3 Sept 2015 is agnostic about “packet channels” and “Individual CCSDS packets from multiple
sources” (implying multiple APIDs). It is really only concerned about multiplexing of packets with different PVNs onto VCs.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I know of many missions that assign different APIDs to a given VCID on the downlink. So I would never want to eliminate that capability. But given how the current SPP defines the SPP Packet Service, I have a very hard time understanding
how to actually create an interoperable implementation. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Greg<o:p></o:p></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">John Pietras <john.pietras@gst.com><br>
<b>Date: </b>Monday, January 29, 2018 at 12:43 PM<br>
<b>To: </b>Greg Kazz <greg.j.kazz@jpl.nasa.gov>, "Gian.Paolo.Calzolari@esa.int" <Gian.Paolo.Calzolari@esa.int><br>
<b>Cc: </b>"sls-slp@mailman.ccsds.org" <sls-slp@mailman.ccsds.org><br>
<b>Subject: </b>RE: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D">Greg,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Your first paragraph states my case exactly, where you strike out APIDs and put in PVNs. The SPP give the functionality of multiplexing by APIDs, which is *<b>not</b>* covered by the current AOS, TC, or TM SDLP
books. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I have only paper copies of the AOS 701.0 Blue Books, so I can’t cut and paste all of the relevant sections from that document, but here’s section 2.4.1.5.b from 701.0-B-2 (Nov. 1992), which explains the gist
of the capability that will lost if the SPP is scrapped: “<u>Individual CCSDS Packets</u>
<u>from multiple sources</u> [underline mine]are concatenated together into a contiguous string of Packets, which is then broken into blocks whose length is arranged such that they may be loaded exactly into the fixed-length CVCDU Data Unit Zone.
<u>Several individual “Packet Channels” may thus concurrently share one VC using the [packet] Multiplexing functions. Each Packet Channel is locally identified using the “Application Process ID” (APID) field contained in the CCSDS Packet header</u> [underline
again mine].” </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Looking past the “packet channel” and “subnet” terminology, the idea was that different applications (i.e., different APIDs) could share the same VC. E.g., several sources of low-rate, sporadic data could share
the same VC. This is *<b>different from</b>* the PVN multiplexing that is in the current SDLP books, which to my understanding is there mainly to accommodate mixing version 1 and version 2 Space Packets with Encapsulation packets in a single VC.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Just to be clear - I’m not insisting that muxing of different packet channels (APIDs) into a single VC has to be retained – there may be good reasons why no one would ever actually want to do it and/or it may
never actually have been used. My only reason to bring this up is to point out that there *<b>is</b>* a difference between the “APID muxing” provided by the SPP and the “PVN muxing” provided by the current SDLP books, and that the WG should consider whether
they want to deprecate that capability (probably with clarification to eliminate implications of end-to-end “routing”, etc.). Also, you might want to check with ISS, since they implemented AOS even before it was completely Blue – they may very well have multiple
APIDs carried in a single VC.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Unfortunately, I have a doctor’s appoint on Wednesday morning. I may get back in time to call into the telecon, and will do so if possible. But if I don’t, I think/hope that I’ve explained the situation well
enough that the WG can deliberate on the merits of my observations (or lack thereof).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">John</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Kazz, Greg J (312B) [mailto:greg.j.kazz@jpl.nasa.gov]
<br>
<b>Sent:</b> Monday, January 29, 2018 2:59 PM<br>
<b>To:</b> Gian.Paolo.Calzolari@esa.int; John Pietras<br>
<b>Cc:</b> sls-slp@mailman.ccsds.org<br>
<b>Subject:</b> Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">John and Gian Paolo,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">It is always worthwhile to ensure we are doing this update correctly.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">But I think in this case, it is the SDLPs (AOS, TM, TC, and the emerging USLP, not Prox-1 because there are no services defined) that provide the Packet Service with the functionality of
<span style="color:#1F497D">muxing/demuxing Packets with different <s>APIDs</s> PVNs into/out of a single VC and NOT the SPP Packet Service.</span></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D">So I still agree with Takahiro, that CCSDS should delete the SPP Packet Service but keep all of the SDLP Packet Services as currently defined in the SDLP blue books. The additional benefit of
removing the SPP Packet Service is removing the confusion of having “yet another Packet Service” as defined in SPP.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D">Below is my analysis:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D">Packet Service as defined in 3.3.1 Overview of Packet Service in SPP is:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">The Packet Service shall transfer Space Packets, pre-formatted by the service user, intact through the LDP.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">The service user must generate Space Packets according to the specification given in section 4 of this Recommendation.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">Space Packets supplied by the service user shall be transferred by the service provider without further formatting.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">*** N.B. There is no mention of muxing/demuxing Packets with different PVNs into/out of a single VC … in the SPP document **</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">I reviewed the <b>AOS SDLP</b>. Below I have cut out a portion of Section 2.2.3.2 Virtual Channel Packet Service and 3.3.1 Overview of
<b>VCP Service</b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">A user of this service is a protocol entity that sends or receives Packets with a single PVN. A
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">Channel, the service provider multiplexes Packets of different versions to form a single
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">stream of Packets to be transferred on that Virtual Channel.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">The exact same words are used in the
<b>TM SDLP</b>, because the VCP Service is defined. See Sections 2.2.3.2 VCP Service and 3.3.1. Overview of
<b>VCP Service</b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">A user of this service is a protocol entity that ends or receives Packets with a single PVN. A
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">Channel, the service provider multiplexes Packets of different versions to form a single
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">stream of Packets to be transferred on that Virtual Channel.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">Very similar for <b>TC SDLP</b>; except for TC, we define the MAP Packet Service. See 2.2.3.3 and 3.3.1 Overview of
<b>MAP Packet Service</b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">A user of this service is a protocol entity identified with the PVN and a GMAP ID (i.e., a
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">GVCID and a MAP ID) that sends or receives Packets with a single PVN. Different users
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">(i.e., Packets with different versions) can share a single MAP Channel, and if there are
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">multiple users on a MAP Channel, the service provider multiplexes Packets of different
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">versions to form a single stream of Packets to be transferred on that MAP Channel.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">We define MAP Packet Service in
<b>USLP SDLP</b> to be the same as the one in TC SDLP. See 2.2.3.2 and 3.3.1 Overview of
<b>MAP Packet Service </b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">A user of this service is a protocol entity that sends or receives Packets with a single PVN and identified with the PVN and a GMAP ID.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">Different users (i.e., Packets with different PVNs) may share a single MAP Channel, and if there are
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">multiple users on a MAP Channel, the service provider multiplexes Packets of different</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt">versions to form a single stream of Packets to be transferred on that MAP Channel.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Times New Roman",serif">Greg</span><o:p></o:p></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 <<a href="mailto:sls-slp-bounces@mailman.ccsds.org">sls-slp-bounces@mailman.ccsds.org</a>> on behalf of "<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>"
<<a href="mailto:Gian.Paolo.Calzolari@esa.int">Gian.Paolo.Calzolari@esa.int</a>><br>
<b>Date: </b>Saturday, January 27, 2018 at 11:00 AM<br>
<b>To: </b>John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Cc: </b>Greg Kazz <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>, "<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>" <<a href="mailto:sls-slp@mailman.ccsds.org">sls-slp@mailman.ccsds.org</a>><br>
<b>Subject: </b>Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><a name="_MailOriginalBody">Good hint, John. <o:p></o:p></a></p>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Regards<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="mso-bookmark:_MailOriginalBody">Gian Paolo<o:p></o:p></span></p>
<div id="AppleMailSignature">
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Sent from my iPhone<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="mso-bookmark:_MailOriginalBody"><br>
On 27. Jan 2018, at 16:21, John Pietras <</span><a href="mailto:john.pietras@gst.com"><span style="mso-bookmark:_MailOriginalBody">john.pietras@gst.com</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">>
wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">Members of the SLPWG,</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">I have read through Greg’s summary of his conversation with Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal
of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing
Packets with different APIDs into/out of a single VC. </span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D"> </span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote
the original AOS Blue Book I can attest to the fact that the ability to flow multiple “packet channels” through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such
packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.
</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D"> </span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality
of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D"> </span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">Best regards,
</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D">John Pietras</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#1F497D"> </span><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b></span><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
SLS-SLP [</span></span><a href="mailto:sls-slp-bounces@mailman.ccsds.org"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">mailto:sls-slp-bounces@mailman.ccsds.org</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">]
<b>On Behalf Of </b>Kazz, Greg J (312B)<br>
<b>Sent:</b> Thursday, January 25, 2018 5:41 PM<br>
<b>To:</b> </span></span><a href="mailto:sls-slp@mailman.ccsds.org"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">sls-slp@mailman.ccsds.org</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif"><br>
<b>Subject:</b> [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book</span><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Dear SLP WG,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Happy New Year 2018 !<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under
Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to
the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Greg<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">CCSDS SLP WG Chairman<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Greg Kazz<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Principal Engineer<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Technical Group Supervisor,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Project Software and End-to-End Information Systems Engineering (312B)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">4800 Oak Grove Dr., M/S 301-490<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span lang="ES-MX">Pasadena, CA 91109</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span lang="ES-MX">1+(818)393 6529(voice)</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody">1</span><span style="mso-bookmark:_MailOriginalBody"><span lang="ES-MX">+(818)393 6871(fax)</span><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span lang="ES-MX">email:
</span></span><a href="mailto:greg.j.kazz@jpl.nasa.gov"><span style="mso-bookmark:_MailOriginalBody"><span lang="ES-MX">greg.j.kazz@jpl.nasa.gov</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody">
<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="font-family:"Times New Roman",serif"> </span><o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<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>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;color:black">
<hr size="2" width="100%" align="center">
</span></span></div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;color:black;background:white"><br>
</span></span><a href="https://filter.gst.com/canit/b.php?c=s&i=01V4jXOp8&m=1a3091b1c61c" target="canit_note"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;background:white">Spam</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;color:black;background:white"><br>
</span></span><a href="https://filter.gst.com/canit/b.php?c=n&i=01V4jXOp8&m=1a3091b1c61c" target="canit_note"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;background:white">Not spam</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;color:black;background:white"><br>
</span></span><a href="https://filter.gst.com/canit/b.php?c=f&i=01V4jXOp8&m=1a3091b1c61c" target="canit_note"><span style="mso-bookmark:_MailOriginalBody"><span style="font-size:13.5pt;font-family:"Times New Roman",serif;background:white">Forget previous vote</span></span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"></span><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>