Subject: Re: Update about draft-petrescu-ipv6-over-80211p-01.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Mar 2014 20:28:24 +0100

I would like to ask whether somewhere exists some form of encouraging 
text saying that IP _is_ allowed on the control channel in the 5.9GHz 
band used by IEEE 802.11p.

Because,

During the presentaion in 6MAN WG about IPv6-over-802.11p I said, if I
recollect correctly, that FCC forbids the use of IP on the control
channel by FCC.

I got direct and indirect private comments about the validity of such
statement.

I may have been wrong, but not entirely.  Maybe it would have been safer
to say that FCC _and_ IEEE forbid that: FCC defines what is a control
channel in the publicly available document '2004 "Report and Order, 
Before the Federal Communications Commission Washington", D.C. 20554, 
FCC 03-324', and IEEE defines what goes on these channels in P1609.4 by 
saying 'data frames containing IP datagrams are only allowed on service 
channels' - implicitely not on control channels.

There is much approximation in these statements but I did my best to
search these documents; and this is reflected in Appendix B of the
IPv6-over-80211p document, analysis at this URL:
http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01#page-25

Alex
PS: there is some ongoing discussion about the documents P1609 not being
public access; I can not do anything about that; IAB IEEE liaison
manager is in discussion about this with IEEE representative and things
advance.

Le 27/01/2014 11:56, Alexandru Petrescu a écrit :
> Hi Ray,
>
> Thanks for the reply.
>
> Le 27/01/2014 08:23, Ray Hunter a écrit :
>> I have read this draft. Thanks for sharing your experiences.
>>
>> Would 6LoWPan RFC6775 not be more appropriate for dealing with the
>> issues identified in Section 5.6, when 802.11p is operating in OCB
>> mode?
>
> There is a similarity and a discrepancy when comparing the low-power
> to the high mobility constraints of 6lowpans and vehicular networks:
> both would benefit if fewer messages were sent, and still vehicle
> networks are not so battery-limited as the sensors.
>
>> I realise that in a vehicular scenario, maintaining the mesh under
>> network may prove challenging.
>
> I think that is right.  Maintaining a mesh under is challenging in
> the vehicular scenarios.
>
> I think RFC6775 has a form of distributing routes (router-to-router
> interactions) but I doubt it describes loop avoidance, which should
> be part of mesh under, right?
>
> The section 5.6 needs more explanation.  Would you be interested?
>
> Also, this would be a typical IPv6-over-foo document, and such as
> maybe we would not need to describe too much routing/meshing detail.
>
> Alex
>>
>> Alexandru Petrescu wrote:
>>> Hello 6MAN participants,
>>>
>>> This is an update you about
>>> draft-petrescu-ipv6-over-80211p-01.txt: what happened with it
>>> since November last year?
>>>
>>> - slight textual modifications about one author affiliation. -
>>> announced on v6ops and on 6lo.  Received some private comments
>>> about its usefulness and where to discuss it.
>>>
>>> Please comment on this draft.
>>>
>>> http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01
>>>
>>> "Transmission of IPv6 Packets over IEEE 802.11p Networks"
>>> draft-petrescu-ipv6-over-80211p-01.txt
>>>
>>> "In order to transmit IPv6 packets on IEEE 802.11p networks
>>> there is a need to define a few parameters such as the
>>> recommended Maximum Transmission Unit size, the header format
>>> preceding the IPv6 base header, the Type value within it, and
>>> others.  This document describes these parameters for IPv6 and
>>> IEEE 802.11p networks; it portrays the layering of IPv6 on
>>> 802.11p similarly to other known 802.11 and Ethernet layers, by
>>> using an existing Ethernet Adaptation Layer.
>>>
>>> In addition, the document attempts to list what is different in
>>> 802.11p compared to more 'traditional' 802.11a/b/g/n layers,
>>> layers over which IPv6 protocols run ok.  Most notably, the
>>> operation outside the context of a BSS (OCB) has impact on IPv6
>>> handover behaviour and on IPv6 security.
>>>
>>> An example of an IPv6 packet captured while transmitted over an
>>> IEEE 802.11p link is given."
>>>
>>> Alex
>>>
>>> --- Ce courrier électronique ne contient aucun virus ou logiciel
>>> malveillant parce que la protection avast! Antivirus est active.
>>> http://www.avast.com
>>>
>>>
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------