Subject: [its] Updated list of suppliers of 802.11p-compatible equipment

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Jun 2013 14:51:22 +0200

Hello participants to ITS email list,

I added Arada Systems to the list of suppliers of 802.11p-compatible 
equipment.  Additionally, I have been pointed that many if not all (?) 
these systems use 802.11p miniPCI boards from UNEX.

The list is now the following:

Arada Systems LocoMate OBU
RENESAS ELECTRONICS
NEC
NXP/Cohda Wireless
Cisco/Cohda Wireless
Denso
Delphi
Savari
Kapsch
Siemens
ITRI
AutoTalks
Commsignia

Yours,

Alex

Le 16/05/2013 20:23, Alexandru Petrescu a écrit :
> Yes, thank you.  The list is now:
>
> RENESAS ELECTRONICS
> NEC
> NXP/Cohda Wireless
> Cisco/Cohda Wireless
> Denso
> Delphi
> Savari
> Kapsch
> Siemens
> ITRI
> AutoTalks
> Commsignia
>
> Yours,
>
> Alex
>
> Le 03/05/2013 18:32, Lenardi, Massimiliano a écrit :
>> Dear All,
>> please also add   RENESAS ELECTRONICS   to the list below of potential
>> suppliers of 11p/DSRC enabled radio devices.
>> Best,
>> -
>> Max
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Alexandru Petrescu
>> Sent: 24 April 2013 13:49
>> To: [email-masked]
>> Subject: Re: [its] suppliers of 802.11p-over-ITS-G5;
>> 802.11s-over-5875-5905MHz
>>
>> Recently I discovered that in addition to the posted list there is
>> also Commsignia as a manufacturer of 802.11p compatible OBU and RSU.
>> The list is now:
>>
>> NEC
>> NXP/Cohda Wireless
>> Cisco/Cohda Wireless
>> Denso
>> Delphi
>> Savari
>> Kapsch
>> Siemens
>> ITRI
>> AutoTalks
>> Commsignia
>>
>> Yours,
>>
>> Alex
>>
>> Le 16/02/2013 13:19, Alexandru Petrescu a écrit :
>>> 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.
>>>
>>> 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
>>>
>>>>
>>>> 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)000
>>>>>>>>>> 020_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-numbe
>>>>>>>>>> rs.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
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> its mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/its
>>
>>
>> _______________________________________________
>> its mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/its
>> **************************************************************************************************
>>
>> E-mail Confidentiality Notice and Disclaimer.
>>
>> This e-mail and any files transmitted with it are confidential and are
>> intended solely for the use
>> of the individual or entity to which they are addressed. Access to
>> this e-mail by anyone else is
>> unauthorised. If you are not the intended recipient, any disclosure,
>> copying, distribution or any
>> action taken or omitted to be taken in reliance on it, is prohibited.
>> E-mail messages are not
>> necessarily secure. Hitachi does not accept responsibility for any
>> changes made to this message
>> after it was sent.
>> Hitachi checks outgoing e-mail messages for the presence of computer
>> viruses.
>> **************************************************************************************************
>>
>> _______________________________________________
>> its mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/its
>>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: "Varadi , Andras \(lesswire AG Ungarn\)" <[email-masked]>
Date: Thu, 13 Jun 2013 17:04:25 +0200

Dear Alexander

Please let me add some info to the topic below

Cohda/NXP are NOT UNEX based, but use their own SoC including enhanced PHY+MAC for better error tolerance at high speed. (the same goes for AutoTalks)

