<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=us-ascii">
<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;}
/* 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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",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:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:1459686376;
mso-list-type:hybrid;
mso-list-template-ids:-745010862 67698709 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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"><span style="color:#1F497D">Hi, Wes. I have responses to several of your comments interleaved below in
</span><span style="color:red">red</span><span style="color:#1F497D">.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regard,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy@nasa.gov>
<br>
<b>Sent:</b> Wednesday, January 09, 2019 9:36 AM<br>
<b>To:</b> John Pietras <john.pietras@gst.com><br>
<b>Cc:</b> CCSDS SMWG ML (smwg@mailman.ccsds.org) <smwg@mailman.ccsds.org><br>
<b>Subject:</b> RE: SPDF: second WG review - now referencing the correct version<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi John, thanks for your help and clarifications!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">It seems pretty easy to update the document to address item A (clarifying the serviceType definition, making sure it matches the indicated profile, and making sure the frequencyBand matches).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Item B seems like it needs more discussion, since as you noted, there are multiple approaches possible. In the Berlin meeting, we were definitely on the track of the SICF being sufficient, as you first describe,
which is why we removed the providerPortId. However, I can’t recall if we discussed the ability for ports to be dynamically assigned by Provision Management, as you mention is a possibility.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">We discussed this further at the 11 December telecon, with Erik advocating for the dynamic-assignment approach. The WG agreed to support both approaches, with me following up in exploring the implications for doing
so (see Erik’s 2018-12-11-TeleconferenceNotes.docx, item 6A (AOB: Port Ids)).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I do like your idea of indicating those through use of ModifiedParameters, since it seems very simple and is basically what ModifiedParameters are there for (indicating things that are updated/changed from the
profile). But that said, either approach that you sketched seems fine with me.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:red">I’m leaning toward the ModifiedParameters approach, too, despite the somewhat awkward semantics of the non-user-configurable “configuration” parameter. Actually, it’s not that bad – from the Functional Resource perspective
it can be structured as a read-only parameter. The only twist is that normally read-only parameters are considered meaningful only when the Service Package is executing and they don’t appear in Space Link Service Profiles/Configuration Profiles, but these
parameters will be given meaningful values as part of the Configuration Profiles as soon as they are instantiated as part of a scheduled Service Package (as a side benefit, making the socket assignments parameter of the transfer service Functional Resources
will make the socket assignments available to the Monitored Data service – potentially useful for troubleshooting when an SLE TS or CSTS user can’t connect during the execution of a Service Package). For now I’m going to concentrate on the ModifiedParameters
approach unless and until someone wants to advocate for the addition of the secheduledSockets data as part of the Service Package itself. I hope to have more to say about this at next week’s telecon.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>>
<br>
<b>Sent:</b> Tuesday, January 8, 2019 5:39 PM<br>
<b>To:</b> Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <<a href="mailto:wesley.m.eddy@nasa.gov">wesley.m.eddy@nasa.gov</a>><br>
<b>Cc:</b> CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>) <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>><br>
<b>Subject:</b> RE: SPDF: second WG review - now referencing the correct version<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wes and CSSMWG colleagues ---<o:p></o:p></p>
<p class="MsoNormal">The day before the 11 December telecon, Wes informed me that I had used the previous version of the Service Package Data Formats (SPDF) White Book as the basis of my comments. So here are my comments on the correct version – W0.02, November
2018.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As with my previous set of comments, these comments flow from two items: (1) the
<b>serviceType</b> parameter of the <b><i>ServiceDetails</i></b> abstract class, and (2) how the
<b>providerPortId</b> parameter values are determined for the transfer service instances contained within the Service Package. Here’s the class diagram from the SPDF for reference:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" align="center" style="text-align:center"><img border="0" width="600" height="550" style="width:6.25in;height:5.7291in" id="Picture_x0020_6" src="cid:image001.jpg@01D4A804.57D1A680" alt="cid:image001.jpg@01D4A10C.FFC61C80"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">A.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Regarding the ServiceDetails <b>serviceType</b> parameter: it is now defined in table 3-7 as just “mandatory parameter”, with Data Type “xsd:string. Values are defined in a SANA registry of service types.” The important piece that is
missing is that this parameter value must equal the value(s) of <b>the ServiceTypes</b> attribute of one of the Space Link Service Profiles contained within the configuration profile referenced by the
<b>onlineConfigProfieRef</b> or <b>offlineConfigProfileRef</b> parameter, as appropriate. This is the ConfigurationProfile metamodel diagram from the Config Profile/Service Agreement book:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in"><o:p> </o:p></p>
<p class="MsoNormal" align="center" style="margin-left:.25in;text-align:center"><img border="0" width="600" height="355" style="width:6.25in;height:3.6979in" id="Picture_x0020_115" src="cid:image002.jpg@01D4A804.57D1A680"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Furthermore, when the Configuration Profile is an online CP, the value of the
<b>frequencyBand</b> parameter of the <b>OnlineServiceDetails</b> component must match the value of the
<b>frequencyBand</b> attribute of the corresponding Space Link Service Profile. The definition of the
<b>frequencyBand</b> parameter in table 3-8 only addresses the overall allowed values, but ignores the important fact that it must have a valid cross-referent in the Configuration Profiles.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">The values of the <b>ServiceTypes</b> attribute of the Space Link Service Profile are taken from the
<b>ServiceType</b> parameter of the Simple Schedule Format. Thus we have a consistent set of “service” names across the CSSM books.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Note that the <b>serviceTypes</b> attribute of the Space Link Service Profile is plural, not singular. This was necessary because some Space Link Service Profiles may provide multiple service types. In particular,
the Online Real-Time Tracking Space Link Service Profile can provide the APA-AZ/EL, APA-X/Y, DOPPLER, and RANGING services simultaneously. All of these services are potentially delivered to the user through one instance of the CSTS Tracking Data service. Consider
a Service Package that collects APA-AZ/EL and RANGING data and delivers it through a single instance of TD-CSTS. As currently written, the singular
<b>serviceType</b> parameter value of the SPDF would require that the SPDF have two
<b>OnlineServiceDetails</b> components: one for the APA service and one for the RANGING service. That’s okay as far as the Configuration Profile and Space Link Service Profile are concerned, but the fact that the SPDF allows each of these services to have different
timing information raises interesting questions. E.g., it implies that antenna angle data and ranging data can be scheduled for different sub-periods of the overall service package. Off the top of my head this seems like a useful capability but I wonder if
it might have some hidden issues. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">B.<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Now I’ll turn my attention to the question of how the provider ports are allocated to the various transfer service instances. This question was originally sparked by the presence of zero or more
<b>providerPortId</b> parameters in the <b>ServiceDetails</b> object. That parameter has been deleted from the most recent version of the SPDF, but it is still legitimate to ask how the provider port
<i>are</i> allocated. What follows is my interpretation of a feasible approach for doing so in the context of the current SPDF.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph">To start, here’s a (relatively) quick description of what the
<b>providerPortId</b> parameter refers to. Each SLE transfer service provider entity and Cross Support Transfer Service provider entity has a
<b>provider port</b>, which is the “address” that the service user uses to BIND to the provider. Because CCSDS has (so far) defined only one protocol for SLE TSes and CSTSed – the
<i>Internet Protocol for Transfer Services</i> (CCSDS 913.1, commonly known as ISP-1), which is based on TCP/IP – the CCSDS-standard “port” is defined to be an IP Socket, that is, an IP address/ TCP port pair.<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">There is one provider port for each transfer service instance in a service package. It is quite possible that there are not only multiple instances of transfer service in a Service Package, but that there are multiple instances
<i>of the same type</i> of transfer service in a Service Package. Furthermore, the TCP sockets for the same transfer service instance will likely be different for every ground station that supports that service instance (e.g., the SLE Return Channel Frames
service for VC3 from a given spacecraft). So the user of a transfer service must know both (a) what the particular transfer service instance is and (b) what is the provider port for that service instance when it is provided by the scheduled ground station.
<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">Note that the SLE TS and CSTS specifications themselves do not know about TCP Sockets. When we started developing SLE in the early 1990s, the push for the ISO Open System Interconnect (OSI) protocols was still strong, and we didn’t
want to tie SLE to a single internetworking protocol stack. So the SLE transfer service specifications have provider port
<u>ID</u> parameters, where the “IDs” are string names that are keys into protocol-specific tables. AS things turned out, the Internet lost it’s sponsored-by-the-US-DoD stigma to a greater extent that ISO OSI protocols were adopted, so when it came time to
create the first Internetworking protocol-specific “convergence layer”, TCP/IP won. For CSTS we continued to use the abstract provider port ID approach. In the remainder of this note, “responderPortId” refers to the abstract name that is configured as part
of the configuration of an SLE-TS or CSTS instance, and “responder port” (without the “Id”) refers to an actual TCP Socket.<o:p></o:p></p>
<p class="MsoListParagraph"><br>
How does the user know what provider port to use as part of a given Service Package? Today (i.e., pre-CCSDS-standard Service Management), this is set up through the pre-establishment of port mapping tables that are known to both the user Mission and the Provider
CSSS. For each site (e.g., ground station) that might be used to support the Mission spacecraft, a port mapping table maps each
<b>providerPortId</b> to one or more TCP sockets to that service instance, and the assignments are known to the user well before any Service Packages are scheduled (effectively, as part of the Service Agreement). The “or more” part relates to a special feature
of ISP-1, which allows a transfer service user to simultaneously attempt to connect to multiple ports concurrently. Only one service provider host is actually configured to respond. This mechanism can be used to pre-establish the port ID for each service instance
at each site (e.g., ground station) that might possibly support that service instance. As part of the execution of a Service Package, the user would know (from the scheduled Service Package) which ground station is supporting that service Package, and would
attempt to bind to all hosts in the port table for that service instance at that ground station. At that ground station, only one of the hosts in the port table is actually configured to support the service instance at that time, so only that configured host
is able to accept the BIND invocation. This approach is based on the use of Service Instance Configuration Files (SICFs) and associated port tables, and so this approach is referred to herein as “the SICF-like approach”.
<br>
<br>
In this SICF-like approach, the Mission does not need to be informed in the Service Package which provider port is assigned to each service instance in order for the users to use the services.
<br>
<br>
Extensible Service Management (if we are still calling it that) will support the SICF-like approach for use by those Provider CSSSes and Missions for which this approach is most appropriate. Use of the SICF-line approach will require the Service Agreement to
(a) identify all of the transfer services that might possibly be used for the duration of the Service Agreement; (b) specify the (abstract)
<b>providerPortId</b> for each transfer service instance, (c) for each transfer service instance, identify the sites (e.g., ground stations) that may be used to execute that transfer service instance; and (d) for each transfer service at each supporting site,
specify the provider port sockets that are assigned to the <b>providerPortId</b> for that transfer service instance. When a Service Package is subsequently scheduled at a given site, one (and only one) of those provider port sockets must be active.<o:p></o:p></p>
<p class="MsoListParagraph"><br>
In addition to the SICF-like approach described above, the SMWG has decided to also support an approach in which the responder ports are dynamically assigned by Provision Management in the scheduling of each Service Package. However, because this approach
doesn’t use pre-arranged port mapping tables, the Service Package info entity that is returned to the user (until recently known as the Service Package Result) must identify the TCP Socket associated with the
<b>responderPortId</b> for each scheduled SLE/CS TS in the Service Package. <br>
<br>
So if we are explicitly identifying the responder ports in the Service Package, what should that look like? There might be several different ways that could work. One approach might be to include an as-scheduled port mapping table as a (new) object of the Service
Package. In some rough sense it would be like the timing information that is included in the Service Package, in that it would only exist once the Service Package is scheduled. The advantage to this approach is that it makes explicit the fact that the Socket
assignments are an artifact of the scheduling process. The following diagram very crudely represents this approach:<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph"><img border="0" width="778" height="678" style="width:8.1041in;height:7.0625in" id="Picture_x0020_3" src="cid:image003.jpg@01D4A804.57D1A680"><o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">A different approach would be to essentially make the provider port (TCP Socket) a new pseudo-configuration parameter of each transfer service instance. I call it a pseudo-configuration parameter because even though it would appear
in the transfer service objects of the Space Link Service Profiles and Configuration Profiles, it would not be configurable by the user. That is, in the Space Link Service Profiles and Configuration Profiles, each TS object would have a
<b>scheduledSocket</b> parameter with a default ‘unassigned’ value that cannot be changed by the user as part of the Service Package Request. When the Service Package is scheduled and returned formatted in Full Service Package mode, Provision Management would
populate the <b>scheduledSocket</b> parameter of each TS object in the returned configuration profiles with the actual socket value that has been assigned to that transfer service instance. When the Service Package is formatted in the Brief Service Package
mode, Provision Management would attach a collection of <b>modifiedParameter</b> parameters to the Service Package, one
<b>modifiedParameter</b> parameter for each scheduled transfer service instance. The advantage to this approach is that requires no new objects/classes to be added to the Service Package format – the information is carried within each transfer service object
of the Space Link Profiles. The disadvantage – such as it is – is that it requires the creation of this new flavor of “configuration” parameter which is configurable only by Provision Management in the process of scheduling the Service Package. The following
figure shows what the Service Package would look like under this approach:<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph"><img border="0" width="997" height="680" style="width:10.3854in;height:7.0833in" id="Picture_x0020_4" src="cid:image004.jpg@01D4A804.57D1A680"><o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoListParagraph">There are likely more possible ways to handle this, but I think that the two that I’ve mentioned in some sense represent the two ends of the spectrum – carry the information explicitly as part of the Service Package, vs. embedding
it in the configuration profiles.<o:p></o:p></p>
<p class="MsoListParagraph"><o:p> </o:p></p>
<p class="MsoNormal">I think at this point I won’t try to burrow down any more of explore other variations.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>