Hi Alex,
Thank you for your exhaustive clarifications!
Indeed, the word encapsulation may be understood/interpreted in different ways!
I will replace it with 'Transportation' in the next update.
On Fri, Jul 5, 2019 at 12:15 PM Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote:
Le 27/06/2019 à 18:38, Joerg Ott via Datatracker a écrit :
[...]
> App. E: why would high mobility affect encapsulation"?
The paragraph in question is this:
>
> Appendix E. Design Considerations
>
> The networks defined by 802.11-OCB are in many ways similar to other
> networks of the 802.11 family. In theory, the encapsulation of IPv6
> over 802.11-OCB could be very similar to the operation of IPv6 over
> other networks of the 802.11 family. However, the high mobility,
> strong link asymmetry and very short connection makes the 802.11-OCB
> link significantly different from other 802.11 networks. Also, the
> automotive applications have specific requirements for reliability,
> security and privacy, which further add to the particularity of the
> 802.11-OCB link.
There a huge list of Design Considerations in the main matter. More and
more reviews led to skinning it to just one paragraph, depicted above.
Let me try to answer to the question of why would high mobility affect
encapsulation.
First, the word encapsulation seems to have captured your attention. I
hope it is for a good reason, but frankly speaking I do not know the
reason why it attracted it. To clarify, let me say that the word
'encapsulation' was used to signify 'carrying' IPv6 datagrams on
802.11-OCB. One expects IPv6 to be carried over OCB as over WiFi.
('encapsulation' was not used to mean IPv6-in-IPv6 encapsulation and
friends).
The high mobility in OCB is contrasted to low (or no) mobility in WiFi -
it means that in WiFi users are near a fixed Access Point and dont move
much. But in OCB there are no access points and cars move a lot.
High mobility in OCB may need to avoid potential interference in order
to ensure safety. TO achieve that, it may be possible that QoS concents
become more mandatory on OCB links (than on WiFi; on WiFi the QoS
concepts are almost absent in implementations). Thus, there may be a
need of some mapping between IPv6 QoS-specific fields and 802.11-OCB
QoS-specific fields. There may be need of other QoS-specific fields.
So, whereas an IPv6-over-WiFi spec (which does not exist, btw) has no
mapping of QoS fields of how IPv6 is 'carried' (encapsulated) on WiFi,
an IPv6-over-OCB would need some mapping of this sort, so that IPv6 is
better 'carried' over OCB. Because of mobility.
QoS is just an example of why encapsulating (carrying) IPv6 on OCB may
need more than just what is needed by carring IPv6 on WiFi.
There are other examples: IPv6 addressing in OCB links requires human
intervention often - it's not as plug and play as IPv6 over WiFi. That
needs easy to remember and subnet-specific link local addresses, like
fe80:1::1/32. These addresses dont exist on IPv6 altogher, let alone
IPv6-over-WiFi.
There are more examples.
Remark my own difficulty of speculating on something which does not
exist: IPv6 over WiFi specification.
Alex
Best Regards
Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco
