Re: Tsvart last call review of draft-ietf-ipwave-ipv6-over-80211ocb-46

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux