Subject: Re: [its] IP over 802.11p

From: "Dowdell, John" <[email-masked]>
Date: Mon, 11 Feb 2013 13:50:33 +0000

Alex

Is anyone making 802.11p radios commercially at reasonable cost? The few I have seen seem to be very expensive (few k$) and there appears to be little support in Linux. 802.11s on the other hand is available on standard Wi-Fi dongles (from $15) and drivers are already available in Linux. Is it correct that 802.11p is mandated for ITS in some regions?

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: 31 January 2013 15:17
To: [email-masked]
Subject: Re: [its] IP over 802.11p

Le 31/01/2013 14:47, Thierry Ernst a écrit :
>
> Well, we do actually run IPv6 over 11p (with or without
> GeoNetworking), so I don't see what kind of issues there might be
> ...

I have some clarification questions about EtherType and 802.11p and
GeoNetworking.

I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet
header uses EtherType soon-to-be-0x8947, whereas when you run IPv6 over
11p without GeoNetworking, the Ethernet header uses EtherType 0x86DD.
This is just a supposition, I don't know how you run it.

Also, if I run IPv4 over 11p with GeoNetworking - should I use EtherType
soon-to-be-0x8947?  Or other?  I suppose that if I run IPv4 over 11p
without GeoNetworking I should use EtherType 0x0800, and if it's ARP
over 802.11p still without GeoNetworking then I should use EtherType 0x0806.

(the letter we've seen recently is not clear whether that allocation is
for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for GeoNetworking
for IPv6, for GeoNetworking for IPv4, etc.  It is not clear either
whether GeoNetworking supports IPv4 or not, or under what form).

I also have some questions about the relationship between the nature of
some 802.11p links (no ESSID, absence of link-layer security - as
opposed to WiFi which has ESSID and link-layer security) and IP.

For example - will V2V prefix exchange using Router Advertisements work
easier on 802.11p links (easier than on WiFi), because the ESSID does
not need to be discovered, the ad-hoc network does not need to be formed
- suffices it to send packets on a certain channel.

(in a V2V draft one seems to say that the presence of Access Point is
absolutely necessary in order for 802.11p to work; but in our
experimentations this is not the case - it is possible to establish
direct vehicle-to-vehicle IP-over-802.11p communications without the
presence of a fixed 802.11p Access Point).

For another example - will IP prefer that the 802.11p channel in France
be 176, 178 or 180? (with WiFi, IP does not care because it can work on
any of the 11 channels equally well, but with 802.11p each of these
three channels seem to be reserved for "Services", "Control" and
"Services").

For another example - is all the security on these links entirely
relaying on IP layer security (IPsec, SeND, EAP, PANA)?

I think finding consensus on some of these questions could lead to
interoperability.

Alex

>
> Regards, Thierry
>
>
>
> On 31/01/13 13:55, Alexandru Petrescu wrote:
>> Given current discussions, I think it may be worth considering a
>> work item about how to run IP over 802.11p.
>>
>> One of the things to say would be whether or not this is IPv6 only
>> or IPv4 also.
>>
>> This would say how this would work _without_ GeoNetworking.
>>
>> It would agree on the EtherType and/or whether there are new ones,
>>  several or only one, or reusing existing EtherTypes.
>>
>> It could be as simple as to say that IP works over 802.11p just as
>> it works over 802.11b - no modifications.
>>
>> What do you think?
>>
>> Alex
>>
>> Le 30/01/2013 11:10, Alexandru Petrescu a écrit :
>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a écrit :
>>>> Hi Alexandru,
>>>>
>>>> IEEE talk only hexa in their Ethertype files.
>>>
>>> I tend to agree that #8947 is a hexadecimal notation also
>>> because the sharp sign preceding it, and because if it were
>>> decimal it would convert to 22F3 which is already reserved for
>>> trill.
>>>
>>> I just watend to make sure.
>>>
>>> Alex
>>>
>>>>
>>>> Regards,
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message----- From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: [email-masked]
>>>>> Subject: Re: [its] What do we need to make ITS WG go forward?
>>>>> - EtherType for ITS
>>>>>
>>>>> Hello Dan,
>>>>>
>>>>> Thank you for the email.
>>>>>
>>>>> I think we definitely need a good interface with IEEE about
>>>>> this.
>>>>>
>>>>> Maybe you could ask them whether this number is hexa or
>>>>> decimal, so we know what to put in implementation (e.g.
>>>>> wireshark packet analyzers, and 802.11p/etsi-its
>>>>> implementations).
>>>>>
>>>>> Also, I am interested to learn whether this deserves being
>>>>> reserved at IANA.
>>>>>
>>>>> Alex
>>>>>
>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> The documents that you are referring (on the ETSI server)
>>>>>> are not freely accessible. A password is required, and
>>>>>> probably only ETSI members have the access information.
>>>>>>
>>>>>> The responsibility for assigning EtherType values is with
>>>>>> the IEEE Registration Authority. They maintain a public
>>>>>> list (updated daily) at
>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt
>>>>>>
>>>>>>
>>>>>>
and according to this list the value 8947 is not allocated.
>>>>>> Now, the public listing information for EtherTypes bears a
>>>>>>  disclaimer that says
>>>>>>
>>>>>> * This is a partial listing of all assigned EtherType
>>>>>> Fields. Not
>>>>> all
>>>>>> recipients wish to publish their assignment at this time.
>>>>>>
>>>>>> Did ETSI require for this information not to be published?
>>>>>> It does not look useful if they want to encourage
>>>>>> interoperability
>>>>>>
>>>>>> Value 0707 mentioned in the thread is not allocated
>>>>>> either.
>>>>>>
>>>>>> Let me know if I can help (as IETF liaison to the
>>>>>> IEEE-SA).
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> *From:[email-masked] [mailto:[email-masked]]
>>>>>> *On Behalf Of *Thierry Ernst *Sent:* Wednesday, January
>>>>>> 30, 2013 11:11 AM *To:* [email-masked] *Subject:* Re: [its]
>>>>>> What do we need to make ITS WG go forward? - EtherType for
>>>>>> ITS
>>>>>>
>>>>>>
>>>>>> Alex,
>>>>>>
>>>>>> IEEE have assigned Ethernet Type Field number #8947 for
>>>>>> ITS use (ETSI TC ITS's GeoNetworking). Check the following
>>>>>> document available on the ETSI server:
>>>>>>
>>>>>> ITS(13)000020
>>>>>> <http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%2813%2900002
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf>
>>>>>> Ethernet Type Field number for GeoNetworking
>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000020_Eth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ernet_Type_Field_number_for_GeoNetworking.pdf
>>>>>>
>>>>>> Regards, Thierry.
>>>>>>
>>>>>>
>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote:
>>>>>>
>>>>>> Le 28/01/2013 14:16, Joe Klein a écrit :
>>>>>>
>>>>>> I really dislike the fact that ISO is charging for the ISO
>>>>>>  21217 - Architecture & ISO 21210 - IPv6 Networking.
>>>>>>
>>>>>> Does this make it any better? Safer?  Should ISO now have
>>>>>> cybersecurity and safety liability if the specification
>>>>>> leads to deaths and damage to property?
>>>>>>
>>>>>>
>>>>>> Does it make any better interoperable as well?
>>>>>>
>>>>>> EtherType 0x0707 described in ITS documents, implemented,
>>>>>> but not specified by IEEE nor reserved at IANA - does not
>>>>>> make it interoperable.
>>>>>>
>>>>>> One wouldn't think that this 0x0707 ethertype be reserved
>>>>>> by
>>>>> somebody
>>>>>> who is not IANA nor IEEE?
>>>>>>
>>>>>> (see a good example of interoperability: IPv6 0x86dd
>>>>>> ethertype is reserved at IEEE and at IANA
>>>>>>
>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> Alex
>>>>>>
>>>>>> Or should these standards remain in
>>>>>>
>>>>>> the public domain, for researches to review and validate?
>>>>>>
>>>>>> Just my 2 cents.
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst
>>>>>> <[email-masked]> <mailto:[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> At this stage, I don't think a new working group is needed.
>>>>>> First, it would need a charter, and support from the
>>>>>> industry. But more importantly, IETF WGs are not usually
>>>>>> sector-driven, so it means the different issues pertaining
>>>>>> to ITS should be brought to
>>>>> VARIOUS
>>>>>> existing WGs, and a WG should only be created if there is
>>>>>> an important issue for which there is no existing WG that
>>>>>> could work on it.
>>>>>>
>>>>>> This said, as mentioned earlier, ITS is not only about
>>>>>> vehicular communications, though the issues listed by
>>>>>> Alexandru below mostly consider vehicular communications.
>>>>>>
>>>>>> What ITS really needs is the definition of a common
>>>>>> communication architecture and the definition of what
>>>>>> features should be comprised for an IPv6 networking stack
>>>>>> deployed for ITS use cases. This cannot be done at IETF,
>>>>>> and actually already exists at ISO: - ISO 21217 -
>>>>>> Architecture - ISO 21210 - IPv6 Networking
>>>>>>
>>>>>> As an input to the discussion, please consider reading
>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web
>>>>>> page: http://www.itssv6.eu/documentation/ D2.2 provides an
>>>>>> analysis of the currently published version of ISO 21210,
>>>>>> but new work items have been launched since then to address
>>>>>> remaining issues.
>>>>>>
>>>>>> Regards, Thierry.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote:
>>>>>>
>>>>>>
>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a écrit :
>>>>>>
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> This is just one opinion, but I'd like to understand why
>>>>>> ITS would need its own IETF group. The work here is the
>>>>>> same (IMO) as what is taking place in MANET. I would vote
>>>>>> that this work be taken up in MANET.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Stan,
>>>>>>
>>>>>> Thank you for the offer.  I considered this offer since
>>>>>> some time.
>>>>>>
>>>>>> I try to understand whether some of these items on which I
>>>>>>  have interest could be brought in in MANET WG: - V2V using
>>>>>>  prefix exchange - VIN-based IP addressing scheme - ND
>>>>>> Prefix Delegation - PMIP-based network mobility - IPv6
>>>>>> single-address connecion 'sharing' with a cellular
>>>>>> operator and a vehicular moving network (type '64share' of
>>>>>> v6ops). - Default Route with DHCPv6.
>>>>>>
>>>>>> Please let me know.
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards, Stan
>>>>>>
>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote:
>>>>>>
>>>>>>
>>>>>> Hi Nabil,
>>>>>>
>>>>>> I think we already done some steps but not sure how far
>>>>>> now. We will need to propose the WG and provide the WG
>>>>>> charter, as use cases and work to be done in this group.
>>>>>> This charter needs to be approved by the IESG. I have not
>>>>>> attended the last meeting so not sure about the status
>>>>>> now,
>>>>>>
>>>>>> AB
>>>>>>
>>>>>> On 1/26/13, Nabil Benamar <[email-masked]>
>>>>>> <mailto:[email-masked]> wrote:
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'm still interested in this list and want to join voices
>>>>>> previously heard to make it a working group. So what
>>>>>> should we exactly do, to achieve this goal ?
>>>>>>
>>>>>>
>>>>>> 2013/1/26 Abdussalam Baryun <[email-masked]>
>>>>>> <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I was interested in this group but not sure where are we so
>>>>>> far. Is there progress, or is there issues/efforts that
>>>>>> need to be completed and volunteered.
>>>>>>
>>>>>> AB _______________________________________________ its
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- * * *تحياتي ، **Cordialement, Regards* * * * * *نبيل
>>>>>> بنعمروNabil Benamar* Professor of computer sciences
>>>>>> Simulation and Modelisation Laboratory Human Sciences
>>>>>> Faculty of Meknes Moulay Ismail* *University* Meknes,
>>>>>> Morocco *GSM: * *+ 212 6 70832236 http://nabilbenamar.com/
>>>>>>
>>>>>> *
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ----------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *
>>>>>>
>>>>>> _______________________________________________
>>>>> its
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ its
>>>>> mailing
>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ its
>>>>> mailing
>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ its
>>>>>> mailing
>>>>> list
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ its mailing
>>>>>> list [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ its mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>>>
>>>
>>> _______________________________________________ its mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/its
>>
>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Feb 2013 16:30:06 +0100

Le 11/02/2013 14:50, Dowdell, John a écrit :
> Alex
>
> Is anyone making 802.11p radios commercially at reasonable cost? The
> few I have seen seem to be very expensive (few k$) and there appears
> to be little support in Linux. 802.11s on the other hand is available
> on standard Wi-Fi dongles (from $15) and drivers are already
> available in Linux. Is it correct that 802.11p is mandated for ITS in
> some regions?

John,

Without advertising, we use finalized 802.11p hardware (OBU, RSU, etc.)
and support from ITRI Taiwan.  The complete package (drivers,
geonetworking, SDKs) is expensive yes in the range of thousands of
USDollars.

This uses MiniPCI 802.11p cards from Unex Technology e.g.
http://unex.com.tw/dsrc-wave which could be inserted in other non-ITRI
PC-like platforms.  I believe these cards may be relatively cheap.  I
don't know whether Unex offer drivers for these cards (be them binary or
open source), we use the binary drivers from ITRI.

I think yes, there seem to be little if any open source GPL driver
support in linux for 802.11p.  I am interested to learn if this exists
somewhere, even in a prototypical form.  We're only aware of SPITS
project, but were not very successful at trying it.

One advantage of .p is that it is regulated such as no need to pay a
license and still allowed to emit at high power levels (33dBm EU, 40dBm
US, compared to hundreds of milliWats for WiFi).  I.e. it is possible to
have two independent vehicles distanced by kilometers, without
infrastructure, and communicate, and without requiring license from
government (whereas in the case of WiFi one can't legally do more than a
hundred meters or so).

I am not sure this is the case for .s(?)  Could .s use high power levels
like EIRP 40dBm and without license?

Then,

I think yes 802.11p is mandated for ITS in Europe by ETSI ITS.

But unfortuntaly for me, the situation in the country I live (France)
seems to be that one is not allowed to use IP-over-802.11p without
geonetworking (i.e. not allowed to use the frequencies allocated to ITS
for 802.11p without using ETSI ITS i.e. geonetworking).

These factors seem to strongly hamper the development of vehicular
specific communication technology at IETF:
- lack of open-source driver codes for 802.11p
- lack of open and free-of-charge access to ETSI standards
- lack of open access to ETSI interoperability results
- lack of cheap hardware implementations of 802.11p
- lack of unregulated/unlicensed frequency allocated for IP-over-80211p
   for long range.
- technical misunderstanding between the ETSI point of view of what is
   IP and the IETF of same.

Although I may sound relatively pessimistic, I also consider I may be
wrong in my reasoning above.

Alex

> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> 31 January 2013 15:17 To: [email-masked] Subject: Re: [its] IP over
> 802.11p
>
> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6
> over 11p without GeoNetworking, the Ethernet header uses EtherType
> 0x86DD. This is just a supposition, I don't know how you run it.
>
> Also, if I run IPv4 over 11p with GeoNetworking - should I use
> EtherType soon-to-be-0x8947?  Or other?  I suppose that if I run
> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800,
> and if it's ARP over 802.11p still without GeoNetworking then I
> should use EtherType 0x0806.
>
> (the letter we've seen recently is not clear whether that allocation
> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for
> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc.  It is not
> clear either whether GeoNetworking supports IPv4 or not, or under
> what form).
>
> I also have some questions about the relationship between the nature
> of some 802.11p links (no ESSID, absence of link-layer security - as
> For example - will V2V prefix exchange using Router Advertisements
> work easier on 802.11p links (easier than on WiFi), because the
> ESSID does not need to be discovered, the ad-hoc network does not
> need to be formed - suffices it to send packets on a certain
> channel.
>
> For another example - will IP prefer that the 802.11p channel in
> France be 176, 178 or 180? (with WiFi, IP does not care because it
> can work on any of the 11 channels equally well, but with 802.11p
> each of these three channels seem to be reserved for "Services",
> "Control" and "Services").
>
>>> One of the things to say would be whether or not this is IPv6
>>> only or IPv4 also.
>>>
>>> It would agree on the EtherType and/or whether there are new
>>> ones, several or only one, or reusing existing EtherTypes.
>>>
>>> It could be as simple as to say that IP works over 802.11p just
>>> as it works over 802.11b - no modifications.
>>>
>>> What do you think?
>>>
>>> Alex
>>>
>>>>>> [mailto:[email-masked]] On Behalf Of Alexandru
>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To:
>>>>>> [email-masked] Subject: Re: [its] What do we need to make
>>>>>> ITS WG go forward? - EtherType for ITS
>>>>>>
>>>>>> Hello Dan,
>>>>>>
>>>>>> Thank you for the email.
>>>>>>
>>>>>>> Now, the public listing information for EtherTypes bears
>>>>>>> a disclaimer that says
>>>>>>>
>>>>>>> Did ETSI require for this information not to be
>>>>>>> published? It does not look useful if they want to
>>>>>>> encourage interoperability
>>>>>>>
>>>>>>> What do we need to make ITS WG go forward? - EtherType
>>>>>>> for ITS
>>>>>>>
>>>>>>>
>>>>>>> Alex,
>>>>>>>
>>>>>>> ITS use (ETSI TC ITS's GeoNetworking). Check the
>>>>>>> following document available on the ETSI server:
>>>>>>>
>>>>>>> ITS(13)000020
>>>>>>> I really dislike the fact that ISO is charging for the
>>>>>>> ISO 21217 - Architecture & ISO 21210 - IPv6 Networking.
>>>>>>>
Alex
>>>>>>> At this stage, I don't think a new working group is
>>>>>>> needed. First, it would need a charter, and support from
>>>>>>> the industry. But more importantly, IETF WGs are not
>>>>>>> usually sector-driven, so it means the different issues
>>>>>>> pertaining to ITS should be brought to
>>>>>> VARIOUS
>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project
>>>>>>> web page: http://www.itssv6.eu/documentation/ D2.2
>>>>>>> provides an analysis of the currently published version
>>>>>>> of ISO 21210, but new work items have been launched
>>>>>>> since then to address remaining issues.
>>>>>>>
>>>>>>> Regards, Thierry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  same (IMO) as what is taking place in MANET. I would
>>>>>>> vote that this work be taken up in MANET.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stan,
>>>>>>>
>>>>>>> I try to understand whether some of these items on which
>>>>>>> I have interest could be brought in in MANET WG: - V2V
>>>>>>> using prefix exchange - VIN-based IP addressing scheme -
>>>>>>> ND Prefix Delegation - PMIP-based network mobility - IPv6
>>>>>>> operator and a vehicular moving network (type '64share'
>>>>>>> of v6ops). - Default Route with DHCPv6.
>>>>>>>
>>>>>>> Please let me know.
>>>>>>>
>>>>>>> Yours,
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards, Stan
>>>>>>>
>>>>>>>  This charter needs to be approved by the IESG. I have
>>>>>>> not attended the last meeting so not sure about the
>>>>>>> status now,
>>>>>>>
>>>>>>> AB
>>>>>>>
>>>>>>> I was interested in this group but not sure where are we
>>>>>>> so far. Is there progress, or is there issues/efforts
>>>>>>> that need to be completed and volunteered.
>>>>>>>
----------
>>>>>>> mailing list [email-masked]
> [email-masked] https://www.ietf.org/mailman/listinfo/its The
> information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially
> sensitive information. The contents of this e-mail are for the
> intended recipient only and therefore if you wish to disclose the
> information contained within this e-mail or attached files, please
> contact the sender prior to any such disclosure. If you are not the
> intended recipient, any disclosure, copying or distribution is
> prohibited. Please also contact the sender and inform them of the
> error and delete the e-mail, including any attached files from your
> system. Cassidian Limited, Registered Office : Quadrant House,
> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
> http://www.cassidian.com
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Feb 2013 16:58:44 +0100

John,

What is the maximum distance range on which a single-link-hop 802.11s
can happen?  (between one STA and another, with void in between).

Is it possible to run IP over 802.11s without employing an intermediary
layer2.5 pre-specified IP mesh-networking?

Alex

Le 11/02/2013 16:30, Alexandru Petrescu a écrit :
>> Is anyone making 802.11p radios commercially at reasonable cost?
>> The few I have seen seem to be very expensive (few k$) and there
>> appears to be little support in Linux. 802.11s on the other hand is
>> available on standard Wi-Fi dongles (from $15) and drivers are
>> already available in Linux. Is it correct that 802.11p is mandated
>> for ITS in some regions?
>
> John,
>
> Without advertising, we use finalized 802.11p hardware (OBU, RSU,
> etc.) and support from ITRI Taiwan.  The complete package (drivers,
> http://unex.com.tw/dsrc-wave which could be inserted in other
> non-ITRI PC-like platforms.  I believe these cards may be relatively
> cheap.  I don't know whether Unex offer drivers for these cards (be
> them binary or open source), we use the binary drivers from ITRI.
>
> support in linux for 802.11p.  I am interested to learn if this
> exists somewhere, even in a prototypical form.  We're only aware of
> SPITS project, but were not very successful at trying it.
>
> license and still allowed to emit at high power levels (33dBm EU,
> 40dBm US, compared to hundreds of milliWats for WiFi).  I.e. it is
> possible to have two independent vehicles distanced by kilometers,
> without infrastructure, and communicate, and without requiring
> license from government (whereas in the case of WiFi one can't
> legally do more than a hundred meters or so).
>
> I am not sure this is the case for .s(?)  Could .s use high power
> levels like EIRP 40dBm and without license?
>
>
> Then,
>
> But unfortuntaly for me, the situation in the country I live
> (France) seems to be that one is not allowed to use IP-over-802.11p
> without geonetworking (i.e. not allowed to use the frequencies
> allocated to ITS for 802.11p without using ETSI ITS i.e.
> geonetworking).
>
> specific communication technology at IETF: - lack of open-source
> driver codes for 802.11p - lack of open and free-of-charge access to
> ETSI standards - lack of open access to ETSI interoperability
> results - lack of cheap hardware implementations of 802.11p - lack of
> unregulated/unlicensed frequency allocated for IP-over-80211p for
> long range. - technical misunderstanding between the ETSI point of
> view of what is IP and the IETF of same.
>
> Although I may sound relatively pessimistic, I also consider I may
> be wrong in my reasoning above.
>
> Alex
>
>>
>> John
>>
>> Sent: 31 January 2013 15:17 To: [email-masked] Subject: Re: [its] IP
>> over 802.11p
>>
>>> GeoNetworking), so I don't see what kind of issues there might
>>> be ...
>>
>> I have some clarification questions about EtherType and 802.11p
>> and GeoNetworking.
>>
>> I guess when you run IPv6 over 11p with GeoNetworking, the
>> Ethernet header uses EtherType soon-to-be-0x8947, whereas when you
>> run IPv6 over 11p without GeoNetworking, the Ethernet header uses
>> EtherType 0x86DD. This is just a supposition, I don't know how you
>> run it.
>>
>> (the letter we've seen recently is not clear whether that
>> allocation is for GeoNetworking, for IP-over-802.11p, for ETSI ITS,
>> for GeoNetworking for IPv6, for GeoNetworking for IPv4, etc.  It is
>> not clear either whether GeoNetworking supports IPv4 or not, or
>> under what form).
>>
>> I also have some questions about the relationship between the
>> nature of some 802.11p links (no ESSID, absence of link-layer
>> security - as opposed to WiFi which has ESSID and link-layer
>> security) and IP.
>>
>> (in a V2V draft one seems to say that the presence of Access Point
>> is absolutely necessary in order for 802.11p to work; but in our
>> experimentations this is not the case - it is possible to
>> establish direct vehicle-to-vehicle IP-over-802.11p communications
>> without the presence of a fixed 802.11p Access Point).
>>
>>>> Given current discussions, I think it may be worth considering
>>>> a work item about how to run IP over 802.11p.
>>>>
>>>> It could be as simple as to say that IP works over 802.11p
>>>> just as it works over 802.11b - no modifications.
>>>>
>>>> What do you think?
>>>>
>>>> Alex
>>>>
>>>>> decimal it would convert to 22F3 which is already reserved
>>>>> for trill.
>>>>>
>>>>>>> I think we definitely need a good interface with IEEE
>>>>>>> about this.
>>>>>>>
>>>>>>> Also, I am interested to learn whether this deserves
>>>>>>> being reserved at IANA.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> The documents that you are referring (on the ETSI
>>>>>>>> server) are not freely accessible. A password is
>>>>>>>> required, and probably only ETSI members have the
>>>>>>>> access information.
>>>>>>>>
>>>>>>>> The responsibility for assigning EtherType values is
>>>>>>>> with the IEEE Registration Authority. They maintain a
>>>>>>>> public list (updated daily) at
>>>>>>>> Now, the public listing information for EtherTypes
>>>>>>>> bears a disclaimer that says
>>>>>>>>
>>>>>>>> *From:[email-masked]
>>>>>>>> [mailto:[email-masked]] *On Behalf Of *Thierry
>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM
>>>>>>>> *To:* [email-masked] *Subject:* Re: [its] What do we need
>>>>>>>> to make ITS WG go forward? - EtherType for ITS
>>>>>>>>
>>>>>>>>
>>>>>>>> Alex,
>>>>>>>>
>>>>>>>> IEEE have assigned Ethernet Type Field number #8947
>>>>>>>> for ITS use (ETSI TC ITS's GeoNetworking). Check the
>>>>>>>> Does this make it any better? Safer?  Should ISO now
>>>>>>>> have cybersecurity and safety liability if the
>>>>>>>> specification leads to deaths and damage to property?
>>>>>>>>
>>>>>>>>
>>>>>>>> EtherType 0x0707 described in ITS documents,
>>>>>>>> implemented, but not specified by IEEE nor reserved at
>>>>>>>> IANA - does not make it interoperable.
>>>>>>>>
>>>>>>>> One wouldn't think that this 0x0707 ethertype be
>>>>>>>> reserved by
>>>>>>> somebody
>>>>>>>> <[email-masked]>
>>>>>>>> <mailto:[email-masked]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> needed. First, it would need a charter, and support
>>>>>>>> from the industry. But more importantly, IETF WGs are
>>>>>>>> not usually sector-driven, so it means the different
>>>>>>>> issues pertaining to ITS should be brought to
>>>>>>> VARIOUS
>>>>>>>> existing WGs, and a WG should only be created if there
>>>>>>>> is an important issue for which there is no existing WG
>>>>>>>> that could work on it.
>>>>>>>>
>>>>>>>> features should be comprised for an IPv6 networking
>>>>>>>> stack deployed for ITS use cases. This cannot be done
>>>>>>>> at IETF, and actually already exists at ISO: - ISO
>>>>>>>> 21217 - Architecture - ISO 21210 - IPv6 Networking
>>>>>>>>
>>>>>>>> documents D2.1 and D2.2 available on the ITSSv6
>>>>>>>> project web page: http://www.itssv6.eu/documentation/
>>>>>>>> D2.2 provides an analysis of the currently published
>>>>>>>> version of ISO 21210, but new work items have been
>>>>>>>> launched since then to address remaining issues.
>>>>>>>>
>>>>>>>> Regards, Thierry.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is just one opinion, but I'd like to understand
>>>>>>>> why ITS would need its own IETF group. The work here is
>>>>>>>> the same (IMO) as what is taking place in MANET. I
>>>>>>>> would vote that this work be taken up in MANET.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Stan,
>>>>>>>>
>>>>>>>> Thank you for the offer.  I considered this offer
>>>>>>>> since some time.
>>>>>>>>
>>>>>>>> I try to understand whether some of these items on
>>>>>>>> which I have interest could be brought in in MANET WG:
>>>>>>>> - V2V using prefix exchange - VIN-based IP addressing
>>>>>>>> scheme - ND Prefix Delegation - PMIP-based network
>>>>>>>> mobility - IPv6 single-address connecion 'sharing' with
>>>>>>>> a cellular operator and a vehicular moving network
>>>>>>>> (type '64share' of v6ops). - Default Route with
>>>>>>>> DHCPv6.
>>>>>>>>
>>>>>>>> Please let me know.
>>>>>>>>
>>>>>>>> Yours,
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards, Stan
>>>>>>>>
>>>>>>>> I think we already done some steps but not sure how
>>>>>>>> far now. We will need to propose the WG and provide the
>>>>>>>> WG charter, as use cases and work to be done in this
>>>>>>>> group. This charter needs to be approved by the IESG. I
>>>>>>>> have not attended the last meeting so not sure about
>>>>>>>> the status now,
>>>>>>>>
>>>>>>>> AB
>>>>>>>>
>>>>>>>> I'm still interested in this list and want to join
>>>>>>>> voices previously heard to make it a working group. So
>>>>>>>> what should we exactly do, to achieve this goal ?
>>>>>>>>
>>>>>>>>
>>>>>>>> I was interested in this group but not sure where are
>>>>>>>> we so far. Is there progress, or is there
>>>>>>>> issues/efforts that need to be completed and
>>>>>>>> volunteered.
>>>>>>>>
>>>>>>>> -- * * *تحياتي ، **Cordialement, Regards* * * * *
>>>>>>>> *نبيل بنعمروNabil Benamar* Professor of computer
>>>>>>>> sciences Simulation and Modelisation Laboratory Human
>>>>>>>> Sciences Faculty of Meknes Moulay Ismail* *University*
>>>>>>>> Meknes, Morocco *GSM: * *+ 212 6 70832236
>>>>>>>> http://nabilbenamar.com/
>>>>>>>>
>>>>>>>> *
>>>>>>>>
>>>>>>>>
>> contact the sender prior to any such disclosure. If you are not
>> the intended recipient, any disclosure, copying or distribution is
>> error and delete the e-mail, including any attached files from
>> your system. Cassidian Limited, Registered Office : Quadrant
>> House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:
>> 04191036 http://www.cassidian.com
>>
>>
>
>

---

From: "Dowdell, John" <[email-masked]>
Date: Mon, 11 Feb 2013 16:42:41 +0000

Hi Alex

802.11s uses standard g/n hardware so the range is the same as standard Wi-Fi, according to the regulations in force in your region. The MAC layer is also the same as g/n; mesh control appears to be done by adding some octets in front of the payload data. Support is provided in the Linux kernel using the unified Wi-Fi drivers, provided your hardware supports mesh mode (use 'iw list' to see).

802.11s is written up in section 13 and annex W of 802.11-2012, freely available from the IEEE web site. The mandatory default forwarding protocol is Hybrid Wireless Mesh Protocol (HWMP), inspired by AODV with metric-aided path selection, but I understand that you can change it to something else if you wish.

Hope this helps

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: 11 February 2013 15:59
To: [email-masked]
Subject: Re: [its] IP over 802.11s (was: IP over 802.11p)

John,

Alex

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 11 Feb 2013 23:03:33 +0100

Hello Alexandru,

> for 802.11p without using ETSI ITS i.e. geonetworking).

Do you have any reference that supports this statement? I have never heard of such restrictions in France so far.

Thank you,
Romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Feb 2013 12:26:49 +0100

Le 11/02/2013 23:03, Romain KUNTZ a écrit :
>> (France) seems to be that one is not allowed to use
>> IP-over-802.11p without geonetworking (i.e. not allowed to use the
>> frequencies allocated to ITS for 802.11p without using ETSI ITS
>> i.e. geonetworking).
>
> Do you have any reference that supports this statement? I have never
> heard of such restrictions in France so far.

Hello Romain,

What channel/frequency would one consider in France, for
IP-over-80211p-w/o-geonet?

About references - the quick study I did is on references from ARCEP and
ETSI, simplified below.

The site of ARCEP[*] says only the following frequencies are reserved
for ITS:
5 875  - 5 905  MHz "ITS"

But the ETSI[**] lists the following center frequencies, with a channel
spacing of 10MHz, and their purposes :
5 900 MHz - G5CC  (Control Channel)   - number 180
5 890 MHz - G5SC2 (Service Channel 2) - number 178
5 880 MHz - G5SC1 (Service Channel 1) - number 176
5 870 MHz - G5SC3 (Service Channel 3) - number 174
5 860 MHz - G5SC4 (Service Channel 4) - number 172
5 470 MHz to 5 725 MHz - G5SC5.

Crossing ARCEP with ETSI one notices that only G5CC, G5SC2 and G5SC1 can
be used in France for 'ITS'.

As for the specific purposes of each such channel for ITS, ETSI[**]
document says:
"G5SC1 and G5SC2 shall be used for ITS road safety and traffic
  efficiency applications".
"Other ITS user applications G5SC3, G5SC4 and G5SC5".

I speculate IP-over-80211p-without-geonet could be qualified as 'Other
ITS user applications', and would not be qualified as 'ITS road safety'
nor as 'traffic efficiency applications'.

It is for thess reasons that I speculate IP-over-80211p-without-geonet
is not possible in France.

I may be missing something?

Alex
[*] ARCEP "Autorité de régulation des comm. électroniques et des postes"
     https://www.espectre.arcep.fr/index.php
     (filled in "Fréquence Inférieure" as 5470MHz
      and "Fréquence Supérieure" as 5905MHz, then click "Rechercher",
      then locate "ITS" in that page)
[**] ETSI ITS Final draft ETSI ES 202 663 V1.1.0 (2009-11)
      Page 13
      Publicly available document retrieved on 12 February 2013 at

http://www.etsi.org/deliver/etsi_es/202600_202699/202663/01.01.00_50/es_202663v010100m.pdf

> Thank you, Romain
>> driver codes for 802.11p - lack of open and free-of-charge access
>> to ETSI standards - lack of open access to ETSI interoperability
>> results - lack of cheap hardware implementations of 802.11p - lack
>> of unregulated/unlicensed frequency allocated for IP-over-80211p
>> for long range. - technical misunderstanding between the ETSI
>> point of view of what is IP and the IETF of same.
>>
>>> Sent: 31 January 2013 15:17 To: [email-masked] Subject: Re: [its]
>>> IP over 802.11p
>>>
>>> Ethernet header uses EtherType soon-to-be-0x8947, whereas when
>>> you run IPv6 over 11p without GeoNetworking, the Ethernet header
>>> uses EtherType 0x86DD. This is just a supposition, I don't know
>>> how you run it.
>>>
>>>  IPv4 over 11p without GeoNetworking I should use EtherType
>>> 0x0800, and if it's ARP over 802.11p still without GeoNetworking
>>> then I should use EtherType 0x0806.
>>>
>>> allocation is for GeoNetworking, for IP-over-802.11p, for ETSI
>>> ITS, for GeoNetworking for IPv6, for GeoNetworking for IPv4,
>>> etc. It is not clear either whether GeoNetworking supports IPv4
>>> or not, or under what form).
>>>
>>> For example - will V2V prefix exchange using Router
>>> Advertisements work easier on 802.11p links (easier than on
>>> WiFi), because the ESSID does not need to be discovered, the
>>> ad-hoc network does not need to be formed - suffices it to send
>>> packets on a certain channel.
>>>
>>> (in a V2V draft one seems to say that the presence of Access
>>> Point is absolutely necessary in order for 802.11p to work; but
>>> in our experimentations this is not the case - it is possible to
>>> establish direct vehicle-to-vehicle IP-over-802.11p
>>> communications without the presence of a fixed 802.11p Access
>>> Point).
>>>
>>>  France be 176, 178 or 180? (with WiFi, IP does not care because
>>>  it can work on any of the 11 channels equally well, but with
>>> 802.11p each of these three channels seem to be reserved for
>>> "Services", "Control" and "Services").
>>>
>>> I think finding consensus on some of these questions could lead
>>> to interoperability.
>>>
>>> Alex
>>>
>>>>
>>>> Regards, Thierry
>>>>
>>>>
>>>>
>>>>> Given current discussions, I think it may be worth
>>>>> considering a work item about how to run IP over 802.11p.
>>>>>
>>>>>>>>> *To:* [email-masked] *Subject:* Re: [its] What do we
>>>>>>>>> need to make ITS WG go forward? - EtherType for ITS
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alex,
>>>>>>>>>
>>>>>>>>> I really dislike the fact that ISO is charging for
>>>>>>>>> the ISO 21217 - Architecture & ISO 21210 - IPv6
>>>>>>>>> Networking.
>>>>>>>>>
>>>>>>>>> implemented, but not specified by IEEE nor reserved
>>>>>>>>> at IANA - does not make it interoperable.
>>>>>>>>>
Alex
>>>>>>>>> from the industry. But more importantly, IETF WGs
>>>>>>>>> are not usually sector-driven, so it means the
>>>>>>>>> different issues pertaining to ITS should be brought
>>>>>>>>> to
>>>>>>>> VARIOUS
>>>>>>>>> existing WGs, and a WG should only be created if
>>>>>>>>> there is an important issue for which there is no
>>>>>>>>> existing WG that could work on it.
>>>>>>>>>
>>>>>>>>> This said, as mentioned earlier, ITS is not only
>>>>>>>>> about vehicular communications, though the issues
>>>>>>>>> listed by Alexandru below mostly consider vehicular
>>>>>>>>> communications.
>>>>>>>>>
>>>>>>>>> As an input to the discussion, please consider
>>>>>>>>> reading documents D2.1 and D2.2 available on the
>>>>>>>>> ITSSv6 project web page:
>>>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides an
>>>>>>>>> analysis of the currently published version of ISO
>>>>>>>>> 21210, but new work items have been launched since
>>>>>>>>> then to address remaining issues.
>>>>>>>>>
>>>>>>>>> Regards, Thierry.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> why ITS would need its own IETF group. The work here
>>>>>>>>> is the same (IMO) as what is taking place in MANET. I
>>>>>>>>> which I have interest could be brought in in MANET
>>>>>>>>> WG: - V2V using prefix exchange - VIN-based IP
>>>>>>>>> addressing scheme - ND Prefix Delegation -
>>>>>>>>> PMIP-based network mobility - IPv6 single-address
>>>>>>>>> connecion 'sharing' with a cellular operator and a
>>>>>>>>> vehicular moving network (type '64share' of v6ops). -
>>>>>>>>> Default Route with DHCPv6.
>>>>>>>>>
>>>>>>>>> Please let me know.
>>>>>>>>>
>>>>>>>>> Yours,
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards, Stan
>>>>>>>>>
>>>>>>>>> far now. We will need to propose the WG and provide
>>>>>>>>> the WG charter, as use cases and work to be done in
>>>>>>>>> this group. This charter needs to be approved by the
>>>>>>>>> IESG. I have not attended the last meeting so not
>>>>>>>>> sure about the status now,
>>>>>>>>>
>>>>>>>>> AB
>>>>>>>>>
>>>>>>>>> voices previously heard to make it a working group.
>>>>>>>>> So what should we exactly do, to achieve this goal ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I was interested in this group but not sure where
>>>>>>>>> are we so far. Is there progress, or is there
>>>>>>>>> AB _______________________________________________
>>>>>>>>> its mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>>> sciences Simulation and Modelisation Laboratory
>>>>>>>>> Human Sciences Faculty of Meknes Moulay Ismail*
>>>>>>>>> *University* Meknes, Morocco *GSM: * *+ 212 6
>>>>>>>>> 70832236 http://nabilbenamar.com/
>>>>>>>>>
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>>
----------
>>> information contained within this e-mail and any files attached
>>> to this e-mail is private and in addition may include
>>> commercially sensitive information. The contents of this e-mail
>>> are for the intended recipient only and therefore if you wish to
>>> disclose the information contained within this e-mail or attached
>>> files, please contact the sender prior to any such disclosure. If
>>> you are not the intended recipient, any disclosure, copying or
>>> distribution is prohibited. Please also contact the sender and
>>> inform them of the error and delete the e-mail, including any
>>> attached files from your system. Cassidian Limited, Registered
>>> Office : Quadrant House, Celtic Springs, Coedkernew, Newport,
>>> NP10 8FZ Company No: 04191036 http://www.cassidian.com
>>>
>>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 10:40:02 +0100

Romain - in linux what channel or frequency do you think could be used
for IP-over-80211p-without-geonetworking?

Alex

Le 12/02/2013 12:26, Alexandru Petrescu a écrit :
>>> IP-over-802.11p without geonetworking (i.e. not allowed to use
>>> the frequencies allocated to ITS for 802.11p without using ETSI
>>> ITS i.e. geonetworking).
>>
>> Do you have any reference that supports this statement? I have
>> never heard of such restrictions in France so far.
>
> Hello Romain,
>
> About references - the quick study I did is on references from ARCEP
> and ETSI, simplified below.
>
> The site of ARCEP[*] says only the following frequencies are
> reserved for ITS: 5 875  - 5 905  MHz "ITS"
>
> But the ETSI[**] lists the following center frequencies, with a
> channel spacing of 10MHz, and their purposes : 5 900 MHz - G5CC
> (Control Channel)   - number 180 5 890 MHz - G5SC2 (Service Channel
> 2) - number 178 5 880 MHz - G5SC1 (Service Channel 1) - number 176 5
> 870 MHz - G5SC3 (Service Channel 3) - number 174 5 860 MHz - G5SC4
> (Service Channel 4) - number 172 5 470 MHz to 5 725 MHz - G5SC5.
>
> Crossing ARCEP with ETSI one notices that only G5CC, G5SC2 and G5SC1
> can be used in France for 'ITS'.
>
> document says: "G5SC1 and G5SC2 shall be used for ITS road safety and
> traffic efficiency applications". "Other ITS user applications G5SC3,
> G5SC4 and G5SC5".
>
> I speculate IP-over-80211p-without-geonet could be qualified as
> 'Other ITS user applications', and would not be qualified as 'ITS
> road safety' nor as 'traffic efficiency applications'.
>
> It is for thess reasons that I speculate
> IP-over-80211p-without-geonet is not possible in France.
>
> Alex [*] ARCEP "Autorité de régulation des comm. électroniques et des
> postes" https://www.espectre.arcep.fr/index.php (filled in "Fréquence
> Inférieure" as 5470MHz and "Fréquence Supérieure" as 5905MHz, then
> click "Rechercher", then locate "ITS" in that page) [**] ETSI ITS
> Final draft ETSI ES 202 663 V1.1.0 (2009-11) Page 13 Publicly
> available document retrieved on 12 February 2013 at
>
>>> These factors seem to strongly hamper the development of
>>> vehicular specific communication technology at IETF: - lack of
>>> open-source driver codes for 802.11p - lack of open and
>>> free-of-charge access to ETSI standards - lack of open access to
>>> ETSI interoperability results - lack of cheap hardware
>>> implementations of 802.11p - lack of unregulated/unlicensed
>>> frequency allocated for IP-over-80211p for long range. -
>>> technical misunderstanding between the ETSI point of view of what
>>> is IP and the IETF of same.
>>>
>>> Although I may sound relatively pessimistic, I also consider I
>>> may be wrong in my reasoning above.
>>>
>>> Alex
>>>
>>>>
>>>> John
>>>>
>>>> Sent: 31 January 2013 15:17 To: [email-masked] Subject: Re:
>>>> [its] IP over 802.11p
>>>>
>>>>> GeoNetworking), so I don't see what kind of issues there
>>>>> might be ...
>>>>
>>>> I have some clarification questions about EtherType and
>>>> 802.11p and GeoNetworking.
>>>>
>>>> you run IPv6 over 11p without GeoNetworking, the Ethernet
>>>> header uses EtherType 0x86DD. This is just a supposition, I
>>>> don't know how you run it.
>>>>
>>>> EtherType soon-to-be-0x8947?  Or other?  I suppose that if I
>>>> run IPv4 over 11p without GeoNetworking I should use EtherType
>>>> 0x0800, and if it's ARP over 802.11p still without
>>>> GeoNetworking then I should use EtherType 0x0806.
>>>>
>>>> etc. It is not clear either whether GeoNetworking supports
>>>> IPv4 or not, or under what form).
>>>>
>>>> ad-hoc network does not need to be formed - suffices it to
>>>> send packets on a certain channel.
>>>>
>>>> Point is absolutely necessary in order for 802.11p to work;
>>>> but in our experimentations this is not the case - it is
>>>> possible to establish direct vehicle-to-vehicle
>>>> IP-over-802.11p communications without the presence of a fixed
>>>> 802.11p Access Point).
>>>>
>>>> For another example - will IP prefer that the 802.11p channel
>>>> in France be 176, 178 or 180? (with WiFi, IP does not care
>>>> because it can work on any of the 11 channels equally well, but
>>>> with 802.11p each of these three channels seem to be reserved
>>>> for "Services", "Control" and "Services").
>>>>
>>>> For another example - is all the security on these links
>>>> entirely relaying on IP layer security (IPsec, SeND, EAP,
>>>> PANA)?
>>>>
>>>> I think finding consensus on some of these questions could
>>>> lead to interoperability.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> Regards, Thierry
>>>>>
>>>>>
>>>>>
>>>>>> One of the things to say would be whether or not this is
>>>>>> IPv6 only or IPv4 also.
>>>>>>
>>>>>> It would agree on the EtherType and/or whether there are
>>>>>> new ones, several or only one, or reusing existing
>>>>>> EtherTypes.
>>>>>>
>>>>>>> I tend to agree that #8947 is a hexadecimal notation
>>>>>>> also because the sharp sign preceding it, and because if
>>>>>>> it were decimal it would convert to 22F3 which is already
>>>>>>> reserved for trill.
>>>>>>>
>>>>>>>>> -----Original Message----- From:
>>>>>>>>> [email-masked] [mailto:[email-masked]] On
>>>>>>>>> Behalf Of Alexandru Petrescu Sent: Wednesday, January
>>>>>>>>> 30, 2013 12:00 PM To: [email-masked] Subject: Re: [its]
>>>>>>>>> What do we need to make ITS WG go forward? -
>>>>>>>>> EtherType for ITS
>>>>>>>>>
>>>>>>>>> Hello Dan,
>>>>>>>>>
>>>>>>>>> Thank you for the email.
>>>>>>>>>
>>>>>>>>> I think we definitely need a good interface with
>>>>>>>>> IEEE about this.
>>>>>>>>>
>>>>>>>>> Maybe you could ask them whether this number is hexa
>>>>>>>>> or decimal, so we know what to put in implementation
>>>>>>>>> (e.g. wireshark packet analyzers, and
>>>>>>>>> 802.11p/etsi-its implementations).
>>>>>>>>>
>>>>>>>>>> The responsibility for assigning EtherType values
>>>>>>>>>> is with the IEEE Registration Authority. They
>>>>>>>>>> maintain a public list (updated daily) at
>>>>>>>>>> * This is a partial listing of all assigned
>>>>>>>>>> EtherType Fields. Not
>>>>>>>>> all
>>>>>>>>>> Value 0707 mentioned in the thread is not
>>>>>>>>>> allocated either.
>>>>>>>>>>
>>>>>>>>>> [mailto:[email-masked]] *On Behalf Of
>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, 2013
>>>>>>>>>> 11:11 AM *To:* [email-masked] *Subject:* Re: [its]
>>>>>>>>>> What do we need to make ITS WG go forward? -
>>>>>>>>>> EtherType for ITS
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Alex,
>>>>>>>>>>
>>>>>>>>>> IEEE have assigned Ethernet Type Field number
>>>>>>>>>> #8947 for ITS use (ETSI TC ITS's GeoNetworking).
>>>>>>>>>> Check the following document available on the ETSI
>>>>>>>>>> server:
>>>>>>>>>>
>>>>>>>>>> ITS(13)000020
>>>>>>>>>> Does this make it any better? Safer?  Should ISO
>>>>>>>>>> now have cybersecurity and safety liability if the
>>>>>>>>>> implemented, but not specified by IEEE nor
>>>>>>>>>> reserved at IANA - does not make it interoperable.
>>>>>>>>>>
>>>>>>>>>> (see a good example of interoperability: IPv6
>>>>>>>>>> 0x86dd ethertype is reserved at IEEE and at IANA
>>>>>>>>>>
>>>>>>>>>> At this stage, I don't think a new working group
>>>>>>>>>> is needed. First, it would need a charter, and
>>>>>>>>>> support from the industry. But more importantly,
>>>>>>>>>> IETF WGs are not usually sector-driven, so it means
>>>>>>>>>> the different issues pertaining to ITS should be
>>>>>>>>>> brought to
>>>>>>>>> VARIOUS
>>>>>>>>>> listed by Alexandru below mostly consider
>>>>>>>>>> vehicular communications.
>>>>>>>>>>
>>>>>>>>>> What ITS really needs is the definition of a
>>>>>>>>>> common communication architecture and the
>>>>>>>>>> definition of what features should be comprised for
>>>>>>>>>> an IPv6 networking stack deployed for ITS use
>>>>>>>>>> cases. This cannot be done at IETF, and actually
>>>>>>>>>> already exists at ISO: - ISO 21217 - Architecture -
>>>>>>>>>> ISO 21210 - IPv6 Networking
>>>>>>>>>>
>>>>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides
>>>>>>>>>> an analysis of the currently published version of
>>>>>>>>>> ISO 21210, but new work items have been launched
>>>>>>>>>> This is just one opinion, but I'd like to
>>>>>>>>>> understand why ITS would need its own IETF group.
>>>>>>>>>> The work here is the same (IMO) as what is taking
>>>>>>>>>> place in MANET. I would vote that this work be
>>>>>>>>>> taken up in MANET.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Stan,
>>>>>>>>>>
>>>>>>>>>> vehicular moving network (type '64share' of v6ops).
>>>>>>>>>> - Default Route with DHCPv6.
>>>>>>>>>>
>>>>>>>>>> Please let me know.
>>>>>>>>>>
>>>>>>>>>> Yours,
>>>>>>>>>>
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards, Stan
>>>>>>>>>>
>>>>>>>>>> I think we already done some steps but not sure
>>>>>>>>>> how far now. We will need to propose the WG and
>>>>>>>>>> provide the WG charter, as use cases and work to be
>>>>>>>>>> done in this group. This charter needs to be
>>>>>>>>>> approved by the IESG. I have not attended the last
>>>>>>>>>> meeting so not sure about the status now,
>>>>>>>>>>
>>>>>>>>>> AB
>>>>>>>>>>
>>>>>>>>>> voices previously heard to make it a working
>>>>>>>>>> group. So what should we exactly do, to achieve
>>>>>>>>>> this goal ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> its mailing
>>>>>>>>>> its mailing list [email-masked]
>>>> The information contained within this e-mail and any files
>>>> attached to this e-mail is private and in addition may include
>>>> commercially sensitive information. The contents of this
>>>> e-mail are for the intended recipient only and therefore if you
>>>> wish to disclose the information contained within this e-mail
>>>> or attached files, please contact the sender prior to any such
>>>> disclosure. If you are not the intended recipient, any
>>>> disclosure, copying or distribution is prohibited. Please also
>>>> contact the sender and inform them of the error and delete the
>>>> e-mail, including any attached files from your system.
>>>> Cassidian Limited, Registered Office : Quadrant House, Celtic
>>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036
>>>> http://www.cassidian.com
>>>>
>>>>
>>>
>>>

---

From: Romain KUNTZ <[email-masked]>
Date: Wed, 13 Feb 2013 11:31:00 +0100

Hello Alexandru,

> nor as 'traffic efficiency applications'.

Thank you for the pointers. From what I understand, ITS road safety is not tied to geonetworking, so I believe IP-over-80211p-without-geonet can be performed on any of the allowed channels.

Romain

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 13 Feb 2013 11:54:59 +0100

Please note that the below statement is not really correct. 
Geonetworking is not defining road safety! It is not at all needed for 
road safety. The frequency channels at 5,9 GHz (30 MHz) allocated in 
Europe are for road safety. This does not require GeoNetworking. In the 
so-called control channel (CCH) also service advertisement messages (ISO 
24102-5) will be transmitted.

Have also in mind that ETSI TC ITS was founded by members of ISO TC204 
WG16. The major part of ITS standards is done at ISO, not at ETSI. This 
is now complemented by work done jointly in ISO TC204 WG18 / CEN TC278 WG16

ISO 21217: ITS communication archtiecture
ISO 21212 / 21213 and others: usage of cellular networks in ITS
ISO 21214: Infrared communications
ISO 21215: M5 communications (this is 802.11p as can be used world-wide!)
ISO 21216: Millimetric wave communications
ISO 21218: Access technology support
ISO 21210 and others: IPv6 networking in ITS
ISO 24102-1: Local ITS station management
ISO 24102-2: Remote ITS station management (in preparation)
ISO 24102-3: Management service access points
ISO 24102-4: ITS station-internal management communications
ISO 24102-5: Fast service advertisement protocol
ISO 29281-1: Fast networking & transport protocol FNTP (actually this is 
for single-hop comms, and should be used instead of GeoNetworking - 
geo-dissemination of information can not be performed with multiple hops 
in a 5,9 GHz channel)
ISO 29281-2: Usage of FNTP in support of the European and Japanese DSRC 
(5,8 GHz)
TS 17423: Communication requirements and objectives of ITS-S 
applications for automatic selection of communication profiles
TS 17429: C-ITS application management in the global context
... and many others

Hans-Joachim Fischer

-- 
------------------------------------------------------------------------------
http://its-standards.info/ESF-News-2012-01.pdf
http://its-standards.info/ESF-News-2011-01.pdf
http://its-standards.info/ESF-News-2010-01.pdf
------------------------------------------------------------------------------
The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
------------------------------------------------------------------------------
Dr. Hans-Joachim Fischer
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340
+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
------------------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 15:04:39 +0100

Le 13/02/2013 11:54, Dr. Hans-Joachim Fischer a écrit :
> Geonetworking is not defining road safety! It is not at all needed
> for road safety.

Noted.

> The frequency channels at 5,9 GHz (30 MHz) allocated in Europe are
> for road safety. This does not require GeoNetworking. In the
> so-called control channel (CCH) also service advertisement messages
> (ISO 24102-5) will be transmitted.

Ok, but IP-over-80211p-without-geonetworking are neither Service
Advertisement messages (ISO 24102-5) nor Traffic Safety messages.  These
IP messages are for Entertainment - video stream, video call.

I guess there is a risk of interference between Entertainment IP and
Service Advertisements, and Road Safety, on this CCH channel.  No?

Alex

>
> Have also in mind that ETSI TC ITS was founded by members of ISO
> TC204 WG16. The major part of ITS standards is done at ISO, not at
> ETSI. This is now complemented by work done jointly in ISO TC204 WG18
> / CEN TC278 WG16
>
> ISO 21217: ITS communication archtiecture ISO 21212 / 21213 and
> others: usage of cellular networks in ITS ISO 21214: Infrared
> communications ISO 21215: M5 communications (this is 802.11p as can
> be used world-wide!) ISO 21216: Millimetric wave communications ISO
> 21218: Access technology support ISO 21210 and others: IPv6
> networking in ITS ISO 24102-1: Local ITS station management ISO
> 24102-2: Remote ITS station management (in preparation) ISO 24102-3:
>  Management service access points ISO 24102-4: ITS station-internal
> management communications ISO 24102-5: Fast service advertisement
> protocol ISO 29281-1: Fast networking & transport protocol FNTP
> (actually this is for single-hop comms, and should be used instead of
> GeoNetworking - geo-dissemination of information can not be performed
> with multiple hops in a 5,9 GHz channel) ISO 29281-2: Usage of FNTP
> in support of the European and Japanese DSRC (5,8 GHz) TS 17423:
> Communication requirements and objectives of ITS-S applications for
> automatic selection of communication profiles TS 17429: C-ITS
> application management in the global context ... and many others
>
>
> Hans-Joachim Fischer
>
>>> 'Other
>>>> ITS user applications', and would not be qualified as 'ITS road
>>>> safety' nor as 'traffic efficiency applications'.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 15:07:21 +0100

Le 13/02/2013 11:31, Romain KUNTZ a écrit :
>>>> the frequencies allocated to ITS for 802.11p without using
>>>> ETSI ITS i.e. geonetworking).
>>>
>> About references - the quick study I did is on references from
>> ARCEP and ETSI, simplified below.
>>
>> (Control Channel)   - number 180 5 890 MHz - G5SC2 (Service
>> Channel 2) - number 178 5 880 MHz - G5SC1 (Service Channel 1) -
>> number 176 5 870 MHz - G5SC3 (Service Channel 3) - number 174 5 860
>> MHz - G5SC4 (Service Channel 4) - number 172 5 470 MHz to 5 725 MHz
>> - G5SC5.
>>
>> Crossing ARCEP with ETSI one notices that only G5CC, G5SC2 and
>> G5SC1 can be used in France for 'ITS'.
>>
>> document says: "G5SC1 and G5SC2 shall be used for ITS road safety
>> and traffic efficiency applications". "Other ITS user applications
>> G5SC3, G5SC4 and G5SC5".
>>
> Thank you for the pointers. From what I understand, ITS road safety
> is not tied to geonetworking, so I believe
> IP-over-80211p-without-geonet can be performed on any of the allowed
> channels.

There would be no risk if I send entertainment vlc videostreams on the
Control Channel?

Could I really send whatever I want on this channel?

Alex

>> Alex [*] ARCEP "Autorité de régulation des comm. électroniques et
>> des postes" https://www.espectre.arcep.fr/index.php (filled in
>> "Fréquence Inférieure" as 5470MHz and "Fréquence Supérieure" as
>> 5905MHz, then click "Rechercher", then locate "ITS" in that page)
>> [**] ETSI ITS Final draft ETSI ES 202 663 V1.1.0 (2009-11) Page 13
Thank you, Romain
>>>> free-of-charge access to ETSI standards - lack of open access
>>>> to ETSI interoperability results - lack of cheap hardware
>>>> technical misunderstanding between the ETSI point of view of
>>>> what is IP and the IETF of same.
>>>>
>>>>> Ethernet header uses EtherType soon-to-be-0x8947, whereas
>>>>> when you run IPv6 over 11p without GeoNetworking, the
>>>>> Ethernet header uses EtherType 0x86DD. This is just a
>>>>> supposition, I don't know how you run it.
>>>>>
>>>>> Also, if I run IPv4 over 11p with GeoNetworking - should I
>>>>> use EtherType soon-to-be-0x8947?  Or other?  I suppose that
>>>>> if I run IPv4 over 11p without GeoNetworking I should use
>>>>> EtherType 0x0800, and if it's ARP over 802.11p still without
>>>>> allocation is for GeoNetworking, for IP-over-802.11p, for
>>>>> ETSI ITS, for GeoNetworking for IPv6, for GeoNetworking for
>>>>> IPv4, etc. It is not clear either whether GeoNetworking
>>>>> supports IPv4 or not, or under what form).
>>>>>
>>>>> IP-over-802.11p communications without the presence of a
>>>>> fixed 802.11p Access Point).
>>>>>
>>>>> For another example - will IP prefer that the 802.11p
>>>>> channel in France be 176, 178 or 180? (with WiFi, IP does not
>>>>> care because it can work on any of the 11 channels equally
>>>>> well, but with 802.11p each of these three channels seem to
>>>>> be reserved for "Services", "Control" and "Services").
>>>>>
>>>>>>> It could be as simple as to say that IP works over
>>>>>>> 802.11p just as it works over 802.11b - no
>>>>>>> modifications.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> also because the sharp sign preceding it, and because
>>>>>>>> if it were decimal it would convert to 22F3 which is
>>>>>>>> already reserved for trill.
>>>>>>>>
>>>>>>>>>> [email-masked] [mailto:[email-masked]]
>>>>>>>>>> On Behalf Of Alexandru Petrescu Sent: Wednesday,
>>>>>>>>>> January 30, 2013 12:00 PM To: [email-masked]
>>>>>>>>>> Subject: Re: [its] What do we need to make ITS WG
>>>>>>>>>> go forward? - EtherType for ITS
>>>>>>>>>>
>>>>>>>>>> Hello Dan,
>>>>>>>>>>
>>>>>>>>>> Thank you for the email.
>>>>>>>>>>
>>>>>>>>>> Maybe you could ask them whether this number is
>>>>>>>>>> hexa or decimal, so we know what to put in
>>>>>>>>>> implementation (e.g. wireshark packet analyzers,
>>>>>>>>>> and 802.11p/etsi-its implementations).
>>>>>>>>>>
>>>>>>>>>> Also, I am interested to learn whether this
>>>>>>>>>> deserves being reserved at IANA.
>>>>>>>>>>
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>>>>>> The responsibility for assigning EtherType
>>>>>>>>>>> values is with the IEEE Registration Authority.
>>>>>>>>>>> They maintain a public list (updated daily) at
>>>>>>>>>>> Now, the public listing information for
>>>>>>>>>>> EtherTypes bears a disclaimer that says
>>>>>>>>>>>
>>>>>>>>>>> published? It does not look useful if they want
>>>>>>>>>>> to encourage interoperability
>>>>>>>>>>>
>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30,
>>>>>>>>>>> 2013 11:11 AM *To:* [email-masked] *Subject:* Re:
>>>>>>>>>>> [its] What do we need to make ITS WG go forward?
>>>>>>>>>>> - EtherType for ITS
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Alex,
>>>>>>>>>>>
>>>>>>>>>>> Check the following document available on the
>>>>>>>>>>> ETSI server:
>>>>>>>>>>>
>>>>>>>>>>> ITS(13)000020
>>>>>>>>>>> I really dislike the fact that ISO is charging
>>>>>>>>>>> for the ISO 21217 - Architecture & ISO 21210 -
>>>>>>>>>>> IPv6 Networking.
>>>>>>>>>>>
>>>>>>>>>>> now have cybersecurity and safety liability if
>>>>>>>>>>> the specification leads to deaths and damage to
>>>>>>>>>>> property?
>>>>>>>>>>>
>>>>>>>>>>>
Alex
>>>>>>>>>>> IETF WGs are not usually sector-driven, so it
>>>>>>>>>>> means the different issues pertaining to ITS
>>>>>>>>>>> should be brought to
>>>>>>>>>> VARIOUS
>>>>>>>>>>>  there is an important issue for which there is
>>>>>>>>>>> no existing WG that could work on it.
>>>>>>>>>>>
>>>>>>>>>>>  about vehicular communications, though the
>>>>>>>>>>> issues listed by Alexandru below mostly consider
>>>>>>>>>>> definition of what features should be comprised
>>>>>>>>>>> for an IPv6 networking stack deployed for ITS
>>>>>>>>>>> use cases. This cannot be done at IETF, and
>>>>>>>>>>> actually already exists at ISO: - ISO 21217 -
>>>>>>>>>>> http://www.itssv6.eu/documentation/ D2.2
>>>>>>>>>>> provides an analysis of the currently published
>>>>>>>>>>> version of ISO 21210, but new work items have
>>>>>>>>>>> been launched since then to address remaining
>>>>>>>>>>> issues.
>>>>>>>>>>>
>>>>>>>>>>> Regards, Thierry.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> understand why ITS would need its own IETF
>>>>>>>>>>> group. The work here is the same (IMO) as what is
>>>>>>>>>>> taking place in MANET. I would vote that this
>>>>>>>>>>> work be taken up in MANET.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Stan,
>>>>>>>>>>>
>>>>>>>>>>> I try to understand whether some of these items
>>>>>>>>>>> on which I have interest could be brought in in
>>>>>>>>>>> MANET WG: - V2V using prefix exchange -
>>>>>>>>>>> VIN-based IP addressing scheme - ND Prefix
>>>>>>>>>>> Delegation - PMIP-based network mobility - IPv6
>>>>>>>>>>> single-address connecion 'sharing' with a
>>>>>>>>>>> cellular operator and a vehicular moving network
>>>>>>>>>>> provide the WG charter, as use cases and work to
>>>>>>>>>>> be done in this group. This charter needs to be
>>>>>>>>>>> approved by the IESG. I have not attended the
>>>>>>>>>>> last meeting so not sure about the status now,
>>>>>>>>>>>
>>>>>>>>>>> AB
>>>>>>>>>>>
>>>>>>>>>>> I'm still interested in this list and want to
>>>>>>>>>>> join voices previously heard to make it a
>>>>>>>>>>> working group. So what should we exactly do, to
>>>>>>>>>>> achieve this goal ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <mailto:[email-masked]>
----------
>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>> <mailto:[email-masked]>
>>>>> attached to this e-mail is private and in addition may
>>>>> include commercially sensitive information. The contents of
>>>>> this e-mail are for the intended recipient only and
>>>>> therefore if you wish to disclose the information contained
>>>>> within this e-mail or attached files, please contact the
>>>>> sender prior to any such disclosure. If you are not the
>>>>> intended recipient, any disclosure, copying or distribution
>>>>> is prohibited. Please also contact the sender and inform them
>>>>> of the error and delete the e-mail, including any attached
>>>>> files from your system. Cassidian Limited, Registered Office
>>>>> : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10
>>>>> 8FZ Company No: 04191036 http://www.cassidian.com
>>>>>
>>>>>
>>>>
>>>>

---

From: Roberto Baldessari <[email-masked]>
Date: Wed, 13 Feb 2013 17:07:46 +0000

Dear Hans-Joachim,

> Have also in mind that ETSI TC ITS was founded by members of ISO TC204 WG16. The major part of ITS standards is done at ISO, not at ETSI. This is now complemented by work done > > jointly in ISO TC204 WG18 / CEN TC278 WG16

It would be more useful if we used this list to discuss technical matters, rather than SDO fights.

You made two wrong statements and I have to address them.

ETSI TC ITS was founded by several partners and I would say that the Car2Car Consortium partners played a bigger role in founding it, than the ISO TC204 partners. Look at who has produced more ETSI ITS standards and who has been chairing the ETSI WGs and the whole TC.

Second "The major part of ITS standards is done at ISO, not at ETSI". This is your wishful thinking.

@all in this list: car makers are going to deploy V2X based on IEEE, ETSI and SAE standards. Their statements are everywhere, e.g. the last ETSI ITS workshop. Go and check.

I am glad to continue the technical discussion and stop the SDO fights. Everyone on the list can make his own opinion on which standards will hit the market.

Best regards,

Roberto

---

From: Roberto Baldessari <[email-masked]>
Date: Wed, 13 Feb 2013 17:24:13 +0000

Alex,

Let me address some of your points and sorry if I do not contribute often to this list.

ETSI standards are free and publicly available, once published (as opposed to other SDOs' standards).

There are many 11p prototypes. Many projects in Europe developed them. I could name a few (including my company's) but I would do it off-line to avoid advertising, if you are interested.

Are you sure ETSI interoperability results are not open? Each participant receives a grade which is not publicly available, but some results should be publicly available.

Cheap hardware 11p implementations will come. It's required by the automotive industry. It's about time.

I don't understand why you don't see GeoNetworking as a feature. You seem to consider it as an obstacle? It's a protocol. IPv6 can run on top of it with some advantages. If you think a better protocol stack should be designed, you can propose it to the industry that should eventually deploy it. However, I think it makes more sense to start from what has been done so far. E.g. review what could be done with IPv6 over GN.

Best regards,

Roberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: 11 February 2013 16:30
To: Dowdell, John
Cc: [email-masked]
Subject: Re: [its] IP over 802.11p

Le 11/02/2013 14:50, Dowdell, John a écrit :
> on standard Wi-Fi dongles (from $15) and drivers are already available 
> in Linux. Is it correct that 802.11p is mandated for ITS in some 
> regions?

John,

Without advertising, we use finalized 802.11p hardware (OBU, RSU, etc.) and support from ITRI Taiwan.  The complete package (drivers, geonetworking, SDKs) is expensive yes in the range of thousands of USDollars.

This uses MiniPCI 802.11p cards from Unex Technology e.g.
http://unex.com.tw/dsrc-wave which could be inserted in other non-ITRI PC-like platforms.  I believe these cards may be relatively cheap.  I don't know whether Unex offer drivers for these cards (be them binary or open source), we use the binary drivers from ITRI.

I think yes, there seem to be little if any open source GPL driver support in linux for 802.11p.  I am interested to learn if this exists somewhere, even in a prototypical form.  We're only aware of SPITS project, but were not very successful at trying it.

One advantage of .p is that it is regulated such as no need to pay a license and still allowed to emit at high power levels (33dBm EU, 40dBm US, compared to hundreds of milliWats for WiFi).  I.e. it is possible to have two independent vehicles distanced by kilometers, without infrastructure, and communicate, and without requiring license from government (whereas in the case of WiFi one can't legally do more than a hundred meters or so).

I am not sure this is the case for .s(?)  Could .s use high power levels like EIRP 40dBm and without license?

Then,

But unfortuntaly for me, the situation in the country I live (France) seems to be that one is not allowed to use IP-over-802.11p without geonetworking (i.e. not allowed to use the frequencies allocated to ITS for 802.11p without using ETSI ITS i.e. geonetworking).

These factors seem to strongly hamper the development of vehicular specific communication technology at IETF:

Although I may sound relatively pessimistic, I also consider I may be wrong in my reasoning above.

Alex

>> GeoNetworking), so I don't see what kind of issues there might be ...
>
> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800, and 
> if it's ARP over 802.11p still without GeoNetworking then I should use 
> EtherType 0x0806.
>
> clear either whether GeoNetworking supports IPv4 or not, or under what 
> form).
>
> work easier on 802.11p links (easier than on WiFi), because the ESSID 
> does not need to be discovered, the ad-hoc network does not need to be 
> formed - suffices it to send packets on a certain channel.
>
> France be 176, 178 or 180? (with WiFi, IP does not care because it can 
> work on any of the 11 channels equally well, but with 802.11p each of 
> these three channels seem to be reserved for "Services", "Control" and 
> "Services").
>
>>>> I tend to agree that #8947 is a hexadecimal notation also because 
>>>> the sharp sign preceding it, and because if it were decimal it 
>>>> would convert to 22F3 which is already reserved for  trill.
>>>>
>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To:
>>>>>> [email-masked] Subject: Re: [its] What do we need to make ITS WG go 
>>>>>> forward? - EtherType for ITS
>>>>>>
>>>>>> Hello Dan,
>>>>>>
>>>>>> Thank you for the email.
>>>>>>
>>>>>> I think we definitely need a good interface with IEEE about this.
>>>>>>
>>>>>> Maybe you could ask them whether this number is hexa or decimal, 
>>>>>> so we know what to put in implementation (e.g.
>>>>>>> The documents that you are referring (on the ETSI server) are 
>>>>>>> not freely accessible. A password is required, and probably only 
>>>>>>> ETSI members have the access information.
>>>>>>>
>>>>>>> The responsibility for assigning EtherType values is with the 
>>>>>>> IEEE Registration Authority. They maintain a public list 
>>>>>>> (updated daily) at 
>>>>>>> * This is a partial listing of all assigned EtherType Fields. 
>>>>>>> Not
>>>>>> all
>>>>>>> Did ETSI require for this information not to be published? It 
>>>>>>> does not look useful if they want to encourage interoperability
>>>>>>>
>>>>>>> Value 0707 mentioned in the thread is not allocated either.
>>>>>>>
>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA).
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>> *From:[email-masked] [mailto:[email-masked]] *On 
>>>>>>> Behalf Of *Thierry Ernst *Sent:* Wednesday, January 30, 2013 
>>>>>>> 11:11 AM *To:* [email-masked] *Subject:* Re: [its] What do we need 
>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use 
>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document 
>>>>>>> available on the ETSI server:
>>>>>>>
>>>>>>> ITS(13)000020
>>>>>>> I really dislike the fact that ISO is charging for the ISO 21217 
>>>>>>> - Architecture & ISO 21210 - IPv6 Networking.
>>>>>>>
>>>>>>> cybersecurity and safety liability if the specification leads to 
>>>>>>> deaths and damage to property?
>>>>>>>
>>>>>>>
>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but 
>>>>>>> not specified by IEEE nor reserved at IANA - does not make it 
>>>>>>> interoperable.
>>>>>>>
>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by
>>>>>> somebody
>>>>>>> (see a good example of interoperability: IPv6 0x86dd ethertype 
>>>>>>> is reserved at IEEE and at IANA
>>>>>>>
Alex
>>>>>>> First, it would need a charter, and support from the industry. 
>>>>>>> But more importantly, IETF WGs are not usually sector-driven, so 
>>>>>>> it means the different issues pertaining to ITS should be 
>>>>>>> brought to
>>>>>> VARIOUS
>>>>>>> existing WGs, and a WG should only be created if there is an 
>>>>>>> important issue for which there is no existing WG that could 
>>>>>>> work on it.
>>>>>>>
>>>>>>> This said, as mentioned earlier, ITS is not only about vehicular 
>>>>>>> communications, though the issues listed by Alexandru below 
>>>>>>> mostly consider vehicular communications.
>>>>>>>
>>>>>>> communication architecture and the definition of what features 
>>>>>>> should be comprised for an IPv6 networking stack deployed for 
>>>>>>> ITS use cases. This cannot be done at IETF, and actually already 
>>>>>>> exists at ISO: - ISO 21217 - Architecture - ISO 21210 - IPv6 
>>>>>>> Networking
>>>>>>>
>>>>>>> As an input to the discussion, please consider reading documents 
>>>>>>> D2.1 and D2.2 available on the ITSSv6 project web page: 
>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides an analysis of 
>>>>>>> the currently published version of ISO 21210, but new work items 
>>>>>>> have been launched since then to address remaining issues.
>>>>>>>
>>>>>>> Regards, Thierry.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is just one opinion, but I'd like to understand why  ITS 
>>>>>>> would need its own IETF group. The work here is the  same (IMO) 
>>>>>>> as what is taking place in MANET. I would vote that this work be 
>>>>>>> taken up in MANET.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stan,
>>>>>>>
>>>>>>> Thank you for the offer.  I considered this offer since some 
>>>>>>> time.
>>>>>>>
>>>>>>> I try to understand whether some of these items on which I have 
>>>>>>> interest could be brought in in MANET WG: - V2V using prefix 
>>>>>>> exchange - VIN-based IP addressing scheme - ND Prefix Delegation 
>>>>>>> - PMIP-based network mobility - IPv6 single-address connecion 
>>>>>>> 'sharing' with a cellular operator and a vehicular moving 
>>>>>>> network (type '64share'
>>>>>>> I think we already done some steps but not sure how far now. We 
>>>>>>> will need to propose the WG and provide the WG charter, as use 
>>>>>>> cases and work to be done in this group.
>>>>>>> attended the last meeting so not sure about the status now,
>>>>>>>
>>>>>>> AB
>>>>>>>
>>>>>>> previously heard to make it a working group. So what should we 
>>>>>>> exactly do, to achieve this goal ?
>>>>>>>
>>>>>>>
>>>>>>> I was interested in this group but not sure where are we so far. 
>>>>>>> Is there progress, or is there issues/efforts that need to be 
>>>>>>> completed and volunteered.
>>>>>>>
>>>>>>> AB _______________________________________________ its mailing 
>>>>>>> بنعمروNabil Benamar* Professor of computer sciences Simulation 
>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes 
>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6 
----------

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 18:45:12 +0100

Roberto,

Thank you for the reply.

> opposed to other SDOs' standards).

I tend to agree, yes.  I said that because, in one particular case, I
was pointed out in private that some ETSI/IEEE pdf letters may not be
available publicly, eg that ethertype letter.  But yes, I did extensive
research on the web about ETSI documents and many are publicly and
freely available.

I think my complain was self-induced by the ISO documents suggested here
on this list.  ISO documents are not available freely, and that is a
difficulty.

YEs, many SDOs dont have publicly freely available documents.

> There are many 11p prototypes. Many projects in Europe developed
> them. I could name a few (including my company's) but I would do it
> off-line to avoid advertising, if you are interested.

If possible, please name them here in an un-advertising manner.
Neutrality is felt when expressed right, there is no worry.

> Are you sure ETSI interoperability results are not open?

I was told that one of the reasons people make IP interoperability tests
at ETSI yet don't discuss them at IETF may be related to the signature
of an NDA with ETSI (i.e. all test results belong to organizer not to
participant).

It may be a misunderstanding on my side...

> Each participant receives a grade which is not publicly available,
> but some results should be publicly available.

I am looking to see whether some URL is available.  Please let know.

> automotive industry. It's about time.

Let's see.

> I don't understand why you don't see GeoNetworking as a feature. You
>  seem to consider it as an obstacle? It's a protocol. IPv6 can run on
>  top of it with some advantages. If you think a better protocol stack
>  should be designed, you can propose it to the industry that should
> eventually deploy it. However, I think it makes more sense to start
> from what has been done so far. E.g. review what could be done with
> IPv6 over GN.

I read the comment.  We could discuss it separately, in a separate
thread.  Basically, I think inserting geography in such internal
workings which is IP addressing changes the nature of this latter, and
may loose its widespread interoperability.  And yes, I should look first
at its advantages.  LEt's discuss separately.

Alex

> 11 February 2013 16:30 To: Dowdell, John Cc: [email-masked] Subject:
> Re: [its] IP over 802.11p
>
> geonetworking (i.e. not allowed to use the frequencies allocated to
> ITS for 802.11p without using ETSI ITS i.e. geonetworking).
>
>>>>>>>> <http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%2813%2
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
900002
>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)0000
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
20_Eth
>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-number
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
s.xml)
>>>>>>>>  is an important issue for which there is no existing
>>>>>>>> WG that could work on it.
>>>>>>>>
>>>>>>>> charter, as use cases and work to be done in this
>>>>>>>> ----------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
------

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 18:45:02 +0100

Thanks to your responses (thanks Romain, Hans-Joachimn and Roberto) I
pursued the research on the web and I can speculate further:

- it is not good to use VLC on IP-straight-over-80211p on any frequency
   between 5875 to 5905 MHz.  These are booked in Europe for safety ITS,
   and only for safety.[*]

- in Europe, ECC of CEPT made a recommendation in 2008 to reserve the
   band 5855-5875MHz for non-safety applications of ITS, which could be
   IP entertainment.  This range of frequencies is also used for other
   purposes (satellite, amateur, ptp wideband, indoors short-range,
   other, with various power levels). [**]

- in France, this ECC (08)01 recommendation is not implemented as of
   year 2012; there seems to be no plan in sight.  In other countries in
   Europe it _is_ implemented.  Detail status is at [***].

I hope I speculate right.

The reason of this discussion is that the hardware to realize ITS
communications is available relatively cheaply, together with
straightforward linux manners to set up the frequency and relatively
strong power levels (25dBm, i.e. distances in the range of kilometers).

Yours,

Alex

[*] DÉCISION DE LA COMMISSION du 5 août 2008 sur l’utilisation
     harmonisée du spectre radioélectrique dans la bande de fréquences
     5 875-5 905MHz pour les applications des systèmes de transport
     intelligents liées à la sécurité
http://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC8QFjAA&url=http%3A%2F%2Feur-lex.europa.eu%2FLexUriServ%2FLexUriServ.do%3Furi%3DOJ%3AL%3A2008%3A220%3A0024%3A0026%3AFR%3APDF&ei=yMobUd7tKdC3hAeYhoHgCg&usg=AFQjCNEZs1ycIT5B-rkaVqIEMrnQ1P-vig&bvm=bv.42261806,d.d2k

[**] ECC RECOMMENDATION (08)01 USE OF THE BAND 5855-5875 MHz FOR
      INTELLIGENT TRANSPORT SYSTEMS (ITS)
http://www.erodocdb.dk/Docs/doc98/official/pdf/REC0801.PDF

[***] Status of implementation of ECC/REC/(08)01 ITS in the band
       5855-5875 MHz
http://www.erodocdb.dk/doks/implement_doc_adm.aspx?docid=2253

Le 13/02/2013 15:07, Alexandru Petrescu a écrit :
>>>>> IP-over-802.11p without geonetworking (i.e. not allowed to
>>>>> use the frequencies allocated to ITS for 802.11p without
>>>>> using ETSI ITS i.e. geonetworking).
>>>>
>>> number 176 5 870 MHz - G5SC3 (Service Channel 3) - number 174 5
>>> 860 MHz - G5SC4 (Service Channel 4) - number 172 5 470 MHz to 5
>>> 725 MHz - G5SC5.
>>>
>>> As for the specific purposes of each such channel for ITS,
>>> ETSI[**] document says: "G5SC1 and G5SC2 shall be used for ITS
>>> road safety and traffic efficiency applications". "Other ITS user
>>> applications G5SC3, G5SC4 and G5SC5".
>>>
>>> 'Other ITS user applications', and would not be qualified as
>>> 'ITS road safety' nor as 'traffic efficiency applications'.
>>
>> Thank you for the pointers. From what I understand, ITS road
>> safety is not tied to geonetworking, so I believe
>> IP-over-80211p-without-geonet can be performed on any of the
>> allowed channels.
>
> There would be no risk if I send entertainment vlc videostreams on
> the Control Channel?
>
>>> Alex [*] ARCEP "Autorité de régulation des comm. électroniques
>>> et des postes" https://www.espectre.arcep.fr/index.php (filled
>>> in "Fréquence Inférieure" as 5470MHz and "Fréquence Supérieure"
>>> as 5905MHz, then click "Rechercher", then locate "ITS" in that
>>> page) [**] ETSI ITS Final draft ETSI ES 202 663 V1.1.0 (2009-11)
>>> Page 13 Publicly available document retrieved on 12 February 2013
>>> at
>>>
>>>>> vehicular specific communication technology at IETF: - lack
>>>>> of open-source driver codes for 802.11p - lack of open and
>>>>> free-of-charge access to ETSI standards - lack of open
>>>>> access to ETSI interoperability results - lack of cheap
>>>>> hardware implementations of 802.11p - lack of
>>>>> unregulated/unlicensed frequency allocated for IP-over-80211p
>>>>>> Petrescu Sent: 31 January 2013 15:17 To: [email-masked]
>>>>>> use EtherType soon-to-be-0x8947?  Or other?  I suppose
>>>>>> that if I run IPv4 over 11p without GeoNetworking I should
>>>>>> use EtherType 0x0800, and if it's ARP over 802.11p still
>>>>>> without GeoNetworking then I should use EtherType 0x0806.
>>>>>>
>>>>>> ETSI ITS, for GeoNetworking for IPv6, for GeoNetworking
>>>>>> for IPv4, etc. It is not clear either whether
>>>>>> GeoNetworking supports IPv4 or not, or under what form).
>>>>>>
>>>>>> I also have some questions about the relationship between
>>>>>> the nature of some 802.11p links (no ESSID, absence of
>>>>>> link-layer security - as opposed to WiFi which has ESSID
>>>>>> and link-layer security) and IP.
>>>>>>
>>>>>> Advertisements work easier on 802.11p links (easier than
>>>>>> on WiFi), because the ESSID does not need to be discovered,
>>>>>> the ad-hoc network does not need to be formed - suffices it
>>>>>> to send packets on a certain channel.
>>>>>>
>>>>>> (in a V2V draft one seems to say that the presence of
>>>>>> Access Point is absolutely necessary in order for 802.11p
>>>>>> to work; but in our experimentations this is not the case -
>>>>>> it is possible to establish direct vehicle-to-vehicle
>>>>>> channel in France be 176, 178 or 180? (with WiFi, IP does
>>>>>> not care because it can work on any of the 11 channels
>>>>>> equally well, but with 802.11p each of these three channels
>>>>>> seem to be reserved for "Services", "Control" and
>>>>>> "Services").
>>>>>>
>>>>>>>> One of the things to say would be whether or not this
>>>>>>>> is IPv6 only or IPv4 also.
>>>>>>>>
>>>>>>>> It would agree on the EtherType and/or whether there
>>>>>>>> are new ones, several or only one, or reusing existing
>>>>>>>> EtherTypes.
>>>>>>>>
>>>>>>>>> also because the sharp sign preceding it, and
>>>>>>>>> because if it were decimal it would convert to 22F3
>>>>>>>>> which is already reserved for trill.
>>>>>>>>>
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> [mailto:[email-masked]] On Behalf Of
>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January 30,
>>>>>>>>>>> 2013 12:00 PM To: [email-masked] Subject: Re: [its]
>>>>>>>>>>>> The documents that you are referring (on the
>>>>>>>>>>>> ETSI server) are not freely accessible. A
>>>>>>>>>>>> password is required, and probably only ETSI
>>>>>>>>>>>> members have the access information.
>>>>>>>>>>>>
>>>>>>>>>>>> values is with the IEEE Registration
>>>>>>>>>>>> Authority. They maintain a public list (updated
>>>>>>>>>>>> daily) at
>>>>>>>>>>>> Did ETSI require for this information not to
>>>>>>>>>>>> be published? It does not look useful if they
>>>>>>>>>>>> want to encourage interoperability
>>>>>>>>>>>>
>>>>>>>>>>>> 2013 11:11 AM *To:* [email-masked] *Subject:*
>>>>>>>>>>>> Re: [its] What do we need to make ITS WG go
>>>>>>>>>>>> #8947 for ITS use (ETSI TC ITS's
>>>>>>>>>>>> GeoNetworking). Check the following document
>>>>>>>>>>>> Does this make it any better? Safer?  Should
>>>>>>>>>>>> ISO now have cybersecurity and safety liability
>>>>>>>>>>>> if the specification leads to deaths and damage
>>>>>>>>>>>> to property?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> At this stage, I don't think a new working
>>>>>>>>>>>> group is needed. First, it would need a
>>>>>>>>>>>> charter, and support from the industry. But
>>>>>>>>>>>> more importantly, IETF WGs are not usually
>>>>>>>>>>>> sector-driven, so it means the different issues
>>>>>>>>>>>> existing WGs, and a WG should only be created
>>>>>>>>>>>> if there is an important issue for which there
>>>>>>>>>>>> is no existing WG that could work on it.
>>>>>>>>>>>>
>>>>>>>>>>>> This said, as mentioned earlier, ITS is not
>>>>>>>>>>>> only about vehicular communications, though
>>>>>>>>>>>> the issues listed by Alexandru below mostly
>>>>>>>>>>>> consider vehicular communications.
>>>>>>>>>>>>
>>>>>>>>>>>> definition of what features should be
>>>>>>>>>>>> comprised for an IPv6 networking stack deployed
>>>>>>>>>>>> for ITS use cases. This cannot be done at IETF,
>>>>>>>>>>>> and actually already exists at ISO: - ISO 21217
>>>>>>>>>>>> - Architecture - ISO 21210 - IPv6 Networking
>>>>>>>>>>>>
>>>>>>>>>>>> reading documents D2.1 and D2.2 available on
>>>>>>>>>>>> the ITSSv6 project web page:
>>>>>>>>>>>> provides an analysis of the currently
>>>>>>>>>>>> published version of ISO 21210, but new work
>>>>>>>>>>>> items have been launched since then to address
>>>>>>>>>>>> remaining issues.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Thierry.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> group. The work here is the same (IMO) as what
>>>>>>>>>>>> is taking place in MANET. I would vote that
>>>>>>>>>>>> this work be taken up in MANET.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Stan,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for the offer.  I considered this
>>>>>>>>>>>> offer since some time.
>>>>>>>>>>>>
>>>>>>>>>>>> I try to understand whether some of these
>>>>>>>>>>>> items on which I have interest could be brought
>>>>>>>>>>>> in in MANET WG: - V2V using prefix exchange -
>>>>>>>>>>>> Delegation - PMIP-based network mobility -
>>>>>>>>>>>> IPv6 single-address connecion 'sharing' with a
>>>>>>>>>>>> cellular operator and a vehicular moving
>>>>>>>>>>>> network (type '64share' of v6ops). - Default
>>>>>>>>>>>> Route with DHCPv6.
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know.
>>>>>>>>>>>>
>>>>>>>>>>>> Yours,
>>>>>>>>>>>>
>>>>>>>>>>>> Alex
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards, Stan
>>>>>>>>>>>>
>>>>>>>>>>>> I think we already done some steps but not
>>>>>>>>>>>> sure how far now. We will need to propose the
>>>>>>>>>>>> WG and provide the WG charter, as use cases and
>>>>>>>>>>>> work to be done in this group. This charter
>>>>>>>>>>>> needs to be approved by the IESG. I have not
>>>>>>>>>>>> working group. So what should we exactly do,
>>>>>>>>>>>> to achieve this goal ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I was interested in this group but not sure
>>>>>>>>>>>> where are we so far. Is there progress, or is
>>>>>>>>>>>> there issues/efforts that need to be completed
>>>>>>>>>>>> and volunteered.
>>>>>>>>>>>>
>>>>>>>>>>>> AB
>>>>>>>>>>>> -- * * *تحياتي ، **Cordialement, Regards* * * *
>>>>>>>>>>>> * *نبيل بنعمروNabil Benamar* Professor of
>>>>>>>>>>>> computer sciences Simulation and Modelisation
>>>>>>>>>>>> Laboratory Human Sciences Faculty of Meknes
>>>>>>>>>>>> Moulay Ismail* *University* Meknes, Morocco
>>>>>>>>>>>> *GSM: * *+ 212 6 70832236
>>>>>>>>>>>> http://nabilbenamar.com/
>>>>>>>>>>>>
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>>
its
its
its
its mailing
>>>>>> https://www.ietf.org/mailman/listinfo/its The information
>>>>>> contained within this e-mail and any files attached to this
>>>>>> e-mail is private and in addition may include commercially
>>>>>> sensitive information. The contents of this e-mail are for
>>>>>> the intended recipient only and therefore if you wish to
>>>>>> disclose the information contained within this e-mail or
>>>>>> attached files, please contact the sender prior to any such
>>>>>> disclosure, copying or distribution is prohibited. Please
>>>>>> also contact the sender and inform them of the error and
>>>>>> delete the e-mail, including any attached files from your
>>>>>> system. Cassidian Limited, Registered Office : Quadrant
>>>>>> House, Celtic Springs, Coedkernew, Newport, NP10 8FZ
>>>>>> Company No: 04191036 http://www.cassidian.com
>>>>>>
>>>>>>
>>>>>
>>>>>

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 13 Feb 2013 20:59:39 +0100

