[Sls-slp] [EXTERNAL] Re: Extending the 1st Header Pointer in AOS to 16 bits to cover max Transfer Frame length

Fri May 20 15:02:25 UTC 2022

Hello Marco,

I totally agree with you. The worst outcome would be to restrict the Space Packet size.
Best regards,
Greg

From: "Marco.Rovatti at esa.int" <Marco.Rovatti at esa.int>
Date: Friday, May 20, 2022 at 1:54 AM
To: "Kazz, Greg (US 312B)" <greg.j.kazz at jpl.nasa.gov>
Cc: "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, "Rodriguez, Shannon(GSFC-5670)" <shannon.rodriguez-1 at nasa.gov>, "Kazz, Greg (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org>, SLS-SLP <sls-slp-bounces at mailman.ccsds.org>, "Sank, Victor J.(GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" <victor.j.sank at nasa.gov>
Subject: [EXTERNAL] Re: [Sls-slp] Extending the 1st Header Pointer in AOS to 16 bits to cover max Transfer Frame length

Good morning SLP-WG,

Being the AOS Frame length a managed parameter and therefore mission dependent, its extension to max 65536 octets does not make existing assets incompatible. In fact, new missions wishing to re-use recurrent HW/SW, may still decide to keep on using 2048 octets long AOS Frames.
If max AOS Frame length gets extended, I'd rather go for expanding the 1st header pointer to 16 bit if CCSDS Space Packet Protocol than constraining the max packet length.
In fact, I would discourage restricting max CCSDS packet length as this may introduce a severe and unnecessary protocol overhead in systems using e.g. CFDP over AOS.

I hope this helps

Best regards

Marco Rovatti
Data Handling and Avionics Engineer

[cid:image001.gif at 01D86C1F.EF6C2E60]
P:        +31 71 5655641
A:        Keplerlaan 1, 2201AG, Noordwijk, NL
W:        www.esa.int<https://urldefense.us/v3/__http:/www.esa.int__;!!PvBDto6Hs4WbVuu7!cqws8EkYedZl_a9pdrL1fkeb9f-FCOG5YuKkk2v5S0uGnyCrJ3ye7oD59M7S2fl1UkGMonmE$>

From:        "Kazz, Greg\(US 312B\) via SLS-SLP" <sls-slp at mailman.ccsds.org>
To:        "Kazz, Greg (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org>
Cc:        "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, "Sank, Victor J.\(GSFC-567.0\)\[SCIENCE SYSTEMS AND APPLICATIONS INC\]" <victor.j.sank at nasa.gov>, "Rodriguez, Shannon\(GSFC-5670\)" <shannon.rodriguez-1 at nasa.gov>
Date:        11/05/2022 19:39
Subject:        [Sls-slp] Extending the 1st Header Pointer in AOS to 16 bits to cover max Transfer Frame length
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
________________________________

Dear SLP WG,

I’ve been asked by Andrea Modenini, the chair of the C&S WG, to poll you concerning their proposal below to utilize the 5 reserve bits in the M_PDU header of the AOS Transfer Frame in order to extend the 1st Header Pointer from 11 bits (2048 octet Maximum AOS Transfer Frame Size) to 16 bits (65536 octet maximum AOS transfer frame). Note: USLP transfer frame maximum is also 65536 octets.

Please provide me with your opinion by end of day May 17.

Here is the proposal from Victor Sank and Shannon Rodriguez at NASA/GSFC:

We agree that First Header Pointer must be able to point to first packet header that is in the Packet Zone of the transfer frame.  Even through the packets can be very long,  limited to a length of 65536 octets, and may cover several transfer frames, the problem is where in the frame the next packet starts.  The 11 bit first header pointer is the limitation since it would not be able to point far into the frame.  But there are 5 bits of reserved that can be used with the 11 bit, giving 16 total and covering what we need.

              We would have to couple the extension of transfer frame lengths with making use of the reserved 5 bit in the M_PDU Header.  There is also an option that can be used.  If there is objection to extending the first header pointer to 16 bits, we could still allow longer transfer frames with the restriction that the packets used with these transfer frames are (temporarily) limited to 2048 octets.  In the future if/when CCSDS agrees to the 16 bit first header pointer, the restriction would be removed.

CCSDS732.0-B-3 shows an M_PDU Header with the first header pointer as 11 bits but also shows 5 bits of reserved.  If we use the 5 bit we have 16 and can point to 65536.

[cid:image002.png at 01D86C1F.EF6C2E60]

Best regards,

Chair SLP WG

Greg Kazz

Principal Engineer

Technical Group Supervisor,

312B Project Protection, Project Software, and End to End Information System Engineering

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

 _______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp<https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp__;!!PvBDto6Hs4WbVuu7!cqws8EkYedZl_a9pdrL1fkeb9f-FCOG5YuKkk2v5S0uGnyCrJ3ye7oD59M7S2fl1UssX6Qam$>

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or

protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received

this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect

personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20220520/ea10da89/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1226 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20220520/ea10da89/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 66923 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20220520/ea10da89/attachment-0001.png>