Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons

[Jérôme Härri <[e-mail]>]

Hi Alex,

>> There is no need of beacons for IEEE 802.11 OCB, this has been debated 
>> in the 802.11p WG years ago.

>But there would be a difference between lack of need, and forbidding them,
right?

Well, here I have to agree with you. But we are taking the problem from the
wrong side. I think it could 'really' help if you could tell us why you want
OCB to allow beacons to be sent. What has been decided 10 years ago does not
need to stay as such...if there is a clear need, that could not solved by
other means, then standards need to be changed.

So, let me take an educated guess: when using 802.11-OCB without either ETSI
ITS, ISO CALM or IEEE WAVE, there is no specification mentioning how an
ITS-G5-OCB mentions its existence (like with a beacon). So, if you need to
connect to it, you would need to know it is there...you want to use a beacon
as some kind of service advertisement or side link information about the
availability of an IP-v6 enabled IEEE 802.11-OCB. Am I going in the right
direction? 

If so, then we should not mention as introduction that beacons are allowed,
but rather state the opposite: OCB beacons are NOT allowed, which creates a
problem for IPv6-over-OCB, as unless they send BSM/CAM, SPaT/MAP or DENM
directly over IP (so, no ISO, ETSI, WAVE), then they will remain
silent...and a vehicle will not be aware of its presence...btw we could also
reach the same objective by requesting an L3 message to act as a
beacon...(in ETSI, it is called a NET beacon).

Then, we should mention that we why we need beacons and either argue however
we want that it would not violate the standard, OR that we need to put this
into a IEEE 802.11 amendment and change it...

Nevertheless, it is not in IETF (Layer 3) that we can state what exist or
not exist in L2...we can only 'cite' what standards from L2 allows and what
it does not, and why it is problematic..

Would it help this way? 

Best Regards,

Jérôme 

Alex

>
>
>
> Fygs
>
>
>
> *From:*its [mailto:[e-mail]] *On Behalf Of *Dr. 
> Hans-Joachim Fischer
> *Sent:* Wednesday, February 01, 2017 8:19 AM
> *To:* [e-mail]
> *Subject:* Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 
> .11-OCB does use beacons
>
>
>
>
>
> That is right, but it has to be presented completely. The simple 
> drawing suggests that Beacons are necessary for ordinary operation.
>
> For sure MAC management frames are supported for specific purposes.
>
>
>
> Hans-Joachim
>
>
>
> Am 01.02.2017 um 13:03 schrieb Jérôme Härri:
>
>     Dear all,
>
>
>
>     I do not agree and I would be happy to have the reference in the
>     IEEE 802.11-2016 stating otherwise.
>
>
>
>     In the 802.11 standard, it clearly state the following line:
>
>
>
>     When dot11OCBActivated is true in a STA:
>
>     " The STA _may send management frames of subtype Action_ and, if the
>     STA maintains a TSF Timer, subtype Timing Advertisement "
>
>     " The STA may send _control frames_, _except_ those of _subtype
>     PS-Poll, CF-End, and CF-End + CFAck_ "
>
>     " The STA may send _data frames of subtype Data, Null, QoS Data, and
>     QoS Null_. "
>
>
>
>     A beacon is a management frame, but not of a class Action, so it
>     _cannot be transmitted when dot11OCBActivated_ is true in a STA. But
>     I agree that it is ambiguous…nevertheless, I would then replace in
>     the draft the mention of what OCB can do or can’t do (e.g. sending
>     beacons) with the exact 802.11-2016 statements. This would avoid
>     misunderstanding.
>
>
>
>     But even if it could be possible, this does not make much sense. A
>     beacon is transmitted on a channel you need to connect to get BSS
>     information and also to get the right frequency. In case of OCB
>     (outside context of a BSS), it is not required. But the real
>     question is ‘why’ would we need beacon, assuming it could be
>     transmitted?
>
>
>
>     Best Regards,
>
>
>
>     Jérôme
>
>
>
>     -----Original Message-----
>     From: its [mailto:[e-mail]] On Behalf Of Alexandre
Petrescu
>     Sent: Wednesday 01 February 2017 11:51
>     To: [e-mail] <mailto:[e-mail]>
>     Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB
>     does use beacons
>
>
>
>     draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use beacons
>
>
>
>     Hello IPWAVErs,
>
>
>
>     It was suggested in private that, contrary to what the draft says,
>     the .11-OCB does use beacons.
>
>
>
>     As such, the following line should disappear from the draft:
>
>
>
>     > 4.  Aspects introduced by the OCB mode to 802.11
>
>     >
>
>     >    In the IEEE 802.11 OCB mode, all nodes in the wireless range can
>
>     >    directly communicate with each other without authentication/
>
>     >    association procedures.  Briefly, the IEEE 802.11 OCB mode has
the
>
>     >    following properties:
>
>     >
>
>     >    o  Wildcard BSSID (i.e., all bits are set to 1) used by each node
>
>     >
>
>     >    o  [strike through] No beacons transmitted
>
>
>
>     Yours,
>
>
>
>     Alex
>
>
>
>
>
>
>     _______________________________________________
>
>     its mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/its
>
>
>
> --
>
> Dr. Hans-Joachim Fischer
>
> Managing Director
>
>
>
>
>
> ----------------------------------------------------------------------
> ----------
>
>
>
>          Seminars on Cooperative Intelligent Transport Systems
>
>              http://fischer-tech.eu/Feeds/CITSseminars.html
>
>
>
> ----------------------------------------------------------------------
> ----------
>
> + + + Instaurare omnia in Christo + + +
>
> ----------------------------------------------------------------------
> ----------
>
> The information contained in this message is confidential and may be 
> legally
>
> privileged. This email is intended for the addressee(s). Addressees 
> may be
>
> individual persons or members of mailing list.
>
> If you are not an addressee, you are hereby notified that any use,
>
> dissemination, or reproduction of this email and its optional 
> attachements is
>
> strictly prohibited and may be unlawful. If you are not an addressee, 
> please
>
> contact the sender by return e-mail and destroy all copies of the 
> original
>
> message.
>
> ----------------------------------------------------------------------
> ----------
>
> ESF GmbH
>
> Fichtenweg 9
>
> 89143 Blaubeuren
>
> [phone] (Direct line)
>
> [phone] (Central office)
>
> [phone] (Fax)
>
> http://fischer-tech.eu : Main web of ESF GmbH
>
> http://its-standards.eu : News on cooperative ITS standardization
>
> http://its-testing.org : International consultancy for cooperative ITS
>
> ----------------------------------------------------------------------
> ----------
>
>
>
> ----------------------------------------------------------------------
> ----------
>
> ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss
>
> C-ITS online news:  http://its-standards.info/Feeds/cits.rss
>
> ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss
>
> ----------------------------------------------------------------------
> ---------
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>

_______________________________________________
its mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/its