[Css-csts] follow-up to VC/MC multiplexng discussion item

[John Pietras]

CSTSWG colleagues -
At the CSTSWG telecon on 28 September, I introduced an issue regarding multiplexing of frames in the production of the Forward Frames service. To briefly recap the issue:

A.      The approach to frame multiplexing has so far been to assume that the same approach would be used as that in the SLE Forward Space Packet, which states that "VC" frames would be multiplexed using one of 3 multiplexing schemes (selectable by Service Management):

-          FIFO

-          Absolute priority

-           Polling vector

B.      Although the SLE FSP book only discusses the single, VC-level muxing, the CCSDS Telecommand, Telemetry, AOS, and forthcoming Unified Space Data Link Protocols (SLDP) are all constructed of multiplexing functions at both the VC and Master Channel (MC) levels. That is to say, not only do all of the SLDPs recognize that frames from different VCs need to be multiplexed into a given MC (hence the VC Multiplexing function in each SLDP), but all of the SLDPs also support the possibility of having multiple MCs on a single forward space link and therefore include the MC Multiplexing function.

C.      As far as the SLDPs are concerned, the selection of actual muxing schemes at both levels is deferred to "project organizations". In the case of SLE FSP, the identification of and limitation to the 3 muxing schemes was made as part of the service specification.

The question is, how should this be addressed with respect to the FF service?

In my presentation at the telecon, I presented three possible approaches for addressing muxing at the MC level:

1.       Just ignore muxing at the MC level - i.e., make it simple FIFO.

2.       Define a set of muxing schemes at the MC level in addition to the VC level (presumably the same set as the 3 for the VC level). This is essentially mirroring the layering in the SLDP specifications.

3.       Collapse the two levels of multiplexing into a single level that would apply the muxing criteria to the GVCIDs of the frames, thus taking it account both the VC and MC of the frames. This would no longer reflect the two-mux-level structure of the SLDP specifications, but if we could assert that the externally-observed behavior was the same, that would be okay (FYI - we were able to make a similar argument for the slight re-ordering of production functions that exists in the Enhanced F-CLTU Orange Book, and that was acceptable to the CESG).

I further proposed that the 3rd option be adopted, stating that I think that it could accomplish everything that the two-tiered approach did (this preserving the externally observed behavior). Wolfgang commented that he thought that the results of the two-tiered approach might not be reproducible by the proposed single layer approach.

Having given this more thought following the telecon, I concur with Wolfgang. I had been thinking only in terms of both layers using the priority scheme, and I'm pretty sure that would still work. However, clearly if we mix schemes - say, priority at the VC level and polling at the MC level - the results could not be reproducible by a single mux implementing a single scheme.

So I think that the safest approach is to consider the two-tiered multiplexing approach. Unless someone sees a problem or a better answer, we'll also consider the same 3 schemes as being available for MC muxing.

Finally, let me state something that I don't think was discussed in the CSTSWG telecon.  Normatively, the CSTS does not "care" what the multiplexing schemes are, and/or whether they are implemented at the VC level, MC level, or both, because this is all part of the standard production processing that underlies the FF service, not of the FF provision itself (which is the normative purview of the FF specification). Importantly, the proper functioning of the Forward Frames TRANSFER SERVICE does not depend on how the frames are being multiplexed underneath. If the FF specification cares at all about the underlying muxing schemes and architecture it is for the purposes of explaining what's going on "top to bottom" in the  informative annexes of the FF specification.

Normatively, the specification of muxing on a forward link *should* be the purview of the definitions of the Functional Resources that represent those VC and MC Multiplexing functions. Essentially, this would consist of citations of the relevant clauses of the SDLP specifications, augmented by the definitions of the multiplexing schemes that are supported by those Functional Resource types (i.e., the 3 schemes identified above). Unfortunately, we don't yet have a normative specification of the Functional Resource types - we only have (so far) the somewhat out-of-date Functional Resource Reference Model Tech Note. Fortunately, it looks like I'll be able bring that Tech Note up to date in the coming year, and the definitions of the Forward TC VC Multiplexing, Forward TC MC Multiplexing, Forward AOS VC Multiplexing, and Forward AOS MC Multiplexing FRs will be brought up to date. Whether to make the Tech Note itself normative to some degree or other is still a matter of debate and in any case "above my pay grade".

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20171010/d2fe6466/attachment.html>