[Sls-slp] Cross support implementation Limitations

[Greenberg, Edward]

The link layer security working group needs to understand the limitations in
the current link layer implementations in order to understand the effects of
minor or even major structural changes to link layer structures.

For example CNES has missions that insert a frame time tag as a secondary
header each telemetry frame for some of its missions.  If the Security
working group, for example, recommended that the security header precede the
insert zone and/or current secondary header would that effect current
services?  Return Frame services only require information in the primary
header and validation/coding acknowledgement, they don't examine the frame's
content.  Packet extraction however would be effected if the structure of
the frame would change even if security was not used.  When security is
included, exclusive of just adding fields to the end of the frame data field
processing may not be effected but finding the data field portion in the
frame may/will probably be effected.

Forward link implementations currently only deal with TC frames.  Security,
if layered above a frame delimitation and validation service would most
likely not effect that underlying service sublayer. The processing of the
frame's contents for extraction of packets however would certainly require
changes in any event to handle the security.

So the question that needs to be answered is what are the bounds that
current Multimission service place on the current frame structures.  It is
questionable if current missions that are handled by mission unique
processing should impose limitations on what should/could be done to modify
the framing structures.

I would suspect that the biggest issue will be the placement of the Security
Header within the frame and the use of spare bits within the primary header.
So it would be important to identify those implementations that would be
effected by location of the security header within the frame or the
limitations that must be included for its inclusion.

An issue that arises is the insert zone.  Can the insert zone (even though
it will be required to be the same size in every frame) be required to be in
the exact same location within frames of different VCs?  I can see where
implementations that use the insert zone would desire it to be independent
of VC and thus require the insert zone to be capable of being delimited
exclusively from primary header information.  This could require that the
security header, in each frame, be the same size and be contained in all
frames if required for any VC when an insert zone is used.

I would also suggest that we examine the possible use of secondary headers
for AOS frames.  The insert zone is an important feature for low rate links
but becomes a burden for high rate links.  A secondary header carrying the
"insert zone contents" from a lower rate link simply supply that same
service when included in a few frames when the frame rate increases.