The 30 MHz allocated in Europe around 5,9 GHz are reserved for road 
safety. However the service advertisement message (SAM) has to go on the 
CCH (as agreed at ETSI TC ITS). However the session, which could be an 
entertainment session, has to be performed on other channels, maybe on 
other media.

I guess that the "dream of video-streaming via 802.11p" now is 
identified as a dream. Bandwidth problems and reservation of bands for 
specific purposes are a fact.

This is absolutely independent from using IPv6 or not. IPv6 is THE 
networking technology for Cooperative ITS - no doubt. GeoNetworking over 
ITS-G5 or even tunneling of IP over GeoNetworking over ITS-G5 simply is 
a NO-GO.

For simple single-hop communications, which is the primary task of V2V, 
FNTP from ISO is much more efficient than GeoNetworking. When it comes 
to the need of geo-dissemination of information, IPv6 should be used 
without GeoNetworking, transported over any kind of network (802.11p in 
a first hop, cellular networks, Internet, ...). Please note also that 
GeoNetworking is covered by IPRs from NEC and others.

Hans-Joachim

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Wed, 13 Feb 2013 21:14:08 +0100

Dear Roberto,

I will not comment on your comments.

Hans-Joachim

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Feb 2013 16:58:51 +0100

Le 13/02/2013 20:59, Dr. Hans-Joachim Fischer a écrit :
> safety.

