Le 28/02/2024 à 21:03, tomaso.dec...@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.blanc...@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
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
