[Starlink] space packet protocol document

[Alexandre Petrescu]

Le 28/02/2024 à 20:28, Marc Blanchet a écrit :
>> Le 28 févr. 2024 à 13:53, Tomaso de Cola via Starlink <starlink at lists.bufferbloat.net> a écrit :
>>
>> But there exists already a CCSDS spec for IP over CCSDS…
> Right, but it is underspecified. It just specifies which value to put in the frame to identify IP in the payload. It does not talk about how to actually use IPv6 in such context: neighbor discovery, IP addresses, DAD, …  IETF had made IPv6 over Foo RFCs for that specific matter. Right now, I doubt that two implementations (if any of IPv6 over CCSDS links exists) would interoperate with this under spec.

I agree with all the points.

The point is, that there could be one or more Internet Drafts that could 
address the issue.

But that is just a matter of idea.  Maybe someone will pick on it.  From 
my side, I will wait and see for some time, where this can go to.

Alex

>
> Marc.
>
>
>> Moreover the snapshot you attached is about TC frames, I.e. for telecommand services…
>>
>> Tomaso
>> Sent from my iPhone
>>
>>> On 28. Feb 2024, at 18:47, Alexandre Petrescu via Starlink <starlink at lists.bufferbloat.net> wrote:
>>>
>>> The CCSDS spec is an interesting document.
>>>
>>> I am trying to find a packet dump of a CCSDS packet that travelled in space according to this CCSDS spec.  If there is a place with CCSDS packet dumps I am interested to see them.
>>>
>>> Given that, I could think about writing an IPv6-over-CCSDS preliminary Internet Draft.
>>>
>>> I could find a png image of a packet dump at ESA (https://essr.esa.int/project/ccsds-wireshark-dissector), but that is not a real packet dump binary file that could be loaded in wireshark; strangely, they do provide a dissector, but not a packet.
>>>
>>> Here are my IPv6 comments about CCSDS, relative to that png of a CCSDS packet (png attached):
>>>
>>>> - the shown 'Frame Length' field is on 16bits.  For IPv6, this can be fine, in principle. The good thing is that the minimum MTU of IPv6 is 1280, and that can be encoded ok with a 16bit length field.  On another hand, the 'Payload Length' of IPv6 is also on 16bit.  This means that the largest normal IPv6 packet would not fit into a single CCSDS frame, and would need to be fragmented by CCSDS.  Maybe fragmentation is little desirable when RTT is 45minutes.  And, there are also the IPv6 'jumbograms'.
>>>>
>>>> - there is a 'Spacecraft ID' and 'VC ID' fields combined on 16bits: this field could be used, if appropriate in some context, to help with forming IPv6 link-local addresses.  If there is worry about privacy, and these IDs could be used to input hashes, such as to obtain hopefully unique numbers; these hopefully unique numbers are often necessary when designing IPv6 addressing architectures, subnet numbers, IPv6 ULA addresses, secure addresses for secure identification, and similar.
>>>>
>>>> - there is a 'SDLS Header' containing a 'Security Parameter Index' field.  If this packet contains an IPv6 packet with an ESP header (encapsulated sec'y protocol) then that too has a 'Security Parameter Index' field (SPI).  It would be good to re-use.  Ideally, one would rely entirely on IPsec and almost not at all on CCSDS-specific security.
>>> Alex
>>>
>>>> Le 23/02/2024 à 19:03, Dave Taht via Starlink a écrit :
>>>> Given the trouble the moon lander has had communicating, I looked over
>>>> this just now.
>>>>
>>>> https://public.ccsds.org/Pubs/133x0b2e1.pdf
>>>>
>>>> I reviewed a similar document for the earth-moon corridor by NASA
>>>> about 2 years ago, and it was a mess of non-interoperable bands and
>>>> protocols. I cannot remember the name of that one.
>>> <example_01.PNG>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink