[Starlink] space packet protocol document

[Starlink] space packet protocol document

[Dave Taht]

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.

-- 
https://blog.cerowrt.org/post/2024_predictions/
Dave Täht CSO, LibreQos

Re: [Starlink] space packet protocol document

[Alexandre Petrescu]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

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.
>

[-- Attachment #2: example_01.PNG --]
[-- Type: image/png, Size: 33665 bytes --]

Re: [Starlink] space packet protocol document

[Tomaso.deCola]

But there exists already a CCSDS spec for IP over CCSDS…
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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] space packet protocol document

[Marc Blanchet]

> Le 28 févr. 2024 à 13:53, Tomaso de Cola via Starlink <starlink@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.

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@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] space packet protocol document

[Tomaso.deCola]

Yes very true, but I think this spec came from a scenario setup where all IP-based functionalities were not necessary, i.e. more like protocol encapsulation rather than actual IP operations. And moreover we are talking of a spec published in 2012…

Tomaso 
Sent from my iPhone

> On 28. Feb 2024, at 20:28, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> 
> 
>> Le 28 févr. 2024 à 13:53, Tomaso de Cola via Starlink <starlink@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.
> 
> 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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> 

Re: [Starlink] space packet protocol document

[Alexandre Petrescu]

Le 28/02/2024 à 21:03, Tomaso.deCola@dlr.de a écrit :
> Yes very true, but I think this spec came from a scenario setup where all IP-based functionalities were not necessary, i.e. more like protocol encapsulation rather than actual IP operations. And moreover we are talking of a spec published in 2012…

1. an IPv6 spec on CCSDS written in 2012 with no echo at IETF 
whatsoever, hmm..., might raise some questions of legitimity. One can do 
many things in separate SDOs or laboratories, but some key points such 
as IP (the fine waist) can not simply be done in so much independence. 
(witness, for example, the new versions of IP beyond of IPv6- they lived 
some life of demonstration, which was good and raised eye brows at the 
time, but no longer do we hear about any one of them in particular).

A similar situation is with IPv6-over-DSRC specified at ETSI: it is not 
deployed, probably because of the requirement of the use of an 
intermediary geonetwork layer (not an IETF protocol, but an ETSI 
protocol).  On another hand, IETF has a similar IPv6-over-802.11p (OCB) 
protocol specified in an RFC.  It is more widely agreed, is relatively 
easier to deploy, although it too has other issues.  There is a balance 
that tends to tip to the IETF IPv6-over-OCB version, IMHO, although the 
jury is still out.  With CCSDS, we are not even in that situation where 
to talk about the CCSDS version of IPv6-over-CCSDS and the IETF version 
of the IPv6-over-CCSDS.

2. even encapsulation has a relationship to how IP is run.

Encapsulation has many meanings.  It could mean complete independence, 
orthogonality, data pipe - one does not care what goes inside, so no 
need of IP spec on CCSDS.  Another meaning is when encapsulation is more 
than prepending a header and a trailer, and where significant advantages 
can be obtained, such as in leaping out from a state to another (VPNs 
and overlay networks come to mind - they are specified, they are not 
orthogonal).  In that sense, there might be a need of agreed specs.

Maybe you mean that IPv6-over-CCSDS that is _not_ CCSDS encapsulation 
might have a future, I dont know.

Finally, the need of specs also comes from interoperability between many 
operators, manufacturers and software houses.  But until now, it seems 
to me the ecosystem is relatively closed, with little chance of bloom.  
Or that it is dedicated more to the space experts, and closed facing to 
the typical network experts.

I will wait and see :-)

Alex

>
> Tomaso
> Sent from my iPhone
>
>> On 28. Feb 2024, at 20:28, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
>>
>> 
>>> Le 28 févr. 2024 à 13:53, Tomaso de Cola via Starlink <starlink@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.
>>
>> 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@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@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink

Re: [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@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@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] space packet protocol document

[Alexandre Petrescu]

Le 28/02/2024 à 19:53, Tomaso.deCola@dlr.de a écrit :
> But there exists already a CCSDS spec for IP over CCSDS…
> Moreover the snapshot you attached is about TC frames, I.e. for telecommand services…

If they gave another example of non telecommand services, or if they 
told that IPv6 must not be carried in telecommand services...

But I will wait and see for some time.

Alex

>
> Tomaso
> Sent from my iPhone
>
>> On 28. Feb 2024, at 18:47, Alexandre Petrescu via Starlink <starlink@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink