Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 figure comparing .11 to .11-OCB

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 11:44:15 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00  figure comparing .11 to .11-OCB

Hello IPWAVErs,

I suggested to illustrate the differences between .11 and .11-OCB by 
means of a figure, and a co-author produced it.  Unless there is 
opposition I will include it in the draft.

    STA                    AP                 STA                    AP
      |                      |                  |                      |
      |<------ Beacon -------|                  |<------ Beacon -------|
      |                      |                  |                      |
      |---- Probe Req. ----->|                  |------- Data -------->|
      |<--- Probe Res. ------|                  |------- Data -------->|
      |                      |                  |------- Data -------->|
      |---- Auth Req. ------>|                  |------- Data -------->|
      |<--- Auth Res. -------|                  |------- Data -------->|
      |                      |                  |------- Data -------->|
      |---- Asso Req. ------>|                  |------- Data -------->|
      |<--- Asso Res. -------|                  |------- Data -------->|
      |                      |                  |------- Data -------->|
      |------- Data -------->|                  |------- Data -------->|
      |------- Data -------->|                  |------- Data -------->|

      (a) Traditional IEEE 802.11               (b) IEEE 802.11 OCB mode

Yours,

Alex

---

From: Nabil BENAMAR <[email-masked]>
Date: Wed, 1 Feb 2017 10:48:17 +0000

No Objection !

Best Regards,
Nabil 

> On Feb 1, 2017, at 10:44 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> I suggested to illustrate the differences between .11 and .11-OCB by means of a figure, and a co-author produced it.  Unless there is opposition I will include it in the draft.
> 
>   STA                    AP                 STA                    AP
>     |                      |                  |                      |
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 11:50:47 +0100

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

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 1 Feb 2017 11:58:11 +0100

* Beacons are not known in OCB mode
  * Data goes bi-directional

Hans-Joachim Fischer

-- 
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
+49 (7344) 175340 (Direct line)
+49 (7344) 919188 (Central office)
+49 (7344) 919123 (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
-------------------------------------------------------------------------------

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 1 Feb 2017 12:15:56 +0100

Hello Alex, All

I agree with Hans-Joachim, no beacon in OCB mode..and in general, we do not
need to show ‘beacons’ in the chart, as even the association process does
not ‘need’ a beacon…it just depends on if you do ‘active’ or ‘passive’
scanning. 

So, if you want to avoid any misunderstanding, you can also simply remove
beacons from the drawing and mention ‘active scanning’…if you want to keep
it, then if you use a beacon, then you do not need the probes (and mention
‘passive’ scanning)..directly association (to the best of my knowledge..)

As for the data chart, it is also unclear..I would also tend to say that it
could be easier to have bi-directional arrows for ‘data’ in both cases.

Another point: this document is about IPv6..I would therefore suggest maybe
to add the IPv6 processes (so that we have IPv6 data). So, you could add the
SLAAC charts and maybe even Router Solicitation/advertisement charts. What
do you think? These would be common between WLAN and OCB…we could then just
visually show that we bypass some ‘lower layer’ phases, but IP remains
similar. This could also help us with the statement that IPv6 needs to
guarantee the security process that OCB is not doing…with such chart, that
could help.

Best Regards,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim
Fischer
Sent: Wednesday 01 February 2017 11:58
To: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 figure
comparing .11 to .11-OCB

Hans-Joachim Fischer

Hello IPWAVErs, 

I suggested to illustrate the differences between .11 and .11-OCB by means
of a figure, and a co-author produced it.  Unless there is opposition I will
include it in the draft. 

   STA                    AP                 STA                    AP 
     |                      |                  |                      | 

Yours, 

Alex 

-- 
Dr. Hans-Joachim Fischer
Managing Director

----------------------------------------------------------------------------
---- 

----------------------------------------------------------------------------
---- 
+ + + Instaurare omnia in Christo + + +
----------------------------------------------------------------------------
---- 
The information contained in this message is confidential and may be legally

dissemination, or reproduction of this email and its optional attachements
is 

----------------------------------------------------------------------------
---- 
----------------------------------------------------------------------------
---- 
 
----------------------------------------------------------------------------
---- 
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
----------------------------------------------------------------------------
---

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 12:36:14 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00 remove sections D.4, D.5 and
                                         D.8 requirements on security

Hello IPWAVErs,

As discussed in Seoul, we will remove the security-related requirements 
text of the following subsections of the Appendix:

D.4 Privacy Reqs
D.5 Auth Reqs
D.8 Security Cert Generation

Yours,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 12:39:32 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00 remove section D.2 on Non-IP
                                         Communications

Hello IPWAVErs,

It was suggested that we remove the section D.2 on "Non-IP 
Communications".  I agree with the suggestion, because this draft only 
deals with IP.

Yours,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 12:48:53 +0100

Hi Hans-Joachim,

>   * Data goes bi-directional

By this latter point do you mean 'Data' arrows should be both ways, in 
the .11-OCB figure?

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 1 Feb 2017 13:03:43 +0100

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:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 01 February 2017 11:51
To: [email-masked]
Subject: [ipwave] 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.

Yours,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 13:44:27 +0100

Dear IPWAVErs,

The current draft says in abstract:
> [...] it portrays the layering of IPv6 on 802.11 OCB similarly to
> other known 802.11 and    Ethernet layers - by using an Ethernet
> Adaptation Layer.

A commenter said:
> Since the IETF ipwave scope is to address IPv6 over 802.11 OCB,
> assuming that the OSI model is used, the boundary on the data plane
> is the LLC SAP (LLC / Higher Layer boundary).  This is the
> “line-in-the-sand”.

IMHO the Ethernet Adaptation Layer is a name I invented to describe what
happens when computers change between 802.11 headers and wired-Ethernet
headers.

The "line in the sand" term is very suggestive as well.

The ISO term "LLC to SAP" interface, or "LLC to Higher Layer" boundary
is also good.

At this time I am tempted to continue calling it an "Ethernet Adaptation
Layer", because at IETF there are other such adaptation layers (e.g.
LoWPAN adaptation layer for IPv6 over 802.15.4 in RFC4944).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 1 Feb 2017 13:52:50 +0100

Hi IPWAVErs,

There was a question:
> There is already a standard providing this capability today [IPv6
> over 802.11-OCB] – IEEE 1609 series. This service is already in used
> today (i.e.; obtaining Security certificates).  Question: are the
> “IETF-IPv6” and “IEEE IPv6” services mutually exclusive or must they
>  coexist in a same system (OBU or RSU)?  If the latter, there may be
>  technical conflicts to be solved.

Asked that way, IMHO and with all due respect, there can not be such a
thing as an "IEEE IPv6" functionality.  There is only one IPv6 (luckily)
and that is defined at IETF.

I agree though that some demos featured certificate obtention on IPv6 on
802.11-OCB.  I heard it multiple times.

If there was any conflict, we should tell them.

We can understand the technical issues if we look at the packet dumps of
these demos, and compare to other packet dumps of IPv6-over-802.11-OCB.
  Could you provide packet dump of obtaining certificates on IPv6 on
802.11-OCB according to IEEE 1609 spec?

Alex

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 1 Feb 2017 14:16:26 +0100

Yes, that is what I mean. It is not just unidirectional communications.

Hans-Joachim

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 1 Feb 2017 14:18:42 +0100

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:
> " 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
>

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: François Simon <[email-masked]>
Date: Wed, 1 Feb 2017 09:01:59 -0500

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

Fygs

From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim
Fischer
Sent: Wednesday, February 01, 2017 8:19 AM
To: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does
use beacons

Hans-Joachim

Dear all,

I do not agree and I would be happy to have the reference in the IEEE
802.11-2016 stating otherwise.

" 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:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 01 February 2017 11:51
To: [email-masked] <mailto:[email-masked]> 
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use
beacons

Hello IPWAVErs,

Yours,

Alex

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/its

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: Nabil BENAMAR <[email-masked]>
Date: Wed, 1 Feb 2017 15:53:03 +0000

Hi Alex, Jerome, All

I agree with Jerome to illustrate the SLAAC in the process of IPv6 configuration. 
It will show that there is no difference with other networks in the IP layer.

Best Regards,
Nabil 

> On Feb 1, 2017, at 11:15 AM, Jérôme Härri <[email-masked]> wrote:
> 
> Hello Alex, All
>  
> I agree with Hans-Joachim, no beacon in OCB mode..and in general, we do not need to show ‘beacons’ in the chart, as even the association process does not ‘need’ a beacon…it just depends on if you do ‘active’ or ‘passive’ scanning. 
>  
> So, if you want to avoid any misunderstanding, you can also simply remove beacons from the drawing and mention ‘active scanning’…if you want to keep it, then if you use a beacon, then you do not need the probes (and mention ‘passive’ scanning)..directly association (to the best of my knowledge..)
>  
> As for the data chart, it is also unclear..I would also tend to say that it could be easier to have bi-directional arrows for ‘data’ in both cases.
>  
> Another point: this document is about IPv6..I would therefore suggest maybe to add the IPv6 processes (so that we have IPv6 data). So, you could add the SLAAC charts and maybe even Router Solicitation/advertisement charts. What do you think? These would be common between WLAN and OCB…we could then just visually show that we bypass some ‘lower layer’ phases, but IP remains similar. This could also help us with the statement that IPv6 needs to guarantee the security process that OCB is not doing…with such chart, that could help.
>  
> Best Regards,
>  
> Jérôme
>  
> From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim Fischer
> Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 figure comparing .11 to .11-OCB
>  
>  
> 
> Beacons are not known in OCB mode
> Data goes bi-directional
> Hans-Joachim Fischer
> 
>  
>> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> -- 
> Dr. Hans-Joachim Fischer
> Managing Director
>  
>  
>              http://fischer-tech.eu/Feeds/CITSseminars.html <http://fischer-tech.eu/Feeds/CITSseminars.html>
>  
> http://fischer-tech.eu <http://fischer-tech.eu/> : Main web of ESF GmbH
> http://its-standards.eu <http://its-standards.eu/> : News on cooperative ITS standardization
> http://its-testing.org <http://its-testing.org/> : International consultancy for cooperative ITS
> ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss <http://fischer-tech.eu/Feeds/esf.rss>
> C-ITS online news:  http://its-standards.info/Feeds/cits.rss <http://its-standards.info/Feeds/cits.rss>
> ESF Online Nachrichten: http://fischer-tech.de/Feeds/esfD.rss <http://fischer-tech.de/Feeds/esfD.rss>

---

From: John Kenney <[email-masked]>
Date: Wed, 1 Feb 2017 11:51:08 -0800

Hi All:

Hans-Joachim and Jérôme are correct that there are no 802.11 beacons in
11-OCB.  Furthermore, there is no station that takes on the AP role. No AP
in 11-OCB. No Probes. No (802.11) Authentication. No (802.11) Association.
Nothing at all that is specific to the BSS concept. All communication is
STA-STA.

The right side of the diagram should be pretty simple.

Best Regards,
John

On Wed, Feb 1, 2017 at 3:15 AM, Jérôme Härri <[email-masked]>
wrote:

> Hello Alex, All
>
>
>
> I agree with Hans-Joachim, no beacon in OCB mode..and in general, we do
> not need to show ‘beacons’ in the chart, as even the association process
> does not ‘need’ a beacon…it just depends on if you do ‘active’ or ‘passive’
> scanning.
>
>
>
> As for the data chart, it is also unclear..I would also tend to say that
> it could be easier to have bi-directional arrows for ‘data’ in both cases.
>
>
>
> Another point: this document is about IPv6..I would therefore suggest
> maybe to add the IPv6 processes (so that we have IPv6 data). So, you could
> add the SLAAC charts and maybe even Router Solicitation/advertisement
> charts. What do you think? These would be common between WLAN and OCB…we
> could then just visually show that we bypass some ‘lower layer’ phases, but
> IP remains similar. This could also help us with the statement that IPv6
> needs to guarantee the security process that OCB is not doing…with such
> chart, that could help.
>
>
>
> Best Regards,
>
>
>
> Jérôme
>
>
>
> *From:* its [mailto:[email-masked]] *On Behalf Of *Dr. Hans-Joachim
> Fischer
> *Sent:* Wednesday 01 February 2017 11:58
> *To:* [email-masked]
> *Subject:* Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 figure
> comparing .11 to .11-OCB
>
>
>
>
>
>    - Beacons are not known in OCB mode
>    - Data goes bi-directional
>
> Hans-Joachim Fischer
>
>
>
> of a figure, and a co-author produced it.  Unless there is opposition I
> will include it in the draft.
>
>    STA                    AP                 STA                    AP
>      |                      |                  |                      |
> +49 (7344) 175340 <+49%207344%20175340> (Direct line)
>
> +49 (7344) 919188 <+49%207344%20919188> (Central office)
>
> +49 (7344) 919123 <+49%207344%20919123> (Fax)
>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 16:20:52 +0100

But some OCB implementations do send Beacons.

In that sense, I propose to say the following.

old:
>> o  No beacons transmitted

new:
>> o  OCB implementations do not receive beacons and most OCB
>> implementations do not transmit Beacons.

Alex

Le 01/02/2017 à 20:20, Dick Roy a écrit :
> To reiterate, in OCB operation there are NO beacons and there are NO
> APs.
>
>
>
> RR
>
>
>
> ------------------------------------------------------------------------
>
>  *From:*Jérôme Härri [mailto:[email-masked]] *Sent:*
> Wednesday, February 1, 2017 4:04 AM *To:* 'Alexandre Petrescu';
> [email-masked] *Subject:* Re: [ipwave]
> _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
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandre Petrescu Sent: Wednesday 01 February 2017 11:51
> To: [email-masked] Subject: [ipwave]

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 2 Feb 2017 17:00:06 +0100

Dear Alex,

well, If I cross on red lights, we cannot then say that as I did, then crossing on red lights is allowed..

if OCB implementations are sending beacons, then it is an implementation issue..it does not mean that beacons should be transmitted by the standards..

Would still suggest to keep the original version or cut-past the exact statement from 802.11-2016 about allowed messages in OCB mode.

But just asking frankly: why do you want to keep this statement about beacons (allowing them to be sent) ? we spend too much time on useless details and not on other key issues..

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 2 févr. 2017 à 16:20, Alexandre Petrescu <[email-masked]> a écrit :
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 17:58:56 +0100

Dear Jérôme,

> then crossing on red lights is allowed..

Except that here we are making the red lights too :-)

> if OCB implementations are sending beacons, then it is an
> implementation issue..it does not mean that beacons should be
> transmitted by the standards..

Or vice-versa: the stds may need to reflect what's happening in practice.

In my lab there are such beacons.  In other lab too.  It is for this
reason that I have the doubt.

I can not put in an Internet Draft (I-D) text that simply comes from
other standards.  I-D should contain text that is about running code.

And, of course, I need to put in this I-D what the WG thinks is good.
This is why I am asking.

