Re: [ipwave] Question on actually using 11-OCB

[Alexandre Petrescu <[e-mail]>]

Le 26/07/2023 à 16:33, Robert Moskowitz a écrit :
> I am working with Uncrewed Aircraft System (UAS) manufacturers on
> A2A direct communication for Detect And Avoid (DAA).

Are these UAS featuring one or several OCB antennas and how are they
pointed, up-down-horizontally?  It is one of the factors that tells how
to make IP run on them.

This DAA, as its name suggests, seems to be important; it has many
similitudes in car-to-car and sat-to-sat collision avoidance.

> See my draft:
> 
> https://datatracker.ietf.org/doc/draft-moskowitz-drip-a2x-adhoc-session/
>
>
>
>
>  > One of the perferred radio links for this is IEEE 802.11-OCB, but
> running over 2.4Ghz.  With channel 6 being mentioned the most.

This (OCB at 2.4GHz) I am not sure it is possible.  Technically yes, but
the reglementation - IIRC - seemed to be saying that OCB must be at
5.9GHz bands not long ago.  Not sure for now.

Or maybe these are new efforts.

(channel 6 is _center_ at 2.4GHz bands, so mandating OCB there might
disturb many people; I'd have expected to consider OCB maybe more at 1
or at 12, but I dont have the whole picture.)

> So the challenge at first is what does this take to do?
> 
> Well I don't have 802.11-2020 but I do have 802.11p-2010.  It seems 
> that all is needed is to set dot11OCBEnabled to true, and follow sec 
> 11.19. No firmware hack needed as long as dot11OCBEnabled is 
> available?

I am not sure what is section 11.19, but indeed, it is sufficient to
turn on OCB mode and there is no need of firmware hacks nowadays.

There are however, details.

Generally speaking, there are two kinds of OCB cards and their drivers
on the market: the proprietary expensive with QoS and the cheap open
source without QoS features in .11 headers.  These cards are
interoperable somehow, meaning that they understand each other, but they
dont ensure QoS when mixed.

For the fw hacks: it might be that firmware hacks might be needed for
the cheap non-QoS OCB cards such as to become QoS aware OCB; this can be
checked; it was not the case a while back; more years ago it was the
case that for any OCB mode - be it Qos or notQoS - there was a need of a
firmware hack.

The RFC IPv6-over-OCB has chosen the path of the expensive cards and
drivers with QoS; it was in part guided by the experience of a
particular vehicular manufacturer, thus effectively mandating the use of
QoS .11 headers for all IPv6.  (this particular manufacturer has other
very advantageous interests in automobile comm technologies but this
particular QoS aspect is debatable IMHO).

If I were to re-start and recommend the use of OCB to other
manufacturers (not the car manufacturers) I'd go the path of cheap cards
instead, if others would rally.

That said, an important aspect (other than the QoS-nonQoS aspect) is how
to make IP work on OCB.  Be they QoS-notQoS cards all will support IPv6,
but how to set up addresses is another matter.  How to run SLAAC, DHCP,
what prefix lengths, are matters that can be up to discussion.  IPMON
touches a little bit on these aspects too.

> Has anyone had experience(s) with this they can share with me?
> 
> This would then be an important use of IPv6 over OCB; also
> leveraging SCHC as an Ethertype:
> 
> https://datatracker.ietf.org/doc/draft-ietf-intarea-schc-protocol-numbers/

Header compression for OCB?  I am not sure there is a need of it?  There
are huge bandwidths now possible with OCB, I'd guess in the range of
Gbit/s.  This is much more than the initial .11p implementations which
maxed at around 16mbit/s.

But probably there are other tech arguments for SCHC and OCB.

Alex

> 
> 
> 
thanks
> 
> Bob
> 
> _______________________________________________ its mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/its