I agree.  (it's a band of 30MHz width from 5875MHz to 5905MHz,
colloquially known here as the '5.9GHz' band. (for precision remark that
in France for example, the 5 930,375  to 6 167,625  MHz is reserved for
other than road safety purposes (ptp), and these people may rightfully
talk '5.9GHz' band as well).

> However the service advertisement message (SAM) has to go on the CCH
> (as agreed at ETSI TC ITS). However the session, which could be an
> entertainment session, has to be performed on other channels, maybe
> on other media.

I agree.

There are two points here.

In IP there is no notion of advertising some IP service on a particular
channel, and deal that service on another channel.  For example, there
is this "Router Advertisement" message but it happens on the same
channel as the IP traffic.  (there is also Session Advertisement,
Link-State Advertisement, more - they all are on the same channel as the
traffic itself).

About performing IP entertainment on another media.  I am trying to find
out what is that media.  I think in France I have exhausted all possible
frequencies, but I will reply separately about "Wireless LAN", ITS-G5C.

> identified as a dream.

I think I agree.  I think IP-over-802.11p-for-entertainment in France is
not possible.

> Bandwidth problems and reservation of bands for specific purposes
> are a fact.
>
> networking technology for Cooperative ITS - no doubt. GeoNetworking
> over ITS-G5 or even tunneling of IP over GeoNetworking over ITS-G5
> simply is a NO-GO.

Do you mean the entire ITS-G5? (ITS-G5A == 5,875 GHz to 5,905 GHz,
ITS-G5B==5,855 GHz to 5,875 GHz and ITS-G5C==5,470 GHz to 5,725 GHz).

I without searching would say that GeoNetworking would be ok for ITS-G5B
and maybe ITS-G5A.

> For simple single-hop communications, which is the primary task of
> V2V, FNTP from ISO is much more efficient than GeoNetworking.

What is FNTP from ISO?

I am interested in V2V communications.  There are two Internet Drafts
describing a technique for V2V communications:
draft-petrescu-autoconf-ra-based-routing-03.txt
draft-jhlee-mext-mnpp-00

We would like to work on this.

> When it comes to the need of geo-dissemination of information, IPv6
> should be used without GeoNetworking, transported over any kind of
> network (802.11p in a first hop, cellular networks, Internet, ...).

I am trying to wrap my mind around geo-dissemination without
geonetworking...

> Please note also that GeoNetworking is covered by IPRs from NEC and
> others.

This is good to know, informally speaking.  One may even try to look in
detail at this, see what is protected and how, what is left open, etc.

Yours,

Alex

>>>>>> But unfortuntaly for me, the situation in the country I
>>>>>> live (France) seems to be that one is not allowed to use
>>>>> Do you have any reference that supports this statement? I
>>>>> have never heard of such restrictions in France so far.
>>>>
>>>> Hello Romain,
>>>>
>>>> road safety and traffic efficiency applications". "Other ITS
>>>> user applications G5SC3, G5SC4 and G5SC5".
>>>>
>>>> page) [**] ETSI ITS Final draft ETSI ES 202 663 V1.1.0
>>>> (2009-11) Page 13 Publicly available document retrieved on 12
>>>> February 2013 at
>>>>
>>>>>> vehicular specific communication technology at IETF: -
>>>>>> lack of open-source driver codes for 802.11p - lack of open
>>>>>> and free-of-charge access to ETSI standards - lack of open
>>>>>> unregulated/unlicensed frequency allocated for
>>>>>> IP-over-80211p for long range. - technical
>>>>>> misunderstanding between the ETSI point of view of what is
>>>>>> IP and the IETF of same.
>>>>>>
>>>>>> Although I may sound relatively pessimistic, I also
>>>>>> consider I may be wrong in my reasoning above.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> I guess when you run IPv6 over 11p with GeoNetworking,
>>>>>>> the Ethernet header uses EtherType soon-to-be-0x8947,
>>>>>>> whereas when you run IPv6 over 11p without
>>>>>>> GeoNetworking, the Ethernet header uses EtherType 0x86DD.
>>>>>>> Also, if I run IPv4 over 11p with GeoNetworking - should
>>>>>>> I use EtherType soon-to-be-0x8947?  Or other?  I suppose
>>>>>>> that if I run IPv4 over 11p without GeoNetworking I
>>>>>>> should use EtherType 0x0800, and if it's ARP over
>>>>>>> 802.11p still without GeoNetworking then I should use
>>>>>>> EtherType 0x0806.
>>>>>>>
>>>>>>> I also have some questions about the relationship
>>>>>>> between the nature of some 802.11p links (no ESSID,
>>>>>>> absence of link-layer security - as opposed to WiFi which
>>>>>>> has ESSID and link-layer security) and IP.
>>>>>>>
>>>>>>> on WiFi), because the ESSID does not need to be
>>>>>>> discovered, the ad-hoc network does not need to be
>>>>>>> Access Point is absolutely necessary in order for
>>>>>>> 802.11p to work; but in our experimentations this is not
>>>>>>> the case - it is possible to establish direct
>>>>>>> vehicle-to-vehicle IP-over-802.11p communications without
>>>>>>> the presence of a fixed 802.11p Access Point).
>>>>>>>
>>>>>>> channel in France be 176, 178 or 180? (with WiFi, IP
>>>>>>> does not care because it can work on any of the 11
>>>>>>> channels equally well, but with 802.11p each of these
>>>>>>> three channels seem to be reserved for "Services",
>>>>>>>  entirely relaying on IP layer security (IPsec, SeND,
>>>>>>> EAP, PANA)?
>>>>>>>
>>>>>>> I think finding consensus on some of these questions
>>>>>>> could lead to interoperability.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> Regards, Thierry
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> One of the things to say would be whether or not
>>>>>>>>> this is IPv6 only or IPv4 also.
>>>>>>>>>
>>>>>>>>> are new ones, several or only one, or reusing
>>>>>>>>> existing EtherTypes.
>>>>>>>>>
>>>>>>>>>> I tend to agree that #8947 is a hexadecimal
>>>>>>>>>> notation also because the sharp sign preceding it,
>>>>>>>>>> and because if it were decimal it would convert to
>>>>>>>>>> 22F3 which is already reserved for trill.
>>>>>>>>>>
>>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January
>>>>>>>>>>>> 30, 2013 12:00 PM To: [email-masked] Subject:
>>>>>>>>>>>> implementation (e.g. wireshark packet
>>>>>>>>>>>> analyzers, and 802.11p/etsi-its
>>>>>>>>>>>> implementations).
>>>>>>>>>>>>
>>>>>>>>>>>>> Authority. They maintain a public list
>>>>>>>>>>>>> (updated daily) at
>>>>>>>>>>>>> I really dislike the fact that ISO is
>>>>>>>>>>>>> charging for the ISO 21217 - Architecture &
>>>>>>>>>>>>> ISO 21210 - IPv6 Networking.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ISO now have cybersecurity and safety
>>>>>>>>>>>>> liability if the specification leads to
>>>>>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry
>>>>>>>>>>>>> Ernst <[email-masked]>
>>>>>>>>>>>>> sector-driven, so it means the different
>>>>>>>>>>>>> existing WGs, and a WG should only be
>>>>>>>>>>>>> created if there is an important issue for
>>>>>>>>>>>>> which there is no existing WG that could work
>>>>>>>>>>>>> on it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> comprised for an IPv6 networking stack
>>>>>>>>>>>>> deployed for ITS use cases. This cannot be
>>>>>>>>>>>>> done at IETF, and actually already exists at
>>>>>>>>>>>>> ISO: - ISO 21217 - Architecture - ISO 21210 -
>>>>>>>>>>>>> IPv6 Networking
>>>>>>>>>>>>>
>>>>>>>>>>>>> As an input to the discussion, please
>>>>>>>>>>>>> consider reading documents D2.1 and D2.2
>>>>>>>>>>>>> available on the ITSSv6 project web page:
>>>>>>>>>>>>> items have been launched since then to
>>>>>>>>>>>>> address remaining issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Thierry.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> group. The work here is the same (IMO) as
>>>>>>>>>>>>> what is taking place in MANET. I would vote
>>>>>>>>>>>>> items on which I have interest could be
>>>>>>>>>>>>> brought in in MANET WG: - V2V using prefix
>>>>>>>>>>>>> exchange - VIN-based IP addressing scheme -
>>>>>>>>>>>>> ND Prefix Delegation - PMIP-based network
>>>>>>>>>>>>> mobility - IPv6 single-address connecion
>>>>>>>>>>>>> 'sharing' with a cellular operator and a
>>>>>>>>>>>>> vehicular moving network (type '64share' of
>>>>>>>>>>>>> sure how far now. We will need to propose
>>>>>>>>>>>>> the WG and provide the WG charter, as use
>>>>>>>>>>>>> This charter needs to be approved by the
>>>>>>>>>>>>> IESG. I have not attended the last meeting so
>>>>>>>>>>>>> not sure about the status now,
>>>>>>>>>>>>>
>>>>>>>>>>>>> AB
>>>>>>>>>>>>>
>>>>>>>>>>>>> where are we so far. Is there progress, or
>>>>>>>>>>>>> is there issues/efforts that need to be
>>>>>>>>>>>>> -- * * *تحياتي ، **Cordialement, Regards* *
>>>>>>>>>>>>> * * * *نبيل بنعمروNabil Benamar* Professor
>>>>>>>>>>>>> of computer sciences Simulation and
>>>>>>>>>>>>> Modelisation Laboratory Human Sciences
>>>>>>>>>>>>> Faculty of Meknes Moulay Ismail* *University*
its
its
its
its mailing
>>>>>>> https://www.ietf.org/mailman/listinfo/its The
>>>>>>> information contained within this e-mail and any files
>>>>>>> include commercially sensitive information. The contents
>>>>>>> of this e-mail are for the intended recipient only and
>>>>>>> therefore if you wish to disclose the information
>>>>>>> contained within this e-mail or attached files, please
>>>>>>> contact the sender prior to any such disclosure. If you
>>>>>>> are not the intended recipient, any disclosure, copying
>>>>>>> or distribution is prohibited. Please also contact the
>>>>>>> sender and inform them of the error and delete the
>>>>>>> Cassidian Limited, Registered Office : Quadrant House,
>>>>>>> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Feb 2013 17:16:41 +0100

I was told in private there is more about this.  So I did more research.

- ETSI ITS suggests for non-safety to use ITS-G5C band (the two others
   are ITS-G5A and B).  This ITS-G5C band 5470MHz-5725MHz was dedicated,
   among other bands, for the "5GHz Radio LAN", before ETSI ITS
   suggested its use.
- on this ITS-G5C one could easily use IP-over-802.11.
- the power levels are 1W (30dBm) outdoors, which is attractive for
   vehicular communications.  But a Master/Slave concept, DFS, TPC and
   Radar Detection must be used, in order to be allowed this high power
   level.  Absent DFS and TPC, the power limits of ITS-G5C are halved to
   bare wifi-like limits (500mW vs 1W).  802.11p inherent non-ESSID
   working is doubtfully compatible with DFS (Dynamic Frequency
   Selection), TPC (Transmission Power Control).

This 5470MHz-5725MHz is ETSI, but is not 802.11p.  The 802.11p can only
work on frequencies that ETSI calls ITS-G5A and ITS-G5B.

IP-over-80211p-over-ITS-G5C is a misnomer.  This can't be a work item.

IP-over-80211-over-ITS-G5C could be ok.

Comments?

Alex

Le 13/02/2013 18:45, Alexandru Petrescu a écrit :
> Thanks to your responses (thanks Romain, Hans-Joachimn and Roberto)
> I pursued the research on the web and I can speculate further:
>
> - it is not good to use VLC on IP-straight-over-80211p on any
> frequency between 5875 to 5905 MHz.  These are booked in Europe for
> safety ITS, and only for safety.[*]
>
> - in Europe, ECC of CEPT made a recommendation in 2008 to reserve
> the band 5855-5875MHz for non-safety applications of ITS, which could
> be IP entertainment.  This range of frequencies is also used for
> other purposes (satellite, amateur, ptp wideband, indoors
> short-range, other, with various power levels). [**]
>
> year 2012; there seems to be no plan in sight.  In other countries
> in Europe it _is_ implemented.  Detail status is at [***].
>
> harmonisée du spectre radioélectrique dans la bande de fréquences 5
> 875-5 905MHz pour les applications des systèmes de transport
>>>> But the ETSI[**] lists the following center frequencies, with
>>>> a channel spacing of 10MHz, and their purposes : 5 900 MHz -
>>>> G5CC (Control Channel)   - number 180 5 890 MHz - G5SC2
>>>> (Service Channel 2) - number 178 5 880 MHz - G5SC1 (Service
>>>> Channel 1) - number 176 5 870 MHz - G5SC3 (Service Channel 3) -
>>>> number 174 5 860 MHz - G5SC4 (Service Channel 4) - number 172 5
>>>> 470 MHz to 5 725 MHz - G5SC5.
>>>>
>>>> I speculate IP-over-80211p-without-geonet could be qualified
>>>> as 'Other ITS user applications', and would not be qualified
>>>> as 'ITS road safety' nor as 'traffic efficiency applications'.
>>>
>>>> in "Fréquence Inférieure" as 5470MHz and "Fréquence
>>>> Supérieure" as 5905MHz, then click "Rechercher", then locate
>>>> "ITS" in that page) [**] ETSI ITS Final draft ETSI ES 202 663
>>>> V1.1.0 (2009-11) Page 13 Publicly available document retrieved
>>>> on 12 February 2013 at
>>>>
>>>>>> IP-over-80211p for long range. - technical misunderstanding
>>>>>> between the ETSI point of view of what is IP and the IETF
>>>>>> of same.
>>>>>>
>>>>>>>> Well, we do actually run IPv6 over 11p (with or
>>>>>>>> without GeoNetworking), so I don't see what kind of
>>>>>>>> issues there might be ...
>>>>>>>
>>>>>>> whereas when you run IPv6 over 11p without GeoNetworking,
>>>>>>> the Ethernet header uses EtherType 0x86DD. This is just
>>>>>>> a supposition, I don't know how you run it.
>>>>>>>
>>>>>>> should use EtherType 0x0800, and if it's ARP over 802.11p
>>>>>>> still without GeoNetworking then I should use EtherType
>>>>>>> 0x0806.
>>>>>>>
>>>>>>> (the letter we've seen recently is not clear whether
>>>>>>> that allocation is for GeoNetworking, for
>>>>>>> IP-over-802.11p, for ETSI ITS, for GeoNetworking for
>>>>>>> IPv6, for GeoNetworking for IPv4, etc. It is not clear
>>>>>>> either whether GeoNetworking supports IPv4 or not, or
>>>>>>> under what form).
>>>>>>>
>>>>>>> discovered, the ad-hoc network does not need to be formed
>>>>>>>>>>>> 30, 2013 12:00 PM To: [email-masked] Subject: Re:
>>>>>>>>>>>> [its] What do we need to make ITS WG go
>>>>>>>>>>>> Maybe you could ask them whether this number
>>>>>>>>>>>> is hexa or decimal, so we know what to put in
>>>>>>>>>>>>> be published? It does not look useful if
>>>>>>>>>>>>> they want to encourage interoperability
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January
>>>>>>>>>>>>> 30, 2013 11:11 AM *To:* [email-masked]
>>>>>>>>>>>>> *Subject:* Re: [its] What do we need to make
>>>>>>>>>>>>> IEEE have assigned Ethernet Type Field
>>>>>>>>>>>>> number #8947 for ITS use (ETSI TC ITS's
>>>>>>>>>>>>> (see a good example of interoperability:
>>>>>>>>>>>>> IPv6 0x86dd ethertype is reserved at IEEE and
>>>>>>>>>>>>> at IANA
>>>>>>>>>>>>>
>>>>>>>>>>>>> cases and work to be done in this group. This
>>>>>>>>>>>>> charter needs to be approved by the IESG. I
>>>>>>>>>>>>> have not attended the last meeting so not
>>>>>>>>>>>>> I'm still interested in this list and want
>>>>>>>>>>>>> to join voices previously heard to make it a
>>>>>>>>>>>>> -- * * *تحياتي ، **Cordialement, Regards* * *
>>>>>>>>>>>>> * * *نبيل بنعمروNabil Benamar* Professor of
>>>>>>>>>>>>> computer sciences Simulation and
its
its
its
its mailing

---

From: Roberto Baldessari <[email-masked]>
Date: Fri, 15 Feb 2013 10:05:06 +0000

Hi Alex,

> I read the comment.  We could discuss it separately, in a separate thread.  
> Basically, I think inserting geography in such internal workings which is IP 
> addressing changes the nature of this latter, and may loose its widespread
> interoperability.  And yes, I should look first at its advantages.  LEt's discuss separately.

I think this is the right thread to discuss this point. But you can rename the subject if you prefer.

With IPv6 over GeoNetworking we do not modify IPv6, we only transport it. So we are perfectly in line with what you said (maximize interoperability).
That's why we map IPv6 multicast into lower layer (GeoNetworking) geocast and we do not make IPv6 geo-aware.

Actually, at the very beginning of this group's discussion, I asked if the group could review the ETSI IPv6 over GeoNetworking standard. It would have been useful to receive some IETF input. We have now submitted an update within ETSI ITS. If approved, it will be published soon (< 1 month). Note that people who also participate(d) in IETF contributed to the ETSI standard. So, I would not talk about IETF/ETSI as two separate worlds. Rather, what is missing is some official/structured cooperation to build on each other's expertise/standards.

Best regards,

Roberto

> don't know whether Unex offer drivers for these cards (be  them binary 
> or open source), we use the binary drivers from ITRI.
>
> without infrastructure, and communicate, and without requiring license 
> from government (whereas in the case of WiFi one can't legally do more 
> than a hundred meters or so).
>
> ETSI standards - lack of open access to ETSI interoperability results 
> - lack of cheap hardware implementations of 802.11p - lack of  
> unregulated/unlicensed frequency allocated for IP-over-80211p for long 
> range. - technical misunderstanding between the ETSI point of view of 
>> does not need to be discovered, the ad-hoc network does not need to 
>> be formed - suffices it to send packets on a certain channel.
>>
>>>>>>> [email-masked] Subject: Re: [its] What do we need to make ITS WG 
>>>>>>>> server) are not freely accessible. A password is required, and 
>>>>>>>> [mailto:[email-masked]] *On Behalf Of *Thierry Ernst 
>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM
>>>>>>>> *To:* [email-masked] *Subject:* Re: [its] What do we need to make 
900002
20_Eth
>>>>>>>> cybersecurity and safety liability if the specification leads 
>>>>>>>> to deaths and damage to property?
>>>>>>>>
>>>>>>>>
s.xml)
>>>>>>>> <[email-masked]> <mailto:[email-masked]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear all,
>>>>>>>>
>>>>>>>> But more importantly, IETF WGs are not usually sector-driven, 
>>>>>>>> so it means the different issues pertaining to ITS should be 
>>>>>>>> brought to
>>>>>>> VARIOUS
>>>>>>>> ITS use cases. This cannot be done at IETF, and actually 
>>>>>>>> already exists at ISO: - ISO
>>>>>>>> page: http://www.itssv6.eu/documentation/
>>>>>>>> D2.2 provides an analysis of the currently published version of 
>>>>>>>> ISO 21210, but new work items have been launched since then to 
>>>>>>>> as what is taking place in MANET. I  would vote that this work 
>>>>>>>> be taken up in MANET.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Stan,
>>>>>>>>
>>>>>>>> interest could be brought in in MANET WG:
>>>>>>>>  - V2V using prefix exchange - VIN-based IP addressing  scheme 
>>>>>>>> - ND Prefix Delegation - PMIP-based network mobility - IPv6 
>>>>>>>> single-address connecion 'sharing' with a cellular operator and 
>>>>>>>> a vehicular moving network (type '64share' of v6ops). - Default 
>>>>>>>> Route with DHCPv6.
>>>>>>>>
>>>>>>>> Please let me know.
>>>>>>>>
>>>>>>>> Yours,
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards, Stan
>>>>>>>>
>>>>>>>> cases and work to be done in this group. This charter needs to 
>>>>>>>> be approved by the IESG. I have not attended the last meeting 
>>>>>>>> so not sure about the status now,
>>>>>>>>
>>>>>>>> AB
>>>>>>>>
>>>>>>>> far. Is there progress, or is there issues/efforts that need to 
>>>>>>>> be completed and volunteered.
>>>>>>>>
------

---

From: "Dr. Hans-Joachim Fischer" <[email-masked]>
Date: Fri, 15 Feb 2013 12:01:52 +0100

Good proposal to work together in the various SDOs.

IETF is also kindly invited to check ISO 21210 (IPv6 in the context of 
ITS), and to contribute to the development of ISO 16788 (IPv6 networking 
security in ITS) and ISO 16789 (IPv6 optimization in ITS). A good 
contact point would be Thierry Ernst.

Hans-Joachim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Feb 2013 15:34:55 +0100

Le 15/02/2013 11:05, Roberto Baldessari a écrit :
>> workings which is IP addressing changes the nature of this latter,
>>  and may loose its widespread interoperability.  And yes, I should
>>  look first at its advantages.  LEt's discuss separately.
>
> With IPv6 over GeoNetworking we do not modify IPv6, we only transport
> it. So we are perfectly in line with what you said (maximize
> interoperability). That's why we map IPv6 multicast into lower layer
> (GeoNetworking) geocast and we do not make IPv6 geo-aware.

I think it is good to prefer to make other layers geo-aware, instead of
IP, because IP has its own notion of what is 'geography' - distance,
metrics, topology - all mean different things in the IP architecture
than to geography.

In some aspects, geonetworking is not only multicast.  There may
be more about geonetworking I still need to re-discover, but here is one
particular aspect:

'C2C NET ID' which is used to form IPv6 addresses for vehicles.  I.e.
such an address is formed based on the geographic position.  If so I
think it is not good, because it means when no position no IP address.

We propose to form IPv6 addresses for vehicles based on the VIN (Vehicle
Identification Numbers), instead of the position.  The VIN is always
there so addresses are always there.

This is one aspect of IP addressing and geonetworking which deserves
discussion.

> Actually, at the very beginning of this group's discussion, I asked
> if the group could review the ETSI IPv6 over GeoNetworking standard.

YEs, I remember, you did.

> It would have been useful to receive some IETF input.

YEs, it would have been useful.  If you could send publicly once again
the ref to that ETSI ITS document, on this list, I could send some
feedback on some very minor aspects.  Please do send the ref.

I want to add - the IETF input, in order to be qualified as such, should
happen publicly, in an organized manner - working group, public
discussion, public decisions.

As a counter-example: my oppinion sent to you in private (even though I
often participate at IETF) should not be qualified as an "IETF input".

It's not that the IETF 'usual suspects' participate at another SDO that
that input is IETF input.  We need documents, WG items, Charters for
that to happen.

> We have now submitted an update within ETSI ITS. If approved, it will
> be published soon (< 1 month).

Well this is good to submit to ETSI ITS.

> Note that people who also participate(d) in IETF contributed to the
> ETSI standard. So, I would not talk about IETF/ETSI as two separate
> worlds. Rather, what is missing is some official/structured
> cooperation to build on each other's expertise/standards.

Yes, we need to have a structured input from IETF.

We need to avoid a situation where IETF person X pretends Y to SDO,
without giving a chance to another IETF person U to express counter-Y.

Alex

>> Sent: 11 February 2013 16:30 To: Dowdell, John Cc: [email-masked]
>>> appears to be little support in Linux. 802.11s on the other hand
>>> is available on standard Wi-Fi dongles (from $15) and drivers are
>>> already available in Linux. Is it correct that 802.11p is
>>> mandated for ITS in some regions?
>>
>> John,
>>
>> etc.) and support from ITRI Taiwan.  The complete package
>> (drivers, geonetworking, SDKs) is expensive yes in the range of
>> thousands of USDollars.
>>
>> non-ITRI PC-like platforms.  I believe these cards may be
>> relatively  cheap.  I don't know whether Unex offer drivers for
>> these cards (be  them binary or open source), we use the binary
>> drivers from ITRI.
>>
>> One advantage of .p is that it is regulated such as no need to pay
>>  a license and still allowed to emit at high power levels (33dBm
>> EU, 40dBm US, compared to hundreds of milliWats for WiFi).  I.e. it
>> is possible to have two independent vehicles distanced by
>> kilometers, without infrastructure, and communicate, and without
>> requiring license from government (whereas in the case of WiFi one
>> can't legally do more than a hundred meters or so).
>>
>> for long range. - technical misunderstanding between the ETSI point
>> of view of what is IP and the IETF of same.
>>
>>> ITS, for GeoNetworking for IPv6, for GeoNetworking for IPv4, etc.
>>> It is not clear either whether GeoNetworking supports IPv4 or
>>> not, or under what form).
>>>
>>> entirely relaying on IP layer security (IPsec, SeND, EAP, PANA)?
>>>
>>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM
>>>>>>>> To: [email-masked] Subject: Re: [its] What do we need to
>>>>>>>> make ITS WG go forward? - EtherType for ITS
>>>>>>>>
>>>>>>>> Hello Dan,
>>>>>>>>
>>>>>>>> Thank you for the email.
>>>>>>>>
>>>>>>>>>  with the IEEE Registration Authority. They maintain
>>>>>>>>> a public list (updated daily) at
>>>>>>>>> <http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%2813%
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
2
>>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
0
>>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
r
>>>>>>>>>  why  ITS would need its own IETF group. The work
>>>>>>>>> here is the  same (IMO) as what is taking place in
>>>>>>>>> MANET. I  would vote that this work be taken up in
>>>>>>>>> MANET.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Stan,
>>>>>>>>>
>>>>>>>>> Sciences Faculty of Meknes Moulay Ismail*
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
-
>>> e-mail, including any attached files from your system. Cassidian
>>> Limited, Registered Office : Quadrant House, Celtic Springs,
>>> Coedkernew, Newport, NP10 8FZ Company No: 04191036
>>> http://www.cassidian.com
>>>
>>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Feb 2013 16:00:12 +0100

I agree.

> IETF is also kindly invited to check ISO 21210 (IPv6 in the context
> of ITS), and to contribute to the development of ISO 16788 (IPv6
> networking security in ITS) and ISO 16789 (IPv6 optimization in
> ITS). A good contact point would be Thierry Ernst.

This is a good invitation.  It is very tempting.

The document ISO21210 is titled "Intelligent transport systems --
Communications access for land mobiles (CALM) -- IPv6 Networking" and
available for buying at
http://www.iso.org/iso/fr/home/store/catalogue_tc/catalogue_detail.htm?csnumber=46549

The document IS 16788 and 16789 are not easily found by a quick google
search - are they private documents?

I am already very curious as to what's in these documents.

But I don't know how to proceed.

I could write in private to Thierry to ask him for these documents.  But
I am afraid he'll decline my requests, because he'd not be allowed to
freely redistribute something someone makes a profit on; nor to
redistribute publicly something that is private.

If I buy one and steal the two others, I could read and form an
oppinion to express here.  But nobody could argue about my oppinion
because very few people have these documents.

I am afraid this kills the discussion about ISO 21210.  And I don't want
it to be so.

This is why I am asking - how would you like IETF, and this list to
check this ISO 21210 ?

Alex

