[Css-csts] RE: No MC-OCF service on AOS links?

[John Pietras]

CSTSWG colleagues ---
I noticed yesterday that there is a disparity between the AOS and TM Space Data Link Protocols regarding MC-OCFs - specifically, TM has an MC-OCF service and AOS doesn't. I asked Greg Kazz (chairman of the SLS Space Link Protocols WG) whether this difference in behavior was intentional and if so why, and got a response from Ed Greenberg (below).

The SLE ROCF service allows MC selection of OCFs regardless of whether the protocol is AOS or TM.

NOTE -  The Cross Support Reference Model defined separate VC-OCF and MC-OCF services which were subsequently combined in the SLE ROCF service, but the Reference Model didn't exclude MC-OCFs for AOS links either.

Is there a legitimate use case for having CLCW-bearing OCFs reporting on a TC VC appear in every frame of a Master Channel (instead of just a single VC)? If so, should we propose to the Space Link Protocols WG that the AOS SDLP be changed to include an MCOCF "service" comparable to the one in the TM SDLP stack?

If there's not a legitimate use case, should the SLE ROCF book be modified to restrict MC-OCF delivery to TM return links?

Best regards,
John

From: Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov]
Sent: Monday, March 04, 2013 5:48 PM
To: Kazz, Greg J (313B); John Pietras
Subject: Re: No MC-OCF service on AOS links?

I haven't talked to Tim Ray yet about using ROCF service but I don't think that we had envisioned MC OCF for AOS because of the nature of the channel it was to be use on.  It was for : 1)very high speed links, 2) many VCs  to service multiple independent users
3) the push was to get away from reliable frame service to reliable file service and for high rate links COP-1 was not the best way to achieve reliable transfer.  The VC-OCF service was to support a single uplink control channel in support of a TC uplink.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130305/d52a29fe/attachment.html