> Would still suggest to keep the original version or cut-past the
> exact statement from 802.11-2016 about allowed messages in OCB mode.
>
> But just asking frankly: why do you want to keep this statement
> about beacons (allowing them to be sent) ? we spend too much time on
> useless details and not on other key issues..

Because I have no guarantee that if I put there "Beacons MUST NOT be
sent" implementers will do so.

I wonder whether there is a reason why Beacons are there in these OCB
implementations that send them.  Or maybe it's just because they are
forgotten there during migration from .11bgn driver to .11-OCB driver.

Alex

>>>> 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:
>>>>
>>> Le 01/02/2017 à 20:20, Dick Roy a écrit : To reiterate, in OCB
>>> operation there are NO beacons and there are NO APs.
>>>
>>>
>>>
>>> RR
>>>
>>>
>>>
>>> " The STA _may send management frames of subtype Action_ and, if
>>> the STA maintains a TSF Timer, subtype Timing Advertisement "
>>>
>>> " The STA may send _data frames of subtype Data, Null, QoS Data,
>>> and QoS Null_. "
>>>
>>>
>>>
>>>  _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:[email-masked]] On Behalf Of Alexandre Petrescu
>>> Sent: Wednesday 01 February 2017 11:51 To: [email-masked] Subject:
>>> [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does
>>> use beacons
>>>
>>>
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 18:09:41 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00 use of term "802.2 LLC"

Hello IPWAVErs,

It has been suggested that the term "802.2 LLC" may not be relevant
because in the next version of the IEEE 802.11 standard the LLC will no
longer be based on IEEE 802.2.

As such, I propose the following change:

old:
> The IPv6 Networking is layered on top of the IEEE 802.2 Logical-Link
>  Control (LLC) layer; this is itself layered on top of the 802.11p
> MAC; this layering illustration is similar to that of running IPv6
> over 802.2    LLC over the 802.11 MAC, or over Ethernet MAC.

new:
> The IPv6 Networking is layered on top of an IEEE 802.11 LLC layer;
> this is itself layered on top of the 802.11 MAC layer; this layering
> illustration is similar to that of running IPv6 over 802.2 LLC over
> the IEEE 802.3 (Ethernet) MAC.

Alex

---

From: Jerome Haerri <[email-masked]>
Date: Thu, 2 Feb 2017 18:17:32 +0100

Alex,

Look, I also have to read standards to understand them and sometimes, they are ambiguous...
But here, we have people who actually took part of the writting, of the 802.11p/OCB mode, and clearly and with absolutely no ambiguity stated that beacons are not sent in OCB...we should listen to them I think..

let's not create 'alternative facts' here...a 'trumpization' of the standard work process will get us nowhere..

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 2 févr. 2017 à 17:58, Alexandre Petrescu <[email-masked]> a écrit :
> 
> Dear Jérôme,
> 
>>>>> can

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 18:30:02 +0100

Le 01/02/2017 à 15:01, François Simon a écrit :
> 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?

Alex

>
>
>
> Fygs
>
>
>
> *From:*its [mailto:[email-masked]] *On Behalf Of *Dr. Hans-Joachim
> Fischer
> *Sent:* Wednesday, February 01, 2017 8:19 AM
> *To:* [email-masked]
> *Subject:* Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB
> does use beacons
>
>
>
>
>
>     (outside context of a BSS), it is not required. But the real

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 18:38:31 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00 handover considerations at
                                         802.11-OCB and 1609

Hello IPWAVErs,

There has been a comment that handovers were never seriously addressed
in 802.11p or IEEE 1609.

As such, I suggest two things.

One is I adapt the text like this:

old:
> However, there are several deployment considerations to optimize the
> performances of running IPv6 over 802.11p (e.g. in the case of
> handovers between 802.11p Access Points, or the consideration of
> using the IP security layer).

new:
> However, there may be some deployment considerations helping optimize
> the performances of running IPv6 over 802.11-OCB (e.g. in the case of
>  handovers between 802.11-OCB [term], or the consideration of using
> the IP security layer).

The other is that I suggest IEEE 802.11-OCB and IEEE P1609 to address
seriously the handover considerations.  At IETF there are a few RFCs and
running code that describe how IP handovers happen.

Yours,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 18:39:12 +0100

Jérôme,

I agree to avoid creating alternative facts.

Is there a packet capture showing Beacons on 802.11-OCB?  If not then 
that's it.

Alex

Le 02/02/2017 à 18:17, Jerome Haerri a écrit :
> But here, we have people who actually _took part of the writting_, of
> the 802.11p/OCB mode, and clearly and with absolutely no ambiguity
> stated that beacons are not sent in OCB...we should listen to them I think..
>
> let's not create '_alternative facts_' here...a 'trumpization' of the
> standard work process will get us nowhere..
>
> Best Regards,
>
> Jérôme
>
> Envoyé de mon iPhone
>
> Le 2 févr. 2017 à 17:58, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> a
> écrit :
>
>> Dear Jérôme,
>>
>>>> Le 2 févr. 2017 à 16:20, Alexandre Petrescu
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> a écrit :
>>>>
>>>>> [email-masked] <mailto:[email-masked]> *Subject:* Re: [ipwave]
>>>>> Sent: Wednesday 01 February 2017 11:51 To: [email-masked]
>>>>> <mailto:[email-masked]> Subject:

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 2 Feb 2017 18:39:38 +0100

Le 01/02/2017 à 21:03, Dick Roy a écrit :
>
> To reiterate, when using an 802.11 MAC & PHY in OCB mode, there is NO
>
> 1)Synchronization,
>

What do you mean by No Synchronisation?

BEcause a packet dump from a commercial RSU features a "IEEE 802.11 
Acknowledgement"?  Is this forbidden?

Alex

> 2)Authentication, or
>
> 3)Association
>
> performed at the MAC sublayer or lower.  There are NO beacons or 
> probes allowed in OCB mode.  That said, any chart showing the 
> difference between OCB and non-OCB mode must be independent of any 
> higher layer service being executed using either (lower layer) mode 
> and as such, addition of such irrelevant information would only be 
> confusing.  OCB mode is very simple:
>
> STA1 STA2
>
>    |←---- data --→|
>
> where data can be data, action, or mgmt frames from a restricted set 
> (e.g. no beacons or probes).
>
> RR
>
> *From:*Nabil BENAMAR [mailto:[email-masked]]
> *Sent:* Wednesday, February 1, 2017 7:53 AM
> *To:* Jérôme Härri
> *Cc:* Dr. Hans-Joachim Fischer; Alexandre Petrescu; [email-masked]
> *//*
>> On Feb 1, 2017, at 11:15 AM, Jérôme Härri <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hello Alex, All
>>
>> I agree with Hans-Joachim, no beacon in OCB mode..and in general, we 
>> do not need to show ‘beacons’ in the chart, as even the association 
>> process does not ‘need’ a beacon…it just depends on if you do 
>> ‘active’ or ‘passive’ scanning.
>>
>> So, if you want to avoid any misunderstanding, you can also simply 
>> remove beacons from the drawing and mention ‘active scanning’…if you 
>> want to keep it, then if you use a beacon, then you do not need the 
>> probes (and mention ‘passive’ scanning)..directly association (to the 
>> best of my knowledge..)
>>
>> As for the data chart, it is also unclear..I would also tend to say 
>> that it could be easier to have bi-directional arrows for ‘data’ in 
>> both cases.
>>
>> maybe to add the IPv6 processes (so that we have IPv6 data). So, you 
>> could add the SLAAC charts and maybe even Router 
>> Solicitation/advertisement charts. What do you think? These would be 
>> common between WLAN and OCB…we could then just visually show that we 
>> bypass some ‘lower layer’ phases, but IP remains similar. This could 
>> also help us with the statement that IPv6 needs to guarantee the 
>> security process that OCB is not doing…with such chart, that could help.
>>
>> Best Regards,
>>
>> Jérôme
>>
>> *From:*its [mailto:[email-masked]]*On Behalf Of*Dr. 
>> Hans-Joachim Fischer
>> *Sent:*Wednesday 01 February 2017 11:58
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 figure 
>> comparing .11 to .11-OCB
>>

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 2 Feb 2017 18:50:16 +0100

Hi Alex,

>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:[email-masked]] *On Behalf Of *Dr. 
> Hans-Joachim Fischer
> *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.
>

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 2 Feb 2017 18:56:20 +0100

Hi Alex,

Well, again we need to check who 'validated' the conformance of an OCB implementation, if any? I mean, even if we capture a beacon, it can also be a wrong implementation of a standard...we need to stay on facts from the standard, not from available implementations...

btw, as this draft is aimed as a WG RFC, should we only refer to standards and not to implementations ?

Best Regards,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Thursday 02 February 2017 18:39
To: Jerome Haerri
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB (non) use of beacons

Jérôme,

Is there a packet capture showing Beacons on 802.11-OCB?  If not then that's it.

Alex

Le 02/02/2017 à 18:17, Jerome Haerri a écrit :
>>>>>> association procedures.  Briefly, the IEEE
>>>>> _cannot be transmitted when dot11OCBActivated_ is true in a STA. 
>>>>> But I agree that it is ambiguous…nevertheless, I would then 
>>>>> -----Original Message----- From: its [mailto:[email-masked]] 
>>>>> On Behalf Of Alexandre Petrescu
>>>>> [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 .11-OCB does use 
>>>>> beacons
>>>>>
>>>>>
>>>>>

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Feb 2017 12:56:49 -0500

>> the IEEE 802.3 (Ethernet) MAC.

I think that talking about Ethernet is causing confusion.  Perhaps it would be more straightforward to say that SNAP [RFC1042] is used to carry the IPv6 Ethertype.

Russ

---

From: John Kenney <[email-masked]>
Date: Thu, 2 Feb 2017 10:12:14 -0800

I completely agree with Jérôme.

If a device is sending a beacon, it is simply not conforming to "outside
the context of a BSS" 802.11 operation.

That might be fine, insofar as a device that supports DSRC might also
support regular 802.11 (or other completely different protocols). Most DSRC
prototypes do in fact support other protocols as well.

But, it is clear that a beacon is not permitted by the portion of the
standard that specifies OCB operation (the language was quoted in a
separate email). So, a device cannot claim to be conforming to OCB when it
sends a beacon. It would be incorrect for the ID to say that a device might
legitimately send a beacon while operating OCB.

You are hearing this directly from several people who actually wrote the
standard.  I hope this input is useful to you.

I will note one other possible source of confusion, in case some people
have run into this.  One important message type used in DSRC is the Basic
Safety Message (or equivalent messages in other standards, e.g. CAM).  In
research literature, it is not uncommon (especially in older papers) to see
these safety messages referred to as "beacons".  That is an entirely
different usage of the word beacon from the 802.11 sense that we are
discussing in this thread.

Best Regards,
John

On Thu, Feb 2, 2017 at 9:56 AM, Jérôme Härri <[email-masked]>
wrote:

> Hi Alex,
>
> Well, again we need to check who 'validated' the conformance of an OCB
> implementation, if any? I mean, even if we capture a beacon, it can also be
> a wrong implementation of a standard...we need to stay on facts from the
> standard, not from available implementations...
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 13:46:51 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
FYI-only par. about IEEE 1609

Hello IPWAVErs,

Recently a comment was made about a paragraph describing how IPv6 and
P1609 inter-relate.  The reading of that paragraph seemed too
authoritative for an IETF Internet Draft.  The suggestion was either to
remove it, or to stress it is "For Your Information only" tagged with
additional details.

I prefer to remove it.

This is the paragraph in question:
> In standards, the operation of IPv6 as a 'data plane' over 802.11p is
> specified at IEEE P1609 in [ieeep1609.3-D9-2010].  For example, it
> mentions that "Networking services also specifies the use of the
> Internet protocol IPv6, and supports transport protocols such as UDP
> and TCP. [...]  A Networking Services implementation shall support
> either IPv6 or WSMP or both." and "IP traffic is sent and received
> through the LLC sublayer as specified in [...]".  The layered stacks
> depicted in the "Architecture" document P1609.0 [ieeep1609.0-D2]
> suggest that WSMP messages may not be transmitted as payload of IPv6
> datagrams; WSMP and IPv6 are parallel (not stacked) layers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 13:49:27 +0100

OCB term expansion

Hello IPWAVErs,

A comment was made about the definition of the term OCB.

I suggest the following.

old:
> OCB: Outside the Context of a Basic Service Set identifier.
> OCB - Outside the Context of a Basic-Service Set ID (BSSID).

new:
> OCB - Outside the Context of a Basic-Service Set ID.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 3 Feb 2017 14:04:08 +0100

Dear Alex,

Actually both old and new are not correct (sorry for not having seen that earlier). 

>From IEEE 802.11-2016, this is the 'real' definition (from the very long table of definitions and acronyms):

--

OCB -  outside the context of a BSS

--

There is no ID, no Identifier…It simply means outside of a BSS. 

So, I suggest to replace by:

new:

> OCB - Outside the Context of a Basic-Service Set.

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 03 February 2017 13:49
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 OCB term expansion

OCB term expansion

Hello IPWAVErs,

I suggest the following.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 13:55:52 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
encryption at MAC or above LLC?

Hello IPWAVErs,

A question was raised about whether encryption would take place at MAC 
layer or above the LLC layer (i.e. IP layer)?

My answer is that encryption should be performed at at least at the IP 
layer, namely IPsec and Encapsulated Security Payload (ESP) header.

The details about how the encryption is performed should be described in 
a different I-D.

But in the IPv6/OCB draft we can tell that "encryption MAY be performed 
at least in the IPsec layer (and potentially in the MAC layer as well)".

Alex

---

From: François Simon <[email-masked]>
Date: Fri, 3 Feb 2017 08:21:11 -0500

While IETF may want to change the definition of OCB, keep in mind the proposed " OCB - Outside the Context of a Basic-Service Set ID." Would NOT be in line with IEEE 802.11 standard where OCB is defined as: "
outside the context of a basic service set (BSS) (OCB): A mode of operation in which a STA is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality
services."

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday, February 03, 2017 7:49 AM
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 OCB term expansion

Hello IPWAVErs,

I suggest the following.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 14:41:45 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
IP channel prohibition by 1609 (and not by .11)

Hello IPWAVErs,

A comment was made suggesting that the 802.11-OCB standard does not
prohibit IP on any channel and, if there is such prohibition, it is
certainly mandated by 1609 documents instead.  It was also commented
that this prohibition is out of the scope of this Internet Draft.

As such, I suggest to remove the following old text:
> o	Explicit prohibition of IPv6 on some channels relevant for the PHY
> of IEEE 802.11p, as opposed to IPv6 not being prohibited on any
> channel on which 802.11a/b/g/n runs; for example, IPv6 is
> prohibited on the 'Control Channel' (number 178 at FCC/IEEE, and
> 180 at ETSI); for a detailed analysis of IEEE and ETSI prohibition
> of IP in particular channels see Appendix B.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 3 Feb 2017 14:50:57 +0100

Hello Alex,

I agree with you. Encryption can only be done at L3 and above in our case, as OCB disconnects any security mechanisms at the MAC layer and it is possible for IETF to make changes to a lower layer. 

And I would more generally tend to think that encryption should be 'end-2-end', so at a service/application layer (e.g. IoT applications)... MAC headers will be sent in clear, and the question would be: what would we need to transmit at the L3 layer, which would not be coming from a higher layer (thus L3 headers), and which would need to be encrypted? 

Nevertheless, we should leave the possibility to encrypt at L3 (as you suggest), although I have the feeling that encryption will actually be done at an application level.

Best Regards,

Jérôme 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 03 February 2017 13:56
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 encryption at MAC or above LLC?

Hello IPWAVErs,

A question was raised about whether encryption would take place at MAC layer or above the LLC layer (i.e. IP layer)?

My answer is that encryption should be performed at at least at the IP layer, namely IPsec and Encapsulated Security Payload (ESP) header.

The details about how the encryption is performed should be described in a different I-D.

But in the IPv6/OCB draft we can tell that "encryption MAY be performed at least in the IPsec layer (and potentially in the MAC layer as well)".

Alex

---

From: William Whyte <[email-masked]>
Date: Fri, 3 Feb 2017 08:51:44 -0500

Is this an area where IP over WAVE would differ from any other form of
IP? I worry that if we start listing things that MAY happen, we start
to imply that things we leave out of the list aren't allowed even if
they were just forgotten.

It might be better to say "Any security mechanism at the IP layer or
above that may be carried out for the general case of IPv6 may also be
carried out for IPWAVE".

Cheers,

William

On Fri, Feb 3, 2017 at 7:55 AM, Alexandre Petrescu
<[email-masked]> wrote:
> But in the IPv6/OCB draft we can tell that "encryption MAY be performed at
> least in the IPsec layer (and potentially in the MAC layer as well)".
>
> Alex
>
>

---

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 3 Feb 2017 14:55:58 +0100

Hi Alex,
You may also want to consider what is the objective of this future rfc.
IEEE 1609, as well as ETSI TC ITS standards, introduce (mandatory)
guidelines on using the 802.11-OCB. These cannot be ignored, or you are
drafting a specification that may not be usable in the field.
I would suggest to keep these considerations in an annex at least.

Best, Michelle

-- 
Michelle Wetterwald
[email-masked]

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 3 Feb 2017 15:19:54 +0100

Hi Alex,

Correct, and same for ETSI. So, in theory, we are not bound by these 'restrictions'. But as Michelle just said, it is not that simple, as accessing a particular ITS channel (US or EU) has usually some specific restrictions, irrespectively if you use WAVE/ISO/ETSI ITS stack or no stack at all. 

A typical example for ETSI is that if we use ITS-G5 (IEEE 802.11-OCB in EU) in Europe, then it needs to implement a DCC mechanism according to the ETSI Harmonized Standard 'EN 302 571'. So, even if we are not bound to have a DCC when we use IPv6-over-OCB, but if we want to access the ITS-G5 bands, we will need to have one, and this, irrespectively if we use the ETSI ITS stack or not. 

Another aspect I just saw by reading through the harmonized standard, is that EN 302 571 restricts the frame size of any ITS-G5 device to 1500 bytes (even if a MAC frame cam be bigger). So, again, even if we can get bigger frames, if we want to use the ITS-G5 spectrum, we need to comply to this. 

I yet did not find any restrictions to IPv6 on this harmonized standard..I will further dig into this to see where precisely this restriction if made at ETSI and if it applies to the spectrum/channel or to the Stack......

You are yet bringing a very good point to the discussions: we need to have a list of the requirements for any ITS-G5/DSRC device to access the ITS bands (UE/EU) and see how we can cope with  them...I can take care of this, if you want.

As for now, I would suggest to replace the current text (too complicated and only restricted to WAVE) with a short sentence such as:

"Transmissions of IPv6 packets on ITS spectrum SHALL comply with the national spectrum regulations, which MAY lead to restrictions on IP operations using IEEE 802.11-2016 in OCB mode."

Best Regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 03 February 2017 14:42
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 IP channel prohibition by 1609 (and not by .11)

Hello IPWAVErs,

A comment was made suggesting that the 802.11-OCB standard does not prohibit IP on any channel and, if there is such prohibition, it is certainly mandated by 1609 documents instead.  It was also commented that this prohibition is out of the scope of this Internet Draft.

As such, I suggest to remove the following old text:
> channel on which 802.11a/b/g/n runs; for example, IPv6 is prohibited 
> on the 'Control Channel' (number 178 at FCC/IEEE, and
> 180 at ETSI); for a detailed analysis of IEEE and ETSI prohibition of 
> IP in particular channels see Appendix B.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 15:38:24 +0100

We are closing this issue: there are no 802.11 Beacon messages in OCB mode.

> o     No 802.11 Beacon messages transmitted
 > [...]

Alex

---

From: François Simon <[email-masked]>
Date: Fri, 3 Feb 2017 10:12:55 -0500

While LLC standard is out of scope for 802.11 is concerned, it is still
mentioned. Two LLC types: 

- LLC Protocol Discrimination (LPD) - IEEE Std 802-2014 - ISO/IEC
8802-2:1998
- EPD EtherType Protocol Discrimination (EPD) - IEEE Std 802-2014 - IEEE Std
802.3-2012

EPD is used for 5.9 GHz Band

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, February 02, 2017 12:57 PM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 use of term
"802.2 LLC"

On Feb 2, 2017, at 12:09 PM, Alexandre Petrescu
<[email-masked]> wrote:

> because in the next version of the IEEE 802.11 standard the LLC will 
> no longer be based on IEEE 802.2.
> 

I think that talking about Ethernet is causing confusion.  Perhaps it would
be more straightforward to say that SNAP [RFC1042] is used to carry the IPv6
Ethertype.

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Feb 2017 17:36:19 +0100

> - LLC Protocol Discrimination (LPD) - IEEE Std 802-2014 - ISO/IEC

Ok, it is good to know.

But is it about the future or about the present? (I have not seen "EPD" 
myself, yet I have seen "LLC" used in IPv6 packets transmitted on 802.11 
in OCB mode).

The text to be put in IPv6/OCB saying LLC or EPD or SNAP depends on that 
tense.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 03 Feb 2017 08:37:09 -0800

Jerome,

Right.

Scope. Encryption at layer 2 limits the scope to the network segment.
 Like the rest of the header, encryption has to be removed before
router. Similarly, L3 (and L4/L5) encryption has to be removed before
the data reaches the end system (usually in the TCP socket).  Thus the
data has no protection within the end system.  L6/7 (aka end-to-end)
can provide protection in the end system.  
     
Requirement. Further, in this set of applications, authenticity is more
important than confidentiality.  Encryption (at least using public key)
provides no authenticity.  

I think the interoperability requirements will make encryption at any
layer below 6 to be very difficult to scale.  By the time you've gotten
everybody who needs the keys properly endowed, you've gotten keys into
the hands of those you didn't want.

b

On Fri, 2017-02-03 at 14:50 +0100, Jérôme Härri wrote:
> Hello Alex,
> 
> I agree with you. Encryption can only be done at L3 and above in our
> case, as OCB disconnects any security mechanisms at the MAC layer and
> it is possible for IETF to make changes to a lower layer. 
> 
> And I would more generally tend to think that encryption should be
> 'end-2-end', so at a service/application layer (e.g. IoT
> applications)... MAC headers will be sent in clear, and the question
> would be: what would we need to transmit at the L3 layer, which would
> not be coming from a higher layer (thus L3 headers), and which would
> need to be encrypted? 
> 
> Nevertheless, we should leave the possibility to encrypt at L3 (as
> you suggest), although I have the feeling that encryption will
> actually be done at an application level.
> 
> Best Regards,
> 
> Jérôme 
> 
> A question was raised about whether encryption would take place at
> MAC layer or above the LLC layer (i.e. IP layer)?
> 
> My answer is that encryption should be performed at at least at the
> IP layer, namely IPsec and Encapsulated Security Payload (ESP)
> header.
> 
> But in the IPv6/OCB draft we can tell that "encryption MAY be
> performed at least in the IPsec layer (and potentially in the MAC
> layer as well)".
> 
> Alex
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:02:43 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
FYI quarter-, half- and full-rate comments

Hello IPWAVErs,

We received an FYI commenting the quarter-, half- and full- data
rates of 802.11 OFDM.

[...]
> o 'half-rate' encoding
[...]
> o  It is worth mentioning that more precise interpretations of the
> 'half-rate' term suggest that a maximum throughput be 27Mbit/s (which
> is half of 802.11g's 54Mbit/s), whereas 6Mbit/s or 12Mbit/s
> throughputs represent effects of further 802.11p-specific PHY
> reductions in the throughput necessary to better accommodate
> vehicle-class speeds and distance ranges.

I will replace the above bullet points with this new text:
> o 'quarter-rate' encoding: whereas 802.11 affords multiple
> combinations of distinct x-rate encodings, widths of spacing between
>  channels and modulation techniques, the 802.11 operating outside the
>  context of a Basic Service Set for Intelligent Transport Systems
> (ITS) mobile and non-mobile operations informally promotes the use of
> quarter-rate, 5 MHz channel spacing, modulation '64 QAM' with r ==
> 3/4, leading to a maximum data rate of 13.5 Mbit/s.  See details in
> section "x-rate encodings for 802.11".

The new appendix section titled "x-rate encoding for 802.11":
> Quick summary of 802.11 OFDM data rates:
>
> o	Half-rate (10 MHz channel spacing) maximum data rate is 27 Mb/s –
> Modulation 64-QAM; r == 3/4;
>
> o	Half-rate minimum data rate is 3 Mb/s – Modulation BPSK; r == 1/2 –
>  Note this is a default and is mandatory by ALL 802.11 STAs.
>
> o	Full-rate (20 MHz channel spacing) the maximum data rate is 54
> Mb/s; 64-QAM; r == 3/4;
>
> o	Full-rate minimum data rate is 6 Mb/s – Modulation BPSK; r == 1/2;
>
> o	Quarter-rate (5 MHz channel spacing) maximum data rate is 13.5 Mb/s
> – Modulation 64-QAM;   r == 3/4;
>
> o	Quarter-rate minimum data rate is 1.5 Mb/s – Modulation BPSK; r ==
>  1/2.
>
> Note: Per IEEE 802.11, the operating class 16 (5 MHz channel spacing)
> is defined for ITS_nonmobile_operations, ITS_mobile_operations.
>
> o  'Half-rate' encoding: as the frequency range, this parameter is
> related to PHY, and thus has not much impact on the interface between
> the IP layer and the MAC layer.  The standard IEEE 802.11p uses OFDM
> encoding at PHY, as other non-b 802.11 variants do. This considers
> 20MHz encoding to be 'full-rate' encoding, as the earlier 20MHz
> encoding which is used extensively by 802.11b. In addition to the
> full-rate encoding, the OFDM rates also involve 5MHz and 10MHz. The
> 10MHz encoding is named 'half-rate'.  The encoding dictates the
> bandwidth and latency characteristics that can be afforded by the
> higher-layer applications of IP communications.  The half-rate means
>  that each symbol takes twice the time to be transmitted; for this to
>  work, all 802.11 software timer values are doubled.  With this, in
> certain channels of the "5.9GHz" band, a maximum bandwidth of
> 12Mbit/s is possible, whereas in other "5.9GHz" channels a minimal
> bandwidth of 1Mbit/s may be used.  It is worth mentioning the
> half-rate encoding is an optional feature characteristic of OFDM PHY
>  (compared to 802.11b's full-rate 20MHz), used by 802.11a before
> 802.11p used it.  In addition to the half-rate (10MHz) used by
> 802.11p in some channels, some other 802.11p channels may use
> full-rate (20MHz) or quarter-rate (5MHz) encoding instead.
>
> o  It is worth mentioning that more precise interpretations of the
> 'half-rate' term suggest that a maximum throughput be 27Mbit/s
> (which is half of 802.11g's 54Mbit/s), whereas 6Mbit/s or 12Mbit/s
> throughputs represent effects of further 802.11p-specific PHY
> reductions in the throughput necessary to better accommodate
> vehicle-class speeds and distance ranges.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:07:38 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
dynamic change of MAC addresses refs

Hello IPWAVErs,

We received a comment about the text describing the need for dynamically
changing the MAC addresses for privacy reasons.

The old text being commented is the following:
> o	In vehicular communications using 802.11p links, there are strong
> privacy concerns with respect to addressing.  While the 802.11p
> standard does not specify anything in particular with respect to MAC
> addresses, in these settings there exists a strong need for dynamic
> change of these addresses (as opposed to the non-vehicular settings -
> real wall protection - where fixed MAC addresses do not currently
> pose some privacy risks).  This is further described in section
> Section 8.

The new next is:
> [same] and in function addressed in IEEE 1609.3, clause 5.5.1 and
> IEEE 1609.4, clause 6.7.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:34:13 +0100

RSU term

Hello IPWAVErs,

We received multiple comments about the RSU term.  The strongest issue
is that apparently there are conflicts between our assumption of RSU to
be a router and FHWA(?) thinking RSU is more like an interface to a
router, or something like a master-RSU controlling (slave?) RSUs.
Unless FHWA tells us they agree RSU is a router, I will modify the
following:

Old:
> 2.  Terminology
[...]
> RSU: Road Side Unit.

New:
> RSR: Road Side Router; an IP router equipped with, or connected to,
> at least one interface that is 802.11 and that is an interface that
> operates in OCB mode.

and substitute RSR for RSU throughout.

This old 'RSU' term, now RSR, is absolutely needed in the draft when
discussing IP handovers and Mobile IP.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:40:08 +0100

WRA suggestion removal

Hello IPWAVErs,

We received a warning about the draft suggesting the use of WRA (WAVE
Router Advertisement - an IEEE message termed like, but different than,
the IP Router Advertisement).  It is said that this suggestion may not
be acceptable by IEEE, and as such may be out of scope in this I-D.

I will remove this old text in the Handovers section.

old:
> Another alternative replacement for the IPv6 Router Advertisement
> may be the message 'WAVE Routing Advertisement' (WRA), which is
> part of the WAVE Service Advertisement and which may contain
> optionally the transmitter location; this message is described in
> section 8.2.5 of [ieeep1609.3-D9-2010].

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:48:14 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
wireshark dissectors (not) free for 802.11p and IEEE WAVE messages

Hello IPWAVErs,

We received a warning about the statement qualifying wireshark being
free [of charge].  I propose to remove the following text:

old:
> The popular wireshark network protocol analyzer is a free software
> tool for Windows and Unix.  It includes a dissector for 802.11p
> features along with all other 802.11 features (i.e. it displays these
> features in a human-readable format).

As a side note, I suggest to ones interested in reading 802.11-OCB
captures to still consider the widely available and popular wireshark
tool, and the freely available dissectors for 802.11-OCB aka 802.11p.
The added-value that may be charged for some enhanced wireshark may lie
in other dissectors like IEEE WAVE messages, or some other traffic
analysis features, but not in the dissection of basic 802.11-OCB fields
described in this draft.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:52:32 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
Security of WSMP and WSA is FYI only

Hello IPWAVErs,

We received a comment suggesting that our mentioning of IEEE WSMP and
WSA being secure should be FYI only (i.e. not req on IEEE, nor a
statement about IEEE mechanism).  As such I remove the following paragraph:

old:
> The WAVE protocol stack provides for strong security when using the
> WAVE Short Message Protocol and the WAVE Service Advertisement
> [ieeep1609.2-D17].

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 11:59:16 +0100

second guessing FCC

Hello IPWAVErs,

There was a comment clarifying the interpretation of FCC-related text,
and advising against and undesirable but otherwise relatively common
practice of 'second guessing' the Commision's oppinion by implementers.

As such, I will remove the following text:

old:
> o  The FCC created two more terms for particular channels
> fcc-cc-172-184], among others.  The channel 172 (5855MHz to 5865MHz))
> is designated "exclusively for [V2V] safety communications for
> accident avoidance and mitigation, and safety of life and property
> applications", and the channel 184 (5915MHz to 5925MHz) is designated
> "exclusively for high-power, longer- distance communications to be
> used for public-safety applications involving safety of life and
> property, including road-intersection collision mitigation".
> However, they are not named "control" channels, and the document does
> not mention any particular restriction on the use of IP on either of
> these channels.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 12:05:01 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
no IPv6 prohibition on the control channel

Hello IPWAVErs,

We received a comment stating that LCC/OBE does not prohibit the use of
IPv6 on the control channel.  (I do not understand what the commenter
meant meant by "LCC" - typo for FCC, LLC? or Lower Control Channel? but
that's another issue).

As such I will remove the following text:
> On another hand, at IEEE, IPv6 is explicitely prohibited on channel
> number 178 decimal - the FCC's 'Control Channel'.  The document
> [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6 traffic on
> the Control Channel: 'data frames containing IP datagrams are only
> allowed on service channels'.  Other 'Service Channels' are allowed
> to use IP, but the Control Channel is not.

There are many other reasons for removing that text that we discussed
here extensively.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 12:13:22 +0100

draft-ietf-ipwave-ipv6-over-80211ocb-00
absence of addressing the multi-channel service of 802.11 OCB

Hello IPWAVErs,

We received a comment stating that this document does not really address
the multi-channel service that 802.11 OCB is capable of providing.

I agree with the comment.

I have not seen other IPv6-over-foo documents addressing channel issues.

There is no IPv6-over-WiFi RFC, which could address them.

In vehicular networks implementations there is often a careful planning
of channel allocation to avoid interference.  Dynamic channel use
schemes exist.

Yours,

Alex

---

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 10 Feb 2017 12:18:54 +0100

Hi Alex,

Actually, an RSU is generally more than an RSR as it is an ITS station per
se and may contain upper (e.g. service or even application) layers.
I suggest to keep the definition of RSU in the text, as it is a widely used
term, but clarify that an RSR could be one of the components of an RSU.

Best regards,
Michelle

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 12:18:58 +0100

Dears,

I am told in private that some packet dumps for 802.11 OCB could be 
found where trials were conducted in US, on this US FHWA RDE site:

https://www.its-rde.net/

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 12:37:04 +0100

Hi Michelle,

Thank you for the suggestion.

But making RSR a component of RSU is different than making RSU a
component of RSR, right?

Despite the widespread belief that RSU would have something to do with
IP and Internet, rarely if ever was there an RSU connected to Internet
that forwarded IP packets - most RSUs are disconnected from the Internet
(the supposedly 'slaves' at FHWA) and the ones that are connected to the
Internet (supposedly the 'masters' at FHWA) are so only in order to be
SNMP-managed remotely, but not to forward.

If we know of some RSU which has this 'forwarding' flag set to 1, then
we should talk about it, and call it a Router.

The "ITS station" term is not a term at IETF.  We could re-use the term
"ITS station", but I would like to know whether "ITS Station" is a
Router or a Host?

Yours,

Alex

Le 10/02/2017 à 12:18, Michelle Wetterwald a écrit :
> Hi Alex,
>
> Actually, an RSU is generally more than an RSR as it is an ITS
> station per se and may contain upper (e.g. service or even
> application) layers. I suggest to keep the definition of RSU in the
> text, as it is a widely used term, but clarify that an RSR could be
> one of the components of an RSU.
>
> Best regards, Michelle
>
> 2017-02-10 11:34 GMT+01:00 Alexandre Petrescu
> <[email-masked]
> <mailto:[email-masked]>>:
>
> draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
>
> Hello IPWAVErs,
>
> We received multiple comments about the RSU term.  The strongest
> issue is that apparently there are conflicts between our assumption
> of RSU to be a router and FHWA(?) thinking RSU is more like an
> interface to a router, or something like a master-RSU controlling
> (slave?) RSUs. Unless FHWA tells us they agree RSU is a router, I
> will modify the following:
>
> Old:
>
> 2.  Terminology
>
> [...]
>
> RSU: Road Side Unit.
>
>
> New:
>
> _______________________________________________ its mailing list
> <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> -- Michelle Wetterwald [email-masked]
> <mailto:[email-masked]>

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 10 Feb 2017 11:39:18 +0000

Hi Alex,

FYI..

Wireshark is an open source software project, and is released under the GNU
General Public License <https://www.gnu.org/licenses/gpl-2.0.html> (GPL).
You can freely use Wireshark on any number of computers you like, without
worrying about license keys or fees or such. In addition, all source code
is freely available under the GPL. Because of that, it is very easy for
people to add new protocols to Wireshark, either as plugins, or built into
the source, and they often do!

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 10 Feb 2017 12:49:35 +0100

Hi Alex,

It could actually be two different terms, depending of what we want to say in the draft. The RSU is no longer a pure C-ITS name, as even LTE-V2X adopted the LTE-UE operating in RSU mode for LTE-V2V communications (meaning you do not need to be a eNB/base station to be a RSU). 
I would tend to think that the RSU is more a function/service than an actual technology...but as I think the debate could be complex and suggest to follow Michelle suggestion to keep the RSU as a 'bigger' entity, and if you need it, a RSR as a potential sub-set of a RSU. As Michelle said, a RSU is not a router  by default...

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:37
To: Michelle Wetterwald
Cc: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Hi Michelle,

But making RSR a component of RSU is different than making RSU a component of RSR, right?

Despite the widespread belief that RSU would have something to do with IP and Internet, rarely if ever was there an RSU connected to Internet that forwarded IP packets - most RSUs are disconnected from the Internet (the supposedly 'slaves' at FHWA) and the ones that are connected to the Internet (supposedly the 'masters' at FHWA) are so only in order to be SNMP-managed remotely, but not to forward.

If we know of some RSU which has this 'forwarding' flag set to 1, then we should talk about it, and call it a Router.

The "ITS station" term is not a term at IETF.  We could re-use the term "ITS station", but I would like to know whether "ITS Station" is a Router or a Host?

Yours,

Alex

Le 10/02/2017 à 12:18, Michelle Wetterwald a écrit :
> Hi Alex,
>
> Actually, an RSU is generally more than an RSR as it is an ITS station 
> per se and may contain upper (e.g. service or even
> is that apparently there are conflicts between our assumption of RSU 
> to be a router and FHWA(?) thinking RSU is more like an interface to a 
> router, or something like a master-RSU controlling
> (slave?) RSUs. Unless FHWA tells us they agree RSU is a router, I will 
> modify the following:
>
> Old:
>
> 2.  Terminology
>
> [...]
>
> RSU: Road Side Unit.
>
>
> New:
>
> RSR: Road Side Router; an IP router equipped with, or connected to, at 
> least one interface that is 802.11 and that is an interface that 
> operates in OCB mode.
>
>

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 10 Feb 2017 12:53:29 +0100

Hello Alex,

What do you mean with multi-channel? OCB does not provide any multi-channel
service. Higher-layer services do (IEEE WAVE or ETSI)...OCB only assume that
the frequency to be used is 'known', so using OCB actually means knowing a
set of channels where to send OCB-related packets...I am not sure if this
could be called a multi-channel service...

However, we should mention that IPv6 would intend to offer such a
service...if this is what you meant, I agree with you.

Best Regards.

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:13
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of
addressing the multi-channel service of 802.11 OCB

Hello IPWAVErs,

We received a comment stating that this document does not really address the
multi-channel service that 802.11 OCB is capable of providing.

In vehicular networks implementations there is often a careful planning of
channel allocation to avoid interference.  Dynamic channel use schemes
exist.

Yours,

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 10 Feb 2017 13:00:43 +0100

Hello Alex,

As discussed, there is a strick prohibition from ETSI and IEEE WAVE. But, as
this work will not use it, we do not need to comply with it. We only need to
comply with national spectrum regulations...whatever is in there...

I would however suggest to add the following statement:
"Transmissions of IPv6 packets on ITS spectrum SHALL comply with the
national spectrum regulations, which MAY lead to restrictions on IP
operations using IEEE 802.11-2016 in OCB mode."

I think this leaves flexibility for this WG to propose solutions..

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:05
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 no IPv6
prohibition on the control channel

Hello IPWAVErs,

We received a comment stating that LCC/OBE does not prohibit the use of
IPv6 on the control channel.  (I do not understand what the commenter meant
meant by "LCC" - typo for FCC, LLC? or Lower Control Channel? but that's
another issue).

As such I will remove the following text:
> [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6 traffic on the 
> Control Channel: 'data frames containing IP datagrams are only allowed 
> on service channels'.  Other 'Service Channels' are allowed to use IP, 
> but the Control Channel is not.

There are many other reasons for removing that text that we discussed here
extensively.

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 10 Feb 2017 13:07:26 +0100

Hello Alex,

Agree..this is not the place to make such statement. However, I think if you
add my previously suggested statement, it would be enough to imply that some
'channels' might be restricted to some functions in some countries, but
without being specific...maybe we could add an normative reference to the
FCC and the ECC, leaving room for interpretation..

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 11:59
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 second guessing
FCC

Hello IPWAVErs,

There was a comment clarifying the interpretation of FCC-related text, and
advising against and undesirable but otherwise relatively common practice of
'second guessing' the Commision's oppinion by implementers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 13:38:31 +0100

Le 10/02/2017 à 13:00, Jérôme Härri a écrit :
> Hello Alex,
>
> As discussed, there is a strick prohibition from ETSI and IEEE WAVE.
> But, as this work will not use it, we do not need to comply with it.
> We only need to comply with national spectrum regulations...whatever
> is in there...
>

Jérôme,

I agree with the first part, that I can add.

The national spectrum regulation in the country where I live does not
lead to restrictions on IP operations using 802.11 in OCB mode.

So I could say:
> national spectrum regulations, which MAY NOT lead to restrictions on
> IP operations using IEEE 802.11-2016 in OCB mode."

Alex

> Behalf Of Alexandre Petrescu Sent: Friday 10 February 2017 12:05 To:
> [email-masked] Subject: [ipwave]
> draft-ietf-ipwave-ipv6-over-80211ocb-00 no IPv6 prohibition on the
> control channel
>
> draft-ietf-ipwave-ipv6-over-80211ocb-00 no IPv6 prohibition on the
> control channel
>
> Hello IPWAVErs,
>
> We received a comment stating that LCC/OBE does not prohibit the use
> of IPv6 on the control channel.  (I do not understand what the
> commenter meant meant by "LCC" - typo for FCC, LLC? or Lower Control
> Channel? but that's another issue).
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Feb 2017 13:50:46 +0100

Hi Jérôme,

The problem with this RSU term is that we dont have a formal definition
of it, agreed across ETSI, FHWA, ISO and so many others.  Everyone uses
it in the way they need for their purposes.  So there will always be
someone to disagree with the IPv6/p Internet Draft believes an RSU to be.

Le 10/02/2017 à 12:49, Jérôme Härri a écrit :
> Hi Alex,
>
> It could actually be two different terms, depending of what we want
> to say in the draft.

In the draft the term RSU was used extensively in the IP handover
discussing involving Mobile IP.  In that discussion RSU is a Router, and
a default router at the same time.

> The RSU is no longer a pure C-ITS name, as even LTE-V2X adopted the
> LTE-UE operating in RSU mode for LTE-V2V communications (meaning you
>  do not need to be a eNB/base station to be a RSU). I would tend to
> think that the RSU is more a function/service than an actual
> technology...but as I think the debate could be complex and suggest
> to follow Michelle suggestion to keep the RSU as a 'bigger' entity,
> and if you need it, a RSR as a potential sub-set of a RSU.

I could indeed see the RSU as a bigger entity.  Something like a big box
near the road, which contains smaller boxes (Hosts, Routers)
interconnected by Ethernet.  Some manufacturers call it that way.

However, this would not solve the problem of FHWA understanding RSU to
be only a hardware interface of such a router.

> As Michelle said, a RSU is not a router by default...

I agree, RSU at ETSI is something that is not necessarily a Router.

But an RSU for the IP handover discussion in IPv6/p Internet Draft _is_
a router.  That makes it a conflict with ETSI too.

And, an RSU in the IP handover discussion _is_ a default router for a
vehicle sending IP packets through it.

We could also call it an "RSU2" for "RSU second generation" and state
that it is a Router, and a default router for vehicles.

Alex

> On Behalf Of Alexandre Petrescu Sent: Friday 10 February 2017 12:37
> To: Michelle Wetterwald Cc: [email-masked] Subject: Re: [ipwave]
> Despite the widespread belief that RSU would have something to do
> with IP and Internet, rarely if ever was there an RSU connected to
> Internet that forwarded IP packets - most RSUs are disconnected from
> the Internet (the supposedly 'slaves' at FHWA) and the ones that are
> connected to the Internet (supposedly the 'masters' at FHWA) are so
> only in order to be SNMP-managed remotely, but not to forward.
>
> If we know of some RSU which has this 'forwarding' flag set to 1,
> then we should talk about it, and call it a Router.
>
> The "ITS station" term is not a term at IETF.  We could re-use the
> term "ITS station", but I would like to know whether "ITS Station"
> is a Router or a Host?
>
> Yours,
>
> Alex
>
>> application) layers. I suggest to keep the definition of RSU in
>> the text, as it is a widely used term, but clarify that an RSR
>> could be one of the components of an RSU.
>>
>> Best regards, Michelle
>>
>> issue is that apparently there are conflicts between our
>> assumption of RSU to be a router and FHWA(?) thinking RSU is more
>> like an interface to a router, or something like a master-RSU
>> controlling (slave?) RSUs. Unless FHWA tells us they agree RSU is a
>> router, I will modify the following:
>>
>> Old:
>>
>> 2.  Terminology
>>
>> [...]
>>
>> RSU: Road Side Unit.
>>
>>
>> New:
>>
>> RSR: Road Side Router; an IP router equipped with, or connected
>> to, at least one interface that is 802.11 and that is an interface
>> that operates in OCB mode.
>>
>>
>> This old 'RSU' term, now RSR, is absolutely needed in the draft
>> when discussing IP handovers and Mobile IP.
>>
>> Alex
>>
>>
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>

---

From: Tony Li <[email-masked]>
Date: Fri, 10 Feb 2017 08:05:39 -0800

> On Feb 10, 2017, at 3:13 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

No RFC has ever been needed for IP over Wi-Fi since the Wi-Fi designers (correctly) concluded that the best course of action was to use Ethernet framing.

The channel selection for Wi-Fi has never been addressed since it has always functioned as a fixed constant out of the scope of interoperability and thus not requiring an RFC.

If someone is proposing a channel changing approach for 802.11 OCB, that would need to be written. Without a proposal on the table, channel selection is left to the management of the consenting stations involved.

Tony

p.s. I find it very disturbing that Alexandre is responding to comments that were apparently not distributed on the list. This is not an open discussion if the comments were not directed to the list.  This is not in keeping with the way that the IETF operates. Could the WG chairs please look into this?

---

From: William Whyte <[email-masked]>
Date: Fri, 10 Feb 2017 08:31:39 -0800

To be clear, WSMP has no inbuilt security. Higher layer entities that
use WSMP may send secured payloads but this is part of the application
specification, not provided by WSMP.

WSA is an example of such a higher layer entity; 1609.3 specifies
security mechanisms (from 1609.2) that are applied before sending the
WSA over WSMP. Note that whether or not to use the 1609.3 security
approach is up to individual deployments -- a private deployment, for
example, could conceivably decide to use different security or no
security, but the recommended approach is the one in 1609.3.

Cheers,

William

---

From: William Whyte <[email-masked]>
Date: Fri, 10 Feb 2017 08:32:39 -0800

Why wouldn't this be acceptable? It's a reference to a published
standard, it should be okay.

Cheers,

William

---

From: John Kenney <[email-masked]>
Date: Fri, 10 Feb 2017 09:13:44 -0800

FWIW, I find DSRC people don't often use this quarter-rate/half-rate
terminology. We just refer to the bandwidth of the channel in absolute
terms.  What is called half rate is a 10 MHz channel.   What is called
quarter rate is a 5 MHz channel.  Full rate is a 20 MHz channel.  I find it
less confusing to use 20/10/5 explicitly than full/half/quarter.  It also
makes sense give that 99% of the time we're only interested in the 10 MHz
case.

John

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 10 Feb 2017 10:52:40 -0800

Box <> function.

If you understand the fragility and warts in radionav systems (GPS,
Galileo, Glonass, Loran) then differential overlays to these systems
makes a lot of sense.  And the most attractive place to put the
differential reference receivers is in the roadside boxes.  The
reference receiver function is a sensor function, not a routing one.
But probably belongs in the same box.

On Fri, 2017-02-10 at 12:49 +0100, Jérôme Härri wrote:
> to say in the draft. The RSU is no longer a pure C-ITS name, as even
> LTE-V2X adopted the LTE-UE operating in RSU mode for LTE-V2V
> communications (meaning you do not need to be a eNB/base station to
> be a RSU). 
> I would tend to think that the RSU is more a function/service than an
> actual technology...but as I think the debate could be complex and
> suggest to follow Michelle suggestion to keep the RSU as a 'bigger'
> entity, and if you need it, a RSR as a potential sub-set of a RSU. As
> Michelle said, a RSU is not a router  by default...
> 
> BR,
> 
> Jérôme
> 
> term "ITS station", but I would like to know whether "ITS Station" is
> a Router or a Host?
> 
> Yours,
> 
> Alex
> 
> > station 
> > the 
> > issue 
> > at

---

From: François Simon <[email-masked]>
Date: Fri, 10 Feb 2017 22:37:22 -0500

Mr. Whyte,

If the last paragraph is indeed the new statement, then I agree with you.

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Friday, February 10, 2017 11:33 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 WRA suggestion
removal

Why wouldn't this be acceptable? It's a reference to a published standard,
it should be okay.

Cheers,

William

On Fri, Feb 10, 2017 at 2:40 AM, Alexandre Petrescu
<[email-masked]> wrote:
> Router Advertisement - an IEEE message termed like, but different 
> than, the IP Router Advertisement).  It is said that this suggestion 
> may not be acceptable by IEEE, and as such may be out of scope in this
I-D.
>> Another alternative replacement for the IPv6 Router Advertisement may 
>> be the message 'WAVE Routing Advertisement' (WRA), which is part of 
>> the WAVE Service Advertisement and which may contain optionally the 
>> transmitter location; this message is described in section 8.2.5 of 
>> [ieeep1609.3-D9-2010].
>
>
> Alex
>
>
>

---

From: William Whyte <[email-masked]>
Date: Sat, 11 Feb 2017 03:01:15 -0800

I wasn't that tired :-)

1609.3 section 6.2.4.2.1 specifies how a WSA can be protected with
1609.2 mechanisms. 1609.3 Annex H gives the 1609.2 security profile
for WSA. So I think it's accurate to say that 1609.3 specifies
security mechanisms, which are defined in 1609.2, to protect WSA.
1609.2 only mentions WSA twice, once in an example, once in an
informative annex. So I think "1609.3 specifies security mechanisms
(from 1609.2)" is an accurate way to say this, just as if WSAs were
sent over TLS, "1609.3 specifies security mechanisms (from TLS)" would
be accurate.

The reason why this matters is that it emphasizes that when you're
going over WSMP, it's up to the specification of the higher layer
entity (in this case, the WME) to specify the security; WSMP itself
doesn't provide any security, and 1609.2 is just a set of tools that
have to be explicitly referenced in the higher layer entity
specification.

Cheers,

William

On Fri, Feb 10, 2017 at 9:20 PM, Dick Roy <[email-masked]> wrote:
> William is a bit tired ... it was a long flight!  The security mechanisms
> are found in 1609.2, not 1609.3 :^))) Other than that, he is absolutely
> right as usual, if for no other reason than he was and still is the most
> significant contributor to this effort.
>
> Cheers,
>
> RR
>
> From: William Whyte [mailto:[email-masked]]
> Sent: Friday, February 10, 2017 8:32 AM
> To: Alexandre Petrescu
> Cc: [email-masked]
> Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 Security of
> WSMP and WSA is FYI only
>

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 11 Feb 2017 14:18:06 +0100

Dear François,

Totally agree. But this is neither DSRC nor 802.11 OCB. This is the IEEE
WAVE stack IEEE 1609.4, which as far as I understand this IETF WG does not
assume to use (and neither the ETSI ITS stack). 

But actually, It is very simple to use different channels using OCB. As
there is no BSS (or IBSS), you can change channel simply by indicating to
the OCB a new channel...as there is no further process required to transmit
on the new channel. 

Yet, the challenge is to be sure that the 'receivers' are also on the
'other' channel, as otherwise, we will transmit and nobody will be there to
receive. That was the objective of the work done in IEEE 1609.4. But such
coordination can also be done purely on an IP(v6) stack, as both Tx and Rx
could be notified on the right channel to get the right message...
A simple indication to OCB on which channel to move would be enough. Even a
multi-channel monitoring can be done using IP(v6) stack, where a
higher-layer service would ask OCB to periodically switch between channel
and monitor  'something'. 

Well, long story short, I do not think multi-channel 'operation' should be
part of this draft. But we could describe how IPv6 can 'request' a channel
switch to OCB. That could indeed be worth mentioning this explicitly. 

BR,

Jérôme

-----Original Message-----
From: François Simon [mailto:[email-masked]] 
Sent: Friday 10 February 2017 21:04
To: 'Jérôme Härri'
Cc: 'Alexandre Petrescu'; [email-masked]
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Multi-channel means that a single device is capable of maintaining multiple
"conversations" quasi-simultaneously.  In the US, the MAC extension (IEEE
1609.4) allows you to support multiple channels under the control of CCH (Ch
178) - TDM.  The problem with this, is you limit your actual overall
transmission rate.  The accepted practice in the US,  is that one radio is
dedicated to a permanent channel to get the maximum data rate (e.g. CH 172)
and used for high-priority applications (i.e. Safety).  Another radio, for
lower priority applications, is allowed to switch channels.  In addition,
each channel can support up to four EDCA parameter sets.  Very "nifty" but
hell to maintain all the state machines!

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Friday, February 10, 2017 6:53 AM
To: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Hello Alex,

Best Regards.

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:13
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Hello IPWAVErs,

Yours,

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Sat, 11 Feb 2017 15:09:51 +0100

Hello Alex,

I do not fully understand your argument about your country not imposing
restriction and why you prefer MAY NOT. Your proposed new formulation gives
the impression that in most countries, IPv6 is restricted...which is not the
case actually. My formulation was the opposite, claiming that in general
there is no restriction, but in some cases, maybe. I still think 'MAY'
should remain, as it would not pose any problem in the country where you
leave.

BR,

Jérôme

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday 10 February 2017 13:39
To: Jérôme Härri; [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 no IPv6

Jérôme,

The national spectrum regulation in the country where I live does not lead
to restrictions on IP operations using 802.11 in OCB mode.

Alex

---

From: William Whyte <[email-masked]>
Date: Sat, 11 Feb 2017 06:26:34 -0800

MAY NOT is also bad standards language -- it's not clear whether it
means MIGHT NOT, which is the same as MAY, or SHALL NOT. I prefer MAY
in this case.

William

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:12:34 +0100

If IP handovers are to rely on the presence of this WRA, then it would 
become a strong requirement on P1609.

This would mean that this WRA message would need - also - to be widely 
available, with open source implementations, for free, as the IP 
handover implementations are available.

Second, this IPv6/OCB document would hardly be a place to set 
requirements on other SDOs, such as IEEE.

In my view, it is not sure IEEE can make the WRA message mandatory, and 
widely available.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:44:31 +0100

Hello Jérôme,

Le 11/02/2017 à 15:09, Jérôme Härri a écrit :
> Hello Alex,
>
> I do not fully understand your argument about your country not
> imposing restriction

Because I have not seen such restriction forbidding IP, in the ARCEP
regulatory body controlling the use of 5.9GHz band.

> and why you prefer MAY NOT.

I agree.  When adding a NOT it looses your intention, and mine too.

> Your proposed new formulation gives the impression that in most
> countries, IPv6 is restricted...which is not the case actually. My
> formulation was the opposite, claiming that in general there is no
> restriction, but in some cases, maybe. I still think 'MAY' should
> remain, as it would not pose any problem in the country where you
> leave.

I think your formulation makes think there may be countries where the
regulator authority forbids IP on some 5.9GHz channel.

Do we know an example country where the frequency regulation authority
(e.g. that country's FCC) forbids the use of IP on some 5.9GHz channel?

Until now all we see is IEEE P1609 making such restriction.

Alex
>
>
> BR,
>
> Jérôme
>
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: Friday 10 February 2017
> 13:39 To: Jérôme Härri; [email-masked] Subject: Re: [ipwave]
>> As discussed, there is a strick prohibition from ETSI and IEEE
>> WAVE. But, as this work will not use it, we do not need to comply
>> with it. We only need to comply with national spectrum
>> regulations...whatever is in there...
>>
>> "Transmissions of IPv6 packets on ITS spectrum SHALL comply with
>> the national spectrum regulations, which MAY lead to restrictions
>> on IP operations using IEEE 802.11-2016 in OCB mode."
>
> Jérôme,
>
> The national spectrum regulation in the country where I live does
> not lead to restrictions on IP operations using 802.11 in OCB mode.
>
> So I could say:
>> "Transmissions of IPv6 packets on ITS spectrum SHALL comply with
>> the national spectrum regulations, which MAY NOT lead to
>> restrictions on IP operations using IEEE 802.11-2016 in OCB mode."
>
> Alex
>
>>
>> On Behalf Of Alexandre Petrescu Sent: Friday 10 February 2017
>> 12:05 To: [email-masked] Subject: [ipwave]
>> We received a comment stating that LCC/OBE does not prohibit the
>> use of IPv6 on the control channel.  (I do not understand what the
>> commenter meant meant by "LCC" - typo for FCC, LLC? or Lower
>> Control Channel? but that's another issue).
>>
>>> On another hand, at IEEE, IPv6 is explicitely prohibited on
>>> channel number 178 decimal - the FCC's 'Control Channel'.  The
>>> document [ieeep1609.4-D9-2010] prohibits upfront the use of IPv6
>>> traffic on the Control Channel: 'data frames containing IP
>>> datagrams are only allowed on service channels'.  Other 'Service
>>> Channels' are allowed to use IP, but the Control Channel is not.
>>
>> There are many other reasons for removing that text that we
>> discussed here extensively.
>>
>> Alex
>>
>>
>>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:44:41 +0100

Le 11/02/2017 à 06:28, Dick Roy a écrit :
> I agree with William (as usual :^)). And if you get the text right,
> it should be even "more acceptable".  First the WRA is NOT a
> message, it's a field in the WSA.

Noted.

> IEEE 1609 vetted the contents of the field with IETF people to make
> sure the contents met its requirements ... they did! It is NOT a
> replacement for the IPv6 router advertisement management message;

But it looks like one.

> it is a means to provide sufficient information to a receiver so that
> an IPv6 packet can be formed that will reach its destination with no
> further network layer exchanges between the receiver and the ITS-S
> access router at the roadside.

But that's what an RA is doing too.  An IP Router Advertisement message
provides enough information to a receiver to form an IP address and
communicate with a default router.

I am pretty much sure the two messages (WSA-with-WRA field, and RA) are
redundant.

Moreover, some other important information is absent from both
(timestamps and other).

At least one of them (not both) is very much needed for IP handover
realisation in OCB mode.

> This is really important (and cool) stuff.  Why you wouldn't include
> it is beyond me.

In an IETF document one wouldn't require the presence of a non-IP
message.  It would be a requirement for other SDO.

And it is beyond me :-) why would IETF require an WSA-with-field-WRA
when an IP RA does the same and is widely available too.

Alex

>
> Cheers,
>
> RR
>
> -----Original Message----- From: William Whyte
> [mailto:[email-masked]] Sent: Friday, February 10,
> 2017 8:33 AM To: Alexandre Petrescu Cc: [email-masked] Subject: Re:
> [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 WRA suggestion
> removal
>
>> draft-ietf-ipwave-ipv6-over-80211ocb-00 WRA suggestion removal
>>
>> Hello IPWAVErs,
>>
>> We received a warning about the draft suggesting the use of WRA
>> (WAVE Router Advertisement - an IEEE message termed like, but
>> different than, the IP Router Advertisement).  It is said that
>> this suggestion may not be acceptable by IEEE, and as such may be
>> out of scope in this I-D.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:44:50 +0100

Richard,

What is that definition in 21217?  Can you copy paste it here so we can 
consider it please?

Alex

Le 11/02/2017 à 05:55, Dick Roy a écrit :
> Definitions of terms depend on to whom you are talking.  I suggest sticking
> with the internationally accepted (except in the US) terminology in ISO
> 21217.  You will find definitions for everything you need concisely defined
> therein.
>
> Cheers,
>
> RR
>
> From: Jérôme Härri [mailto:[email-masked]]
> Sent: Friday, February 10, 2017 3:50 AM
> To: 'Alexandre Petrescu'; 'Michelle Wetterwald'
> Cc: [email-masked]
> It could actually be two different terms, depending of what we want to say
> in the draft. The RSU is no longer a pure C-ITS name, as even LTE-V2X
> adopted the LTE-UE operating in RSU mode for LTE-V2V communications (meaning
> you do not need to be a eNB/base station to be a RSU).
> I would tend to think that the RSU is more a function/service than an actual
> technology...but as I think the debate could be complex and suggest to
> follow Michelle suggestion to keep the RSU as a 'bigger' entity, and if you
> need it, a RSR as a potential sub-set of a RSU. As Michelle said, a RSU is
> not a router  by default...
>
> BR,
>
> Jérôme
>
> Despite the widespread belief that RSU would have something to do with IP
> and Internet, rarely if ever was there an RSU connected to Internet that
> forwarded IP packets - most RSUs are disconnected from the Internet (the
> supposedly 'slaves' at FHWA) and the ones that are connected to the Internet
> (supposedly the 'masters' at FHWA) are so only in order to be SNMP-managed
> remotely, but not to forward.
>
> If we know of some RSU which has this 'forwarding' flag set to 1, then we
> should talk about it, and call it a Router.
>
> The "ITS station" term is not a term at IETF.  We could re-use the term "ITS
> station", but I would like to know whether "ITS Station" is a Router or a
> Host?
>
> Yours,
>
> Alex
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:44:59 +0100

Le 11/02/2017 à 05:35, Dick Roy a écrit :
> This text is flawed.  OCB has NOTHING to say about the PHY!  OCB can be used
> with any of the 802.11 PHYs and is NOT restricted to 5.9GHz PHYs.  In
> discussing data rates and channel bandwidths, OCB is irrelevant other than
> to say in the US, in the 5.9GHz band, OCB is (or soon will be :^)) mandatory
> (see 802.11-2016 and SAE J2945/1).
>
> Secondly, half-rate refers to the fundamental system clock in an 80211
> chipset.  10MHz channels are achieved by simply downsampling the system
> clock (40MHz usually) by a factor of 2 (then 2 again to get 5MHz channels).
> As a consequence, all the data rates get halved (the halved again).  It's
> really quite simple. There is NOTHING about 802.11p that changes any of
> this.  The ONLY PHY related changes are to the Rx sensitivity and the Tx
> masks, but this is WAY OUTSIDE the scope of IETFs effort.
>
> All this stuff is much ado 'bout nothin'.  Simply note the default data
> rates that must be supported in 5.9GHz operations (and the optional others
> if you care) in the 10 MHz and 20MHz channels in the 5.9GHz band and charge
> ahead.

Noted.  Version -01 will talk much less about PHY.  Maybe in the 
appendices, or maybe not at all.

Alex

> Sent: Friday, February 10, 2017 2:03 AM
> To: [email-masked]
> Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 FYI quarter-,
> half- and full-rate comments
>
>> o	Half-rate (10 MHz channel spacing) maximum data rate is 27 Mb/s -
>> o	Half-rate minimum data rate is 3 Mb/s - Modulation BPSK; r == 1/2 -
>> o	Full-rate minimum data rate is 6 Mb/s - Modulation BPSK; r == 1/2;
>>
>> - Modulation 64-QAM;   r == 3/4;
>>
>> o	Quarter-rate minimum data rate is 1.5 Mb/s - Modulation BPSK; r ==
>>  1/2.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:45:10 +0100

Le 11/02/2017 à 05:28, Dick Roy a écrit :
> There are still problems with the text.  First 802.11p is NOT a
> standard and no longer exists (trivial point, but nonetheless true).

This will get fixed in -01 version, some time next week.

> Second, fixed MAC addresses have been proven to pose a privacy risk
> (remember the trash cans in London!).  There is work ongoing in 802
> and other place on this issue (see for example IEEE 802c which is
> currently in ballot). I would replace this entire paragraph with a
> simple statement that tumbling of MAC addresses in the local address
> space is one of the mechanisms used to address the privacy issue
> where it arises (see IEEE 1609 ...)

Please propose text.

Alex

> [mailto:[email-masked]] Sent: Friday, February 10, 2017
> 2:08 AM To: [email-masked] Subject: [ipwave]
> draft-ietf-ipwave-ipv6-over-80211ocb-00 dynamic change of MAC
> addresses refs
>
> draft-ietf-ipwave-ipv6-over-80211ocb-00 dynamic change of MAC
> addresses refs
>
> Hello IPWAVErs,
>
> We received a comment about the text describing the need for
> dynamically changing the MAC addresses for privacy reasons.
>
>> o	In vehicular communications using 802.11p links, there are
>> strong privacy concerns with respect to addressing.  While the
>> 802.11p standard does not specify anything in particular with
>> respect to MAC addresses, in these settings there exists a strong
>> need for dynamic change of these addresses (as opposed to the
>> non-vehicular settings - real wall protection - where fixed MAC
>> addresses do not currently pose some privacy risks).  This is
>> further described in section Section 8.
>
> The new next is:

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 18:45:16 +0100

If the app-level data generated by these sensors (lat/long/alt, time) 
are put in UDP or other payloads of IP then it makes sense to talk about 
these sensors in these RSUs routers.

But, up to now, ITS deployments do this:
- POI over something else than IP
- TSA is not mandatory (Time Stamp Advertisement).

Alternatively, one would do something like this:
- POI as PIDF-LO data (RFC5491) over IP
- IP Router Advertisements containing timestamps (to be defined)
- NTP over IP to send timestamps.

Then we can talk here about location sensors in RSU router boxes...

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:05:37 +0100

802.21 for IP handovers

Hello IPWAVErs,

José Santa Lozano commented that their implementation can rely on 802.21
(instead of WSA-with-WRA-field or RA) to realize IP handovers in 802.11-OCB.

The old text is this:
> One such message may be the 802.11p’s Time Advertisement, or higher
> layer messages such as the "Basic Safety Message" (in the US) or the
> "Cooperative Awareness Message " (in the EU), that are usually sent
> several times per second. Another alternative replacement for the
> IPv6 Router Advertisement may be the message ’WAVE Routing
> Advertisement’ (WRA), which is part of the WAVE Service
> Advertisement and which may contain optionally the transmitter
> location; this message is described in section 8.2.5 of
> [ieeep1609.3-D9-2010].

New, if at all:
> One such message may be the 802.11p’s Time Advertisement, or higher
> layer messages such as the "Basic Safety Message" (in the US) or the
> "Cooperative Awareness Message " (in the EU), that are usually sent
> several times per second. Another alternative replacement for the
> IPv6 Router Advertisement may be the message ’WAVE Routing
> Advertisement’ (WRA), which is part of the WAVE Service Advertisement
> and which may contain optionally the transmitter location; this
> message is described in section 8.2.5 of [ieeep1609.3-D9-2010].  Yet
> another alternative replacement for IPv6 RA is the involvement of
> 802.21 signal levels, or additional 802.21 entities,

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:08:43 +0100

This is a nit, but typos are always worth reporting early.  They help 
with later process.  There is a typo "capturing" - "captured" in the 
following text.

> We describe an experiment of capturing an IPv6 packet captured on an
> 802.11p link.

I will fix this.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:49:29 +0100

multiple interfaces

José reports that IP MCoA protocol (multiple care-of addresses, RFC5648)
could be used when multiply-interfaced vehicles are used.  For that I
suggest the new text below.

(in addition, I also suggest to look at the new effort in BoF stage at
IETF called 'banana' which considers also the use of multiple
interfaces, for bandwidth augmentation. ietf.org/mailman/listinfo/banana)

old text:
> D.6. Multiple interfaces
[...]
> This will require specific logic to ensure, for example, that packets
> meant for a vehicle in front are actually sent by the radio in the
> front, or that multiple copies of the same packet received by
> multiple interfaces are treated as a single packet. Treating each
> wireless interface as a separate network interface pushes such issues
> to the application layer.

new text:
> This will require specific logic to ensure, for example, that packets
> meant for a vehicle in front are actually sent by the radio in the
> front, or that multiple copies of the same packet received by
> multiple interfaces are treated as a single packet. Treating each
> wireless interface as a separate network interface pushes such issues
> to the application layer.
>
> If Mobile IPv6 with NEMO extensions is used, then the MCoA RFC5648
> technology is relevant for Mobile Routers with multiple interfaces,
> deployed in vehicles.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:49:46 +0100

certs req, IPsec

A somewhat less clear comment I received about text requiring the use of 
certificates.  The comment mentions IPsec and authentication too.

old text:
> Similarly to Non IP safety-critical communications, IPv6 over
> 802.11-OCB packets must contain a certificate, including at least the
> public key of the sender, that will allow the receiver to
> authenticate the packet, and guarantee its legitimacy.

IMHO it would be little advantageous to require each IP/OCB packet to 
contain a certificate.  It would make them too big.

IMHO too IPsec can work without certs, too.

But since this is potentially a subject of much debate, I would remove 
that old text, and delegate to another security-specific document.

At this time I remove that old text.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:50:07 +0100

ETSI CAM and IP

It has been commented, that to the best of one's reading, the
ETSI ITS documents do not specify what is the protocol that should be
used to encapsulate CAMs.  This leads to wonder whether or not IP can be
used to transport CAMs, and, if not - why not?

The ETSI documents having been reviewed are the following:
ETSI TS 102 637-2
ETSI EN 302 665

In this draft, the old text is the following:
> D.2. Non IP Communications
>
> In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be
> used with IP datagrams. For example, Basic Safety Message (BSM, an
> IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI
> ITS-G5 datagram), are each transmitted as a payload that is preceded
> by link-layer headers, without an IP header.

I propose the following new text:
> D.2. Non IP Communications
>
> In IEEE 1609 and ETSI ITS, safety-related communications MAY NOT be
> used with IP datagrams. For example, Basic Safety Message (BSM, an
> IEEE 1609 datagram), are each transmitted as a payload that is preceded
> by link-layer headers, without an IP header.

(remark "MAY NOT" instead of CANNOT, and CAM absence).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Feb 2017 19:50:27 +0100

IP (not) for safety

José also reports that the following old text in Appendix D "Design
Considerations" is excluding the use of IP for safety-related apps.
Some people may think so, some otherwise.  There is a suggestion we
clarify this in the main part of the text, not in an Appendix.

old:
> This section [Appendix D] does not address safety-related
> applications, which are done on non-IP communications.

new:
> ?

IMHO I would be silent about this.  But if we want to say something
about this in the Introduction, that we agree, then I will put it.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Sun, 12 Feb 2017 14:15:59 -0800

None of the differential systems that I know of generate lat/long/alt
data.  dGPS generates delta pseudoranges -- the difference between the
satellite <--> receiver distance that it IS getting and that it SHOULD
be getting, based on it's known location.  dLoran (or eLoran in today's
buzz) generates delta TDs.  (It would be possible to squeeze out a box
location in lat/long/alt via an SNMP get -- the differential box must
know its location to function -- but that's administrative, not
operational).  

Nit aside, we're agreeing that it's app level data and putting it into
UDP PDUs and blasting it out makes sense.

On Sun, 2017-02-12 at 18:45 +0100, Alexandre Petrescu wrote:
> > > > text, as it is a widely used term, but clarify that an RSR
> > > > could
> > > > be
> > > > is that apparently there are conflicts between our assumption
> > > > of
> > > > RSU
> > > > to be a router and FHWA(?) thinking RSU is more like an
> > > > interface
> > > > to a
> > > > to,

---

From: John Kenney <[email-masked]>
Date: Sun, 12 Feb 2017 17:52:18 -0800

Hi Alex,

Without addressing the main point you are making, I point out simply that
the BSM is not an IEEE 1609 datagram (it is an SAE J2735 message), and I
agree with William Whyte's comment in another thread that "MAY NOT" is
ambiguous (could mean shall not or might not).

Best Regards,
John

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Mon, 13 Feb 2017 07:46:00 +0100

Dear all,

right. In general the standards from ETSI do not require using a 
specific communication protocotol stack. Thus - from a standards point 
of view - any communications protocol stack is possible, e.g.

  * FNTP / ITS-M5 (ISO 29281-1 / ISO 21215)
  * IPv6 / ITS-M5 (ISO 21210 and others / ISO 21215)
  * FNTP  / LTE V2X (ISO 29281-1 / ISO 17515)
  * IPv6 / LTE V2X (ISO 21210 and others / ISO 17515)
  * WSMP / IEEE 802.11 OCB (IEEE 1609.3 - interoperable with FNTP / ITS-M5)
  * ...

Hans-Joachim Fischer

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Mon, 13 Feb 2017 07:48:27 +0100

All definitions from ISO standards are publicly accessible at the ISO 
Online Browsing Platform (OBP) free of charge. The link to those from 
ISO 21217 is https://www.iso.org/obp/ui/#iso:std:iso:21217

Hans-Joachim

Am 12.02.2017 um 18:44 schrieb Alexandre Petrescu:
> Richard,
>
> What is that definition in 21217?  Can you copy paste it here so we 
> can consider it please?
>
> Alex
>
>> to say
>> actual
>> component
>> of RSR, right?
>> with IP
>> then we
>> term "ITS

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: José Santa Lozano <[email-masked]>
Date: Mon, 13 Feb 2017 09:51:38 +0100

Dear Alex,

Thanks for considering the comment.

Nevertheless, we also use RA in our solution in order to detect an 802.11p access router. The usage of 802.21 is an additional source of information to speed-up the selection of the most convenient point of attachment or communication flow to use. Due to this, let me propose a text that could be placed at the end of the former version of that paragraph:

"Additionally, IEEE 802.21 can be used to improve the network selection process, since it provides standardized mechanisms to monitor parameters of the local transceiver (e.g. the RSSI sensed from a RSU) and the reception of external information from an infrastructure node about the surrounding networks (e.g. area coverage or monetary cost)"

Just a suggestion.

Jose.

> El 12 feb 2017, a las 19:05, Alexandre Petrescu <[email-masked]> escribió:
>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 13 Feb 2017 10:25:49 +0100

Dear Alex, 

I agree with John on the confusing 'MAY NOT', and more generally to the
general confusion in the ETSI about what is allowed or not allowed for what
message...I am OK with suggested change, although in general I think we
could also remove the complete 'non-IP' section..as it does not bring much..

Now, on why/how CAM can be IPv6 compliant, at this state of the standard,
CAM cannot be transmitted on IPv6 (maybe in the future...). There is indeed
no strong 'restriction' (and I think that was the objective of the ETSI to
leave the door open), but one have to read more than these two standard to
see that it is not possible at this stage (I know, ETSI is cumbersome...). 

Here are the justifications of my statements:

Indeed:
* ETSI CAM standard ETSI EN 302 637-2 in section " 5.3.4.2 Interface to the
IPv6 stack and the combined IPv6/GeoNetworking stack " leaves the door open
for CAM being transmitted on IPv6 (and I insist here on IPv6, not v4)

BUT:
* in ETSI EN 302 571, in section "6.1.3 CAM generation frequency" it
mentions a require DCC interface in its triggering conditions. 
* In ETSI EN 302 637-2, the priority level is indicated in "6.2.3 General
priority constraints"  to be according to the ETSI EN 302 636-4-1
(Geonetworking media-independent). 
* The EN 302 637-2 in its section "6.2.2 Security constraints" binds the
transmission of CAMs to certificate that are currently only specified for
the ETSI ITS stack. 
But most critical:
* In ETSI EN 302 571 mentions that accessing CCH requires a DCC
implementation, which CAM over pure IPv6 does not do so far....
* if you send CAM without GeoNET, you create a major security breach, as
there are no 'standard' mentioning how certificate/authentication is
performed, considering OCB does not do any. 

So, it is a quite strict restriction at this stage of the standard that CAM
MUST be sent (so far) only using GeoNet and not IPv6 (and even stricter not
IPv4).  I like to keep an open mind, as I also believe that CAM could also
be allowed to be transmitted in different technologies (LTE-V2X) or stack
(IPv6), but in EU at this state of the standard, CAM must be transmitted on
geonet and not IPv6. 

To change this, we would need at least four key aspects:
1) have a DCC for IPv6 access on ITS-G5 spectrum
2) specify what T_cam_gen_dcc would mean in this case
3) propose a change to the ETSI EN 302 637-2 to allow a CAM traffic class
not bound to GeoNet 
4) specify how security mechanisms would be integrated into the CAM
headers/trailers and transmitted over IPv6.

I think this could be a direction this group could go, but a lot of work is
on the table....

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday 12 February 2017 19:50
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 ETSI CAM and IP

It has been commented, that to the best of one's reading, the ETSI ITS
documents do not specify what is the protocol that should be used to
encapsulate CAMs.  This leads to wonder whether or not IP can be used to
transport CAMs, and, if not - why not?

I propose the following new text:
> IEEE 1609 datagram), are each transmitted as a payload that is 
> preceded by link-layer headers, without an IP header.

Alex

---

From: José Santa Lozano <[email-masked]>
Date: Mon, 13 Feb 2017 10:48:59 +0100

Dear Jerome, Alex,

Thanks for the clarification.

Given these points, and considering that probably in the future CAM could be transmitted over IPv6, one option would be not to say anything about CAM in the draft. At the moment, I think CAM are only cited when talking about the traffic that cannot be packetized with IPv6. According to your points, it appears that it is not explicitly prohibited to use CAM over IPv6 in the ETSI standards, so this could be more appropriate than the initial text.

Regards,

Jose.

> El 13 feb 2017, a las 10:25, Jérôme Härri <[email-masked]> escribió:
> 
> Dear Alex, 
>

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 13 Feb 2017 11:15:25 +0100

Hello Alex,

I am not sure to fully understand the objective of this piece of text
anymore. I follow some other comments raising concerns on mentioning any
IEEE 1609-related message, as it would imply that our stack would be able to
decode them..which is far from being clear at this time. It is indeed also
an IEEE standard, but it is not the same 'community' and not the same stack
level.

