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