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

Tue Jan 8 22:38:50 UTC 2019

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 01D4A779.034E1FC0]

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:image007.jpg at 01D4A779.034E1FC0]

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:image008.jpg at 01D4A779.034E1FC0]

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/20190108/d1499213/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/20190108/d1499213/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 23978 bytes
Desc: image004.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190108/d1499213/attachment-0006.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/20190108/d1499213/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 53031 bytes
Desc: image007.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190108/d1499213/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 64987 bytes
Desc: image008.jpg
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190108/d1499213/attachment-0009.jpg>