I think we are being too specific in a field of large unknown. We should
remain more pragmatic and adopt one of the following two strategy:
1) a full specification of our claim: if we claim that something can be done
with one specific message and if it is in the scope of the document, then
explicitly mention it. This would typically be the case if we want to
explain how to get RSSI from IPv6 RA or any other related IPv6 message.
2) just mention generalities, without any specifics: e.g. this text could be
simplified as follows: "(...) in case of absence of L3 signaling, L2
signaling MAY be used to estimate the channel or link quality. " (whatever
L2 means).

Best regards,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday 12 February 2017 19:06
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 802.21 for IP
handovers

Hello IPWAVErs,

The old text is this:
> message is described in section 8.2.5 of [ieeep1609.3-D9-2010].

Alex

---

From: François Simon <[email-masked]>
Date: Mon, 13 Feb 2017 10:33:13 -0500

Two Antennae: Multiple Input Multiple Output (MIMO) technology - The
antennas at each end of the communications circuit are combined to minimize
errors and optimize data speed.

Non-intersection RSUs:

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 3:42 AM
To: François Simon <[email-masked]>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Le 11/02/2017 à 01:30, François Simon a écrit :
> Both are arguable.
>
> a) Antennas:  Depend on applications.  In the picture, this is mostly 
> for intersections where OBE's transmissions comes from all directions.  
> An omni-directional is more appropriate for tolling applications.

If this is for intersection, then why are there _two_ antennas, each omni?
IT should be 180deg for each.  It makes no sense to put 2 omnis. 
One omni would be sufficient.

And do they have a figure which is _not_ for intersection? (i.e. for along
the road?)

Alex

> b) boosters on surge-suppressor......; I do not see the point.  I miss 
> the point.
> Fygs
>
> Sent: Friday, February 10, 2017 11:28 AM
> To: François Simon <[email-masked] <mailto:[email-masked]> >
> Thanks for the note.
> As a side note, note that omni antennas dont make much sense on pole 
> along roads - should be sector antennas.  This is a common mistake at many
sites.
>
> In addition to surge-suppressors one should use boosters too, to 
> extend reach.
>
> Le 10/02/2017 à 17:12, François Simon a écrit :
>> I would be very careful to replace RSU with RSR systematically 
>> (global change).  The figure below shows how, in the US, FHWA sees 
>> the implementation (one of several):
>>
>>
>> In this figure, the RSR is in the left hand bottom corner.
>>
>> Fygs
>>
>>
>>
>> Sent: Friday, February 10, 2017 5:34 AM
>> Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
>>
(slave?) RSUs.

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 13 Feb 2017 16:41:57 +0100

Following your feedback,

Whereas a full MIMO remains arguable at this stage (my personal view I have
to admit), as one would need to orient the beams and learn the channel state
which is constantly moving (basically tracking a vehicle), a key benefit of
having two antennas on a RSU (and actually on a OBU) could be antenna
diversity with space-time coding (e.g. 2x1). Unfortunately, OCB does not
allow this (and neither MIMO). So, multi-antennas so far can only be used
for multi-transceivers as far as I know. 