>>> I read the comment.  We could discuss it separately, in a
>>> separate thread. Basically, I think inserting geography in such
>>> internal workings which is IP addressing changes the nature of
>>> this latter, and may loose its widespread interoperability.  And
>>> yes, I should look first at its advantages. LEt's discuss
>>> separately.
>> With IPv6 over GeoNetworking we do not modify IPv6, we only
>> transport it. So we are perfectly in line with what you said
>> (maximize interoperability). That's why we map IPv6 multicast into
>> lower layer (GeoNetworking) geocast and we do not make IPv6
>> geo-aware.
>>
>> Actually, at the very beginning of this group's discussion, I
>> asked if the group could review the ETSI IPv6 over GeoNetworking
>> standard. It would have been useful to receive some IETF input. We
>> have now submitted an update within ETSI ITS. If approved, it will
>> be published soon (< 1 month). Note that people who also
>> participate(d) in IETF contributed to the ETSI standard. So, I
>> would not talk about IETF/ETSI as two separate worlds. Rather,
>> what is missing is some official/structured cooperation to build on
>> each other's expertise/standards.
>>
>> Best regards,
>>
>> Roberto
>>
>>
>>
>>> Best regards,
>>>
>>> Roberto
>>>
>>>
>>>
>>>
>>>
>

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 15 Feb 2013 17:04:43 +0100

Alexandru, instead of constantly flooding this list with questions, you 
should make the effort of reading the FREE documents that are pointed to 
you, and these include ITSSv6 deliverables D2.1 and D2.2 that I alredy 
pointed to you early on on this list 
(https://project.inria.fr/itssv6/documentation/) and that describe the 
content of ISO 21210 and other ISO documents. After reading, you might  
be willing to spend the little fee that goes with buying ISO 21210.

Yes, it's not free, and I'm not in charge of the business model of ISO 
more than the ussiness model of IETF. ISO meetings are FREE while you 
pay hundreds of euros to attend IETF meetings. This is not free either, 
but one has to pay for the costs (meeting rooms, cookies, editor, 
publications, etc.). So, both ISO and IETF have to collect money to up 
their livings.

Regards,
Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Feb 2013 17:29:39 +0100

Le 15/02/2013 17:04, Thierry Ernst a écrit :
> Alexandru, instead of constantly flooding this list with questions,
> you should make the effort of reading the FREE documents that are
> pointed to you, and these include ITSSv6 deliverables D2.1 and D2.2
> that I alredy pointed to you early on on this list
> (https://project.inria.fr/itssv6/documentation/) and that describe
> the content of ISO 21210 and other ISO documents.

Thierry - I need the "meat" of it.  I don't want an interpretation of
it.  Otherwise put - why don't you write a draft about it?

I also participate in a number of EU projets (like ITSSv6 seems to be),
and we do develop some work there which may land at standards work, but
I don't refer to these EU projects' deliverables here.  Nobody will read
them I think.

For example, I work in EU project EXALTED.  We developped there a method
of DHCPv6 Default Route.  We implemented.  We documented it in
deliverable D4.2, public.

But when I wanted to discuss it at IETF I then re-documented it in an
Internet Draft: draft-mouton-mif-dhcpv6-drlo-02.txt

I added an Ack in that draft saying the work was performed within EU
project EXALTED.

Only with such a draft I got comments from peers at IETF.

> After reading, you might be willing to spend the little fee that goes
> with buying ISO 21210.

No no Thierry, not in this case.

(remark in a separate case I purchased some ISO document about VIN, and
we will write a draft about IPv6 and VIN addressing, which refers to it;
but I doubt it will go far, because of that reference; we'll see).

> Yes, it's not free, and I'm not in charge of the business model of
> ISO more than the ussiness model of IETF. ISO meetings are FREE while
> you pay hundreds of euros to attend IETF meetings.

I didn't know ISO meetings were free.  I guess you mean free of charge?

I guess they are not open to everybody, like IETF is.  The ISO person is
somehow elected, no?

I agree with you business models vary, but if we want something done
here then we must play by the rules here, and, as you say, they are:
- pay the travel/hotel
- pay the 600usd registration, thrice a year.
- some exceptions available.

I'll add:
- anybody can come
- debate openly
- free documents
- running code
- rough consensus

> This is not free either, but one has to pay for the costs (meeting
> rooms, cookies, editor, publications, etc.). So, both ISO and IETF
> have to collect money to up their livings.

I tend to agree.

I think our disagreements relate to the way we could technically work
together.

I personally don't think we could work at IETF about ISO topics about
which we don't have free access documents.  I personally can't.  I could
explain why, if needed.

Alex

>>> IETF is also kindly invited to check ISO 21210 (IPv6 in the
>>> context of ITS), and to contribute to the development of ISO
>>> 16788 (IPv6 networking security in ITS) and ISO 16789 (IPv6
>>> optimization in ITS). A good contact point would be Thierry
>>> Ernst.
>>
>> Communications access for land mobiles (CALM) -- IPv6 Networking"
>> and available for buying at
>> The document IS 16788 and 16789 are not easily found by a quick
>> google search - are they private documents?
>>
>> I could write in private to Thierry to ask him for these documents.
>> But I am afraid he'll decline my requests, because he'd not be
>> allowed to freely redistribute something someone makes a profit on;
>> nor to redistribute publicly something that is private.
>>
>> oppinion to express here.  But nobody could argue about my
>> oppinion because very few people have these documents.
>>
>> I am afraid this kills the discussion about ISO 21210.  And I don't
>> want it to be so.
>>
>> This is why I am asking - how would you like IETF, and this list
>> to check this ISO 21210 ?
>>
>> Alex
>>
>>>
>>>
>>> Hans-Joachim
>>>
>>>
>>>>> separate thread. Basically, I think inserting geography in
>>>>> such internal workings which is IP addressing changes the
>>>>> nature of this latter, and may loose its widespread
>>>> I think this is the right thread to discuss this point. But
>>>> you can rename the subject if you prefer.
>>>>
>>>> (maximize interoperability). That's why we map IPv6 multicast
>>>> into lower layer (GeoNetworking) geocast and we do not make
>>>> IPv6 geo-aware.
>>>>
>>>> asked if the group could review the ETSI IPv6 over
>>>> GeoNetworking standard. It would have been useful to receive
>>>> some IETF input. We have now submitted an update within ETSI
>>>> ITS. If approved, it will be published soon (< 1 month). Note
>>>> that people who also participate(d) in IETF contributed to the
>>>>  ETSI standard. So, I would not talk about IETF/ETSI as two
>>>> separate worlds. Rather, what is missing is some
>>>> official/structured cooperation to build on each other's
>>>> expertise/standards.
>>>>
>>>> Best regards,
>>>>
>>>> Roberto
>>>>
>>>>
>>>>
>>>>> Best regards,
>>>>>
>>>>> Roberto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Feb 2013 19:27:04 +0100

Le 13/02/2013 20:59, Dr. Hans-Joachim Fischer a écrit :
> safety. However the service advertisement message (SAM) has to go on
> the CCH (as agreed at ETSI TC ITS). However the session, which could
> be an entertainment session, has to be performed on other channels,
> maybe on other media.
>
> identified as a dream. Bandwidth problems and reservation of bands
> for specific purposes are a fact.
>

Hans-Joachim,

FNTP stands for "Fast Networking and Transport Layer Protocol" at ISO.

But at IETF there is this Fast Mobile IP protocol.  There are many other
IETF options or protocols with Fast in their names.  (also IEEE recently
has something about 802.11ai about fastness and DHCP).

What do you think would need to be done at IETF about FNTP?

Alex

>>>>>>>>>>>>> ISO: - ISO 21217 - Architecture - ISO 21210
>>>>>>>>>>>>> - IPv6 Networking
>>>>>>>>>>>>>
its
its
its
its mailing

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 16 Feb 2013 13:19:52 +0100

Le 11/02/2013 14:50, Dowdell, John a écrit :
>  to be little support in Linux.

John,

A person was kind enough to gather in one place information which is
otherwise sparsely but publicly available; this information is about
suppliers of 802.11p-over-ITS-G5 frequencies (5875-5905MHz,
5855-5875MHz, 5470-5725MHz; caveat - only some are allowed in some
countries, check the local regulator before turning these on).

NEC
NXP/Cohda Wireless
Cisco/Cohda Wireless
Denso
Delphi
Savari
Kapsch
Siemens
ITRI
AutoTalks

I have some experience with ITRI equipment.  In their offer there is a
full-blown RSU, for around 1500EUR.  This is for a RSU hardened box for
outdoors, powerpc, GPS-enabled, 2x 802.11p interfaces, Ethernet with
PoE, USB, and linux 2.6.  Among these, it is
the software which is expensive; this includes Atheros driver
modifications, new kernel modules for "BTP" (Base Transmission
Protocol?), 'geonetworking', 'wave'.

OTher than a full-blown RSU, one could acquire also ITRI individual
'802.11p' miniPCI cards which are in the order of couple hundreds of euros.

This is not a commercial advertisement.  Technically speaking this means
many things for designing protocols.  For example:

It means it is easily possible to run linux with IPv6 over a 'wave0'
interface.   Just turn it on, watch the IPv6 link-local address, echo
the frequency value and ping. (no need to set ESSID, nor security).

In addition to the Ethernet interfaces, the RSU has _2_ 802.11p
different interfaces, and one Ethernet.  Not just two antennas, but two
interfaces (ifconfig 'wave0' and 'wave1'). This means one doesn't need
to 'relay' packets and that one needs to 'route' packets, in the
traditional sense of 'routing'.  (compare this for example to RPL
context where a sensor has a _single_ interface and there is no routing,
but 'relaying').

Also this outdoors RSU has 1 GPS antenna.  This means that geonetworking
does not work if one tries to use this indoors in a lab where GPS signal
does not reach. (unless one installs a GPS 'repeater' - easy to do but
check with regulator in country, or use a GPS 'replayer' software to
play pre-recorded NMEA sentences on /dev/tty).

Note also it is strange to design an RSU Road Side Unit - designed to be
fixed with respect to Earth, and put a GPS interface on it.  It would
have been easier to just record the GPS coordinates once and set them in
a file for as long as that RSU stays there.  I consider it as an extra,
but cheaper RSU without GPS should be possible.

> 802.11s on the other hand is available on standard Wi-Fi dongles
> (from $15) and drivers are already available in Linux. Is it correct
> that 802.11p is mandated for ITS in some regions?

I doubt 802.11p be mandated for ITS.

I think the regulator mandates the application which could be used on
some frequencies.

Where I live, the regulator mandates the use of vehicular 'safety'
applications at 5875-5905MHz.  The technical 'conditions' are referred
by the regulator to ETSI documents (the regulator is not ETSI, but often
implements what ETSI wants, but not always).  I doubt the regulator
mandates 'geonetworking' for this band.

I doubt 'IP' could be qualified as 'safety'.

Hence I think 802.11s _could_ be used on the range 5875-5905MHz, as long
as it does not transport IP.

802.11p has some features which could qualify as 'safety'.  For example,
it has some MAC-layer messages for 'emergency', and with timestamps
(absent from .11 non-p standard), which don't transport IP.

'geonetworking' also has some features which could qualify as 'safety'.
I just don't remember which.

What features in 802.11s would qualify as 'safety'?

Alex

> EtherType soon-to-be-0x8947?  Or other?  I suppose that if I run IPv4
> over 11p without GeoNetworking I should use EtherType 0x0800, and if
> it's ARP over 802.11p still without GeoNetworking then I should use
> EtherType 0x0806.
>
>  of some 802.11p links (no ESSID, absence of link-layer security -
> as opposed to WiFi which has ESSID and link-layer security) and IP.
>
>>>>>> [email-masked] Subject: Re: [its] What do we need to make ITS
>>>>>> WG go forward? - EtherType for ITS
>>>>>>
>>>>>> Hello Dan,
>>>>>>
>>>>>> Thank you for the email.
>>>>>>
>>>>>>> required, and probably only ETSI members have the access
>>>>>>> information.
>>>>>>>
>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM *To:*
>>>>>>> [email-masked] *Subject:* Re: [its] What do we need to make
Alex
>>>>>>> stack deployed for ITS use cases. This cannot be done at
>>>>>>> IETF, and actually already exists at ISO: - ISO 21217 -
>>>>>>> of ISO 21210, but new work items have been launched since
>>>>>>>  ND Prefix Delegation - PMIP-based network mobility -
>>>>>>> IPv6 single-address connecion 'sharing' with a cellular
----------
> system. Cassidian Limited, Registered Office : Quadrant House, Celtic

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 16 Feb 2013 13:32:00 +0100

Hans-Joachim,

I forgot to say, in relationship with FNTP, mobility options like Fast
handovers, are also pertinent to other groups.

At IRTF (Internet Research Task Force) there is this MOBOPTS Research
Group where some times they discuss these techniques for mobility.

At IETF in the NETEXT Working Group often there is discussion about use
of Proxy Mobile IP and Fast MIP.

In the DMM (Distributed Mobility Management) WG there is currently
discussion about what to do next.  And this idea of improved handovers
may come up there as well.

In the DHC (Dynamic Host Configuration) WG, there is this question of
how to do fast DHCP over 802.11ai, with the goal to realize fast
configurations in crowded pedestrian areas.

One would check these groups as well.  If you need further information
about these groups we can provide.

Alex

Le 15/02/2013 19:27, Alexandru Petrescu a écrit :
>> The 30 MHz allocated in Europe around 5,9 GHz are reserved for
>> road safety. However the service advertisement message (SAM) has to
>> go on the CCH (as agreed at ETSI TC ITS). However the session,
>> which could be an entertainment session, has to be performed on
>> other channels, maybe on other media.
>>
>> networking technology for Cooperative ITS - no doubt.
>> GeoNetworking over ITS-G5 or even tunneling of IP over
>> GeoNetworking over ITS-G5 simply is a NO-GO.
>>
> But at IETF there is this Fast Mobile IP protocol.  There are many
> other IETF options or protocols with Fast in their names.  (also IEEE
> recently has something about 802.11ai about fastness and DHCP).
>
>> When it comes to the need of geo-dissemination of information,
>> IPv6 should be used without GeoNetworking, transported over any
>> kind of network (802.11p in a first hop, cellular networks,
>> Internet, ...). Please note also that GeoNetworking is covered by
>> IPRs from NEC and others.
>
>>
>>
>> Hans-Joachim
>>
>>>>>>> IP-over-802.11p without geonetworking (i.e. not allowed
>>>>>>> to use the frequencies allocated to ITS for 802.11p
>>>>>>> without using ETSI ITS i.e. geonetworking).
>>>>>>
>>>>> About references - the quick study I did is on references
>>>>> from ARCEP and ETSI, simplified below.
>>>>>
>>>>> Channel 1) - number 176 5 870 MHz - G5SC3 (Service Channel 3)
>>>>> - number 174 5 860 MHz - G5SC4 (Service Channel 4) - number
>>>>> 172 5 470 MHz to 5 725 MHz - G5SC5.
>>>>>
>>>>> Crossing ARCEP with ETSI one notices that only G5CC, G5SC2
>>>>> and G5SC1 can be used in France for 'ITS'.
>>>>>
>>>>> ETSI[**] document says: "G5SC1 and G5SC2 shall be used for
>>>>> ITS road safety and traffic efficiency applications". "Other
>>>>> ITS user applications G5SC3, G5SC4 and G5SC5".
>>>>>
>>> There would be no risk if I send entertainment vlc videostreams
>>> on the Control Channel?
>>>
>>>>> Alex [*] ARCEP "Autorité de régulation des comm.
>>>>> électroniques et des postes"
>>>>> https://www.espectre.arcep.fr/index.php (filled in "Fréquence
>>>>> Inférieure" as 5470MHz and "Fréquence Supérieure" as 5905MHz,
>>>>> then click "Rechercher", then locate "ITS" in that page) [**]
>>>>> ETSI ITS Final draft ETSI ES 202 663 V1.1.0 (2009-11) Page 13
>>>>>>> lack of open-source driver codes for 802.11p - lack of
>>>>>>> open and free-of-charge access to ETSI standards - lack
>>>>>>> of open access to ETSI interoperability results - lack of
>>>>>>> cheap hardware implementations of 802.11p - lack of
>>>>>>> misunderstanding between the ETSI point of view of what
>>>>>>>> I have some clarification questions about EtherType
>>>>>>>> and 802.11p and GeoNetworking.
>>>>>>>>
>>>>>>>> GeoNetworking, the Ethernet header uses EtherType
>>>>>>>> Also, if I run IPv4 over 11p with GeoNetworking -
>>>>>>>> should I use EtherType soon-to-be-0x8947?  Or other?  I
>>>>>>>> suppose that if I run IPv4 over 11p without
>>>>>>>> GeoNetworking I should use EtherType 0x0800, and if
>>>>>>>> it's ARP over 802.11p still without GeoNetworking then
>>>>>>>> I should use EtherType 0x0806.
>>>>>>>>
>>>>>>>> absence of link-layer security - as opposed to WiFi
>>>>>>>> which has ESSID and link-layer security) and IP.
>>>>>>>>
>>>>>>>> Advertisements work easier on 802.11p links (easier
>>>>>>>> than on WiFi), because the ESSID does not need to be
>>>>>>>> 802.11p to work; but in our experimentations this is
>>>>>>>> not the case - it is possible to establish direct
>>>>>>>> vehicle-to-vehicle IP-over-802.11p communications
>>>>>>>> For another example - is all the security on these
>>>>>>>> links entirely relaying on IP layer security (IPsec,
>>>>>>>> SeND, EAP, PANA)?
>>>>>>>>
>>>>>>>>>> It would agree on the EtherType and/or whether
>>>>>>>>>> there are new ones, several or only one, or
>>>>>>>>>> reusing existing EtherTypes.
>>>>>>>>>>
>>>>>>>>>>> notation also because the sharp sign preceding
>>>>>>>>>>> it, and because if it were decimal it would
>>>>>>>>>>> convert to 22F3 which is already reserved for
>>>>>>>>>>> trill.
>>>>>>>>>>>
>>>>>>>>>>>>> is hexa or decimal, so we know what to put
>>>>>>>>>>>>> in implementation (e.g. wireshark packet
>>>>>>>>>>>>>> The documents that you are referring (on
>>>>>>>>>>>>>> the ETSI server) are not freely accessible.
>>>>>>>>>>>>>> A password is required, and probably only
>>>>>>>>>>>>>> * This is a partial listing of all
>>>>>>>>>>>>>> assigned EtherType Fields. Not
>>>>>>>>>>>>> all
>>>>>>>>>>>>>> Did ETSI require for this information not
>>>>>>>>>>>>>> to be published? It does not look useful
>>>>>>>>>>>>>> if they want to encourage interoperability
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [mailto:[email-masked]] *On Behalf
>>>>>>>>>>>>>> Of *Thierry Ernst *Sent:* Wednesday,
>>>>>>>>>>>>>> January 30, 2013 11:11 AM *To:*
>>>>>>>>>>>>>> [email-masked] *Subject:* Re: [its] What do
>>>>>>>>>>>>>> we need to make ITS WG go forward? -
>>>>>>>>>>>>>> EtherType for ITS
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alex,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> GeoNetworking). Check the following
>>>>>>>>>>>>>> charging for the ISO 21217 - Architecture
>>>>>>>>>>>>>> & ISO 21210 - IPv6 Networking.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does this make it any better? Safer?
>>>>>>>>>>>>>> Should ISO now have cybersecurity and
>>>>>>>>>>>>>> safety liability if the specification leads
>>>>>>>>>>>>>> EtherType 0x0707 described in ITS
>>>>>>>>>>>>>> documents, implemented, but not specified
>>>>>>>>>>>>>> by IEEE nor reserved at IANA - does not
>>>>>>>>>>>>>> make it interoperable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IPv6 0x86dd ethertype is reserved at IEEE
>>>>>>>>>>>>>> and at IANA
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> charter, and support from the industry.
>>>>>>>>>>>>>> But more importantly, IETF WGs are not
>>>>>>>>>>>>>> usually sector-driven, so it means the
>>>>>>>>>>>>>> different issues pertaining to ITS should
>>>>>>>>>>>>>> be brought to
>>>>>>>>>>>>> VARIOUS
>>>>>>>>>>>>>> which there is no existing WG that could
>>>>>>>>>>>>>> work on it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This said, as mentioned earlier, ITS is
>>>>>>>>>>>>>> not only about vehicular communications,
>>>>>>>>>>>>>> though the issues listed by Alexandru below
>>>>>>>>>>>>>> What ITS really needs is the definition of
>>>>>>>>>>>>>> a common communication architecture and
>>>>>>>>>>>>>> the definition of what features should be
>>>>>>>>>>>>>> done at IETF, and actually already exists
>>>>>>>>>>>>>> at ISO: - ISO 21217 - Architecture - ISO
>>>>>>>>>>>>>> 21210 - IPv6 Networking
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> published version of ISO 21210, but new
>>>>>>>>>>>>>> work items have been launched since then
>>>>>>>>>>>>>> to address remaining issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, Thierry.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> what is taking place in MANET. I would
>>>>>>>>>>>>>> Thank you for the offer.  I considered
>>>>>>>>>>>>>> this offer since some time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> exchange - VIN-based IP addressing scheme
>>>>>>>>>>>>>> - ND Prefix Delegation - PMIP-based
>>>>>>>>>>>>>> network mobility - IPv6 single-address
>>>>>>>>>>>>>> connecion 'sharing' with a cellular
>>>>>>>>>>>>>> operator and a vehicular moving network
>>>>>>>>>>>>>> (type '64share' of v6ops). - Default Route
>>>>>>>>>>>>>> with DHCPv6.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yours,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards, Stan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IESG. I have not attended the last meeting
>>>>>>>>>>>>>> to join voices previously heard to make it
>>>>>>>>>>>>>> a working group. So what should we exactly
>>>>>>>>>>>>>> do, to achieve this goal ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was interested in this group but not
>>>>>>>>>>>>>> sure where are we so far. Is there
>>>>>>>>>>>>>> progress, or is there issues/efforts that
>>>>>>>>>>>>>> -- * * *تحياتي ، **Cordialement, Regards*
>>>>>>>>>>>>>> * * * * *نبيل بنعمروNabil Benamar*
>>>>>>>>>>>>>> Professor of computer sciences Simulation
>>>>>>>>>>>>>> and Modelisation Laboratory Human Sciences
>>>>>>>>>>>>>> Faculty of Meknes Moulay Ismail*
>>>>>>>>>>>>>> *University* Meknes, Morocco *GSM: * *+ 212
>>>>>>>>>>>>>> 6 70832236 http://nabilbenamar.com/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
its
its
its
its mailing
>>>>>>>> include commercially sensitive information. The
>>>>>>>> contents of this e-mail are for the intended recipient
>>>>>>>> only and therefore if you wish to disclose the
>>>>>>>> information contained within this e-mail or attached
>>>>>>>> files, please contact the sender prior to any such
>>>>>>>> disclosure, copying or distribution is prohibited.
>>>>>>>> Please also contact the sender and inform them of the
>>>>>>>> error and delete the e-mail, including any attached
>>>>>>>> files from your system. Cassidian Limited, Registered
>>>>>>>> Office : Quadrant House, Celtic Springs, Coedkernew,
>>>>>>>> Newport, NP10 8FZ Company No: 04191036
>>>>>>>> http://www.cassidian.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 17 Feb 2013 11:51:31 +0100

