Re: [ieee-ietf-coord] RFC8691 and 802.11bd

[Peter Yee <[e-mail]>]

Alex,

	I'm not entirely familiar with the RFC 8691's use of IEEE 802.11 QoS headers, but from what I can see the requirement seems to be that data will be transmitted in QoS Data frames. Nothing I see in IEEE 802.11bd indicates to me that IEEE 802.11bd is substantially changing handling of QoS frames. It mostly just refers to the Duration/ID field value calculations.

	The MIB mentioned in IEEE 802.11bd is the NGV PHY MIB (Next Generation V2X Physical Layer MIB). IEEE 802.11 MIBs are generally manipulated via the Service Access Points for the MAC Layer Management Entity (MLME) or the PHY Layer Management Entity (PLME). A Station Management Entity (SME) is defined that interacts with both SAPs, while the PLME and MLME can also interface with each other directly as well. IEEE 802.11bd merely adds NGV-specific attributes to the PHY MIB. It doesn't present any new interfaces, so IEEE 802.11bd does not make any mention of IP (in any regard), SNMP, or 192. This would rightly be left to the baseline IEEE 802.11 specification, currently IEEE 802.11-2020. The SME may present an external, IP-accessible SNMP interface, but that's not really defined in IEEE 802.11. The only mentions of SNMP in IEEE 802.11-2020 are within the MIB itself, mostly for IMPORTS and in comments about things like compliance statements. IPv6 (RFC 8200) is listed as a normative reference in IEEE 802.11-2020. Anything found in IEEE 802.11-2020 is assumed to apply to IEEE 802.11bd unless IEEE 802.11bd changes something found in the baseline. As such, I believe that if IEEE 802.11-2020 is adequate to your needs in terms of the management interface, then there doesn't appear to be any difference in IEEE 802.11bd that would materially affect your ability to manage an IEEE 802.11bd device.

	If you need additional details, I would suggest you contact either Dorothy Stanley (IEEE 802.11 WG chair) regarding access to the IEEE 802.11bd draft or Bo Sun (IEEE 802.11 Task Group bd chair) regarding specific points. TGbd appears to be holding weekly virtual meetings on Tuesdays at 10 a.m. US Eastern Time. It might be possible for you to get time on the agenda to discuss your concerns. Participation in the virtual meetings is freely open to all.

		-Peter

-----Original Message-----
From: Alexandre Petrescu <[e-mail]> 
Sent: Wednesday, October 20, 2021 12:05 AM
To: Peter Yee <[e-mail]>
Cc: [e-mail]
Subject: Re: [ieee-ietf-coord] RFC8691 and 802.11bd

Peter,

Thanks for the clarification.  Sorry missing a first reply back in July, despite careful attention.

It makes sense at MAC layer to stay independent of the upper layers, including IP.

Some interactions might be helpful, though.  RFC8691 conditions the use of .11 QoS headers for using IPv6, and as such one would like to make sure .11bd is able to do these .11 QoS headers.  Otherwise IPv6 wont work on .11bd, unhappily.

.11 documents often mention 'MIB' and sometimes might mention 'IP' or '192.'.  That is a sign that .11 might depend on SNMP and further on IP, even though not very explicitly.  If so (if .11bd D2 mentions 'MIB' or 'SNMP' or '192.') then one would like to make sure the current version of IP is supported, explicitely.

Can I check that?

Alex



Le 19/10/2021 à 18:56, Peter Yee a écrit :
> Alex,
> 
> As I replied to your original message back in July, IEEE 802.11bd
> D2.0 does not mention IPv6 at all. It doesn't contain the term 
> "Internet" either or any obvious reference to IPv6 through other terms 
> such as "upper layer" or "higher layer".
> 
> -Peter
> 
> -----Original Message----- From: ieee-ietf-coord 
> <[e-mail]> On Behalf Of Alexandre Petrescu
> Sent: Tuesday, October 19, 2021 6:51 AM To: [e-mail]
> Subject: Re: [ieee-ietf-coord] RFC8691 and 802.11bd
> 
> Does the 802.11bd D2.0 of July 2021 mention 'IPv6'?
> 
> Alex
> 
> Le 15/07/2021 à 21:24, Alexandre Petrescu a écrit :
>> Hi, participants to the IEEE-IETF coordination,
>> 
>> RFC8691 "IPv6 over OCB" is produced by the IPWAVE WG of IETF.  It 
>> describes the layering of the IPv6 network protocol on top of the
>> 802.11 MAC in OCB mode.  This mode is the preferred mode of operation 
>> for automobile networks that involve 802.11.  This OCB mode is also 
>> known as 802.11p, and will be used in the future 802.11bd to be 
>> released by IEEE in 2022.
>> 
>> I would like to say that it will be a great idea if the 802.11bd 
>> document cited RFC8691 whenever the former said 'IPv6'.  It would be 
>> a perfect match.
>> 
>> How to achieve that goal?
>> 
>> I think there might be a few hurdles in achieving it:
>> 
>> - I do not have regular access to the 802.11bd ongoing developments, 
>> and the latest documents.  I am not a member of the IEEE respective 
>> group.
>> 
>> - some IEEE people often think that _if_ there is a network layer in 
>> automobile networks, then that would first be the IEEE's networking 
>> layer for it, which is IEEE 1609.3, and 'WSMP', which is a different 
>> thing than the IP networking layer.  It might be that IEEE gives 
>> preference to that networking layer instead of IP.
>> 
>> From an architecture point of view, I think there is no comparison to 
>> be made between those two networking layers.  The IP networking layer 
>> clearly has several advantages, scuh as its addressability capacity 
>> and the forwarding of datagrams for scalability.
>> 
>> From an implementation point of view, I did see many implementations 
>> of this IPv6-over-OCB (802.11p) running in many automobile networks. 
>> An implementation of IPv6-over-OCB of 802.11bd is only around the 
>> corner, not posing any significant challenge in realization.
>> 
>> Maybe these worries are not really founded, and maybe it is extremely 
>> easy to cite RFC8691 in 802.11bd.  But how to do it?
>> 
>> Alex
>> 
>> 
>> _______________________________________________ ieee-ietf-coord 
>> mailing list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>> 
> 
> _______________________________________________ ieee-ietf-coord 
> mailing list [e-mail] 
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord
>