Maximum Frame length wrt SDLS added fields

[dccutrig]

Open as a reminder:

Maximum frame length is 1024 octets for a TC Frame. Should it be our responsibility to ensure that we do not violate this CCSDS Spec by adding SDLS to a frame?

e.g. if a frame is 1020 bytes and we add 6 bytes by adding SDLS headers, we've violated maximum TC length.

Thought: Could be checked in the update TF length function, if nothing else

[IbraheemYSaleh]

If we do add this, I think the proper place it should be added is in the managed parameters for each GVCID. We need to allow users to specify variable maximums per GVCID (which can sometimes be less than 1024 bytes).

Some channels may allow larger frames, while some might be better off with short frames (EG large file transfers to deep space missions) -- it's really not a project-wide configuration that can be hardcoded to 1024 bytes.

[dccutrig]

For reference:

[dccutrig]

To follow-up on this, do we want to impose framing restrictions outside of the absolute TC maximum, or leave this to the underlying ground station to generally take care of? (e.g. if it is operating on some assumption that the max length should be less than 1024?)

[IbraheemYSaleh]

[IbraheemYSaleh]

Maximum Transfer Frame Length should be a managed parameter ... It needs to be added to the Crypto_Config_Add_Gvcid_Managed_Parameter function. https://github.jpl.nasa.gov/ASEC/AMMOS-CryptoLib/issues/21