We will need geonetworking in ITS, but in new draft not in proposed charter *.

[*] http://www.ietf.org/mail-archive/web/its/current/msg00220.html

AB

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Mon, 18 Feb 2013 18:28:24 +0100

Hi Hans-Joachim,

El 13/02/2013, a las 20:59, Dr. Hans-Joachim Fischer escribió:
> 
> The 30 MHz allocated in Europe around 5,9 GHz are reserved for road safety. However the service advertisement message (SAM) has to go on the CCH (as agreed at ETSI TC ITS). However the session, which could be an entertainment session, has to be performed on other channels, maybe on other media.
> 
> I guess that the "dream of video-streaming via 802.11p" now is identified as a dream. Bandwidth problems and reservation of bands for specific purposes are a fact.
> 
> This is absolutely independent from using IPv6 or not. IPv6 is THE networking technology for Cooperative ITS - no doubt. GeoNetworking over ITS-G5 or even tunneling of IP over GeoNetworking over ITS-G5 simply is a NO-GO.
> 
Could you provide the rationale for such statement, please? Any reference?

> For simple single-hop communications, which is the primary task of V2V,

I'm curious about this design decision from ISO. I mean, for information dissemination, it seems that issuing as many single-hop messages as possible within a given channel is favored over more bandwidth-saving multi-hop approaches. Am I wrong? If not, is there any evidence of the technical superiority of one approach over another?

> FNTP from ISO is much more efficient than GeoNetworking. When it comes to the need of geo-dissemination of information, IPv6 should be used without GeoNetworking, transported over any kind of network (802.11p in a first hop, cellular networks, Internet, ...).

I'm not sure whether I understood you correctly. Do you mean that IPv6 should incorporate geographic information? Or maybe that geo-dissemination must be handled by the application layer?

Best,
fran

> Please note also that GeoNetworking is covered by IPRs from NEC and others.
> 
> 
> Hans-Joachim
> 

--
Francisco J. Ros, PhD
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)
http://masimum.inf.um.es/fjrm/

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Mon, 18 Feb 2013 18:51:12 +0100

Hi Roberto,

> That's why we map IPv6 multicast into lower layer (GeoNetworking) geocast and we do not make IPv6 geo-aware.
Yes, that's a perfectly fine approach. However, embedding geographic information within IPv6 is technically possible and interoperability isn't broken. We implemented something along these lines some years ago by exploiting hop-by-hop extension headers. Advantages: no need for tunneling, no need for gateways between the vehicular network and the Internet, and standard IPv6 nodes can receive and process (maybe route?) the message. Of course there are disadvantages too.

Also, I can't see why this would break internal working of IP (at least no more than AODV, DSR, or any other MANET reactive protocol does). Routing table lookups are performed as usual. When an entry is not found, the routing protocol is invoked to find one. For unicast (multicast) communications the routing table (OIL) is updated. Then, the message is forwarded (or dropped if no entry matches).

I'm not arguing that this solution is better than the GeoNetworking way. Just wanted to note that the solution space could be broader than the one this thread is assuming.

Best,
fran

---

From: Roberto Baldessari <[email-masked]>
Date: Tue, 19 Feb 2013 08:24:00 +0000

Hi Francisco,

I agree with you to keep the solution space broad for IETF. I just described the approach followed by ETSI. The rationale of the ETSI approach is to keep IPv6 as-is. Besides having a shorter time to market, this also allows to re-use proven and wide spread IPv6 implementations untouched. Anyway, this group is free to propose an alternative approach, I am not trying to steer this group. I just want the people to understand the reasons of certain choices.

Best regards,

Roberto

-----Original Message-----
From: Francisco Javier Ros Muñoz [mailto:[email-masked]] 
Sent: 18 February 2013 18:51
To: Roberto Baldessari
Cc: Alexandru Petrescu; Dowdell, John; [email-masked]
Subject: Re: [its] IP over 802.11p

Hi Roberto,

El 15/02/2013, a las 11:05, Roberto Baldessari escribió:

>> Basically, I think inserting geography in such internal workings 
>> which is IP addressing changes the nature of this latter, and may 
>> loose its widespread interoperability.  And yes, I should look first at its advantages.  LEt's discuss separately.
> 

Best,
fran

>>> need to be formed - suffices it to send packets on a certain channel.
>>> 
>>>>>>>>> *To:* [email-masked] *Subject:* Re: [its] What do we need to 
>>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS 
>>>>>>>>> use (ETSI TC ITS's GeoNetworking). Check the following 
>>>>>>>>> D2.2 provides an analysis of the currently published version 
>>>>>>>>> of ISO 21210, but new work items have been launched since then 
>>>>>>>>> would need its own IETF group. The work here is the  same 
>>>>>>>>> (IMO) as what is taking place in MANET. I  would vote that 
>>>>>>>>> have interest could be brought in in MANET WG:
>>>>>>>>> single-address connecion 'sharing' with a cellular operator 
>>>>>>>>> and a vehicular moving network (type '64share' of v6ops). - 
>>>>>>>>> I think we already done some steps but not sure how far now. 
>>>>>>>>> We will need to propose the WG and provide the WG charter, as 
>>>>>>>>> use cases and work to be done in this group. This charter 
>>>>>>>>> needs to be approved by the IESG. I have not attended the last 
>>>>>>>>> previously heard to make it a working group. So  what should 
>>>>>>>>> we exactly do, to achieve this goal ?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> far. Is there progress, or is there issues/efforts that need 
>>>>>>>>> to be completed and volunteered.
>>>>>>>>>

---

From: Roberto Baldessari <[email-masked]>
Date: Tue, 19 Feb 2013 08:28:43 +0000

Hi Alex,

The ETSI GeoNetworking address is not derived from the position of a node, but it consists of the MAC address + some other fields that describe the type of station.

This is v1.1.1, published some time ago. However, now ETSI already has a new draft with important changes, but the geonetworking address approach is not changing
http://www.etsi.org/deliver/etsi_ts/102600_102699/1026360401/01.01.01_60/ts_1026360401v010101p.pdf

See section 6.3.

Best regards,

Roberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: 15 February 2013 15:35
To: Roberto Baldessari
Cc: Dowdell, John; [email-masked]
Subject: Re: [its] IPv6 and geonetworking (was: IP over 802.11p)

> (GeoNetworking) geocast and we do not make IPv6 geo-aware.

I think it is good to prefer to make other layers geo-aware, instead of IP, because IP has its own notion of what is 'geography' - distance, metrics, topology - all mean different things in the IP architecture than to geography.

In some aspects, geonetworking is not only multicast.  There may be more about geonetworking I still need to re-discover, but here is one particular aspect:

'C2C NET ID' which is used to form IPv6 addresses for vehicles.  I.e.
such an address is formed based on the geographic position.  If so I think it is not good, because it means when no position no IP address.

We propose to form IPv6 addresses for vehicles based on the VIN (Vehicle Identification Numbers), instead of the position.  The VIN is always there so addresses are always there.

This is one aspect of IP addressing and geonetworking which deserves discussion.

> Actually, at the very beginning of this group's discussion, I asked if 
> the group could review the ETSI IPv6 over GeoNetworking standard.

> It would have been useful to receive some IETF input.

YEs, it would have been useful.  If you could send publicly once again the ref to that ETSI ITS document, on this list, I could send some feedback on some very minor aspects.  Please do send the ref.

I want to add - the IETF input, in order to be qualified as such, should happen publicly, in an organized manner - working group, public discussion, public decisions.

As a counter-example: my oppinion sent to you in private (even though I often participate at IETF) should not be qualified as an "IETF input".

It's not that the IETF 'usual suspects' participate at another SDO that that input is IETF input.  We need documents, WG items, Charters for that to happen.

We need to avoid a situation where IETF person X pretends Y to SDO, without giving a chance to another IETF person U to express counter-Y.

Alex

>>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc.
>>> It is not clear either whether GeoNetworking supports IPv4 or not, 
>>> or under what form).
>>>
>>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM
>>>>>>>> To: [email-masked] Subject: Re: [its] What do we need to make ITS 
2
0
r
>>>>>>>>> documents D2.1 and D2.2 available on the
>>>>>>>>> ITSSv6 project web page:
>>>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides an  analysis 
>>>>>>>>> of the currently published version of ISO 21210, but new work 
>>>>>>>>> items have been launched since then to address remaining 
>>>>>>>>> issues.
>>>>>>>>>
>>>>>>>>> Regards, Thierry.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> have interest could be brought in in MANET
>>>>>>>>> WG: - V2V using prefix exchange - VIN-based IP addressing  
>>>>>>>>> scheme - ND Prefix Delegation - PMIP-based network mobility - 
>>>>>>>>> needs to be approved by the  IESG. I have not attended the 
>>>>>>>>> previously heard to make it a working group.
>>>>>>>>> Moulay Ismail*
-

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 19 Feb 2013 10:39:28 +0100

On 2/15/13, Roberto Baldessari <[email-masked]> wrote:
> Actually, at the very beginning of this group's discussion, I asked if the
> group could review the ETSI IPv6 over GeoNetworking standard. It would have
> been useful to receive some IETF input. We have now submitted an update
> within ETSI ITS. If approved, it will be published soon (< 1 month). Note
> that people who also participate(d) in IETF contributed to the ETSI
> standard. So, I would not talk about IETF/ETSI as two separate worlds.
> Rather, what is missing is some official/structured cooperation to build on

I don't like to separate any IETF customer or participant from IETF,
not sure if there is a cooperation agreement between ETSI and IETF.
However, I agree it is important to know about other published works,

AB

---

From: Francisco Javier Ros Muñoz <[email-masked]>
Date: Tue, 19 Feb 2013 10:42:11 +0100

Roberto,

Then we're on the same page here, I'm not advocating either option, just showing alternatives.

Best,
fran

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Feb 2013 14:38:22 +0100

Roberto,

First - far from my any intention to bash on geonetworking.  It is a
technology that deserves consideration at IETF.  It may have IPR aspects
but that could be discussed as well - decisions may converge abou t it.

In my comments I may be some times too approximate, and even wrong at times.

Le 19/02/2013 09:28, Roberto Baldessari a écrit :
> Hi Alex,
>
> The ETSI GeoNetworking address is not derived from the position of a
>  node, but it consists of the MAC address + some other fields that
> describe the type of station.

I agree.

The URL below describes a geonetworking address format on its page 14,
section 6.3.  That geonetworking address does not have position in it.

(for precise nits - the length of the address seems to be 64 (in the
table 1, add the number of bits it makes up for 64).  But in the
graphical representation in Figure 3, it seems to be length 74 instead.)

To explain my earlier remark about address and position - I was under
another impression of the notion of 'address' of geonetworking.

At several places this doc in the URL below says 'position vector of the
source', and 'position vector of the destination'.  The
position vector is containing latitude/longitude/altitude etc.  I am
afraid the spec uses this Position Vector as an address, semantically.
I may be wrong, but it is my impression.

For example, it has this notion of 'neighbor': IS_NEIGHBOR is true if
'the GeoAdhoc router is in direct communication range, i.e. is a
neighbour.'  I understand that that can be realized by comparing
positions.  Two positions that differ only in a small amount of seconds
are neighbors.

Based on that decision two computers may or not communicate.

But the decision based on comparing these coordinates is too heavily
relying on positioning.  It may very well be that the two computers
_are_ in communication range (send a beacon, receive it) yet their
positioning indicates they are not (because of interference or other).

(I can discuss separately about the dillution of precision, position
representation, Glonass and WGS-84, Galileo precision 10cm vs 1m - all
are factors of imprecision which weigh too heavy on the decision about
connecting two computers).

Neighbor Discovery protocol is an IPv6 protocol at IETF.  This can also
be used to discover neighbors.  I think we need to discuss why ND is not
used in ETSI ITS - there may indeed exist reasons why.

> This is v1.1.1, published some time ago. However, now ETSI already
> has a new draft with important changes, but the geonetworking address
> approach is not changing

YEs.

Please help make such we can comment publicly on the draft in progress.

I will continue read what you send - thanks, but I humbly will decline
to accept to be told that it's not the last version.  I am humbly not a
second-class citizen of the group.

To achieve this, maybe it is possible to disseminate the ETSI draft here
at IETF, for standardization work (if ETSI relationship has a notion of
free dissemination for standardization work, as ISO seems to have).
This can be made possible if this discussion list becomes a BoF and
further a WG.

One could comment on the Draft Charter proposal - please help us improve
it, thank you.

(also - I am interested in what do the other SDOs look like, and what
are their interest at IETF; towards that goal I am open to suggestions).

Alex

> 15 February 2013 15:35 To: Roberto Baldessari Cc: Dowdell, John;
> [email-masked] Subject: Re: [its] IPv6 and geonetworking (was: IP over
>  802.11p)
>
> I think it is good to prefer to make other layers geo-aware, instead
>  of IP, because IP has its own notion of what is 'geography' -
> distance, metrics, topology - all mean different things in the IP
> architecture than to geography.
>
> In some aspects, geonetworking is not only multicast.  There may be
> more about geonetworking I still need to re-discover, but here is one
> particular aspect:
>
> We propose to form IPv6 addresses for vehicles based on the VIN
> (Vehicle Identification Numbers), instead of the position.  The VIN
> is always there so addresses are always there.
>
> YEs, it would have been useful.  If you could send publicly once
> again the ref to that ETSI ITS document, on this list, I could send
> some feedback on some very minor aspects.  Please do send the ref.
>
> I want to add - the IETF input, in order to be qualified as such,
> should happen publicly, in an organized manner - working group,
> public discussion, public decisions.
>
> As a counter-example: my oppinion sent to you in private (even though
> I often participate at IETF) should not be qualified as an "IETF
> input".
>
> It's not that the IETF 'usual suspects' participate at another SDO
> that that input is IETF input.  We need documents, WG items, Charters
> for that to happen.
>
>> We have now submitted an update within ETSI ITS. If approved, it
>> will be published soon (< 1 month).
>
>> Note that people who also participate(d) in IETF contributed to
>> the ETSI standard. So, I would not talk about IETF/ETSI as two
>>>> Is anyone making 802.11p radios commercially at reasonable
>>>> cost? The few I have seen seem to be very expensive (few k$)
>>>> and there appears to be little support in Linux. 802.11s on the
>>>> other hand is available on standard Wi-Fi dongles (from $15)
>>>> and drivers are already available in Linux. Is it correct that
>>>> 802.11p is mandated for ITS in some regions?
>>>
>>> John,
>>>
>>> Without advertising, we use finalized 802.11p hardware (OBU,
>>> RSU, etc.) and support from ITRI Taiwan.  The complete package
>>> I think yes, there seem to be little if any open source GPL
>>> driver support in linux for 802.11p.  I am interested to learn if
>>> this exists somewhere, even in a prototypical form.  We're only
>>> aware of SPITS project, but were not very successful at trying
>>> it.
>>>
>>> One advantage of .p is that it is regulated such as no need to
>>> pay  a license and still allowed to emit at high power levels
>>> (33dBm EU, 40dBm US, compared to hundreds of milliWats for WiFi).
>>> I.e. it is possible to have two independent vehicles distanced by
>>> requiring license from government (whereas in the case of WiFi
>>> one can't legally do more than a hundred meters or so).
>>>
>>> I am not sure this is the case for .s(?)  Could .s use high
>>> power levels like EIRP 40dBm and without license?
>>>
>>>
>>> Then,
>>>
>>>> in our experimentations this is not the case - it is possible
>>>> to  establish direct vehicle-to-vehicle IP-over-802.11p
>>>>>>> because the sharp sign preceding it, and because if it
>>>>>>> were decimal it would convert to 22F3 which is already
>>>>>>> reserved for  trill.
>>>>>>>
>>>>>>>>>> for ITS use (ETSI TC ITS's GeoNetworking). Check
>>>>>>>>>> the  following document available on the ETSI
>>>>>>>>>> server:
>>>>>>>>>>
>>>>>>>>>> ITS(13)000020
>>>>>>>>>> <http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%2813
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
%
>>>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)00
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
0
>>>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numb
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
e
>>>>>>>>>> different issues pertaining to ITS should be
>>>>>>>>>> brought to
>>>>>>>>> VARIOUS
>>>>>>>>>>  which I have interest could be brought in in
>>>>>>>>>> MANET WG: - V2V using prefix exchange - VIN-based
>>>>>>>>>> IP addressing scheme - ND Prefix Delegation -
>>>>>>>>>> this group. This charter needs to be approved by
>>>>>>>>>> the  IESG. I have not attended the last meeting so
>>>>>>>>>> --------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
-