|
note: my text is an
explanation of how I see things. I am not an author of the
OCB document. The OCB document has an Editor, and it belongs
to the WG IPWAVE.
Alex
Le 05/07/2019 à 13:15, Alexandre
Petrescu a écrit :
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
|