But as we aim at beyond DAY 2, we never know what the future holds...so,
having multiple antennas, with different patterns might be expected in the
future. We should leave it open. 

BR,

Jérôme
_____________________________________________
From: its [mailto:[email-masked]] On Behalf Of François Simon
Sent: Monday 13 February 2017 16:33
To: 'Alexandre Petrescu'
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Non-intersection RSUs:

 << File: Untitled attachment 00062.txt >> 

 << OLE Object: Picture (Device Independent Bitmap) >> 

 << OLE Object: Picture (Device Independent Bitmap) >> 

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 3:42 AM
To: François Simon <[email-masked]>
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Alex

sites.
(slave?) RSUs.
> << OLE Object: Picture (Device Independent Bitmap) >>

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Mon, 13 Feb 2017 16:50:33 +0100

Where is the below statement written in a normative way in a standard?

Hans-Joachim

Am 13.02.2017 um 16:41 schrieb Jérôme Härri:
> ... antenna
> diversity ... Unfortunately, OCB does not
> allow this

-- 
Dr. Hans-Joachim Fischer
Managing Director

---

From: François Simon <[email-masked]>
Date: Mon, 13 Feb 2017 10:53:05 -0500

Agreed.  The point is just a "caution".  IEEE 1609 does specified that the
MAC sub-layer is enhanced with Multi-Channel Operation function (IEEE
1609.4).  The protocol model shows the MAC sub-layer as "WAVE MAC (including
channel coordination )" on the data plane. However, I do not believe that
the coordination is actually performed by the MAC itself (data plane), but
rather in the SME.

Fygs

-----Original Message-----
From: Jérôme Härri [mailto:[email-masked]] 
Sent: Saturday, February 11, 2017 8:18 AM
To: 'François Simon' <[email-masked]>; [email-masked]
Cc: 'Alexandre Petrescu' <[email-masked]>
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Dear François,

BR,

Jérôme

-----Original Message-----
From: François Simon [mailto:[email-masked]]
Sent: Friday 10 February 2017 21:04
To: 'Jérôme Härri'
Cc: 'Alexandre Petrescu'; [email-masked]
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Friday, February 10, 2017 6:53 AM
To: 'Alexandre Petrescu' <[email-masked]>; [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Hello Alex,

Best Regards.

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 10 February 2017 12:13
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 absence of

Hello IPWAVErs,

Yours,

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 13 Feb 2017 16:54:22 +0100

As far as I know, IEEE 802.11-2012 OCB is based on IEEE 802.11a, which
neither support STBC codes nor MIMO.

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Dr. Hans-Joachim
Fischer
Sent: Monday 13 February 2017 16:51
To: [email-masked]
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Hans-Joachim

Am 13.02.2017 um 16:41 schrieb Jérôme Härri:
> ... antenna
> diversity ... Unfortunately, OCB does not allow this

--
Dr. Hans-Joachim Fischer
Managing Director

---

From: François Simon <[email-masked]>
Date: Mon, 13 Feb 2017 11:53:52 -0500

In the US the original purpose of allocating the 5.9 GHz and DSRC was/is for
Safety Applications, whatever they may be. I do not think it would be wise
to restrict any protocols to provide such service.   

Fygs

DSRC (Dedicated Short Range Communications) is a two-way short- to-
medium-range wireless communications capability that permits very high data
transmission critical in communications-based active safety applications.

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, February 12, 2017 1:50 PM
To: [email-masked]
Subject: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 IP (not) for
safety

José also reports that the following old text in Appendix D "Design
Considerations" is excluding the use of IP for safety-related apps.
Some people may think so, some otherwise.  There is a suggestion we clarify
this in the main part of the text, not in an Appendix.

IMHO I would be silent about this.  But if we want to say something about
this in the Introduction, that we agree, then I will put it.

Alex

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 14 Feb 2017 10:20:56 +0100

Dear Dick,

You are right :-). It is an issue to embrace several telecomm. providers in order to achieve such scenario.  However, this is subject to future agreements out of our control, and this kind of support services could be even externally provided, offering information about networks in the surroundings, independently of the operator… For sure it is something to be exploited in the future. Imagine that we are still waiting for IPv6 support from many operators…

Regards,

Jose.

> El 13 feb 2017, a las 18:27, Dick Roy <[email-masked]> escribió:
> 
> There seems to be some confusion here.  BSMs/CAMs are generally NOT sent from roadside units; they are sent from vehicular ITS-Ss.  Secondly, other than the silly restriction in the US on CH178 and the J2945/1 restriction on Ch172, IPv6 frames can be sent on any channel, including IPv6 RAs.  Finally, the WRA is included in a WSA and can be sent on ANY channel as a WSM (i.e. using WSMP).
>  
> Use of 802.21 functions and services to help with heterogeneous handovers is a good idea and should be pursued.  Let me know if you know of ANY operator of a wide area cellular system (LTE, 3G, etc.) that has agreed to implement ANY of 802.21 for handing off its traffic to some other network :^)))
>  
> Cheers,
> 
> RR
>  
> From: José Santa Lozano [mailto:[email-masked]] 
> Sent: Monday, February 13, 2017 12:52 AM
> To: Alexandre Petrescu
> Cc: [email-masked]
> Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 802.21 for IP handovers
>  
> Dear Alex,
>  
>> El 12 feb 2017, a las 19:05, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> escribió:
>>

---

From: Michelle Wetterwald <[email-masked]>
Date: Tue, 14 Feb 2017 12:14:26 +0100

Dear all,

I am not sure about involving 802.21 here. Its main achievement is to
provide an abstraction layer that helps understand the status of the lower
layers. It can be quite useful to trigger a handover in any type of
scenario involving mobility.
However, in any case, it does not intend to replace the IPv6 router
advertisement and an IPv6 node would not be able to configure its address
using 802.21 only. So I suggest to keep the old text in the bottom email
below.

Best regards,
Michelle Wetterwald
[email-masked]
----
Senior expert in networking and telecommunications

2017-02-14 10:20 GMT+01:00 José Santa Lozano <[email-masked]>:

