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

[Nabil Benamar <[e-mail]>]

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 <
[e-mail]> 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