[Sls-slp] Current Version of USLP RED book Feb 13 2018 Version

Tue Feb 13 23:51:45 UTC 2018

Dear SLP WG,

The current version of the USLP RED book with date of Feb 13, 2018 is now found at the URL below: http://tiny.cc/hk23qy

Please let me know if you have any issues or questions regarding this material.

It contains some minor updates since the release of the RED 3.1 version by the Secretariat, due to results of interoperability testing.

The Sections that have changes are:

  1.  Overview of Services – A new diagram (based upon the SDU and PDU diagram that Marjorie DeLandelong developed for the CCSDS IP over CCSDS) has been inserted into Section 2.2 to introduce the topic of SDUs and PDUs as well as the reoccurring service primitives (.request, .indication, NOTIFY. Indication) along with a few short paragraphs of descriptive text thereafter. See pp. 2-6, 2-7.
  2.  Clean up of the following service diagrams (see text explaining the rationale for the update directly below – diagrams and Sections involved: Figures: 2-6, 4-6, 4-17, 4-24, 4-26 (MC_OCF Service moved from VC Reception Function to MC_Demux function), Text moved from 4.3.6 and moved to 4.3.8.  Please note that Figure 2-6 is identical to Figure 4-17 and has always been duplicated in all of the SDLP blue books for ease of reference.

First of all, the OCF_Flag tells us whether or not an OCF_SDU is or is not contained in any given transfer frame.
In TM, within a Virtual Channel, the OCF_Flag is static.
The difference between MC_OCF and VC_OCF service, in MC_OCF service the pick up of the OCF_SDU is from a MC_OCF service provider and the delivery of the OCF_SDU is to the MC_OCF service provider on the receive side.
In VC_OCF service, there is an OCF Service provider for each VC that carries an OCF_SDU, which is picked up by that specific VC_OCF service provider and delivered to that VC_OCF service provider on the receive side.

Now, because we only have fixed length frames in TM, the requirement in TM is that the OCF services are static i.e., the carrying of an OCF_SDU cannot be changed on a frame by frame basis.
In USLP, in the general case, the OCF_Flag is dynamic meaning that the transfer of an OCF_SDU can change on a frame by frame basis.
You asked , “Then, recalling that there is a OCF_Flag in the transfer frame header can the OCF be omitted (if desired) also for fixed length frames?” – Yes it can, however it would complicate the frame assembly process, since in this case we are dealing with a fixed length frame constraint. So most likely in a fixed length case, the USLP OCF_Flag will be static. But it is not mandatory.

Note also In AOS there is only VC_OCF service. It is static in a VC and the VC_OCF service is managed because there is no OCF_Flag.

In USLP, we only have a MC_OCF service. We looked at the MC_OCF service definition as described in Section 3 of TM and compared it to ours in USLP. There is no difference except for the OCF_Flag requirement i.e., that the flag is static for a mission phase in TM but dynamic (and controlled by the USLP VC Managed Parameters). In other words, USLP allows an OCF_SDU to be carried on a frame by frame basis and in TM, each frame in the VC would have to carry an OCF_SDU throughout the mission phase.

So, does that mean we need to rename the OCF service in USLP ? We don’t think so, because we still have a MC_OCF service (as defined) that picks up the OCF_SDUs from one MC_OCF service provider and delivers all of the OCF_SDUs to one MC_OCF service provider on the receive side. The basics haven’t changed. We just removed the constraint on the OCF_Flag to allow it to be dynamic on a frame by frame basis, mostly because of the variable length frame nature of USLP which provides better efficiency in transferring OCFs across the link. Also OCF_SDU pick up and delivery are globally identifiable for MC_OCF service.

Concerning figure 2-5 and 4-6, we believe the figures are correct as currently drawn. Recall that these figures are illustrations of a possible implementation. One can do it in many different ways. You have the current version but I have also attached it here as well.
We have the MC_OCF Service injected into the VC Generation box on the sending side, because that is the function where all of the components of the VC come together except for Insert Zone (All Frames generation) and CRC (All Frames Generation). In the VC generation box is where the VC construction process picks up the OCF_SDU from the MC_OCF service for that participating VC and builds the VC frame. When the flag is set, the OCF_SDU is extracted and provided to the MC_OCF service within the MC Demultiplexing Function.

If there are any issues with these updates, we will discuss them at the Spring 2018 meeting in Gaithersburg, MD, USA in early April.

Best Regards,

Greg Kazz
Principal Engineer
Technical Group Supervisor,
Project Software and End-to-End Information Systems Engineering (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180213/3eb10b3d/attachment.html>