> Dear Dick,
>
> You are right :-). It is an issue to embrace several telecomm. providers
> in order to achieve such scenario.  However, this is subject to future
> agreements out of our control, and this kind of support services could be
> even externally provided, offering information about networks in the
> surroundings, independently of the operator… For sure it is something to be
> exploited in the future. Imagine that we are still waiting for IPv6 support
> from many operators…
>
> Regards,
>
> Jose.
>
>
>
> There seems to be some confusion here.  BSMs/CAMs are generally NOT sent
> from roadside units; they are sent from vehicular ITS-Ss.  Secondly, other
> than the silly restriction in the US on CH178 and the J2945/1 restriction
> on Ch172, IPv6 frames can be sent on any channel, including IPv6 RAs.
> Finally, the WRA is included in a WSA and can be sent on ANY channel as a
> WSM (i.e. using WSMP).
>
> Use of 802.21 functions and services to help with heterogeneous handovers
> is a good idea and should be pursued.  Let me know if you know of ANY
> operator of a wide area cellular system (LTE, 3G, etc.) that has agreed to
> implement ANY of 802.21 for handing off its traffic to some other network
> :^)))
>
> Cheers,
>
> RR
>
> ------------------------------
> *From:* José Santa Lozano [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, February 13, 2017 12:52 AM
> *To:* Alexandre Petrescu
> *Cc:* [email-masked]
> *Subject:* Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 802.21
> for IP handovers
>
> Dear Alex,
>
> Nevertheless, we also use RA in our solution in order to detect an 802.11p
> access router. The usage of 802.21 is an additional source of information
> to speed-up the selection of the most convenient point of attachment or
> communication flow to use. Due to this, let me propose a text that could be
> placed at the end of the former version of that paragraph:
>
> "Additionally, IEEE 802.21 can be used to improve the network selection
> process, since it provides standardized mechanisms to monitor parameters of
> the local transceiver (e.g. the RSSI sensed from a RSU) and the reception
> of external information from an infrastructure node about the surrounding
> networks (e.g. area coverage or monetary cost)"
>
> Just a suggestion.
>
> Jose.
>
>
>
>

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 14 Feb 2017 13:08:21 +0100

Dear Michele,

It does not only provides information about the lower layers, but also additional information that could come from an infrastructure node (for instance), providing details about the networks in the surroundings.

Anyhow, it was only a comment, since it appears that the document suggests some approaches to tackle the problem of handover, and the .21 is just another supporting technology for this issue.

Regards,

-- 
José Santa Lozano
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta <http://ants.inf.um.es/~josesanta>

> El 14 feb 2017, a las 12:14, Michelle Wetterwald <[email-masked]> escribió:
> 
> Dear all,
> 
> I am not sure about involving 802.21 here. Its main achievement is to provide an abstraction layer that helps understand the status of the lower layers. It can be quite useful to trigger a handover in any type of scenario involving mobility. 
> However, in any case, it does not intend to replace the IPv6 router advertisement and an IPv6 node would not be able to configure its address using 802.21 only. So I suggest to keep the old text in the bottom email below. 
> 
> Best regards,
> Michelle Wetterwald
> [email-masked] <mailto:[email-masked]>
> ----
> 2017-02-14 10:20 GMT+01:00 José Santa Lozano <[email-masked] <mailto:[email-masked]>>:
> Dear Dick,
> 
>> El 13 feb 2017, a las 18:27, Dick Roy <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> From: José Santa Lozano [mailto:[email-masked] <mailto:[email-masked]>] 
>> Cc: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: François Simon <[email-masked]>
Date: Tue, 14 Feb 2017 09:52:16 -0500

In this figure the router would be the item at the right-hand, bottom corner “Backhaul Local Communications”.   Fygs

From: Michelle Wetterwald [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2017 6:31 AM
To: François Simon <[email-masked]>
Subject: Fwd: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Hi François,

Thank you for sending me this picture, but I cannot see any RSR.

I can only see an RSU, which may host an RSR, as I mentioned to Alex in my email below.

Can you help me locate the RSR?

Thanks, Michelle

Michelle Wetterwald

---------- Forwarded message ----------
From: Michelle Wetterwald <[email-masked] <mailto:[email-masked]> >
Date: Tue, Feb 14, 2017 at 12:27 PM
Subject: Fwd: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
To: Michelle Wetterwald <[email-masked] <mailto:[email-masked]> >

---------- Forwarded message ----------
From: François Simon <[email-masked] <mailto:[email-masked]> >
Date: 2017-02-10 17:50 GMT+01:00
Subject: RE: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
To: Michelle Wetterwald <[email-masked] <mailto:[email-masked]> >

See one of US FHWA view of RSE. RSR in left-hand bottom corner.   fygs

From: its [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Michelle Wetterwald
Sent: Friday, February 10, 2017 6:19 AM
To: Alexandre Petrescu <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term

Hi Alex,

Actually, an RSU is generally more than an RSR as it is an ITS station per se and may contain upper (e.g. service or even application) layers.

I suggest to keep the definition of RSU in the text, as it is a widely used term, but clarify that an RSR could be one of the components of an RSU.

Best regards, 

Michelle

2017-02-10 11:34 GMT+01:00 Alexandre Petrescu <[email-masked] <mailto:[email-masked]> >:

Hello IPWAVErs,

Old:

2.  Terminology

[...]

RSU: Road Side Unit.

New:

Alex

-- 

Michelle Wetterwald

-- 

Michelle Wetterwald

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 15:52:08 +0100

Le 04/02/2017 à 02:35, Dick Roy a écrit :
> I assume by "seen 'LLC' in IPv6 packets ... on ... OCB" you mean you
> have seen wireshark output that has a full LLC SNAP header in the
> MAC frame of a stream containing an IPv6 network layer NPDU (aka
> IPv6 packet).

Wireshark calls that "LLC" not "LLC SNAP".

> Since you are based in Europe, I am not surprised, however, in ALL
> PHY streams in the US and elsewhere (except Europe) you will NOT see
> those 6 useless bytes, only the Ethertype field will be present.
> Hopefully Europe gets its act together sometime soon.

I dont understand you.  It's not a matter of continents.

It depends how the packet was captured: monitor mode, or normal mode.
In monitor mode one can see all 802.11 headers, whereas in normal mode
one can see only "Ethernet II".  The IPv6 layer considers only the
fields of that "Ethernet II" header: MAC addresses and Ethertype.  The
IPv6 layer does not consider the many other fields of 802.11 headers.

Alex

> [mailto:[email-masked]] Sent: Friday, February 3, 2017
> 8:36 AM To: François Simon; 'Russ Housley' Cc: [email-masked] Subject:
> Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 use of term
> "802.2 LLC"
>
>
>
>> While LLC standard is out of scope for 802.11 is concerned, it is
>> still mentioned. Two LLC types:
>>
>> 8802-2:1998 - EPD EtherType Protocol Discrimination (EPD) - IEEE
>> Std 802-2014 - IEEE
> Std
>> 802.3-2012
>>
> But is it about the future or about the present? (I have not seen
> "EPD" myself, yet I have seen "LLC" used in IPv6 packets transmitted
> on 802.11 in OCB mode).
>
> The text to be put in IPv6/OCB saying LLC or EPD or SNAP depends on
> that tense.
>
> Alex
>
>>
>> Fygs
>>
>>
>> On Behalf Of Russ Housley Sent: Thursday, February 02, 2017 12:57
>> PM To: Alexandre Petrescu <[email-masked]> Cc:
>> [email-masked] Subject: Re: [ipwave]
>>> It has been suggested that the term "802.2 LLC" may not be
>>> relevant because in the next version of the IEEE 802.11 standard
>>> the LLC will no longer be based on IEEE 802.2.
>>>
>>>> The IPv6 Networking is layered on top of the IEEE 802.2
>>>> Logical-Link Control (LLC) layer; this is itself layered on
>>>> top of the 802.11p MAC; this layering illustration is similar
>>>> to that of running IPv6 over 802.2    LLC over the 802.11 MAC,
>>>> or over Ethernet MAC.
>>>
>>> new:
>>>> The IPv6 Networking is layered on top of an IEEE 802.11 LLC
>>>> layer; this is itself layered on top of the 802.11 MAC layer;
>>>> this layering illustration is similar to that of running IPv6
>>>> over 802.2 LLC over the IEEE 802.3 (Ethernet) MAC.
>>
>> I think that talking about Ethernet is causing confusion.  Perhaps
>> it
> would
>> be more straightforward to say that SNAP [RFC1042] is used to
>> carry the
> IPv6
>> Ethertype.
>>
>> Russ _______________________________________________ its mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>
>>
>
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 16:05:12 +0100

Dick,

Le 04/02/2017 à 09:51, Dick Roy a écrit :
> Now you are getting to the real heart of the ITS WI in the IETF!
> 1609/802.11 OCB was and is simply a single link protocol set.  There
> are NO networks, no networking, no nothing.  IPv6 was recognized in
> the 1609 standards (and ISO standards) as the "preferred" networking
> technology should there be a need for such (which there obviously
> is!).  While 802.11 has developed and is developing functionality
> that makes seemless handover between APs a bit easier (.11ai and
> friends), the how it is accomplished in the "network" is out of scope
> for both 802 and 1609.  You will not get either group to develop
> mobility management protocols anytime soon (read: before we all pass
> away:^)  Furthermore, there is NO chance of deploying a wide area
> bridged network consisting solely of 5.9GHz RSUs.  Some networking
> functionality will be mandatory in any deployments.  Enter IPv6!
> IPv6 mobility management (handover, session continuity, etc.) for
> rapidly changing network topologies is EXACTLY what we (those of us
> doing all the other ITS comm stuff:^)) "hired you guys at the IETF"
> to do for us!

I can agree that IEEE would not do IP handover work.

Handovers are of two types: MAC handovers and IP handovers.  The IP
handovers are designed at IETF, e.g. the Mobile IP protocol.

The IP handovers would be specified in a separate document, because the
IP-over-foo RFCs dont describe handovers.

Alex

> [mailto:[email-masked]] Sent: Thursday, February 2,
> 2017 9:39 AM To: [email-masked] Subject: [ipwave]
> There has been a comment that handovers were never seriously
> addressed in 802.11p or IEEE 1609.
>
>> However, there are several deployment considerations to optimize
>> the performances of running IPv6 over 802.11p (e.g. in the case of
>> However, there may be some deployment considerations helping
>> optimize the performances of running IPv6 over 802.11-OCB (e.g. in
>> the case of handovers between 802.11-OCB [term], or the
>> consideration of using the IP security layer).
>
> The other is that I suggest IEEE 802.11-OCB and IEEE P1609 to
> address seriously the handover considerations.  At IETF there are a
> few RFCs and running code that describe how IP handovers happen.
>
> Yours,
>
> Alex
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 16:07:55 +0100

Jérôme,

Le 13/02/2017 à 11:15, Jérôme Härri a écrit :
> anymore.

It is an IP-over-foo document.  There are many IP-over-foo RFCs, e.g.
RFC2464.  They describe very simple parameters like MTU, address
mapping, and others.

> I follow some other comments raising concerns on mentioning any IEEE
> 1609-related message, as it would imply that our stack would be able
> to decode them..which is far from being clear at this time. It is
> indeed also an IEEE standard, but it is not the same 'community' and
> not the same stack level.
>
> I think we are being too specific in a field of large unknown. We
> should remain more pragmatic and adopt one of the following two
> strategy: 1) a full specification of our claim: if we claim that
> something can be done with one specific message and if it is in the
> scope of the document, then explicitly mention it. This would
> typically be the case if we want to explain how to get RSSI from
> IPv6 RA or any other related IPv6 message.

This should be described in an 'IP handover on 802.11 OCB' Internet Draft.

> 2) just mention generalities, without any specifics: e.g. this text
> could be simplified as follows: "(...) in case of absence of L3
> signaling, L2 signaling MAY be used to estimate the channel or link
> quality. " (whatever L2 means).

Even that may look too detail for some.

Alex

> On Behalf Of Alexandre Petrescu Sent: Sunday 12 February 2017 19:06
> draft-ietf-ipwave-ipv6-over-80211ocb-00 802.21 for IP handovers
>
> draft-ietf-ipwave-ipv6-over-80211ocb-00 802.21 for IP handovers
>
> Hello IPWAVErs,
>
> José Santa Lozano commented that their implementation can rely on
> 802.21 (instead of WSA-with-WRA-field or RA) to realize IP handovers
> in 802.11-OCB.
>
> The old text is this:
>> One such message may be the 802.11p's Time Advertisement, or
>> higher layer messages such as the "Basic Safety Message" (in the
>> US) or the "Cooperative Awareness Message " (in the EU), that are
>> usually sent several times per second. Another alternative
>> replacement for the IPv6 Router Advertisement may be the message
>> 'WAVE Routing Advertisement' (WRA), which is part of the WAVE
>> Service Advertisement and which may contain optionally the
>> transmitter location; this message is described in section 8.2.5
>> of [ieeep1609.3-D9-2010].
>
> New, if at all:
>> One such message may be the 802.11p's Time Advertisement, or
>> higher layer messages such as the "Basic Safety Message" (in the
>> US) or the "Cooperative Awareness Message " (in the EU), that are
>> usually sent several times per second. Another alternative
>> replacement for the IPv6 Router Advertisement may be the message
>> 'WAVE Routing Advertisement' (WRA), which is part of the WAVE
>> Service Advertisement and which may contain optionally the
>> transmitter location; this message is described in section 8.2.5
>> of [ieeep1609.3-D9-2010].  Yet another alternative replacement for
>> IPv6 RA is the involvement of 802.21 signal levels, or additional
>> 802.21 entities,
>
> Alex
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 16:09:35 +0100

Hello IPWAVErs,

I propose we remove the entire section 6 "Handover between OCB links":
https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-00#section-6

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 16:51:46 +0100

Le 14/02/2017 à 15:52, François Simon a écrit :
> In this figure the router would be the item at the right-hand, bottom
> corner “Backhaul Local Communications”.   Fygs

In the boxes I work with the router is not only the 'backhaul router' 
but also the Road-Side Unit that is pictured in that figure.

That RSU has 1 ethernet interface and 2 802.11-OCB interfaces, and runs 
IP routing (not bridging) between these interfaces.

There are many scalability advantages and interference avoidance to 
using routing, and not bridging, in that RSU.

Alex

>
>
>
> *From:*Michelle Wetterwald [mailto:[email-masked]]
> *Sent:* Tuesday, February 14, 2017 6:31 AM
> *To:* François Simon <[email-masked]>
> *Subject:* Fwd: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
>
>
>
> Hi François,
>
> From: *Michelle Wetterwald* <[email-masked]
> <mailto:[email-masked]>>
> To: Michelle Wetterwald <[email-masked]
> <mailto:[email-masked]>>
>
>
>
> From: *François Simon* <[email-masked] <mailto:[email-masked]>>
> To: Michelle Wetterwald <[email-masked]
> <mailto:[email-masked]>>
>
> *From:*its [mailto:[email-masked] <mailto:[email-masked]>]
> *On Behalf Of *Michelle Wetterwald
> *Sent:* Friday, February 10, 2017 6:19 AM
> *To:* Alexandre Petrescu <[email-masked]
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [ipwave] draft-ietf-ipwave-ipv6-over-80211ocb-00 RSU term
>
>
>
> Hi Alex,
>
>
>
> per se and may contain upper (e.g. service or even application) layers.
>
> I suggest to keep the definition of RSU in the text, as it is a widely
> used term, but clarify that an RSR could be one of the components of an RSU.
>
>
>
> Best regards,
>
> Michelle
>
>
>
> <[email-masked] <mailto:[email-masked]>>:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 20 Feb 2017 16:54:15 +0100

RSU antennas along routes, and while not in intersection RSU 
deployments, should be directional, not omni-directional.

These omnidirectional antennas make no sense if they are not in the 
center of something (e.g. the center of intersection).  They should be 
directional, with a certain angle of aperture.

Alex

Le 13/02/2017 à 16:33, François Simon a écrit :
> antennas at each end of the communications circuit are combined to
> minimize errors and optimize data speed.
>
> Non-intersection RSUs:
>
>
>
>
> If this is for intersection, then why are there _two_ antennas, each
> omni?  IT should be 180deg for each.  It makes no sense to put 2 omnis.
> And do they have a figure which is _not_ for intersection? (i.e. for
> along the road?)
>
> Alex
>
>> To: François Simon <[email-masked] <mailto:[email-masked]>>
>> along roads - should be sector antennas.  This is a common mistake at many sites.
>>
>>> interface to a router, or something like a master-RSU controlling (slave?) RSUs.