[Smwg] SPDF: second WG review - now referencing the correct version - additional comments

Mon Jan 14 22:46:36 UTC 2019

CSSMWG colleagues,
I wanted to explore in a bit more detail the component parameters of the SPDF ModifiedParameter class before tomorrow's telecon. It turned out to be an interesting journey.

In the SPDF book, the ModifiedParameters class is defined as having two parameters:

-          frNickname, described as "The functional resource nickname, as defined in the service agreement (indicating the text classifiers of the functional resource type name and instance number)", with Data Type "xsd:string Values as defined in reference [12]".

-          parameter, described as "The parameter is represented using an AbstractParameter class that includes the name (text classifier) of the parameter, as well as the value to be used for the parameter", with Data Type "AbstractParameter  Contents defined in reference [12]".
I'll start with "reference [12]" of which there are two in the current draft of the SPDF: Service Agreement and Service Configuration which I'll call [12a] and Service Management Common Data Entities [12b].

So now let's look at the frNickname parameter. The reference in the description to "service agreement" would seem to point to the SA and CM book ([12a]), although the current draft of that book does not mention frNickname. Presumably it will when it is fleshed out, so making the Data Type point to [12a] makes ultimate sense. HOWEVER, the FrParameters class in [12b] ALSO includes an fRNickname *parameter*, but the definition is currently just a reference to "Functional Resource Tech Note (or wherever the function resource nickname concept is defined). Issue x CCSDS ???? (Technical Note), CCSDS nnn.n-??-n. Washington, D.C.: CCSDS, ???? 201n". That is, it's not (yet) a data *type* on its own; i.e., if we are going to declare it to be a common type, it should be FrNickname, which is itself of type xsd:string. The FrNickname XML *type* could then be defined in the Common Data Entities (since it would be used in multiple Info Entities) and the rules for defining the contents of those strings defined in the SA & CP book. My final comment (for now) on the frNickname parameter: since we are now defining the configuration profiles to be part of the service agreement, it is technically correct to say that values of the frNicknames are defined as part of the Service Agreement. However, the assignment of the values will be as part of the configuration profile components of those service agreements.

Now let's look at the parameter parameter, which is specified as an AbstractParameter, defined in "reference [12]". Again, the first reference [12] (SA&CP) currently says nothing about AbstractParameter, but the second ref 12 (Common Data Entities) *does* mention AbstractParameter, but only with respect to the FrParameter class, the only element of which is fRNickname. So the trail runs stops here as far as understating what the parameter parameter of the SPDF ModifiedParameter class is.

Interestingly enough, the only definition of the AbstractParameter class that I have been able to find is in the Abstract Even Definition book. But in that book it is defined as having only a single parameter, name. Thus the AbstractParameter class defined in the Abstract Even Definition book does not meet the definition of the AbstractParameter type needed by the parameter parameter of the SPDF ModifiedParameter class, which must contain not only the name of the parameter but also the value.

At this point I will simply say that that there are inconsistencies across the books that need to be fixed. Finally, I'd recommend renaming the parameter parameter of the SPDF SPDF ModifiedParameter class to something a bit more specific, like frParameter.

Best regards,
John

From: Marcin.Gnat at dlr.de <Marcin.Gnat at dlr.de>
Sent: Friday, January 11, 2019 9:20 AM
To: John Pietras <john.pietras at gst.com>; wesley.m.eddy at nasa.gov
Cc: smwg at mailman.ccsds.org
Subject: RE: SPDF: second WG review - now referencing the correct version

Hi John and Wes,

I just went through this, and I like both things. Regarding A, I was feeling something like this will be necessary, but did not spend time yet to think deeper about it. And on one hand having the data format of ServiceType to xsd:string and same time fixing the allowed values to the list present in Simple Schedule should work (finally we have SoS Book already out, so it can be referenced).

Regarding B, I also rather tend to the usage of ModifiedParameter, even the providerPort information is kind of "hidden in the woods of Configuration Profile forest" ;-). The information about its special use needs to be than captured however somewhere (and I'm not sure if the future Configuration Profile Book will be sufficient). Maybe there shall be some notion of that in SPDF Book. What do you think? Later on we need it also definitely in Green Book update (AI: Erik).

Best Regards
Marcin

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Mittwoch, 9. Januar 2019 16:55
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.]
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>)
Subject: Re: [Smwg] SPDF: second WG review - now referencing the correct version

Hi, Wes. I have responses to several of your comments interleaved below in red.

Best regard,
John

From: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov<mailto:wesley.m.eddy at nasa.gov>>
Sent: Wednesday, January 09, 2019 9:36 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>) <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: RE: SPDF: second WG review - now referencing the correct version

Hi John, thanks for your help and clarifications!

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).

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.

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)).

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.

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.

From: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Sent: Tuesday, January 8, 2019 5:39 PM
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov<mailto:wesley.m.eddy at nasa.gov>>
Cc: CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>) <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: RE: SPDF: second WG review - now referencing the correct version

Wes and CSSMWG colleagues ---
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.

As with my previous set of comments, these comments flow from two items: (1) the serviceType parameter of the ServiceDetails abstract class, and (2) how the providerPortId parameter values are determined for the transfer service instances contained within the Service Package. Here's the class diagram from the SPDF for reference:

[cid:image001.jpg at 01D4A10C.FFC61C80]

A.      Regarding the ServiceDetails serviceType 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 the ServiceTypes attribute of one of the Space Link Service Profiles contained within the configuration profile referenced by the onlineConfigProfieRef or offlineConfigProfileRef parameter, as appropriate. This is the ConfigurationProfile metamodel diagram from the Config Profile/Service Agreement book:

[cid:image002.jpg at 01D4AC28.96140230]

Furthermore, when the Configuration Profile is an online CP, the value of the frequencyBand parameter of the OnlineServiceDetails component must match the value of the frequencyBand attribute of the corresponding Space Link Service Profile. The definition of the frequencyBand 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.

The values of the ServiceTypes attribute of the Space Link Service Profile are taken from the ServiceType parameter of the Simple Schedule Format. Thus we have a consistent set of "service" names across the CSSM books.

Note that the serviceTypes 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 serviceType parameter value of the SPDF would require that the SPDF have two OnlineServiceDetails 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.

B.      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 providerPortId parameters in the ServiceDetails 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 are allocated. What follows is my interpretation of a feasible approach for doing so in the context of the current SPDF.

To start, here's a (relatively) quick description of what the providerPortId parameter refers to. Each SLE transfer service provider entity and Cross Support Transfer Service provider entity has a provider port, 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 Internet Protocol for Transfer Services (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.

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 of the same type 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.

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 ID 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.

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 providerPortId 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".

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.

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) providerPortId 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 providerPortId 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.

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 responderPortId for each scheduled SLE/CS TS in the Service Package.

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:

[cid:image003.jpg at 01D4AC28.96140230]

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 scheduledSocket 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 scheduledSocket 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 modifiedParameter parameters to the Service Package, one modifiedParameter 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:

[cid:image004.jpg at 01D4AC28.96140230]

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.

I think at this point I won't try to burrow down any more of explore other variations.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190114/3d888cf1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 43006 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190114/3d888cf1/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 23978 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190114/3d888cf1/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 53031 bytes
Desc: image003.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190114/3d888cf1/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 64987 bytes
Desc: image004.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190114/3d888cf1/attachment-0007.jpg>