Üdvözlettel / Best regards,
   András Váradi

     Project Manager :: Technical Customer Support
     Automotive & WLAN Group 
     lesswire   Hungary | Office: +36 23521 667 | Email: [email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 11, 2013 2:51 PM
To: [email-masked]
Subject: [its] Updated list of suppliers of 802.11p-compatible equipment

I added Arada Systems to the list of suppliers of 802.11p-compatible equipment.  Additionally, I have been pointed that many if not all (?) these systems use 802.11p miniPCI boards from UNEX.

Yours,

Alex

Le 16/05/2013 20:23, 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.
>>>
>>> John,
>>>
>>> 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'.
>>>
>>> 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').
>>>
>>> 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'
>>> 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.
>>>
>>>> (from $15) and drivers are already available in Linux. Is it 
>>>> correct that 802.11p is mandated for ITS in some regions?
>>>
>>> I think the regulator mandates the application which could be used 
>>> on some frequencies.
>>>
>>> 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.
>>>
>>>> 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.
>>>>
>>>> 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 
>>>> direct vehicle-to-vehicle IP-over-802.11p communications without 
>>>> the presence of a fixed 802.11p Access Point).
>>>>
>>>>>> 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
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>>> Maybe you could ask them whether this number is hexa or 
>>>>>>>>> decimal, so we know what to put in implementation (e.g.
>>>>>>>>>> server) are not freely accessible. A password is required, 
>>>>>>>>>> and probably only ETSI members have the access information.
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> (see a good example of interoperability: IPv6 0x86dd 
>>>>>>>>>> ethertype is reserved at IEEE and at IANA
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> 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 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.
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> AB _______________________________________________ its 
>>>>>>>>>> بنعمروNabil Benamar* Professor of computer sciences 
>>>>>>>>>> Simulation and Modelisation Laboratory Human Sciences Faculty 
>>>>>>>>>> of Meknes Moulay Ismail* *University* Meknes, Morocco *GSM: * 
>>>>>>>>>> *+ 212 6
>>>> system. Cassidian Limited, Registered Office : Quadrant House, 
>>>> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 
>>>> http://www.cassidian.com
>>>>
>>>>
>>>
>>>
>> This e-mail and any files transmitted with it are confidential and 
>> are intended solely for the use of the individual or entity to which 
>> they are addressed. Access to this e-mail by anyone else is 
>> copying, distribution or any action taken or omitted to be taken in 
>> reliance on it, is prohibited.
>> E-mail messages are not
>> changes made to this message after it was sent.

---

From: Roberto Baldessari <[email-masked]>
Date: Fri, 21 Jun 2013 16:06:31 +0000

Yes, whoever provided the info about the majority of vendors using UNEX is wrong.

Roberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Varadi , Andras (lesswire AG Ungarn)
Sent: 13 June 2013 17:04
To: [email-masked]
Subject: Re: [its] Updated list of suppliers of 802.11p-compatible equipment

Dear Alexander

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 11, 2013 2:51 PM
To: [email-masked]
Subject: [its] Updated list of suppliers of 802.11p-compatible equipment

Yours,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Jun 2013 19:12:55 +0200

Hello Roberto,

It is not one particular person, but rather an informal discussion here
and there that expressed that that particular manufacturer was likely to
be known by several people.

It is good to know your message below.

Yours,

Alex

Le 21/06/2013 18:06, Roberto Baldessari a écrit :
> [mailto:[email-masked]] On Behalf Of Varadi , Andras (lesswire
> AG Ungarn) Sent: 13 June 2013 17:04 To: [email-masked] Subject: Re:
> [its] Updated list of suppliers of 802.11p-compatible equipment
>
> Dear Alexander
>
> Cohda/NXP are NOT UNEX based, but use their own SoC including
> enhanced PHY+MAC for better error tolerance at high speed. (the same
> goes for AutoTalks)
>
> Üdvözlettel / Best regards, András Váradi
>
> Project Manager :: Technical Customer Support Automotive & WLAN
> Group lesswire   Hungary | Office: +36 23521 667 | Email:
> [email-masked]
>
>
> Tuesday, June 11, 2013 2:51 PM To: [email-masked] Subject: [its]
> Updated list of suppliers of 802.11p-compatible equipment
>
> equipment.  Additionally, I have been pointed that many if not all
> (?) these systems use 802.11p miniPCI boards from UNEX.
>
> Arada Systems LocoMate OBU RENESAS ELECTRONICS NEC NXP/Cohda
> Wireless Cisco/Cohda Wireless Denso Delphi Savari Kapsch Siemens
> ITRI AutoTalks Commsignia
>
> Yours,
>
> Alex
>
>> RENESAS ELECTRONICS NEC NXP/Cohda Wireless Cisco/Cohda Wireless
>> Denso Delphi Savari Kapsch Siemens ITRI AutoTalks Commsignia
>>
>> Yours,
>>
>> Alex
>>
>>> Dear All, please also add   RENESAS ELECTRONICS   to the list
>>> below of potential suppliers of 11p/DSRC enabled radio devices.
>>> Best, - Max
>>>
>>>
>>> Sent: 24 April 2013 13:49 To: [email-masked] Subject: Re: [its]
>>> suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz
>>>
>>> Recently I discovered that in addition to the posted list there
>>> is also Commsignia as a manufacturer of 802.11p compatible OBU
>>> and RSU. The list is now:
>>>
>>> NEC NXP/Cohda Wireless Cisco/Cohda Wireless Denso Delphi Savari
>>> Kapsch Siemens ITRI AutoTalks Commsignia
>>>
>>> Yours,
>>>
>>> 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.
>>>>
>>>> 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').
>>>>
>>>> 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 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.
>>>>
>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>> 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).
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> * 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,
>>>>>>>>>>>
>>>>>>>>>>> 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%281
>>>>>>>>>>>
>>>>>>>>>>>
3%
>>>>>>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)0
>>>>>>>>>>>
>>>>>>>>>>>
00
>>>>>>>>>>> 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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> EtherType 0x0707 described in ITS documents,
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-num
>>>>>>>>>>>
>>>>>>>>>>>
be
>>>>>>>>>>> <[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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> AB
>>>>>>>>>>> its mailing list [email-masked]
>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>> -- * * *تحياتي ، **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
>>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
--
>>>>>>>>>>> its mailing
>>>>>>>>>>> its mailing list [email-masked]
>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>> its mailing list [email-masked]
>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>> its mailing list [email-masked]
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>> *********************************************************************
>>>
>>>
*****************************
>>> This e-mail and any files transmitted with it are confidential
>>> and are intended solely for the use of the individual or entity
>>> to which they are addressed. Access to this e-mail by anyone else
>>> is unauthorised. If you are not the intended recipient, any
>>> disclosure, copying, distribution or any action taken or omitted
>>> to be taken in reliance on it, is prohibited. E-mail messages are
>>> not necessarily secure. Hitachi does not accept responsibility
>>> for any changes made to this message after it was sent. Hitachi
>>> checks outgoing e-mail messages for the presence of computer
>>> viruses.
>>> *********************************************************************
>>>
>>>
*****************************