From john.dowdell@cassidian.com Mon Feb 11 05:50:48 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D10A21F860A for ; Mon, 11 Feb 2013 05:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt4GGmI2BXUz for ; Mon, 11 Feb 2013 05:50:45 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 24C2521F8653 for ; Mon, 11 Feb 2013 05:50:42 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 11 Feb 2013 14:50:36 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 11 Feb 2013 14:50:35 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 14:50:35 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 14:50:34 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 11 Feb 2013 13:50:34 +0000 From: "Dowdell, John" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [its] IP over 802.11p Thread-Index: AQHN/8X6j5rs2KjOqkeDe7ySghK2Xph0vJ9g Date: Mon, 11 Feb 2013 13:50:33 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.131] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2013 13:50:34.0695 (UTC) FILETIME=[C3E6BD70:01CE085E] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19628.007 X-TM-AS-Result: No--39.454700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 13:50:48 -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 corre= ct that 802.11p is mandated for ITS in some regions? John -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over 802.11p Le 31/01/2013 14:47, Thierry Ernst a =E9crit : > > 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 =E9crit : >>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>> 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: its-bounces@ietf.org >>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: its@ietf.org >>>>> 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 =E9crit : >>>>>> 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:*its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>> *On Behalf Of *Thierry Ernst *Sent:* Wednesday, January >>>>>> 30, 2013 11:11 AM *To:* its@ietf.org *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 >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> 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_E= th >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> 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 =E9crit : >>>>>> >>>>>> 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.xm= l) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> 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 >>>>>> >>>>>> 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 =E9crit : >>>>>> >>>>>> >>>>>> 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 >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> 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 its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * *=E4= =C8=ED=E1 >>>>>> =C8=E4=DA=E3=D1=E6Nabil 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 its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>> mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>> mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing >>>>> list >>>>>> its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > _______________________________________________ its mailing list its@ietf.org 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 infor= mation. 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 disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From alexandru.petrescu@gmail.com Mon Feb 11 07:30:15 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DB121F8AB6 for ; Mon, 11 Feb 2013 07:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.206 X-Spam-Level: X-Spam-Status: No, score=-11.206 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZO5YT9zqwBb for ; Mon, 11 Feb 2013 07:30:13 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E868D21F8984 for ; Mon, 11 Feb 2013 07:30:12 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1BFUAfm027758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Feb 2013 16:30:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1BFUAg5002962; Mon, 11 Feb 2013 16:30:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1BFU6Pf015276; Mon, 11 Feb 2013 16:30:10 +0100 Message-ID: <51190E7E.4040001@gmail.com> Date: Mon, 11 Feb 2013 16:30:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dowdell, John" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:30:15 -0000 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 > > John > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>> its@ietf.org 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:*its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>> *On Behalf Of *Thierry Ernst *Sent:* Wednesday, January >>>>>>> 30, 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> 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 >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 its@ietf.org >>>>>>> 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 its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>> list >>>>>>> its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > _______________________________________________ its mailing list > its@ietf.org 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@gmail.com Mon Feb 11 07:58:50 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B1E21F867E for ; Mon, 11 Feb 2013 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.235 X-Spam-Level: X-Spam-Status: No, score=-11.235 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v83P8c0Zr-Qd for ; Mon, 11 Feb 2013 07:58:48 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4F21F8873 for ; Mon, 11 Feb 2013 07:58:47 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1BFwjMu006021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Feb 2013 16:58:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1BFwjBj016096 for ; Mon, 11 Feb 2013 16:58:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1BFwilc032248 for ; Mon, 11 Feb 2013 16:58:44 +0100 Message-ID: <51191534.1040802@gmail.com> Date: Mon, 11 Feb 2013 16:58:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> In-Reply-To: <51190E7E.4040001@gmail.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11s (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:58:50 -0000 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 : > 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 > >> >> John >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org 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:*its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>> *To:* its@ietf.org *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 >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > 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 >>>>>>>> >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 its@ietf.org >>>>>>>> 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 its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>> list >>>>>>>> its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org 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 > its@ietf.org https://www.ietf.org/mailman/listinfo/its From john.dowdell@cassidian.com Mon Feb 11 08:42:48 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1509421F854E for ; Mon, 11 Feb 2013 08:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90136q798pu3 for ; Mon, 11 Feb 2013 08:42:46 -0800 (PST) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47C21F85FD for ; Mon, 11 Feb 2013 08:42:44 -0800 (PST) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 11 Feb 2013 17:42:44 +0100 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Mon, 11 Feb 2013 17:42:43 +0100 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 17:42:43 +0100 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 17:42:42 +0100 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Mon, 11 Feb 2013 16:42:42 +0000 From: "Dowdell, John" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [its] IP over 802.11s (was: IP over 802.11p) Thread-Index: AQHOCHFWEVMvftgEQEGOQS5cjy0nvZh00rBA Date: Mon, 11 Feb 2013 16:42:41 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB06AC6458@SUCNPTEXM02.com.ad.uk.ds.corp> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <0dbfc64d-0a51-40d0-aeb2-944405dd13db@SUCNPTEXC01.COM.AD.UK.DS.CORP> In-Reply-To: <0dbfc64d-0a51-40d0-aeb2-944405dd13db@SUCNPTEXC01.COM.AD.UK.DS.CORP> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.23.131] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2013 16:42:42.0645 (UTC) FILETIME=[CFD6D850:01CE0876] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.800.1017-19630.000 X-TM-AS-Result: No--21.713000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [its] IP over 802.11s (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:42:48 -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 usin= g 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 avai= lable from the IEEE web site. The mandatory default forwarding protocol is = Hybrid Wireless Mesh Protocol (HWMP), inspired by AODV with metric-aided pa= th selection, but I understand that you can change it to something else if = you wish. Hope this helps John -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 11 February 2013 15:59 To: its@ietf.org Subject: Re: [its] IP over 802.11s (was: IP over 802.11p) 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 =E9crit : > Le 11/02/2013 14:50, Dowdell, John a =E9crit : >> 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 > >> >> John >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP >> over 802.11p >> >> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>> >>> 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 =E9crit : >>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>> 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: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org 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 =E9crit : >>>>>>>> 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:*its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>> *To:* its@ietf.org *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 >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > 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 =E9crit : >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> 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 =E9crit : >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * >>>>>>>> *=E4=C8=ED=E1 =C8=E4=DA=E3=D1=E6Nabil Benamar* Professor of comput= er >>>>>>>> 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 its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>> list >>>>>>>> its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org 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 > its@ietf.org https://www.ietf.org/mailman/listinfo/its _______________________________________________ its mailing list its@ietf.org 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 infor= mation. 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 disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From r.kuntz@gmail.com Mon Feb 11 14:03:37 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2206621F85D2 for ; Mon, 11 Feb 2013 14:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28LXcrrhUuUc for ; Mon, 11 Feb 2013 14:03:35 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96E21F85D0 for ; Mon, 11 Feb 2013 14:03:34 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so3693572wib.9 for ; Mon, 11 Feb 2013 14:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ieNzQHO7oK4ZeMWg+q0Xi1S2DqcXCVZFnK1NXc2D2YA=; b=kiOgkylCgFa9XIJ16W7SNHlIxX+ajFhfsYb8Y0/DquDFuwT848UxU1JhxGMhHdbMXU 254MxKRNqyOCfpHwh9aLv3U7X+nDDSm7/Lp73qS8e34Rlp7fJyKeW9JyJC0rjTTqz7sC e2Fka73f08j3x+C3X/VGH4A4yuSK7NeiCfpGCTKBgxLL0ylcPPlWV+/HvB69w+aPPNQa HMK8fOLHsyOYPiCweCUeQ2O+xnppfVr6x42wa5mplXQcgceskIuWqL1wWkI2frgW6m4w /7t4fh3CuB3c1hdKkcpVmcH3xgg12Mt5rRx2tI7q9bWflYDH2eZ3zIeor6OsX193Kbbu obfg== X-Received: by 10.194.118.166 with SMTP id kn6mr26858807wjb.18.1360620213770; Mon, 11 Feb 2013 14:03:33 -0800 (PST) Received: from [192.168.0.12] (81-64-76-117.rev.numericable.fr. [81.64.76.117]) by mx.google.com with ESMTPS id t7sm26546976wiy.2.2013.02.11.14.03.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 14:03:32 -0800 (PST) Content-Type: text/plain; charset=windows-1256 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Romain KUNTZ In-Reply-To: <51190E7E.4040001@gmail.com> Date: Mon, 11 Feb 2013 23:03:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 22:03:37 -0000 Hello Alexandru, On Feb 11, 2013, at 16:30 , Alexandru Petrescu = wrote: > I think yes 802.11p is mandated for ITS in Europe by ETSI ITS. >=20 > 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). Do you have any reference that supports this statement? I have never = heard of such restrictions in France so far. Thank you, Romain=20 > 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. >=20 > Although I may sound relatively pessimistic, I also consider I may be > wrong in my reasoning above. >=20 > Alex >=20 >>=20 >> John >>=20 >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over >> 802.11p >>=20 >> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>>=20 >>> Well, we do actually run IPv6 over 11p (with or without >>> GeoNetworking), so I don't see what kind of issues there might be >>> ... >>=20 >> I have some clarification questions about EtherType and 802.11p and >> GeoNetworking. >>=20 >> 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. >>=20 >> 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. >>=20 >> (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). >>=20 >> 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. >>=20 >> 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. >>=20 >> (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). >>=20 >> 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"). >>=20 >> For another example - is all the security on these links entirely >> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>=20 >> I think finding consensus on some of these questions could lead to >> interoperability. >>=20 >> Alex >>=20 >>>=20 >>> Regards, Thierry >>>=20 >>>=20 >>>=20 >>> 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. >>>>=20 >>>> One of the things to say would be whether or not this is IPv6 >>>> only or IPv4 also. >>>>=20 >>>> This would say how this would work _without_ GeoNetworking. >>>>=20 >>>> It would agree on the EtherType and/or whether there are new >>>> ones, several or only one, or reusing existing EtherTypes. >>>>=20 >>>> It could be as simple as to say that IP works over 802.11p just >>>> as it works over 802.11b - no modifications. >>>>=20 >>>> What do you think? >>>>=20 >>>> Alex >>>>=20 >>>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>> Hi Alexandru, >>>>>>=20 >>>>>> IEEE talk only hexa in their Ethertype files. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> I just watend to make sure. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Dan >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org Subject: Re: [its] What do we need to make >>>>>>> ITS WG go forward? - EtherType for ITS >>>>>>>=20 >>>>>>> Hello Dan, >>>>>>>=20 >>>>>>> Thank you for the email. >>>>>>>=20 >>>>>>> I think we definitely need a good interface with IEEE about >>>>>>> this. >>>>>>>=20 >>>>>>> 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). >>>>>>>=20 >>>>>>> Also, I am interested to learn whether this deserves being >>>>>>> reserved at IANA. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > and according to this list the value 8947 is not allocated. >>>>>>>> Now, the public listing information for EtherTypes bears >>>>>>>> a disclaimer that says >>>>>>>>=20 >>>>>>>> * This is a partial listing of all assigned EtherType >>>>>>>> Fields. Not >>>>>>> all >>>>>>>> recipients wish to publish their assignment at this >>>>>>>> time. >>>>>>>>=20 >>>>>>>> Did ETSI require for this information not to be >>>>>>>> published? It does not look useful if they want to >>>>>>>> encourage interoperability >>>>>>>>=20 >>>>>>>> Value 0707 mentioned in the thread is not allocated >>>>>>>> either. >>>>>>>>=20 >>>>>>>> Let me know if I can help (as IETF liaison to the >>>>>>>> IEEE-SA). >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Dan >>>>>>>>=20 >>>>>>>> *From:*its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>>> *On Behalf Of *Thierry Ernst *Sent:* Wednesday, January >>>>>>>> 30, 2013 11:11 AM *To:* its@ietf.org *Subject:* Re: [its] >>>>>>>> What do we need to make ITS WG go forward? - EtherType >>>>>>>> for ITS >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Alex, >>>>>>>>=20 >>>>>>>> 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: >>>>>>>>=20 >>>>>>>> ITS(13)000020 >>>>>>>> = >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>=20 >>>>>>>> Regards, Thierry. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>=20 >>>>>>>> Le 28/01/2013 14:16, Joe Klein a =E9crit : >>>>>>>>=20 >>>>>>>> I really dislike the fact that ISO is charging for the >>>>>>>> ISO 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Does it make any better interoperable as well? >>>>>>>>=20 >>>>>>>> EtherType 0x0707 described in ITS documents, implemented, >>>>>>>> but not specified by IEEE nor reserved at IANA - does not >>>>>>>> make it interoperable. >>>>>>>>=20 >>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved >>>>>>>> by >>>>>>> somebody >>>>>>>> who is not IANA nor IEEE? >>>>>>>>=20 >>>>>>>> (see a good example of interoperability: IPv6 0x86dd >>>>>>>> ethertype is reserved at IEEE and at IANA >>>>>>>>=20 >>>>>>>> = http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > Alex >>>>>>>>=20 >>>>>>>> Or should these standards remain in >>>>>>>>=20 >>>>>>>> the public domain, for researches to review and >>>>>>>> validate? >>>>>>>>=20 >>>>>>>> Just my 2 cents. >>>>>>>>=20 >>>>>>>> Joe >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Dear all, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> This said, as mentioned earlier, ITS is not only about >>>>>>>> vehicular communications, though the issues listed by >>>>>>>> Alexandru below mostly consider vehicular >>>>>>>> communications. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Regards, Thierry. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =E9crit : >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Stan, >>>>>>>>=20 >>>>>>>> Thank you for the offer. I considered this offer since >>>>>>>> some time. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Please let me know. >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, Stan >>>>>>>>=20 >>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi Nabil, >>>>>>>>=20 >>>>>>>> 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, >>>>>>>>=20 >>>>>>>> AB >>>>>>>>=20 >>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> 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 ? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>> >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> AB _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * = *=E4=C8=ED=E1 >>>>>>>> =C8=E4=DA=E3=D1=E6Nabil 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/ >>>>>>>>=20 >>>>>>>> * >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 > ---------- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> * >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>> its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>> list >>>>>>>> its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>=20 >>=20 >>=20 >> _______________________________________________ its mailing list >> its@ietf.org 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 >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Tue Feb 12 03:26:59 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4AB21F8D0E for ; Tue, 12 Feb 2013 03:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.263 X-Spam-Level: X-Spam-Status: No, score=-11.263 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFeV8EqHC9gF for ; Tue, 12 Feb 2013 03:26:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B475C21F8AED for ; Tue, 12 Feb 2013 03:26:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1CBQrBY005395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Feb 2013 12:26:53 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1CBQr9N007215; Tue, 12 Feb 2013 12:26:53 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1CBQnD3008589; Tue, 12 Feb 2013 12:26:53 +0100 Message-ID: <511A26F9.4080809@gmail.com> Date: Tue, 12 Feb 2013 12:26:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Romain KUNTZ References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 11:26:59 -0000 Le 11/02/2013 23:03, Romain KUNTZ a écrit : > Hello Alexandru, > > On Feb 11, 2013, at 16:30 , Alexandru Petrescu > wrote: >> 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). > > 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 > > > > >> 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 >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>> its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>> *To:* its@ietf.org *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 >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 its@ietf.org >>>>>>>>> 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 its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>> list >>>>>>>>> its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org 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 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > From alexandru.petrescu@gmail.com Wed Feb 13 01:40:21 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1245821F8838 for ; Wed, 13 Feb 2013 01:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.288 X-Spam-Level: X-Spam-Status: No, score=-11.288 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77uMskgsfWgq for ; Wed, 13 Feb 2013 01:40:18 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4421F8840 for ; Wed, 13 Feb 2013 01:40:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1D9eDsf004920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Feb 2013 10:40:13 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1D9eDJS017663 for ; Wed, 13 Feb 2013 10:40:13 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1D9e3BF030664 for ; Wed, 13 Feb 2013 10:40:13 +0100 Message-ID: <511B5F72.6060205@gmail.com> Date: Wed, 13 Feb 2013 10:40:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> In-Reply-To: <511A26F9.4080809@gmail.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 09:40:21 -0000 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 : > Le 11/02/2013 23:03, Romain KUNTZ a écrit : >> Hello Alexandru, >> >> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >> wrote: >>> 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). >> >> 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 >> >> >> >> >>> 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 >>>> >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: >>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] On >>>>>>>>> Behalf Of Alexandru Petrescu Sent: Wednesday, January >>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, 2013 >>>>>>>>>> 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 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 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 its@ietf.org >>>>>>>>>> >>>>>>>>>> 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 its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org 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 >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From r.kuntz@gmail.com Wed Feb 13 02:31:07 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F094521F8514 for ; Wed, 13 Feb 2013 02:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V82-dVDOqPP for ; Wed, 13 Feb 2013 02:31:05 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4921F8414 for ; Wed, 13 Feb 2013 02:31:04 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so531275eek.40 for ; Wed, 13 Feb 2013 02:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=cASUWWSnmUovLutme0j01ZeaiQUJLx8C6I7JI6p8trE=; b=RTkrkeqAmy26YcvFJf1IDZFmfttPj0Z1ksWUV4AE77nfUNoK3cBEDe0QzkN02F+6Io aPZo9U6MU80BK56D/ysKmtDFsTng9K6gNGmZ8Tj3zTmjjCYQhYNBirRJ7wksTRkScQBF KkuEhNgSNznGe9gx4e0F3zITHck1/aJGFTXL8dcZWmOcG9d9EVJ5f4lgrPDY17TZ6Lyj ZRvk7SSm0ZVUBPvAosjma0gVR9MxWaZbBhaSTYhHP1hiVpKAhzxj1nctevVDO+MyPU// C+p84EKaH8z9vsaLrzEmta6hV+ZEmARRwH2jpEYXeF9470ktzH5XroAvvKOr8HgCTWaY 0z4Q== X-Received: by 10.14.223.199 with SMTP id v47mr3592607eep.18.1360751461428; Wed, 13 Feb 2013 02:31:01 -0800 (PST) Received: from guest-rocq-135039.inria.fr (guest-rocq-135039.inria.fr. [128.93.135.39]) by mx.google.com with ESMTPS id s3sm1807758eem.4.2013.02.13.02.30.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 02:30:59 -0800 (PST) Content-Type: text/plain; charset=windows-1256 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Romain KUNTZ In-Reply-To: <511A26F9.4080809@gmail.com> Date: Wed, 13 Feb 2013 11:31:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 10:31:07 -0000 Hello Alexandru, On Feb 12, 2013, at 12:26 , Alexandru Petrescu = wrote: > Le 11/02/2013 23:03, Romain KUNTZ a =E9crit : >> Hello Alexandru, >>=20 >> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >> wrote: >>> I think yes 802.11p is mandated for ITS in Europe by ETSI ITS. >>>=20 >>> 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). >>=20 >> Do you have any reference that supports this statement? I have never >> heard of such restrictions in France so far. >=20 > Hello Romain, >=20 > What channel/frequency would one consider in France, for > IP-over-80211p-w/o-geonet? >=20 > About references - the quick study I did is on references from ARCEP = and > ETSI, simplified below. >=20 > The site of ARCEP[*] says only the following frequencies are reserved > for ITS: > 5 875 - 5 905 MHz "ITS" >=20 > 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. >=20 > Crossing ARCEP with ETSI one notices that only G5CC, G5SC2 and G5SC1 = can > be used in France for 'ITS'. >=20 > 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". >=20 > 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'. Thank you for the pointers. =46rom 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 > It is for thess reasons that I speculate IP-over-80211p-without-geonet > is not possible in France. >=20 > I may be missing something? >=20 > Alex > [*] ARCEP "Autorit=E9 de r=E9gulation des comm. =E9lectroniques et des = postes" > https://www.espectre.arcep.fr/index.php > (filled in "Fr=E9quence Inf=E9rieure" as 5470MHz > and "Fr=E9quence Sup=E9rieure" 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 >=20 > = http://www.etsi.org/deliver/etsi_es/202600_202699/202663/01.01.00_50/es_20= 2663v010100m.pdf >=20 >>=20 >> Thank you, Romain >>=20 >>=20 >>=20 >>=20 >>> 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. >>>=20 >>> Although I may sound relatively pessimistic, I also consider I may >>> be wrong in my reasoning above. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> John >>>>=20 >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] >>>> IP over 802.11p >>>>=20 >>>> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>>>>=20 >>>>> Well, we do actually run IPv6 over 11p (with or without >>>>> GeoNetworking), so I don't see what kind of issues there might >>>>> be ... >>>>=20 >>>> I have some clarification questions about EtherType and 802.11p >>>> and GeoNetworking. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> (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). >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> (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). >>>>=20 >>>> 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"). >>>>=20 >>>> For another example - is all the security on these links entirely >>>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>>>=20 >>>> I think finding consensus on some of these questions could lead >>>> to interoperability. >>>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>> Regards, Thierry >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 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. >>>>>>=20 >>>>>> One of the things to say would be whether or not this is IPv6 >>>>>> only or IPv4 also. >>>>>>=20 >>>>>> This would say how this would work _without_ GeoNetworking. >>>>>>=20 >>>>>> It would agree on the EtherType and/or whether there are new >>>>>> ones, several or only one, or reusing existing EtherTypes. >>>>>>=20 >>>>>> It could be as simple as to say that IP works over 802.11p >>>>>> just as it works over 802.11b - no modifications. >>>>>>=20 >>>>>> What do you think? >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>>>> Hi Alexandru, >>>>>>>>=20 >>>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> I just watend to make sure. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Dan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>>> its@ietf.org Subject: Re: [its] What do we need to make >>>>>>>>> ITS WG go forward? - EtherType for ITS >>>>>>>>>=20 >>>>>>>>> Hello Dan, >>>>>>>>>=20 >>>>>>>>> Thank you for the email. >>>>>>>>>=20 >>>>>>>>> I think we definitely need a good interface with IEEE >>>>>>>>> about this. >>>>>>>>>=20 >>>>>>>>> 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). >>>>>>>>>=20 >>>>>>>>> Also, I am interested to learn whether this deserves >>>>>>>>> being reserved at IANA. >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > and according to this list the value 8947 is not allocated. >>>>>>>>>> Now, the public listing information for EtherTypes >>>>>>>>>> bears a disclaimer that says >>>>>>>>>>=20 >>>>>>>>>> * This is a partial listing of all assigned EtherType >>>>>>>>>> Fields. Not >>>>>>>>> all >>>>>>>>>> recipients wish to publish their assignment at this >>>>>>>>>> time. >>>>>>>>>>=20 >>>>>>>>>> Did ETSI require for this information not to be >>>>>>>>>> published? It does not look useful if they want to >>>>>>>>>> encourage interoperability >>>>>>>>>>=20 >>>>>>>>>> Value 0707 mentioned in the thread is not allocated >>>>>>>>>> either. >>>>>>>>>>=20 >>>>>>>>>> Let me know if I can help (as IETF liaison to the >>>>>>>>>> IEEE-SA). >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Dan >>>>>>>>>>=20 >>>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>>> *To:* its@ietf.org *Subject:* Re: [its] What do we >>>>>>>>>> need to make ITS WG go forward? - EtherType for ITS >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Alex, >>>>>>>>>>=20 >>>>>>>>>> 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: >>>>>>>>>>=20 >>>>>>>>>> ITS(13)000020 >>>>>>>>>> = >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > 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 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>>=20 >>>>>>>>>> Regards, Thierry. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>>=20 >>>>>>>>>> Le 28/01/2013 14:16, Joe Klein a =E9crit : >>>>>>>>>>=20 >>>>>>>>>> I really dislike the fact that ISO is charging for >>>>>>>>>> the ISO 21217 - Architecture & ISO 21210 - IPv6 >>>>>>>>>> Networking. >>>>>>>>>>=20 >>>>>>>>>> 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? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>>=20 >>>>>>>>>> EtherType 0x0707 described in ITS documents, >>>>>>>>>> implemented, but not specified by IEEE nor reserved >>>>>>>>>> at IANA - does not make it interoperable. >>>>>>>>>>=20 >>>>>>>>>> One wouldn't think that this 0x0707 ethertype be >>>>>>>>>> reserved by >>>>>>>>> somebody >>>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>>=20 >>>>>>>>>> (see a good example of interoperability: IPv6 0x86dd >>>>>>>>>> ethertype is reserved at IEEE and at IANA >>>>>>>>>>=20 >>>>>>>>>> = http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > Alex >>>>>>>>>>=20 >>>>>>>>>> Or should these standards remain in >>>>>>>>>>=20 >>>>>>>>>> the public domain, for researches to review and >>>>>>>>>> validate? >>>>>>>>>>=20 >>>>>>>>>> Just my 2 cents. >>>>>>>>>>=20 >>>>>>>>>> Joe >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Dear all, >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> This said, as mentioned earlier, ITS is not only >>>>>>>>>> about vehicular communications, though the issues >>>>>>>>>> listed by Alexandru below mostly consider vehicular >>>>>>>>>> communications. >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Regards, Thierry. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =E9crit >>>>>>>>>> : >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> All, >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Stan, >>>>>>>>>>=20 >>>>>>>>>> Thank you for the offer. I considered this offer >>>>>>>>>> since some time. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Please let me know. >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, Stan >>>>>>>>>>=20 >>>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi Nabil, >>>>>>>>>>=20 >>>>>>>>>> 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, >>>>>>>>>>=20 >>>>>>>>>> AB >>>>>>>>>>=20 >>>>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> 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 ? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> AB _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * = * >>>>>>>>>> *=E4=C8=ED=E1 =C8=E4=DA=E3=D1=E6Nabil 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/ >>>>>>>>>>=20 >>>>>>>>>> * >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > ---------- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> * >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>> its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org 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 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >=20 >=20 From HJFischer@fischer-tech.eu Wed Feb 13 02:54:10 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967B921F88B4 for ; Wed, 13 Feb 2013 02:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy5QpL-q4lsN for ; Wed, 13 Feb 2013 02:54:09 -0800 (PST) Received: from webbox333.server-home.org (webbox333.server-home.org [83.220.144.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3E21F88A3 for ; Wed, 13 Feb 2013 02:54:09 -0800 (PST) Received: from [192.168.222.117] (p54A97412.dip.t-dialin.net [84.169.116.18]) by webbox333.server-home.org (Postfix) with ESMTPSA id 9E8235F95B for ; Wed, 13 Feb 2013 11:54:07 +0100 (CET) Message-ID: <511B7103.2000200@fischer-tech.eu> Date: Wed, 13 Feb 2013 11:54:59 +0100 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 10:54:10 -0000 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 Am 13.02.2013 11:31, schrieb Romain KUNTZ: >> 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'. -- ------------------------------------------------------------------------------ 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@gmail.com Wed Feb 13 06:04:52 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171EB21F8712 for ; Wed, 13 Feb 2013 06:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8aPhEvfvwRl for ; Wed, 13 Feb 2013 06:04:51 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6521F8706 for ; Wed, 13 Feb 2013 06:04:50 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1DE4np4022974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Feb 2013 15:04:49 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1DE4npi023373 for ; Wed, 13 Feb 2013 15:04:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1DE4dSV032052 for ; Wed, 13 Feb 2013 15:04:49 +0100 Message-ID: <511B9D77.4080208@gmail.com> Date: Wed, 13 Feb 2013 15:04:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B7103.2000200@fischer-tech.eu> In-Reply-To: <511B7103.2000200@fischer-tech.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:04:52 -0000 Le 13/02/2013 11:54, Dr. Hans-Joachim Fischer a écrit : > > 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. 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 > > Am 13.02.2013 11:31, schrieb Romain KUNTZ: >>> 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'. > From alexandru.petrescu@gmail.com Wed Feb 13 06:07:28 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57BE21F86F6 for ; Wed, 13 Feb 2013 06:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.31 X-Spam-Level: X-Spam-Status: No, score=-11.31 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfK0OASwvVge for ; Wed, 13 Feb 2013 06:07:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1907E21F86E3 for ; Wed, 13 Feb 2013 06:07:25 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1DE7NH0010307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 15:07:23 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1DE7MiZ024220; Wed, 13 Feb 2013 15:07:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1DE7LH5001034; Wed, 13 Feb 2013 15:07:22 +0100 Message-ID: <511B9E19.5040500@gmail.com> Date: Wed, 13 Feb 2013 15:07:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Romain KUNTZ References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:07:29 -0000 Le 13/02/2013 11:31, Romain KUNTZ a écrit : > Hello Alexandru, > > On Feb 12, 2013, at 12:26 , Alexandru Petrescu > wrote: >> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>> Hello Alexandru, >>> >>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>> wrote: >>>> 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). >>> >>> 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'. > > 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 > > Romain > > >> 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 >>> >>> >>> >>> >>>> 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 >>>>> >>>>> -----Original Message----- From: its-bounces@ietf.org >>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: >>>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>>>>> On Behalf Of Alexandru Petrescu Sent: Wednesday, >>>>>>>>>> January 30, 2013 12:00 PM To: its@ietf.org >>>>>>>>>> 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:*its-bounces@ietf.org >>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>> >>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its >>>>>>>>>> mailing >>>>>>>>>>> list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its >>>>>>>>>> mailing >>>>>>>>>>> list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing >>>>>>>>>> list >>>>>>>>>>> its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >> >> > > > From Roberto.Baldessari@neclab.eu Wed Feb 13 09:08:56 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D221F8AA3 for ; Wed, 13 Feb 2013 09:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2J359qXaRd5 for ; Wed, 13 Feb 2013 09:08:56 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98821F88A3 for ; Wed, 13 Feb 2013 09:08:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 705C31031EA; Wed, 13 Feb 2013 18:08:52 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdGCPAMKdsdc; Wed, 13 Feb 2013 18:08:52 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 58848103132; Wed, 13 Feb 2013 18:08:42 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 13 Feb 2013 18:07:46 +0100 From: Roberto Baldessari To: "Dr. Hans-Joachim Fischer" , "its@ietf.org" Thread-Topic: [its] IP over 802.11p - frequencies local Thread-Index: AQHOCRPwLIHHvVhazEmshpEYHkR3cZh3h4MAgAAGs4CAAHTTAA== Date: Wed, 13 Feb 2013 17:07:46 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F859F4FF58@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B7103.2000200@fischer-tech.eu> In-Reply-To: <511B7103.2000200@fischer-tech.eu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:08:56 -0000 Dear Hans-Joachim, > Have also in mind that ETSI TC ITS was founded by members of ISO TC204 WG= 16. The major part of ITS standards is done at ISO, not at ETSI. This is no= w 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 Car2Ca= r Consortium partners played a bigger role in founding it, than the ISO TC2= 04 partners. Look at who has produced more ETSI ITS standards and who has b= een 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 a= nd SAE standards. Their statements are everywhere, e.g. the last ETSI ITS w= orkshop. Go and check. I am glad to continue the technical discussion and stop the SDO fights. Eve= ryone on the list can make his own opinion on which standards will hit the = market. Best regards, Roberto From Roberto.Baldessari@neclab.eu Wed Feb 13 09:25:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D921F8996 for ; Wed, 13 Feb 2013 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrxSfPI3mQut for ; Wed, 13 Feb 2013 09:25:28 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC621F8423 for ; Wed, 13 Feb 2013 09:25:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A525E1031EA; Wed, 13 Feb 2013 18:25:25 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrCXbcF4Lea5; Wed, 13 Feb 2013 18:25:25 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 87C38103132; Wed, 13 Feb 2013 18:25:10 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 13 Feb 2013 18:24:15 +0100 From: Roberto Baldessari To: Alexandru Petrescu , "Dowdell, John" Thread-Topic: [its] IP over 802.11p Thread-Index: AQHN/8X6j5rs2KjOqkeDe7ySghK2Xph0vJ9ggAAMZwCAA1H1wA== Date: Wed, 13 Feb 2013 17:24:13 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> In-Reply-To: <51190E7E.4040001@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.217] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "its@ietf.org" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:25:31 -0000 Alex, Let me address some of your points and sorry if I do not contribute often t= o 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 co= uld 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 r= eceives 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 automoti= ve industry. It's about time. I don't understand why you don't see GeoNetworking as a feature. You seem t= o consider it as an obstacle? It's a protocol. IPv6 can run on top of it wi= th some advantages. If you think a better protocol stack should be designed= , you can propose it to the industry that should eventually deploy it. Howe= ver, 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: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org Subject: Re: [its] IP over 802.11p Le 11/02/2013 14:50, Dowdell, John a =E9crit : > Alex > > Is anyone making 802.11p radios commercially at reasonable cost? The=20 > few I have seen seem to be very expensive (few k$) and there appears=20 > to be little support in Linux. 802.11s on the other hand is available=20 > on standard Wi-Fi dongles (from $15) and drivers are already available=20 > in Linux. Is it correct that 802.11p is mandated for ITS in some=20 > regions? John, Without advertising, we use finalized 802.11p hardware (OBU, RSU, etc.) and= support from ITRI Taiwan. The complete package (drivers, geonetworking, S= DKs) 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-l= ike platforms. I believe these cards may be relatively cheap. I don't kno= w 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, e= ven in a prototypical form. We're only aware of SPITS project, but were no= t very successful at trying it. One advantage of .p is that it is regulated such as no need to pay a licens= e and still allowed to emit at high power levels (33dBm EU, 40dBm US, compa= red to hundreds of milliWats for WiFi). I.e. it is possible to have two in= dependent vehicles distanced by kilometers, without infrastructure, and com= municate, and without requiring license from government (whereas in the cas= e 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 li= ke 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 with= out 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 > > John > > -----Original Message----- From: its-bounces@ietf.org=20 > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP over=20 > 802.11p > > Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >> >> Well, we do actually run IPv6 over 11p (with or without=20 >> GeoNetworking), so I don't see what kind of issues there might be ... > > I have some clarification questions about EtherType and 802.11p and=20 > GeoNetworking. > > I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20 > header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20 > over 11p without GeoNetworking, the Ethernet header uses EtherType=20 > 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=20 > EtherType soon-to-be-0x8947? Or other? I suppose that if I run > IPv4 over 11p without GeoNetworking I should use EtherType 0x0800, and=20 > if it's ARP over 802.11p still without GeoNetworking then I should use=20 > EtherType 0x0806. > > (the letter we've seen recently is not clear whether that allocation=20 > is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 > GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not=20 > clear either whether GeoNetworking supports IPv4 or not, or under what=20 > form). > > I also have some questions about the relationship between the nature=20 > of some 802.11p links (no ESSID, absence of link-layer security - as=20 > opposed to WiFi which has ESSID and link-layer security) and IP. > > For example - will V2V prefix exchange using Router Advertisements=20 > work easier on 802.11p links (easier than on WiFi), because the ESSID=20 > does not need to be discovered, the ad-hoc network does not need to be=20 > 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=20 > absolutely necessary in order for 802.11p to work; but in our=20 > experimentations this is not the case - it is possible to establish=20 > direct vehicle-to-vehicle IP-over-802.11p communications without the =20 > presence of a fixed 802.11p Access Point). > > For another example - will IP prefer that the 802.11p channel in=20 > France be 176, 178 or 180? (with WiFi, IP does not care because it can=20 > work on any of the 11 channels equally well, but with 802.11p each of=20 > these three channels seem to be reserved for "Services", "Control" and=20 > "Services"). > > For another example - is all the security on these links entirely=20 > relaying on IP layer security (IPsec, SeND, EAP, PANA)? > > I think finding consensus on some of these questions could lead to=20 > interoperability. > > Alex > >> >> Regards, Thierry >> >> >> >> On 31/01/13 13:55, Alexandru Petrescu wrote: >>> Given current discussions, I think it may be worth considering a =20 >>> 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=20 >>> 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,=20 >>> several or only one, or reusing existing EtherTypes. >>> >>> It could be as simple as to say that IP works over 802.11p just as=20 >>> it works over 802.11b - no modifications. >>> >>> What do you think? >>> >>> Alex >>> >>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>> Hi Alexandru, >>>>> >>>>> IEEE talk only hexa in their Ethertype files. >>>> >>>> I tend to agree that #8947 is a hexadecimal notation also because=20 >>>> the sharp sign preceding it, and because if it were decimal it=20 >>>> would convert to 22F3 which is already reserved for trill. >>>> >>>> I just watend to make sure. >>>> >>>> Alex >>>> >>>>> >>>>> Regards, >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 >>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG go=20 >>>>>> 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,=20 >>>>>> so we know what to put in implementation (e.g. >>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>> implementations). >>>>>> >>>>>> Also, I am interested to learn whether this deserves being =20 >>>>>> reserved at IANA. >>>>>> >>>>>> Alex >>>>>> >>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>> Hi, >>>>>>> >>>>>>> The documents that you are referring (on the ETSI server) are=20 >>>>>>> not freely accessible. A password is required, and probably only=20 >>>>>>> ETSI members have the access information. >>>>>>> >>>>>>> The responsibility for assigning EtherType values is with the=20 >>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>> (updated daily) at=20 >>>>>>> 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=20 >>>>>>> disclaimer that says >>>>>>> >>>>>>> * This is a partial listing of all assigned EtherType Fields.=20 >>>>>>> Not >>>>>> all >>>>>>> recipients wish to publish their assignment at this time. >>>>>>> >>>>>>> Did ETSI require for this information not to be published? It=20 >>>>>>> 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:*its-bounces@ietf.org [mailto:its-bounces@ietf.org] *On=20 >>>>>>> Behalf Of *Thierry Ernst *Sent:* Wednesday, January 30, 2013=20 >>>>>>> 11:11 AM *To:* its@ietf.org *Subject:* Re: [its] What do we need=20 >>>>>>> to make ITS WG go forward? - EtherType for ITS >>>>>>> >>>>>>> >>>>>>> Alex, >>>>>>> >>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use=20 >>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document=20 >>>>>>> available on the ETSI server: >>>>>>> >>>>>>> ITS(13)000020 >>>>>>> >>>>>> 900002 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf> >>>>>>> Ethernet Type Field number for GeoNetworking=20 >>>>>>> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)0000 >>>>>>> 20_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 =E9crit : >>>>>>> >>>>>>> I really dislike the fact that ISO is charging for the ISO 21217=20 >>>>>>> - Architecture & ISO 21210 - IPv6 Networking. >>>>>>> >>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>> cybersecurity and safety liability if the specification leads to=20 >>>>>>> deaths and damage to property? >>>>>>> >>>>>>> >>>>>>> Does it make any better interoperable as well? >>>>>>> >>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20 >>>>>>> not specified by IEEE nor reserved at IANA - does not make it=20 >>>>>>> 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=20 >>>>>>> is reserved at IEEE and at IANA >>>>>>> >>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-number >>>>>>> s.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=20 >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> At this stage, I don't think a new working group is needed.=20 >>>>>>> First, it would need a charter, and support from the industry.=20 >>>>>>> But more importantly, IETF WGs are not usually sector-driven, so=20 >>>>>>> it means the different issues pertaining to ITS should be=20 >>>>>>> brought to >>>>>> VARIOUS >>>>>>> existing WGs, and a WG should only be created if there is an=20 >>>>>>> important issue for which there is no existing WG that could=20 >>>>>>> work on it. >>>>>>> >>>>>>> This said, as mentioned earlier, ITS is not only about vehicular=20 >>>>>>> communications, though the issues listed by Alexandru below=20 >>>>>>> mostly consider vehicular communications. >>>>>>> >>>>>>> What ITS really needs is the definition of a common=20 >>>>>>> communication architecture and the definition of what features=20 >>>>>>> should be comprised for an IPv6 networking stack deployed for=20 >>>>>>> ITS use cases. This cannot be done at IETF, and actually already=20 >>>>>>> exists at ISO: - ISO 21217 - Architecture - ISO 21210 - IPv6=20 >>>>>>> Networking >>>>>>> >>>>>>> As an input to the discussion, please consider reading documents=20 >>>>>>> D2.1 and D2.2 available on the ITSSv6 project web page:=20 >>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides an analysis of=20 >>>>>>> the currently published version of ISO 21210, but new work items=20 >>>>>>> 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 =E9crit : >>>>>>> >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> This is just one opinion, but I'd like to understand why ITS=20 >>>>>>> would need its own IETF group. The work here is the same (IMO)=20 >>>>>>> as what is taking place in MANET. I would vote that this work be=20 >>>>>>> taken up in MANET. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Stan, >>>>>>> >>>>>>> Thank you for the offer. I considered this offer since some=20 >>>>>>> time. >>>>>>> >>>>>>> I try to understand whether some of these items on which I have=20 >>>>>>> interest could be brought in in MANET WG: - V2V using prefix=20 >>>>>>> exchange - VIN-based IP addressing scheme - ND Prefix Delegation=20 >>>>>>> - PMIP-based network mobility - IPv6 single-address connecion=20 >>>>>>> 'sharing' with a cellular operator and a vehicular moving=20 >>>>>>> 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=20 >>>>>>> will need to propose the WG and provide the WG charter, as use=20 >>>>>>> cases and work to be done in this group. >>>>>>> This charter needs to be approved by the IESG. I have not=20 >>>>>>> attended the last meeting so not sure about the status now, >>>>>>> >>>>>>> AB >>>>>>> >>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>> previously heard to make it a working group. So what should we=20 >>>>>>> exactly do, to achieve this goal ? >>>>>>> >>>>>>> >>>>>>> 2013/1/26 Abdussalam Baryun =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I was interested in this group but not sure where are we so far.=20 >>>>>>> Is there progress, or is there issues/efforts that need to be=20 >>>>>>> completed and volunteered. >>>>>>> >>>>>>> AB _______________________________________________ its mailing=20 >>>>>>> list its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * *= =E4=C8=ED=E1=20 >>>>>>> =C8=E4=DA=E3=D1=E6Nabil Benamar* Professor of computer sciences Sim= ulation=20 >>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20 >>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6=20 >>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>> >>>>>>> * >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * >>>>>>> >>>>>>> _______________________________________________ >>>>>> its >>>>>>> mailing list its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing >>>>>> list >>>>>>> its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> _______________________________________________ its mailing list=20 >>>>>>> its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing list=20 >>>>>>> its@ietf.org =20 >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing list=20 >>>>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > _______________________________________________ its mailing list > its@ietf.org 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Wed Feb 13 09:45:18 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7918521F8923 for ; Wed, 13 Feb 2013 09:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.332 X-Spam-Level: X-Spam-Status: No, score=-11.332 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO9L7XGe18bR for ; Wed, 13 Feb 2013 09:45:16 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9E21F8917 for ; Wed, 13 Feb 2013 09:45:15 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1DHjDgE021026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 18:45:14 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1DHjDPh004381; Wed, 13 Feb 2013 18:45:13 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1DHjCgS028972; Wed, 13 Feb 2013 18:45:13 +0100 Message-ID: <511BD128.8070907@gmail.com> Date: Wed, 13 Feb 2013 18:45:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roberto Baldessari References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:45:18 -0000 Roberto, Thank you for the reply. Le 13/02/2013 18:24, Roberto Baldessari a écrit : > 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). 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. > Cheap hardware 11p implementations will come. It's required by the > 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 > > Best regards, > > Roberto > > > > > > > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org Subject: > Re: [its] IP over 802.11p > > 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 > >> >> John >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org 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:*its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>> *To:* its@ietf.org *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 >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 900002 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > 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)0000 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 20_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-number >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> s.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 >>>>>>>> >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 its@ietf.org >>>>>>>> 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 its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>> list >>>>>>>> its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org 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 > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Wed Feb 13 09:45:18 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CEC21F8917 for ; Wed, 13 Feb 2013 09:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.354 X-Spam-Level: X-Spam-Status: No, score=-11.354 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AsSokwTmECP for ; Wed, 13 Feb 2013 09:45:15 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1621F8877 for ; Wed, 13 Feb 2013 09:45:14 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1DHjDZI021904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Feb 2013 18:45:13 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1DHjDbk004361 for ; Wed, 13 Feb 2013 18:45:13 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1DHj2bu028921 for ; Wed, 13 Feb 2013 18:45:12 +0100 Message-ID: <511BD11E.2030307@gmail.com> Date: Wed, 13 Feb 2013 18:45:02 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> In-Reply-To: <511B9E19.5040500@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:45:18 -0000 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 : > Le 13/02/2013 11:31, Romain KUNTZ a écrit : >> Hello Alexandru, >> >> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >> wrote: >>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>> Hello Alexandru, >>>> >>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>> wrote: >>>>> 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). >>>> >>>> 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'. >> >> 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 > >> >> Romain >> >> >>> 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 >>>> >>>> >>>> >>>> >>>>> 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 >>>>>> >>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org >>>>>> 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: >>>>>>>>>>> its-bounces@ietf.org >>>>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of >>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January 30, >>>>>>>>>>> 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>>>>>>>>>> > 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 >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its >>>>>>>>>>> mailing >>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its >>>>>>>>>>> mailing >>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing >>>>>>>>>>> list >>>>>>>>>>>> its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>> >>> >> >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From HJFischer@fischer-tech.eu Wed Feb 13 11:58:50 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A83A21E8037 for ; Wed, 13 Feb 2013 11:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YEz3NHWLKfl for ; Wed, 13 Feb 2013 11:58:48 -0800 (PST) Received: from webbox333.server-home.org (webbox333.server-home.org [83.220.144.54]) by ietfa.amsl.com (Postfix) with ESMTP id 501C121E804C for ; Wed, 13 Feb 2013 11:58:47 -0800 (PST) Received: from [192.168.222.117] (p54A97412.dip.t-dialin.net [84.169.116.18]) by webbox333.server-home.org (Postfix) with ESMTPSA id 5E6F95F9DC for ; Wed, 13 Feb 2013 20:58:45 +0100 (CET) Message-ID: <511BF0AB.7090808@fischer-tech.eu> Date: Wed, 13 Feb 2013 20:59:39 +0100 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> In-Reply-To: <511B9E19.5040500@gmail.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:58:50 -0000 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 Am 13.02.2013 15:07, schrieb Alexandru Petrescu: > Le 13/02/2013 11:31, Romain KUNTZ a écrit : >> Hello Alexandru, >> >> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >> wrote: >>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>> Hello Alexandru, >>>> >>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>> wrote: >>>>> 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). >>>> >>>> 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'. >> >> 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 > >> >> Romain >> >> >>> 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 >>>> >>>> >>>> >>>> >>>>> 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 >>>>>> >>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: >>>>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>>>>>> On Behalf Of Alexandru Petrescu Sent: Wednesday, >>>>>>>>>>> January 30, 2013 12:00 PM To: its@ietf.org >>>>>>>>>>> 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:*its-bounces@ietf.org >>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>>>>>>>>>> > 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 >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its >>>>>>>>>>> mailing >>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its >>>>>>>>>>> mailing >>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its mailing >>>>>>>>>>> list >>>>>>>>>>>> its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ its >>>>>>>>>>> mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org 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 its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>> >>> >> >> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- ------------------------------------------------------------------------------ http://its-standards.info/ESF-News-2012-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 HJFischer@fischer-tech.eu Wed Feb 13 12:13:13 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE1521F868B for ; Wed, 13 Feb 2013 12:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBjVRHVzzdoa for ; Wed, 13 Feb 2013 12:13:12 -0800 (PST) Received: from webbox333.server-home.org (webbox333.server-home.org [83.220.144.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3F221F8681 for ; Wed, 13 Feb 2013 12:13:12 -0800 (PST) Received: from [192.168.222.117] (p54A97412.dip.t-dialin.net [84.169.116.18]) by webbox333.server-home.org (Postfix) with ESMTPSA id 8887F5F9EA; Wed, 13 Feb 2013 21:13:11 +0100 (CET) Message-ID: <511BF410.9040408@fischer-tech.eu> Date: Wed, 13 Feb 2013 21:14:08 +0100 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roberto Baldessari References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B7103.2000200@fischer-tech.eu> <81154EB5875DC143AFAA75562B06D1F859F4FF58@PALLENE.office.hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F4FF58@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "its@ietf.org" Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:13:13 -0000 Dear Roberto, I will not comment on your comments. Hans-Joachim Am 13.02.2013 18:07, schrieb Roberto Baldessari: > 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 > > > > > > > > -- ------------------------------------------------------------------------------ http://its-standards.info/ESF-News-2012-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@gmail.com Thu Feb 14 07:59:06 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7021F8806 for ; Thu, 14 Feb 2013 07:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.374 X-Spam-Level: X-Spam-Status: No, score=-11.374 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUH5sZWXToVi for ; Thu, 14 Feb 2013 07:59:03 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id E130821F8561 for ; Thu, 14 Feb 2013 07:58:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1EFwwev012435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Feb 2013 16:58:58 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1EFwwSp016806 for ; Thu, 14 Feb 2013 16:58:58 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1EFwpoI006783 for ; Thu, 14 Feb 2013 16:58:58 +0100 Message-ID: <511D09BB.7010809@gmail.com> Date: Thu, 14 Feb 2013 16:58:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> <511BF0AB.7090808@fischer-tech.eu> In-Reply-To: <511BF0AB.7090808@fischer-tech.eu> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:59:06 -0000 Le 13/02/2013 20:59, Dr. Hans-Joachim Fischer a écrit : > > The 30 MHz allocated in Europe around 5,9 GHz are reserved for road > 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. > I guess that the "dream of video-streaming via 802.11p" now is > 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. > > 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. 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 > > > Hans-Joachim > > Am 13.02.2013 15:07, schrieb Alexandru Petrescu: >> Le 13/02/2013 11:31, Romain KUNTZ a écrit : >>> Hello Alexandru, >>> >>> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >>> wrote: >>>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>>> Hello Alexandru, >>>>> >>>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>>> wrote: >>>>>> 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). >>>>> >>>>> 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'. >>> >>> 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 >> >>> >>> Romain >>> >>> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>>> 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 >>>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org >>>>>>> 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: >>>>>>>>>>>> its-bounces@ietf.org >>>>>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of >>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January >>>>>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> 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 >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing >>>>>>>>>>>> list >>>>>>>>>>>>> its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> 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 its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Thu Feb 14 08:16:50 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A41321F886F for ; Thu, 14 Feb 2013 08:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.393 X-Spam-Level: X-Spam-Status: No, score=-11.393 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s8-GALw+ZXw for ; Thu, 14 Feb 2013 08:16:48 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3692D21F8868 for ; Thu, 14 Feb 2013 08:16:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1EGGkFC012222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Feb 2013 17:16:46 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1EGGjHl025023 for ; Thu, 14 Feb 2013 17:16:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1EGGfYT019443 for ; Thu, 14 Feb 2013 17:16:45 +0100 Message-ID: <511D0DE9.1070801@gmail.com> Date: Thu, 14 Feb 2013 17:16:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> <511BD11E.2030307@gmail.com> In-Reply-To: <511BD11E.2030307@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP over 802.11p - frequencies local, Radio LAN and 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:16:50 -0000 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). [**] > > - 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 : >> Le 13/02/2013 11:31, Romain KUNTZ a écrit : >>> Hello Alexandru, >>> >>> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >>> wrote: >>>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>>> Hello Alexandru, >>>>> >>>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>>> wrote: >>>>>> 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). >>>>> >>>>> 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'. >>> >>> 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 >> >>> >>> Romain >>> >>> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>>> 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 >>>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org >>>>>>> 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: >>>>>>>>>>>> its-bounces@ietf.org >>>>>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of >>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January >>>>>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January >>>>>>>>>>>>> 30, 2013 11:11 AM *To:* its@ietf.org >>>>>>>>>>>>> *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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> 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 >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its mailing >>>>>>>>>>>> list >>>>>>>>>>>>> its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> 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 its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From Roberto.Baldessari@neclab.eu Fri Feb 15 02:06:09 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03F921F8992 for ; Fri, 15 Feb 2013 02:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up8TEqeF5nNc for ; Fri, 15 Feb 2013 02:06:07 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6E21F8953 for ; Fri, 15 Feb 2013 02:06:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F2093103241; Fri, 15 Feb 2013 11:06:05 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-lckwWEXpqT; Fri, 15 Feb 2013 11:06:05 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id AAD97103240; Fri, 15 Feb 2013 11:05:50 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 15 Feb 2013 11:05:50 +0100 From: Roberto Baldessari To: Alexandru Petrescu Thread-Topic: [its] IP over 802.11p Thread-Index: AQHN/8X6j5rs2KjOqkeDe7ySghK2Xph0vJ9ggAAMZwCAA1H1wP//+HQAgAKsVCA= Date: Fri, 15 Feb 2013 10:05:06 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> In-Reply-To: <511BD128.8070907@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.217] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dowdell, John" , "its@ietf.org" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:06:09 -0000 Hi Alex, > I read the comment. We could discuss it separately, in a separate thread= . =20 > Basically, I think inserting geography in such internal workings which is= IP=20 > addressing changes the nature of this latter, and may loose its widesprea= d > 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. S= o we are perfectly in line with what you said (maximize interoperability). That's why we map IPv6 multicast into lower layer (GeoNetworking) geocast a= nd 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 wi= thin ETSI ITS. If approved, it will be published soon (< 1 month). Note tha= t 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 i= s missing is some official/structured cooperation to build on each other's = expertise/standards. Best regards, Roberto > > Best regards, > > Roberto > > > > > > > > -----Original Message----- From: its-bounces@ietf.org=20 > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org Subject: > Re: [its] IP over 802.11p > > Le 11/02/2013 14:50, Dowdell, John a =E9crit : >> 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=20 >> appears to be little support in Linux. 802.11s on the other hand is=20 >> available on standard Wi-Fi dongles (from $15) and drivers are=20 >> already available in Linux. Is it correct that 802.11p is mandated =20 >> 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,=20 > geonetworking, SDKs) is expensive yes in the range of thousands of=20 > 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=20 > PC-like platforms. I believe these cards may be relatively cheap. I=20 > don't know whether Unex offer drivers for these cards (be them binary=20 > or open source), we use the binary drivers from ITRI. > > I think yes, there seem to be little if any open source GPL driver=20 > support in linux for 802.11p. I am interested to learn if this exists=20 > somewhere, even in a prototypical form. We're only aware of SPITS=20 > 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 =20 > license and still allowed to emit at high power levels (33dBm EU,=20 > 40dBm US, compared to hundreds of milliWats for WiFi). I.e. it is=20 > possible to have two independent vehicles distanced by kilometers,=20 > without infrastructure, and communicate, and without requiring license=20 > from government (whereas in the case of WiFi one can't legally do more=20 > than a hundred meters or so). > > I am not sure this is the case for .s(?) Could .s use high power=20 > 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)=20 > seems to be that one is not allowed to use IP-over-802.11p without=20 > geonetworking (i.e. not allowed to use the frequencies allocated to=20 > ITS for 802.11p without using ETSI ITS i.e. geonetworking). > > These factors seem to strongly hamper the development of vehicular=20 > specific communication technology at IETF: - lack of open-source=20 > driver codes for 802.11p - lack of open and free-of-charge access to =20 > ETSI standards - lack of open access to ETSI interoperability results=20 > - lack of cheap hardware implementations of 802.11p - lack of =20 > unregulated/unlicensed frequency allocated for IP-over-80211p for long=20 > range. - technical misunderstanding between the ETSI point of view of=20 > what is IP and the IETF of same. > > Although I may sound relatively pessimistic, I also consider I may be=20 > wrong in my reasoning above. > > Alex > >> >> John >> >> -----Original Message----- From: its-bounces@ietf.org=20 >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP=20 >> over 802.11p >> >> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>> >>> Well, we do actually run IPv6 over 11p (with or without=20 >>> GeoNetworking), so I don't see what kind of issues there might be=20 >>> ... >> >> I have some clarification questions about EtherType and 802.11p and=20 >> GeoNetworking. >> >> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20 >> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20 >> over 11p without GeoNetworking, the Ethernet header uses EtherType=20 >> 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=20 >> EtherType soon-to-be-0x8947? Or other? I suppose that if I run >> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800, =20 >> and if it's ARP over 802.11p still without GeoNetworking then I=20 >> should use EtherType 0x0806. >> >> (the letter we've seen recently is not clear whether that allocation=20 >> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 >> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not=20 >> clear either whether GeoNetworking supports IPv4 or not, or under=20 >> what form). >> >> I also have some questions about the relationship between the nature=20 >> of some 802.11p links (no ESSID, absence of link-layer security - as=20 >> opposed to WiFi which has ESSID and link-layer >> security) and IP. >> >> For example - will V2V prefix exchange using Router Advertisements=20 >> work easier on 802.11p links (easier than on WiFi), because the ESSID=20 >> does not need to be discovered, the ad-hoc network does not need to=20 >> 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 =20 >> is absolutely necessary in order for 802.11p to work; but in our=20 >> experimentations this is not the case - it is possible to establish=20 >> direct vehicle-to-vehicle IP-over-802.11p communications without the=20 >> presence of a fixed 802.11p Access Point). >> >> For another example - will IP prefer that the 802.11p channel in=20 >> France be 176, 178 or 180? (with WiFi, IP does not care because it =20 >> can work on any of the 11 channels equally well, but with 802.11p =20 >> each of these three channels seem to be reserved for "Services",=20 >> "Control" and "Services"). >> >> For another example - is all the security on these links entirely=20 >> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >> >> I think finding consensus on some of these questions could lead to=20 >> interoperability. >> >> Alex >> >>> >>> Regards, Thierry >>> >>> >>> >>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>> Given current discussions, I think it may be worth considering a=20 >>>> 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=20 >>>> 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,=20 >>>> several or only one, or reusing existing EtherTypes. >>>> >>>> It could be as simple as to say that IP works over 802.11p just as=20 >>>> it works over 802.11b - no modifications. >>>> >>>> What do you think? >>>> >>>> Alex >>>> >>>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>> Hi Alexandru, >>>>>> >>>>>> IEEE talk only hexa in their Ethertype files. >>>>> >>>>> I tend to agree that #8947 is a hexadecimal notation also because=20 >>>>> the sharp sign preceding it, and because if it were decimal it=20 >>>>> would convert to 22F3 which is already reserved for trill. >>>>> >>>>> I just watend to make sure. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 >>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG=20 >>>>>>> go forward? - EtherType for ITS >>>>>>> >>>>>>> Hello Dan, >>>>>>> >>>>>>> Thank you for the email. >>>>>>> >>>>>>> I think we definitely need a good interface with IEEE about=20 >>>>>>> this. >>>>>>> >>>>>>> Maybe you could ask them whether this number is hexa or decimal,=20 >>>>>>> so we know what to put in implementation (e.g. >>>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>>> implementations). >>>>>>> >>>>>>> Also, I am interested to learn whether this deserves being=20 >>>>>>> reserved at IANA. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>>> Hi, >>>>>>>> >>>>>>>> The documents that you are referring (on the ETSI >>>>>>>> server) are not freely accessible. A password is required, and=20 >>>>>>>> probably only ETSI members have the access information. >>>>>>>> >>>>>>>> The responsibility for assigning EtherType values is with the=20 >>>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>>> (updated daily) at=20 >>>>>>>> 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=20 >>>>>>>> disclaimer that says >>>>>>>> >>>>>>>> * This is a partial listing of all assigned EtherType Fields.=20 >>>>>>>> Not >>>>>>> all >>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>> >>>>>>>> Did ETSI require for this information not to be published? It=20 >>>>>>>> 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:*its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst=20 >>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>> *To:* its@ietf.org *Subject:* Re: [its] What do we need to make=20 >>>>>>>> ITS WG go forward? - EtherType for ITS >>>>>>>> >>>>>>>> >>>>>>>> Alex, >>>>>>>> >>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS use=20 >>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document=20 >>>>>>>> available on the ETSI server: >>>>>>>> >>>>>>>> ITS(13)000020 >>>>>>>> >>>>>>> 2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 900002 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > 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 >>>>>>>> 0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 20_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 =E9crit : >>>>>>>> >>>>>>>> I really dislike the fact that ISO is charging for the ISO=20 >>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>> >>>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>>> cybersecurity and safety liability if the specification leads=20 >>>>>>>> to deaths and damage to property? >>>>>>>> >>>>>>>> >>>>>>>> Does it make any better interoperable as well? >>>>>>>> >>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20 >>>>>>>> not specified by IEEE nor reserved at IANA - does not make it=20 >>>>>>>> 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=20 >>>>>>>> is reserved at IEEE and at IANA >>>>>>>> >>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe >>>>>>>> r >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> s.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=20 >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> At this stage, I don't think a new working group is needed.=20 >>>>>>>> First, it would need a charter, and support from the industry.=20 >>>>>>>> But more importantly, IETF WGs are not usually sector-driven,=20 >>>>>>>> so it means the different issues pertaining to ITS should be=20 >>>>>>>> brought to >>>>>>> VARIOUS >>>>>>>> existing WGs, and a WG should only be created if there is an=20 >>>>>>>> important issue for which there is no existing WG that could=20 >>>>>>>> work on it. >>>>>>>> >>>>>>>> This said, as mentioned earlier, ITS is not only about =20 >>>>>>>> vehicular communications, though the issues listed by =20 >>>>>>>> Alexandru below mostly consider vehicular communications. >>>>>>>> >>>>>>>> What ITS really needs is the definition of a common=20 >>>>>>>> communication architecture and the definition of what features=20 >>>>>>>> should be comprised for an IPv6 networking stack deployed for=20 >>>>>>>> ITS use cases. This cannot be done at IETF, and actually=20 >>>>>>>> already exists at ISO: - ISO >>>>>>>> 21217 - Architecture - ISO 21210 - IPv6 Networking >>>>>>>> >>>>>>>> As an input to the discussion, please consider reading =20 >>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web=20 >>>>>>>> page: http://www.itssv6.eu/documentation/ >>>>>>>> D2.2 provides an analysis of the currently published version of=20 >>>>>>>> ISO 21210, but new work items have been launched since then to=20 >>>>>>>> address remaining issues. >>>>>>>> >>>>>>>> Regards, Thierry. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>> >>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =E9crit : >>>>>>>> >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> This is just one opinion, but I'd like to understand why ITS=20 >>>>>>>> would need its own IETF group. The work here is the same (IMO)=20 >>>>>>>> as what is taking place in MANET. I would vote that this work=20 >>>>>>>> be taken up in MANET. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stan, >>>>>>>> >>>>>>>> Thank you for the offer. I considered this offer since some=20 >>>>>>>> time. >>>>>>>> >>>>>>>> I try to understand whether some of these items on which I have=20 >>>>>>>> interest could be brought in in MANET WG: >>>>>>>> - V2V using prefix exchange - VIN-based IP addressing scheme=20 >>>>>>>> - ND Prefix Delegation - PMIP-based network mobility - IPv6=20 >>>>>>>> single-address connecion 'sharing' with a cellular operator and=20 >>>>>>>> a vehicular moving network (type '64share' of v6ops). - Default=20 >>>>>>>> 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=20 >>>>>>>> will need to propose the WG and provide the WG charter, as use=20 >>>>>>>> cases and work to be done in this group. This charter needs to=20 >>>>>>>> be approved by the IESG. I have not attended the last meeting=20 >>>>>>>> so not sure about the status now, >>>>>>>> >>>>>>>> AB >>>>>>>> >>>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>>> previously heard to make it a working group. So what should we=20 >>>>>>>> exactly do, to achieve this goal ? >>>>>>>> >>>>>>>> >>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I was interested in this group but not sure where are we so=20 >>>>>>>> far. Is there progress, or is there issues/efforts that need to=20 >>>>>>>> be completed and volunteered. >>>>>>>> >>>>>>>> AB _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * *= =E4=C8=ED=E1=20 >>>>>>>> =C8=E4=DA=E3=D1=E6Nabil Benamar* Professor of computer sciences Si= mulation=20 >>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20 >>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6=20 >>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > ---------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> its >>>>>>>> mailing list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing >>>>>>> list >>>>>>>> its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org =20 >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its mailing=20 >>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org 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 > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From HJFischer@fischer-tech.eu Fri Feb 15 03:00:11 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4589321F8546 for ; Fri, 15 Feb 2013 03:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LriQlynXOQlX for ; Fri, 15 Feb 2013 03:00:10 -0800 (PST) Received: from webbox333.server-home.org (webbox333.server-home.org [83.220.144.54]) by ietfa.amsl.com (Postfix) with ESMTP id 35EDF21F8532 for ; Fri, 15 Feb 2013 03:00:10 -0800 (PST) Received: from [192.168.222.117] (p54A976E8.dip.t-dialin.net [84.169.118.232]) by webbox333.server-home.org (Postfix) with ESMTPSA id 33C1F5FA72 for ; Fri, 15 Feb 2013 12:00:08 +0100 (CET) Message-ID: <511E15A0.9060108@fischer-tech.eu> Date: Fri, 15 Feb 2013 12:01:52 +0100 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 11:00:11 -0000 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 --- There is one world and one ITS --- Am 15.02.2013 11:05, schrieb Roberto Baldessari: > 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 > > > >> Best regards, >> >> Roberto >> >> >> >> >> -- ------------------------------------------------------------------------------ http://its-standards.info/ESF-News-2012-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@gmail.com Fri Feb 15 06:35:14 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C527F21F85D4 for ; Fri, 15 Feb 2013 06:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.412 X-Spam-Level: X-Spam-Status: No, score=-11.412 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOgpaD-C9uzf for ; Fri, 15 Feb 2013 06:35:12 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 102BE21F85DA for ; Fri, 15 Feb 2013 06:35:11 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FEZ6OT031317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 15:35:06 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FEZ6C2010150; Fri, 15 Feb 2013 15:35:06 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FEYt3d009802; Fri, 15 Feb 2013 15:35:06 +0100 Message-ID: <511E478F.8020003@gmail.com> Date: Fri, 15 Feb 2013 15:34:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roberto Baldessari References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "Dowdell, John" , "its@ietf.org" Subject: Re: [its] IPv6 and geonetworking (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 14:35:14 -0000 Le 15/02/2013 11:05, Roberto Baldessari a écrit : > 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. 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 > > Best regards, > > Roberto > > > >> >> Best regards, >> >> Roberto >> >> >> >> >> >> >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org >> Subject: Re: [its] IP over 802.11p >> >> 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 >> >>> >>> John >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM >>>>>>>> To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>> *To:* its@ietf.org *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 >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > 900002 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > 20_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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> r >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > s.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 >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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 its@ietf.org >>>>>>>>> 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 its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>> list >>>>>>>>> its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org 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 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Fri Feb 15 07:00:24 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A44D21F8546 for ; Fri, 15 Feb 2013 07:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.43 X-Spam-Level: X-Spam-Status: No, score=-11.43 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+ZzIJJZkuxM for ; Fri, 15 Feb 2013 07:00:23 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id D57C221F852C for ; Fri, 15 Feb 2013 07:00:22 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FF0L5I009905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Feb 2013 16:00:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FF0L7i022134 for ; Fri, 15 Feb 2013 16:00:21 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FF0CIE015826 for ; Fri, 15 Feb 2013 16:00:21 +0100 Message-ID: <511E4D7C.1020304@gmail.com> Date: Fri, 15 Feb 2013 16:00:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E15A0.9060108@fischer-tech.eu> In-Reply-To: <511E15A0.9060108@fischer-tech.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] how to check ISO documents (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 15:00:24 -0000 Le 15/02/2013 12:01, Dr. Hans-Joachim Fischer a écrit : > > Good proposal to work together in the various SDOs. 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 > > > Hans-Joachim > > > --- There is one world and one ITS --- > > > > Am 15.02.2013 11:05, schrieb Roberto Baldessari: >> 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 >> >> >> >>> Best regards, >>> >>> Roberto >>> >>> >>> >>> >>> > From alexandru.petrescu@gmail.com Fri Feb 15 08:05:00 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3F21F8314 for ; Fri, 15 Feb 2013 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLe2i38xxRwF for ; Fri, 15 Feb 2013 08:04:59 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF521F8497 for ; Fri, 15 Feb 2013 08:04:55 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FG4t1D009740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Feb 2013 17:04:55 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FG4sgN019763 for ; Fri, 15 Feb 2013 17:04:54 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FG4lQ7022772 for ; Fri, 15 Feb 2013 17:04:54 +0100 Message-ID: <511E5C9F.2060501@gmail.com> Date: Fri, 15 Feb 2013 17:04:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] IETF documents - access conditions, status, advancement X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:05:00 -0000 Hello all, First and foremost, the items below are authoritatively discussed on the IETF email list at ietf@ietf.org. But following private discussions about ITS, I would like to point out a few points about IETF, which IMHO are widely known: - when some IETF person talks mentions a draft, like "draft-byrne-v6ops- 64share-03" he actually means that draft is available publicly and freely, e.g. go to: http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 I go download it, check a message format or two and then I object publicly about a missing bit at position 3. The draft name per se (draft-byrne-v6ops-64share-03) has a meaning with respect to its status, group, authority if you wish and obviously version. They are mentioned below. - most if not all IETF documents are publicly and freely available documents. The most important ones (Request for Comments, Internet Drafts) are freely and publicly available - since 1970 until long in the future, hopefully. Check for example RFC 1 "Host Software", 7 april 1969, at: http://www.rfc-editor.org/rfc/rfc1.txt - an IETF "standard" has a long way before it becomes such. First, a personal Internet Draft (I-D) is submitted - an individual submission. The submission is free of charge. Its title contains first Author's last name as second token in the file name, e.g. draft-petrescu-blah-blah. This document has not much influence other than maybe raising one or two comments. Once submitted, a draft is immediately freely available at ietf.org. I submit now, and 2 minutes later my draft is public. All for free. In theory an individual draft is deleted after 6 months since last update. In practice many public archives seem to store these forever. Please submit drafts. Second, if people agree, they form a Working Group. In this, the Charter should define a Work Item. That Work Item should lead to the editing of a WG item draft. This draft has 'ietf' as the second token in the filename, instead of Author's first name, e.g. draft-ietf-v6ops-64share-02 (an evolution of the individual personal draft-byrne-v6ops-64share-03). This WG item has more weight than the individual submission - more people agree about it; there's commitment to pursue it, it would rarely die. YEt it's not yet a 'standard'. Third, if people agree, they submit it to IESG - a set of experts. They deliberate and may kill it, or make it better. Then it is a Proposed Standard. As you see, it's not yet a Standard. Then it becomes a Draft Standard. As you see, it's still not a Standard. All this process may take anywhere from a few months to several years, with the second option being more common. Some very slowly if ever go beyond Proposed Standard status (the case of NEMOv6). In addition, there exist alternative Tracks. The above is the Standards Track, but there are also BCP (Best Common Practices), Informational and Experimental RFCs, sponsored or not. Each has its peculiarity, but rarely called a Standard. - the conditions to advance a document are 'rough consensus' - i.e. there is some consensus about, it's not just one person, and 'running code' - i.e. there is some implementation about it. - one could write a draft and push it hard - if there's no consensus and no code it dies out. - one could implement, deploy widely, make money of it - if there's no consensus it's not an RFC. Yours, Alex From thierry.ernst@inria.fr Fri Feb 15 08:05:01 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551921F8314 for ; Fri, 15 Feb 2013 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.249 X-Spam-Level: X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGtpwKnNq6On for ; Fri, 15 Feb 2013 08:04:59 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id E54C421F842C for ; Fri, 15 Feb 2013 08:04:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,674,1355094000"; d="vcf'?scan'208";a="3073079" Received: from vir78-2-82-247-222-224.fbx.proxad.net (HELO Mont-Ventoux-2.local) ([82.247.222.224]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Feb 2013 17:04:47 +0100 Message-ID: <511E5C9B.70609@inria.fr> Date: Fri, 15 Feb 2013 17:04:43 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E15A0.9060108@fischer-tech.eu> <511E4D7C.1020304@gmail.com> In-Reply-To: <511E4D7C.1020304@gmail.com> Content-Type: multipart/mixed; boundary="------------050908020904080700040902" Subject: Re: [its] how to check ISO documents X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:05:01 -0000 This is a multi-part message in MIME format. --------------050908020904080700040902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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. On 15/02/13 16:00, Alexandru Petrescu wrote: > Le 15/02/2013 12:01, Dr. Hans-Joachim Fischer a écrit : >> >> Good proposal to work together in the various SDOs. > > 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 > >> >> >> Hans-Joachim >> >> >> --- There is one world and one ITS --- >> >> >> >> Am 15.02.2013 11:05, schrieb Roberto Baldessari: >>> 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 >>> >>> >>> >>>> Best regards, >>>> >>>> Roberto >>>> >>>> >>>> >>>> >>>> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------050908020904080700040902 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------050908020904080700040902-- From alexandru.petrescu@gmail.com Fri Feb 15 08:29:53 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3101A21F8574 for ; Fri, 15 Feb 2013 08:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.443 X-Spam-Level: X-Spam-Status: No, score=-11.443 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPVdfYSOJey2 for ; Fri, 15 Feb 2013 08:29:51 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 535E221F88E2 for ; Fri, 15 Feb 2013 08:29:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FGTkLm001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Feb 2013 17:29:46 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FGTkxV027664 for ; Fri, 15 Feb 2013 17:29:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FGTdpR002051 for ; Fri, 15 Feb 2013 17:29:46 +0100 Message-ID: <511E6273.4020506@gmail.com> Date: Fri, 15 Feb 2013 17:29:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E15A0.9060108@fischer-tech.eu> <511E4D7C.1020304@gmail.com> <511E5C9B.70609@inria! .fr> In-Reply-To: <511E5C9B.70609@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] how to check ISO documents X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:29:53 -0000 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 > > Regards, Thierry. > > > > On 15/02/13 16:00, Alexandru Petrescu wrote: >> Le 15/02/2013 12:01, Dr. Hans-Joachim Fischer a écrit : >>> >>> Good proposal to work together in the various SDOs. >> >> 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 >> >>> >>> >>> Hans-Joachim >>> >>> >>> --- There is one world and one ITS --- >>> >>> >>> >>> Am 15.02.2013 11:05, schrieb Roberto Baldessari: >>>> 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 >>>> >>>> >>>> >>>>> Best regards, >>>>> >>>>> Roberto >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Fri Feb 15 10:27:13 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C146321F8717 for ; Fri, 15 Feb 2013 10:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.459 X-Spam-Level: X-Spam-Status: No, score=-11.459 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GvlG-5QZ7hv for ; Fri, 15 Feb 2013 10:27:11 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78221F8563 for ; Fri, 15 Feb 2013 10:27:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FIR8LN005674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 19:27:09 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FIR80P019573; Fri, 15 Feb 2013 19:27:08 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FIR4JE009085; Fri, 15 Feb 2013 19:27:08 +0100 Message-ID: <511E7DF8.9040800@gmail.com> Date: Fri, 15 Feb 2013 19:27:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dr. Hans-Joachim Fischer" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> <511BF0AB.7090808@fischer-tech.eu> In-Reply-To: <511BF0AB.7090808@fischer-tech.eu> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] FNTP (was: IP over 802.11p - frequencies local) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:27:13 -0000 Le 13/02/2013 20:59, Dr. Hans-Joachim Fischer 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. > > 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. 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 > 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 > > Am 13.02.2013 15:07, schrieb Alexandru Petrescu: >> Le 13/02/2013 11:31, Romain KUNTZ a écrit : >>> Hello Alexandru, >>> >>> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >>> wrote: >>>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>>> Hello Alexandru, >>>>> >>>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>>> wrote: >>>>>> 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). >>>>> >>>>> 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'. >>> >>> 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 >> >>> >>> Romain >>> >>> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>>> 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 >>>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org >>>>>>> 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: >>>>>>>>>>>> its-bounces@ietf.org >>>>>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of >>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January >>>>>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> 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 >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing >>>>>>>>>>>> list >>>>>>>>>>>>> its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> 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 its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Fri Feb 15 11:49:45 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3221F86A5 for ; Fri, 15 Feb 2013 11:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.174 X-Spam-Level: X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZjE4iMv3Paa for ; Fri, 15 Feb 2013 11:49:44 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2885821F8692 for ; Fri, 15 Feb 2013 11:49:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1FJngER016986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Feb 2013 20:49:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1FJngWm031049 for ; Fri, 15 Feb 2013 20:49:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1FJnVEn005516 for ; Fri, 15 Feb 2013 20:49:39 +0100 Message-ID: <511E914B.6010702@gmail.com> Date: Fri, 15 Feb 2013 20:49:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:49:45 -0000 Hello, Following discussions I am drafting a Charter proposal for Intelligent Transportation Systems at IETF. Can we commit on some work items? Can we discuss with MANET WG about work items in MANET? Can we add other work items? Or eliminate some? Can we decide milestones? Please comment, Alex ---------------------------------------------------------------------- Intelligent Transportation Systems at IETF Draft Charter Proposal February 15th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: informal bar BoF Chairs: TBD TBD Assigned Area Director: TBD (Jari Arkko and Ralph Droms helped at a stage) Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) are composed of mobile and fixed computing and communicating equipment. The fixed access points are deployed along terrestrial roads (e.g. Road-Side Units), shores along water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless access to equipment deployed in mobile vehicles (e.g. On-Board Units). The entire system is connected to the Internet through one or several IP paths. In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two different radios). Due to the mobile nature of the system, several problems exist with respect to IP addressing and route establishment such that Internet communications can be realized (a typical IP network is using mostly IP addresses topologically valid at a single point, and relatively stable routing system). In addition, several new problems specific to vehicular communications at application layer are exposed when the communication protocol is IP. Several Standards Development Organizations outside IETF work towards developping protocols for vehicular communications. In some cases IP protocols are used for transport, in other cases IP protocols are modified for the purpose. The examples of SDOs and respective groups and documents are: ETSI ITS, ISO TC, IEEE 802.11p, AUTOSAR, IPSO. A number of IETF protocols are being considered in the context of Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, ND, ULA, DHCPv6. Others are not excluded. At IETF several Working Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce work which is highly pertinent to the ITS context. Ongoing work ------------ Overall, in this group, the ongoing work items are to identify the following: (1) vehicular-specific problems to be solved with IETF protocols, (2) interactions with SDOs, (3) existing IETF protocols which may solve the problems. (4) EtherTypes for transporting IP over a MAC specific to vehicular communications. (5) country-level frequencies for long-range vehicular communications with an IP-friendly MAC layer. Potential work items -------------------- The following potential work items exist: Scenarios and requirements for vehicular communications will be developped which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. One generic use case should be identified as supporting basis for further developments. This could be under the form of an instrumented ambulance. The ambulance is connected to the Internet and offers wireless and wired access to a large number of individual equipments deployed in-vehicle. There is a need to identify which existing protocols may be reused to realize the connection between the ambulance and the hospital. IP-over-foo, where foo is one particular link-layer which is identified as very pertinent for vehicular communications. One particular example is IEEE 802.11p, but is not the only one; clarifications whether IP-over-80211p is actually possible, due to lack of country-level regulation. IP is not 'safety' but rather 'entertainment'. Other link-layers which are pertinent are 802.11abgn, and 802.11ai, and 802.11ak. The preferred ones will be those allowing long-range communications between vehicles, at high-power levels. Addressing mechanisms for vehicular communications: methods of converting a Vehicular Identification Number, or geographical coordinates, into an IPv6 address, and vice-versa. Scoping of IPv6 addresses: addresses within a vehicle, between vehicles, to infrastructure. Distributing addresses between vehicles, using dynamic mechanisms, such as DHCP or ND, which respect constraints of applications. Route exchanges between vehicles, and between vehicles and road-side units. This includes the identification of a need to realize the exchanges, the constraints related to loop-free graphs and networks which scale to large sizes, their interaction with the imposed physical topology. Fast Network Transport Protocol is a protocol designed at ISO for vehicular communications. Feedback is solicited from IETF about this protocol. GeoNetworking is a protocol designed at ETSI. Feedback is solicited from IETF about this protocol. Milestones: Mar 2013 - Meet in Orlando Jul 2013 - Meet in Berlin From alison@she-devel.com Fri Feb 15 16:06:19 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37821F84D9 for ; Fri, 15 Feb 2013 16:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sp1WAxTUjVw for ; Fri, 15 Feb 2013 16:06:18 -0800 (PST) Received: from mail-ia0-x22d.google.com (ia-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E121F84C2 for ; Fri, 15 Feb 2013 16:06:17 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id h37so3825505iak.18 for ; Fri, 15 Feb 2013 16:06:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=OJIWNo4Qq8UM6/LS/jnkoHvCHVgPWtnGKjUQw+mTiNg=; b=H+CXUz9GPSxuxpwHI1zD+qvFSoit+CU94n+/cqOUvY3HP7YTGQflN9MBFxqjOL6yKA n0uAIV+MXXYeOOrYYosI4ME1gjFPhbRb/vzAjAz3GYJK8O52Fgr5WThTU7DOgOL3I+mI OcbAYieA3ujp5+9N5A6v+Lp0Qa1epGoutBVpGUxYtRnSvdAsXSRYYAif3O2W2SBefJji B1vP3572EMvJZl7A7xMTiVN7MGpHAzp+kyMM4Mt4Ak31aA1k0ummCEmhvCmAIwdfjrUf 5nLKNUTZDUxZUSmIc7OIA/C7TyLGsc8a0JWIzaHTpwZd8RTeMyw6j3sBbuaz/rvucrrL bJ1g== MIME-Version: 1.0 X-Received: by 10.50.40.131 with SMTP id x3mr3970330igk.10.1360973177273; Fri, 15 Feb 2013 16:06:17 -0800 (PST) Received: by 10.42.196.200 with HTTP; Fri, 15 Feb 2013 16:06:17 -0800 (PST) Date: Fri, 15 Feb 2013 16:06:17 -0800 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlMCZkoOlW4WhqRkTsPIgHL7mJhH/l5UEE8wW5vzlw5MUgE55SQru4m4TkBfNiKCtfXktO0 Subject: [its] "Addressing the hard problems of automotive Linux: networking and IPC" talk slides X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 00:06:19 -0000 Colleagues, I'm giving a presentation next week at Embedded Linux Conference: http://events.linuxfoundation.org/events/embedded-linux-conference/schedule which is partly about networking, and which draws from many ideas and resources I've learned about by reading this valuable mailing list. I'd appreciate any suggestions you might have based on my slides: http://she-devel.com/Chaiken_ELC_2013.pdf I've already submitted them to the Conference organizers, but can still change my oral presentation, which is Thursday 2/21. The content about networking is more in the second half of the presentation. If any of you ever pass through the San Francisco Bay area, I invite you once again to give a talk to the Silicon Valley Automotive Open Source Group I organize, which often draws 50 or 60 attendees to its monthly meetings. Best wishes, Alison Chaiken -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} Access is more important than ownership. -- Joe Gebbia, AirBnB From abdussalambaryun@gmail.com Fri Feb 15 17:51:38 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B5C21F847C for ; Fri, 15 Feb 2013 17:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIGGZB+ks2MJ for ; Fri, 15 Feb 2013 17:51:38 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id B064B21F8481 for ; Fri, 15 Feb 2013 17:51:37 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so1808389wib.0 for ; Fri, 15 Feb 2013 17:51:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Tl40OXzrN/ZUQjWyo3B1rMbCOKslYX2IMw4Fl0CACKQ=; b=XRWYurAUcK79MnLNUqhvjp/MNgmlxSSs49d3CgvFup07moCSVKxwiX5oA3xk/7Bm20 5TgetJEiTYK7f89XoQenS43WLXFhfxbDccJy4xYSWAEp1KfRADoMgFGj5Pz/reiSulNS MSBXzlDZ8KU5TFQBNYpWbOpimODN1phDv267xiSkADaexB1Ib1PR9FpRvYxQGBQszDsM oONeQ1OHDWR3QxoT6Fpct7dI78exQqJfOxit2vezUvsfAKnR6r1OHDbIz7SmlsZ5RdsI OY3Bf3eUnsKFpZ7XWAA25BF/9AGILaNSBdU3ZQT38VzwygFKcfNPo9mE94vd0TK1Ckzm gKSQ== MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr9198488wib.30.1360979496893; Fri, 15 Feb 2013 17:51:36 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 17:51:36 -0800 (PST) In-Reply-To: <511E914B.6010702@gmail.com> References: <511E914B.6010702@gmail.com> Date: Sat, 16 Feb 2013 02:51:36 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 01:51:39 -0000 On 2/15/13, Alexandru Petrescu wrote: > Hello, > > Following discussions I am drafting a Charter proposal for Intelligent > Transportation Systems at IETF. > > Can we commit on some work items? yes I think we can > Can we discuss with MANET WG about work items in MANET? we already got offer from co-chair (recharter-manet), but I don't prefer to mix the MANET work in ITS work because believe they are different scopes, MANET is general purpose but ITS is specific scope, we need both in ietf, > Can we add other work items? Or eliminate some? it is better to start with simple solid requirements to establish > Can we decide milestones? maybe two drafts; ITS framework, and ITS applicability. > > Please comment, Regarding the charter, it is a great start to have discussion on the new charter, which I think that IETF should think about the requirement of this WG. IMO, the ITS applicability still not clear from charter, I will try to add my thoughts, AB From abdussalambaryun@gmail.com Fri Feb 15 18:06:56 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D721F85E8 for ; Fri, 15 Feb 2013 18:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixb1MWUXL0IX for ; Fri, 15 Feb 2013 18:06:56 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BAC4F21F85E7 for ; Fri, 15 Feb 2013 18:06:55 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so3360442wey.5 for ; Fri, 15 Feb 2013 18:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SK76edXM26g/SDhHpqKZmfjgIkJYt47qIiEL4dcMhiQ=; b=Be9G8rhMepeqlfp024tMSBBCHxrmo6siFrtqvvKKjB5zaN6tB42xlIfoIuvGuaOmwc gqeENn72UmdS+jgVoYG4doDqan/UR3R43NZKIbTzUwPCfrTfnJ6ZXfOUMhT1IaPCtWpq 442OV3CKQ1GPzWrBQSpXDcUNoQweHU8vMdMMJi8bIYbAse8/syh+KjZciSloa3ZQxHFe UeD+olILx2yTWvdoY1K8ELrJzHsEh8/wLb3i6oK0TIBiPd9EuwucpmFipuytsir51VN3 dP0yM+dsVpnL/Fn34TclUDugQLkwFGrSfAoXlqXBQSsdfMwelJPLuVx1Gq9k5y9WJ9iy rrlw== MIME-Version: 1.0 X-Received: by 10.180.93.168 with SMTP id cv8mr7592174wib.5.1360980414779; Fri, 15 Feb 2013 18:06:54 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 18:06:54 -0800 (PST) In-Reply-To: <511E914B.6010702@gmail.com> References: <511E914B.6010702@gmail.com> Date: Sat, 16 Feb 2013 03:06:54 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 02:06:56 -0000 Hi Alex, > A number of IETF protocols are being considered in the context of > Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, > ND, ULA, DHCPv6. Others are not excluded. At IETF several Working > Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce work which > is highly pertinent to the ITS context. What about ROLL, I think it is more related to ITS, I think we should consider that our intelligent systems/devices need use some of ROLL techniques in V2V and V2I ITS = ROLL + MANET IMHO, that the chater proposed, mentions the ITS applicability that should include MANET applicability and ROLL applicability. AB From abdussalambaryun@gmail.com Fri Feb 15 18:42:00 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A321F8461; Fri, 15 Feb 2013 18:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TahHawXAINwO; Fri, 15 Feb 2013 18:41:50 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1F21F81FF; Fri, 15 Feb 2013 18:41:28 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so2034160wie.0 for ; Fri, 15 Feb 2013 18:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=7TwCseVVEvyEY9AFTq/vUsCm8XV5mrRoXwNBseiS+mo=; b=Hujak3I/uHbiAwyOHZPh726CLtYMbJTv4PitQh3zhXkfDvNXvTr/BAJ+Iu2Uu9cOHQ OaFSXGkqYchD25675JKvJT5DWg/9UnNymaXGWpWW+koEXnmdfRfUSPnmr9r6ApZruRww rYO5uRqnbHWlwP1TRTSpN6sVDCjdc32mFReNutyziRH118HFgQBWLXgVVab8nyHC0cTZ +O3U1o+UMn9Pycz8/w66ftR9ZPbI1kV1vxHYS+Fr+IyWsApz5UwwRBKMYQyvrqUEAI7v Yq+3qSjXWJRZsPwph+YB/ZzgaWvW6VyhUTbenzmGMUZmpFMasYeRu95/6d2LHiqadxHP BhPg== MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr9296723wib.30.1360981813712; Fri, 15 Feb 2013 18:30:13 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 18:30:13 -0800 (PST) Date: Sat, 16 Feb 2013 03:30:13 +0100 Message-ID: From: Abdussalam Baryun To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , roll Subject: [its] Using ROLL technique in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 02:42:01 -0000 I think it is reasonable to include applications of the ROLL efforts into ITS, not only to consider Mobile-IP. On 2/15/13, Alexandru Petrescu wrote: > Intelligent Transportation Systems (ITS) are composed of mobile and > fixed computing and communicating equipment. The fixed access points > are deployed along terrestrial roads (e.g. Road-Side Units), shores > along water paths; alternatively, mobile or fixed access points may be > deployed above ground; they all offer wireless access to equipment > deployed in mobile vehicles (e.g. On-Board Units). The entire system > is connected to the Internet through one or several IP paths. In this > system, disjoint and heterogeneous radio systems are used (e.g. a > vehicle uses two different radios). I will try to amend; Intelligent Transportation Systems (ITS) are composed of interconnected systems of machines; vehicles, mobile devices and fixed embedded devices (actuator and sensors). These machines communicate with fixed access points which are are deployed along terrestrial roads (e.g. Road-Side Units), shores along water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless access to equipment deployed in mobile vehicles (e.g. On-Board Units). The entire system is connected to the Internet through one or several IP paths. In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two different radios). AB From pthubert@cisco.com Sat Feb 16 00:39:26 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6C121F854A for ; Sat, 16 Feb 2013 00:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr-JRWxivq3s for ; Sat, 16 Feb 2013 00:39:25 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 343B121F853A for ; Sat, 16 Feb 2013 00:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1650; q=dns/txt; s=iport; t=1361003965; x=1362213565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r44XQ4RIi7KAan+Ocf8F0+7oeU/7APpF2h2yb4ray7o=; b=CgX7M0ulD3hO2wWz3uQumHly2i3u47spruOfY/OdMNoY7ALEjf7Fm7X5 lvr7z6vhNKjqZ2HLJMZVrUemsvdnAeCjMCzblsut3DOcHMeTZ90As8RbT JNhvkVRYoDe2OsTFR8RzI6cgDmyMZphbZHJCaVkWcIZN2vPPJaK+tRKFs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAA5FH1GtJXHA/2dsb2JhbABEwBx8FnOCHwEBAQMBAQEBawsFBwQCAQgRBAEBCx0HJwsUCQgCBAENBQiIBAYMvHgEjwAmCwcGgllhA4gxnlODB4In X-IronPort-AV: E=Sophos;i="4.84,678,1355097600"; d="scan'208";a="177824996" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 16 Feb 2013 08:39:24 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1G8dOO1021251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Feb 2013 08:39:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 02:39:24 -0600 From: "Pascal Thubert (pthubert)" To: Abdussalam Baryun , Alexandru Petrescu , Ryuji Wakikawa Thread-Topic: [its] Draft Charter proposal Thread-Index: AQHOC7Wf0KvHa2AQckye0Zlo0wYHDJh8Ib4AgAAHJoA= Date: Sat, 16 Feb 2013 08:39:23 +0000 Deferred-Delivery: Sat, 16 Feb 2013 08:39:00 +0000 Message-ID: References: <511E914B.6010702@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.80.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jari.arkko@piuha.net" , "its@ietf.org" Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 08:39:26 -0000 I'd be surprised if Alex disagrees - or Ryuji for that matter. We were a bit too mush ahead of phase but the combination of local and glob= al mobility is what we wanted to achieve with MANEMO some years ago. RPL has the exact properties that we were looking for at the time. The glob= al mobility can be achieved a number of ways, but is seems that making the = road side unit the locator is the simple thing. In that case, we have a num= ber of possibilities of the shelf, including LISP, PMIP, or MIP/NEMO-proxy = such as discussed in global HAHA for DMM. Cheers, Pascal -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Abdus= salam Baryun Sent: samedi 16 f=E9vrier 2013 03:07 To: Alexandru Petrescu Cc: its@ietf.org Subject: Re: [its] Draft Charter proposal Hi Alex, > A number of IETF protocols are being considered in the context of=20 > Intelligent Transportation Systems - most notably IPv6, Mobile IPv6,=20 > ND, ULA, DHCPv6. Others are not excluded. At IETF several Working=20 > Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce work which=20 > is highly pertinent to the ITS context. What about ROLL, I think it is more related to ITS, I think we should consi= der that our intelligent systems/devices need use some of ROLL techniques i= n V2V and V2I ITS =3D ROLL + MANET IMHO, that the chater proposed, mentions the ITS applicability that should = include MANET applicability and ROLL applicability. AB _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Sat Feb 16 04:20:16 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6546621F8700 for ; Sat, 16 Feb 2013 04:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.464 X-Spam-Level: X-Spam-Status: No, score=-11.464 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xe8DqtXzWlM for ; Sat, 16 Feb 2013 04:20:13 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF921F84F4 for ; Sat, 16 Feb 2013 04:20:10 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GCK3lL017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Feb 2013 13:20:04 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GCK30V000489; Sat, 16 Feb 2013 13:20:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GCJrvc026936; Sat, 16 Feb 2013 13:20:03 +0100 Message-ID: <511F7968.7090309@gmail.com> Date: Sat, 16 Feb 2013 13:19:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Dowdell, John" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] suppliers of 802.11p-over-ITS-G5; 802.11s-over-5875-5905MHz (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:20:17 -0000 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: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 31 January 2013 15:17 To: its@ietf.org 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: its-bounces@ietf.org >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>> its@ietf.org 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:*its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM *To:* >>>>>>> its@ietf.org *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 >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> 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 >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 its@ietf.org >>>>>>> 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 its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>> mailing >>>>>>> list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing >>>>>> list >>>>>>> its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > _______________________________________________ its mailing list > its@ietf.org 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@gmail.com Sat Feb 16 04:32:09 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6ED21F86AE for ; Sat, 16 Feb 2013 04:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.479 X-Spam-Level: X-Spam-Status: No, score=-11.479 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGz2MzlOvXz1 for ; Sat, 16 Feb 2013 04:32:07 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id BB62E21F86AF for ; Sat, 16 Feb 2013 04:32:06 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GCW5tG011324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Feb 2013 13:32:05 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GCW42F001541 for ; Sat, 16 Feb 2013 13:32:05 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GCW0wW015637 for ; Sat, 16 Feb 2013 13:32:04 +0100 Message-ID: <511F7C40.2030901@gmail.com> Date: Sat, 16 Feb 2013 13:32:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> <511BF0AB.7090808@fischer-tech.eu> <511E7DF8.9040800@gmail.com> In-Reply-To: <511E7DF8.9040800@gmail.com> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] FNTP X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:32:09 -0000 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 : > Le 13/02/2013 20:59, Dr. Hans-Joachim Fischer 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. >> >> 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. > > 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 > > >> 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 >> >> Am 13.02.2013 15:07, schrieb Alexandru Petrescu: >>> Le 13/02/2013 11:31, Romain KUNTZ a écrit : >>>> Hello Alexandru, >>>> >>>> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >>>> wrote: >>>>> Le 11/02/2013 23:03, Romain KUNTZ a écrit : >>>>>> Hello Alexandru, >>>>>> >>>>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>>>> wrote: >>>>>>> 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). >>>>>> >>>>>> 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'. >>>> >>>> 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 >>> >>>> >>>> Romain >>>> >>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 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 >>>>>>>> >>>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>> Petrescu Sent: 31 January 2013 15:17 To: its@ietf.org >>>>>>>> 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: >>>>>>>>>>>>> its-bounces@ietf.org >>>>>>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of >>>>>>>>>>>>> Alexandru Petrescu Sent: Wednesday, January >>>>>>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf >>>>>>>>>>>>>> Of *Thierry Ernst *Sent:* Wednesday, >>>>>>>>>>>>>> January 30, 2013 11:11 AM *To:* >>>>>>>>>>>>>> its@ietf.org *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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> 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 >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 its@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its >>>>>>>>>>>>> mailing >>>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its >>>>>>>>>>>>> mailing >>>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its mailing >>>>>>>>>>>>> list >>>>>>>>>>>>>> its@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> 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 its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Sat Feb 16 05:04:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20AD21F8853 for ; Sat, 16 Feb 2013 05:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whZEtAI+R-fh for ; Sat, 16 Feb 2013 05:04:57 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BA02E21F87CB for ; Sat, 16 Feb 2013 05:04:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GD4tdK024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Feb 2013 14:04:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GD4toM005170 for ; Sat, 16 Feb 2013 14:04:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GD4pia001870 for ; Sat, 16 Feb 2013 14:04:55 +0100 Message-ID: <511F83F3.3080306@gmail.com> Date: Sat, 16 Feb 2013 14:04:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] "Addressing the hard problems of automotive Linux: networking and IPC" talk slides X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:04:57 -0000 Alison, Thank you for the email. Good luck with the presentation at the Embedded Linux Conference. It's good to be invited talk to the monthly Silicon Valley Automotive Open Source Group. About the pdf you refer to http://she-devel.com/Chaiken_ELC_2013.pdf I've been contacted privately by AUTOSAR representative, I'll meet soon. I am told AUTOSAR also discusses address auto-configuration for in-vehicle? And OBD/Ethernet? And in your slide I see AUTOSAR ECU protocol? What is ECU protocol? CAN-Ethernet demo seems to be interesting. AF_BUS - a new family of protocols, akin to AF_UNIX. Do you think the Draft Charter proposal I sent earlier in the 'its' email list covers these concepts? I wrote this 'addresses within a vehicle' keywords, but not sure whether it covers well what needs to be done. I welcome comments on this Draft Charter proposal. (and I learn from your slides that there exists IEEE 1609.3 WSMP ok, which I guess is like FNTP mentioned by Hans-Joachim at ISO). Alex Le 16/02/2013 01:06, Alison Chaiken a écrit : > Colleagues, I'm giving a presentation next week at Embedded Linux > Conference: > > http://events.linuxfoundation.org/events/embedded-linux-conference/schedule > > > which is partly about networking, and which draws from many ideas > and resources I've learned about by reading this valuable mailing > list. I'd appreciate any suggestions you might have based on my > slides: > > http://she-devel.com/Chaiken_ELC_2013.pdf > > I've already submitted them to the Conference organizers, but can > still change my oral presentation, which is Thursday 2/21. The > content about networking is more in the second half of the > presentation. > > If any of you ever pass through the San Francisco Bay area, I invite > you once again to give a talk to the Silicon Valley Automotive Open > Source Group I organize, which often draws 50 or 60 attendees to its > monthly meetings. > > Best wishes, Alison Chaiken > From alexandru.petrescu@gmail.com Sat Feb 16 05:22:24 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF37221F84E2 for ; Sat, 16 Feb 2013 05:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKB+xRuYz3Wp for ; Sat, 16 Feb 2013 05:22:24 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id EB78121F84BB for ; Sat, 16 Feb 2013 05:22:23 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GDMMav027449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Feb 2013 14:22:22 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GDMMTr007198; Sat, 16 Feb 2013 14:22:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GDMG7h005227; Sat, 16 Feb 2013 14:22:22 +0100 Message-ID: <511F8808.8000306@gmail.com> Date: Sat, 16 Feb 2013 14:22:16 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Abdussalam Baryun References: <511E914B.6010702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] RoLL and Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:22:25 -0000 Le 16/02/2013 03:06, Abdussalam Baryun a écrit : > Hi Alex, > >> A number of IETF protocols are being considered in the context of >> Intelligent Transportation Systems - most notably IPv6, Mobile >> IPv6, ND, ULA, DHCPv6. Others are not excluded. At IETF several >> Working Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce >> work which is highly pertinent to the ITS context. > > What about ROLL, I think it is more related to ITS, I think we should > consider that our intelligent systems/devices need use some of ROLL > techniques in V2V and V2I > > ITS = ROLL + MANET > > IMHO, that the chater proposed, mentions the ITS applicability that > should include MANET applicability and ROLL applicability. Abdussalam, Thank you for the comments. I am ready to add something in the Charter proposal about RoLL, also because also PAscal talks it. But let me comment further. RoLL stands for Routing over Low-Power and Lossy Links. But with V2V one would be looking more at high-power links, because the higher the power the higher the speed of vehicles (e.g. in France at 100mW WiFi a V2V entertaining videoconference allows for two convoyed vehicles speed of around 90km/h, because the 100mW corresponds to approximately 50meter distance, which is the security distance in France for speed of 90km/h, no more). This would mean it's impossible to use RoLL on a highway where the recommended speed is much above 90km/h. RoLL is designed for links in the short-range family, like 802.15.4. Whereas for V2V one would look at longer-range. Inside a vehicle, RoLL would run ok on lossy links. But we also consider in a vehicle to use more reliable links, like Ethernet cable, OBD-II interfaces, CAN. Currently AUTOSAR SDO seems interested in IP in vehicles, but I am not sure whether they mention RoLL? In the Alison slides there seems to be mention of a AUTOSAR ECU protocol, but not sure what is it? Now of course, one could say that the RPL protocol could run on anything, not necessarily low-power links and lossy links. At which point I could reply that there are other routing protocols which could run on anything as well. But what RoLL doesn't have and what we'd propose to do here is a mechanism to exchange routes, and to do address autoconfiguration for vehicles. Depending on these aspects, we need to identify how to add RoLL in the ITS picture. What do you think? Alex > > AB > From alexandru.petrescu@gmail.com Sat Feb 16 05:30:50 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF8021F8836 for ; Sat, 16 Feb 2013 05:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkicwXIhAGX3 for ; Sat, 16 Feb 2013 05:30:49 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4921F87FA for ; Sat, 16 Feb 2013 05:30:48 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GDUjhE028847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Feb 2013 14:30:45 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GDUjxK007960; Sat, 16 Feb 2013 14:30:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GDUenL006525; Sat, 16 Feb 2013 14:30:44 +0100 Message-ID: <511F8A00.4080408@gmail.com> Date: Sat, 16 Feb 2013 14:30:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <511E914B.6010702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "jari.arkko@piuha.net" , Ryuji Wakikawa , "its@ietf.org" , Abdussalam Baryun Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:30:50 -0000 Le 16/02/2013 09:39, Pascal Thubert (pthubert) a écrit : > I'd be surprised if Alex disagrees - or Ryuji for that matter. > > We were a bit too mush ahead of phase but the combination of local > and global mobility is what we wanted to achieve with MANEMO some > years ago. Well, it didn't pursue in 2007... > RPL has the exact properties that we were looking for at the time. But Pascal, RPL is something which could do anything? I thought it were only for wireless sensor networks, low-power and lossy links. In V2V one needs high-power links and in-vehicle one appreciates the non-lossy reliability of Ethernet. Where would RPL fit? > The global mobility can be achieved a number of ways, but is seems > that making the road side unit the locator is the simple thing. Please explain, what does it mean to make the RSU the locator. In some cases RSUs are needed, and in other cases direct V2V communications between vehicles are needed as well (w/o infrastructure). For these V2V cases, RPL would not be needed, right? > In that case, we have a number of possibilities of the shelf, > including LISP, PMIP, or MIP/NEMO-proxy such as discussed in global > HAHA for DMM. I think I agree. PMIP with an RSU as MAG is tempting. Sandra wrote private email about VIP-WAVE which is documented in a quality paper at http://bbcr.uwaterloo.ca/~slcesped/i/preprintVIPWAVE.pdf LISP yes could be analyzed to see how it fits the OBU/RSU distinction. GlobalHAHA would need to be suggested to DMM, not here, right? (I don't know what you meant?). I need to modify the Charter proposal according to your suggestions. I will do so soon. Alex > > Cheers, > > Pascal > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: > samedi 16 février 2013 03:07 To: Alexandru Petrescu Cc: its@ietf.org > Subject: Re: [its] Draft Charter proposal > > Hi Alex, > >> A number of IETF protocols are being considered in the context of >> Intelligent Transportation Systems - most notably IPv6, Mobile >> IPv6, ND, ULA, DHCPv6. Others are not excluded. At IETF several >> Working Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce >> work which is highly pertinent to the ITS context. > > What about ROLL, I think it is more related to ITS, I think we should > consider that our intelligent systems/devices need use some of ROLL > techniques in V2V and V2I > > ITS = ROLL + MANET > > IMHO, that the chater proposed, mentions the ITS applicability that > should include MANET applicability and ROLL applicability. > > AB _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Sat Feb 16 05:46:48 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7D21F881A for ; Sat, 16 Feb 2013 05:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwsBFrMrzgVW for ; Sat, 16 Feb 2013 05:46:47 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BD23621F87FA for ; Sat, 16 Feb 2013 05:46:46 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1GDkjTp023502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Feb 2013 14:46:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1GDkjKt009408 for ; Sat, 16 Feb 2013 14:46:45 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (arletty1-201-7.intra.cea.fr [132.166.201.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1GDkfmi028228 for ; Sat, 16 Feb 2013 14:46:45 +0100 Message-ID: <511F8DC1.3000701@gmail.com> Date: Sat, 16 Feb 2013 14:46:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Proposal to advance towards disseminating SDO documents for standards work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:46:48 -0000 Dear ITS participants who also participate in external SDOs: ETSI, ISO, IEEE, Several times you expressed needs for IETF to review SDO documents which are private, but could be used by standards contributors. Several members of ITS public list may express interest to review the documents and provide technical feedback. But there are three problems: - typically IETF feedback is formalized, there are official 'liaison' statements. They take public debate into account, public Internet Drafts, etc. - some IETF-minded people may prefer to offer feedback under the form of neutral yet public discussion, which includes study and analyze, instead of definitive personal statements. - this list ITS at IETF is just an email list, it doesn't have the backing of IETF under any form. Tomorrow the list may disappear altogether. This discussion on ITS list is not yet Standards work. I propose the following way forward: help us form an official Working Group. At that point the SDO documents could be disseminated without worry within the Working Group, because it would be Standards work. To achieve that, please comment on the Draft Charter proposal. Alternatively, please write drafts expressing oppinion which is relevant to SDO and expresses what SDO needs from IETF. Thank you in advance, Alex From sm@resistor.net Sat Feb 16 07:40:42 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F9921F86AF for ; Sat, 16 Feb 2013 07:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi0mU4bslksU for ; Sat, 16 Feb 2013 07:40:41 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1521121F884A for ; Sat, 16 Feb 2013 07:40:41 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1GFeWRr001427; Sat, 16 Feb 2013 07:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361029236; bh=DUs8tCrjoW/pY9hKzzGJnbMYOT9x4HNjrXSc33duQzg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AUUwbhKxkYxi4xSXUkVSlIKnmNfLwT6q3r+CabhKf6yDC5cGganC9avZtuZtwoyVe w6LjawfqAcABZWa1VJNqA4YgxLUhj0fwnuudvfEmr7VbIZHUYtK7RMpWacq5D5dr2N oyxHadBplcRT1TL+D/y2x0+VnbYT3tOQ/++biY/Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361029236; i=@resistor.net; bh=DUs8tCrjoW/pY9hKzzGJnbMYOT9x4HNjrXSc33duQzg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1seA+mWPSIg0fWJD6UpM5NPUt1uEfL2IvgKSIby2W7PbU1Fqs3xYqWrNjFpqVE2fQ d+nO7gDhYxc6p4l16BzZDqg9mGm0UN9rECXbtJs/0/4NYqVE0wQTMIRaGmMDtWy+Vp AdQSazcgLrx4Mqq2k0bkn1wH4B2hD9rMXlldv++8= Message-Id: <6.2.5.6.2.20130216072742.099689f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Feb 2013 07:40:28 -0800 To: Alexandru Petrescu From: SM In-Reply-To: <511F8DC1.3000701@gmail.com> References: <511F8DC1.3000701@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: its@ietf.org Subject: Re: [its] Proposal to advance towards disseminating SDO documents for standards work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:40:42 -0000 Hi Alexandru, At 05:46 16-02-2013, Alexandru Petrescu wrote: >Several times you expressed needs for IETF to review SDO documents which >are private, but could be used by standards contributors. > >Several members of ITS public list may express interest to review the >documents and provide technical feedback. When I have to read a draft I may also have to read some of the work it references. If access to that work is not free, I generally give up on the draft. I am not asking for that work to be made free. Regards, -sm From abdussalambaryun@gmail.com Sat Feb 16 12:36:30 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D978B21F88C7 for ; Sat, 16 Feb 2013 12:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2CK9TkJqlRp for ; Sat, 16 Feb 2013 12:36:30 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C07A521F8895 for ; Sat, 16 Feb 2013 12:36:29 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so2295348wic.5 for ; Sat, 16 Feb 2013 12:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GCaVnkWjgJsSwFKwm58c+YY7PKqOQ/XV76BgIQQFInQ=; b=rhlatNSGmluxgduTytOgo6r4JPZtTXXHqOX7DW9ZHc62RsCsD1iL1mUMwUGbIDjjBA CODQ8/7b8IEOoL0R9O/NV4AC0g6Z5xiVD2YSoDawzv2RR8JoFFkUHVcGGUBdCgy95MJR o6dMWkAeDJ7K8e0b2fXmfTX59GG/3ltoFyTHhMhMQRxnxY8edcyFbPFm17vx0MOSwsQp wzTcB9WYAia7435jCTmiixmfdi5PNncZuu4Qdun2ywtd5va6smv8R+XDnAnRBr67I2j2 TYGfo6WatXlBhz7N5+fwyEbS+pb1IHKgVM6+ukn6/85EIgJ7+Ph1ehYy2XaB9DFgXzOO 9oBg== MIME-Version: 1.0 X-Received: by 10.180.109.131 with SMTP id hs3mr5323253wib.18.1361046988821; Sat, 16 Feb 2013 12:36:28 -0800 (PST) Received: by 10.180.101.70 with HTTP; Sat, 16 Feb 2013 12:36:28 -0800 (PST) In-Reply-To: <511F8DC1.3000701@gmail.com> References: <511F8DC1.3000701@gmail.com> Date: Sat, 16 Feb 2013 21:36:28 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Proposal to advance towards disseminating SDO documents for standards work X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 20:36:31 -0000 On 2/16/13, Alexandru Petrescu wrote: > Dear ITS participants who also participate in external SDOs: ETSI, ISO, > IEEE, I didn't work in other SDOs but maybe in future, we already have the IETF, others have different work flow, > > Several times you expressed needs for IETF to review SDO documents which > are private, but could be used by standards contributors. Yes, I agree because the Internet community is a very wide community, > > Several members of ITS public list may express interest to review the > documents and provide technical feedback. > > But there are three problems: > - typically IETF feedback is formalized, there are official 'liaison' > statements. They take public debate into account, public Internet > Drafts, etc. Why private, private stuff are for private sectors, yes public is more open to community (volunteering), and more accessed by end-users. Don't see the problem, > - some IETF-minded people may prefer to offer feedback under the form > of neutral yet public discussion, which includes study and analyze, > instead of definitive personal statements. don't understand this point. > - this list ITS at IETF is just an email list, it doesn't have the > backing of IETF under any form. Tomorrow the list may disappear > altogether. This discussion on ITS list is not yet Standards work. > Yes that is why we need to propose to an IETF WG. We should not discuss very deep, just framework, and applicability, after accepted and liasened then we progress. > I propose the following way forward: help us form an official Working > Group. At that point the SDO documents could be disseminated without > worry within the Working Group, because it would be Standards work. I think that is ok > > To achieve that, please comment on the Draft Charter proposal. > Alternatively, please write drafts expressing oppinion which is relevant > to SDO and expresses what SDO needs from IETF. > IMO, we do the internet work standard, they don't do that, so they need the IETF, AB From alison@she-devel.com Sat Feb 16 17:58:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C221621F8487 for ; Sat, 16 Feb 2013 17:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkW9MB9qIqWs for ; Sat, 16 Feb 2013 17:58:57 -0800 (PST) Received: from mail-ie0-x229.google.com (ie-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2526621F847C for ; Sat, 16 Feb 2013 17:58:56 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id 13so6277729iea.0 for ; Sat, 16 Feb 2013 17:58:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=2gAVictGK+YWRkz3QQcisSjUwVOvTXcpItgf0/y+/L4=; b=ZR8IW0lKGRBPVj7E81t0JrSJsnaNwge4OTrP/mJakt3ZfRzpfbpjkh8DtLh6bfeHq/ 59m4Pd7cpndC9OsY+0/B+51a9FVRu2EqWhCJOsXgY7lCq2uiaaqHdartnTqdUktQAYjR 47y9iXS2FKEAwwx9j90D0WBjJI2xhuqMoCtFScrZlOod63EKhtVpl+4uh0wOs2kTDED7 uHSevavLdVTZq+/uN/ZnLlM9SYMiiBJ4DZo4GaXzc2sNo6xqOCefFQ/vfayv6YkPxAPk N0+Y8uyzHjFGvlecntIgijYYj4hyaLt1MIhL+9rNUig7G+7OzCN0SLJGCQvIRaalTRmZ gZkA== MIME-Version: 1.0 X-Received: by 10.42.81.148 with SMTP id z20mr4077535ick.5.1361066336439; Sat, 16 Feb 2013 17:58:56 -0800 (PST) Received: by 10.42.196.200 with HTTP; Sat, 16 Feb 2013 17:58:56 -0800 (PST) Date: Sat, 16 Feb 2013 17:58:56 -0800 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnh30y6XW8efRGEojywJfT+uxXM7fnHvtOpNA9Wzht5FfFs7Ze6a+b/tBGvZGiFX9DIQNCe Subject: Re: [its] "Addressing the hard problems of automotive Linux: networking and IPC" talk slides X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 01:58:57 -0000 Alexandru Petrescu asks: > I am told AUTOSAR also discusses address auto-configuration for > in-vehicle? And OBD/Ethernet? And in your slide I see AUTOSAR ECU > protocol? What is ECU protocol? AUTOSAR is a design methodology and interface specification for vehicles; see also OSEK. Most ECUs talk on CAN, but of course CAN has more than one version, and is itself only a Link Layer protocol, with lots of different stacks available above. Look up the Imamoter work or the Renesas app note I mention in the slides for more info. > CAN-Ethernet demo seems to be interesting. > AF_BUS - a new family of protocols, akin to AF_UNIX. > > Do you think the Draft Charter proposal I sent earlier in the 'its' > email list covers these concepts? CAN and AF_BUS are for vehicle intranets, while ITS group is mostly concerned with intervehicle networks, isn't it? Or would you like to cover intranets as well? The whole question of how to use sockets in a scalable pub-sub context within vehicles is rife with controversy at the moment. > (and I learn from your slides that there exists IEEE 1609.3 WSMP ok, > which I guess is like FNTP mentioned by Hans-Joachim at ISO). I haven't had a chance to read up on FNTP yet, but since IEEE is an international body, I presume that EU implementations of V2V safety messages will be compliant. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} Access is more important than ownership. -- Joe Gebbia, AirBnB From abdussalambaryun@gmail.com Sun Feb 17 02:39:23 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4296621F871E for ; Sun, 17 Feb 2013 02:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyG0uLRIhy6p for ; Sun, 17 Feb 2013 02:39:22 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6625F21F8628 for ; Sun, 17 Feb 2013 02:39:22 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so1226571pbc.7 for ; Sun, 17 Feb 2013 02:39:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=LLxW29ZAm5+pSgVVa/WeSJPifzLDiZt7j96r3S0FkkA=; b=QlSfwjTP8XqMGYK5F9IhdR5JnVvjr8Pr8wgTkN0WuZsubs70KOQpcmVLKkmEv24cCY E5p7rlu0NLFgZnJ28ULvnTMFm9vgqtZ+eWg7fYxGr+FhED30HFmNcu0zyJ3twx0SsRe2 TpctKvdTLw/MzRKhkzdT5/0+bZkFA9EUAj/AvOsbwqbdG6QBXAubOJOZ6ctdZ7+r7Mnt H08KpWlVrE7kgyJ+IBQuk6LOAqEl40VfRD/793XamwBlmUiqMxTDr8ZOY9H/fBMa/bAS /UDx72mB08JKeGUAySAgnSeu4oZJQ546LuSOpiE8jaim8udbsaTrnzqaWlFG3lWDnzss ++Yw== MIME-Version: 1.0 X-Received: by 10.68.7.106 with SMTP id i10mr20716235pba.43.1361097562210; Sun, 17 Feb 2013 02:39:22 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 17 Feb 2013 02:39:21 -0800 (PST) In-Reply-To: <511F8808.8000306@gmail.com> References: <511E914B.6010702@gmail.com> <511F8808.8000306@gmail.com> Date: Sun, 17 Feb 2013 11:39:21 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "its@ietf.org" Subject: Re: [its] RoLL and Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 10:39:23 -0000 Hi Alex, IMHO, the proposed charter [1] is more technical than describing the use-case, which is good to have technical but needs the clarify of use-cases. The ITS V2V is using MANEMO, but as recommended [2] within the Vehicle we will need ROLL [3] for many small devices, to make a smart/intelligent system. I think the ITS has networking of different capability devices. We need to benefit from smart cities services/applications to make the ITS more intelligent. MANET does not consider intelligents or sensitivity to population/transport environment requirements, this is the beauty of ITS. As you mentioned the ROLL does not consider high power devices too (ITS considers both high and low). So their charter and all IETF WGs have different scope than ITS. I recommend that we mention the smart city use-case for ITS which I think this is never chartered in IETF (new use-case), and it's prety much related. The ITS is important for networking country or world transports to make them more intelligent (i.e. the proposed WG is not general purpose, but specifc for transportation systems). We need to state our ITS system requirements/services for transports within cities and between cities or countries, making them smart. The use-case of ITS is different than ROLL and MANET but ITS may (not MUST) use the both techniques to be adaptive to its new IETF use-case. [1] http://www.ietf.org/mail-archive/web/its/current/msg00220.html [2] http://www.ietf.org/mail-archive/web/its/current/msg00224.html [3] ROLL is routing over LLN AB On 2/16/13, Alexandru Petrescu wrote: > Le 16/02/2013 03:06, Abdussalam Baryun a =E9crit : >> Hi Alex, >> >>> A number of IETF protocols are being considered in the context of >>> Intelligent Transportation Systems - most notably IPv6, Mobile >>> IPv6, ND, ULA, DHCPv6. Others are not excluded. At IETF several >>> Working Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce >>> work which is highly pertinent to the ITS context. >> >> What about ROLL, I think it is more related to ITS, I think we should >> consider that our intelligent systems/devices need use some of ROLL >> techniques in V2V and V2I >> >> ITS =3D ROLL + MANET >> >> IMHO, that the chater proposed, mentions the ITS applicability that >> should include MANET applicability and ROLL applicability. > > Abdussalam, > > Thank you for the comments. I am ready to add something in the Charter > proposal about RoLL, also because also PAscal talks it. > > But let me comment further. > > RoLL stands for Routing over Low-Power and Lossy Links. But with V2V > one would be looking more at high-power links, because the higher the > power the higher the speed of vehicles (e.g. in France at 100mW WiFi a > V2V entertaining videoconference allows for two convoyed vehicles speed > of around 90km/h, because the 100mW corresponds to approximately 50meter > distance, which is the security distance in France for speed of 90km/h, > no more). This would mean it's impossible to use RoLL > on a highway where the recommended speed is much above 90km/h. > > RoLL is designed for links in the short-range family, like 802.15.4. > Whereas for V2V one would look at longer-range. > > Inside a vehicle, RoLL would run ok on lossy links. But we also > consider in a vehicle to use more reliable links, like Ethernet cable, > OBD-II interfaces, CAN. Currently AUTOSAR SDO seems interested in IP in > vehicles, but I am not sure whether they mention RoLL? In the Alison > slides there seems to be mention of a AUTOSAR ECU protocol, but not sure > what is it? > > Now of course, one could say that the RPL protocol could run on > anything, not necessarily low-power links and lossy links. At which > point I could reply that there are other routing protocols which could > run on anything as well. > > But what RoLL doesn't have and what we'd propose to do here is a > mechanism to exchange routes, and to do address autoconfiguration for > vehicles. > > Depending on these aspects, we need to identify how to add RoLL in the > ITS picture. > > What do you think? > > Alex > > >> >> AB >> > > > From abdussalambaryun@gmail.com Sun Feb 17 02:51:34 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A1421F8800 for ; Sun, 17 Feb 2013 02:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnMEPMsHMquM for ; Sun, 17 Feb 2013 02:51:32 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id EF29021F87D5 for ; Sun, 17 Feb 2013 02:51:31 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so2364013pad.6 for ; Sun, 17 Feb 2013 02:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PHl/XIBTmvcABQOlepYaU7uriyitccO2a/68wEqbtAA=; b=eQJRNmDRwOmzv0FUFDebpWKCak/tAIO3yDs74KZsauRPud3+6wFh6sEmoMFGUONEQT yurKd/U6+/WytGkEceGDP2TB1KFMeCgU+K6t7doYw4BktKZ9XWCqCwNjWSkJOGg4McQk qU9ReirbudM/XbifnJncnyRtsC2hD+BYO8EOUBFBHuyInIMi8QmGE3s9lFsIbAAle+NB B7ALIu6wA8NDJc3XE+IKnLacU78r6MbAkwmEaeGzDGHeZbJg51TS8kgITENbodqWOxVr tr5NKItrBiOPfUwbpPiB2+Wv1TpHCpeXo2lbVvlQTZeoVLjnIjTt37YqQQQDvMfDQrr5 oGTQ== MIME-Version: 1.0 X-Received: by 10.68.252.232 with SMTP id zv8mr20271443pbc.166.1361098291717; Sun, 17 Feb 2013 02:51:31 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 17 Feb 2013 02:51:31 -0800 (PST) In-Reply-To: <511E478F.8020003@gmail.com> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E478F.8020003@gmail.com> Date: Sun, 17 Feb 2013 11:51:31 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Roberto Baldessari , "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IPv6 and geonetworking (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 10:51:34 -0000 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 On 2/15/13, Alexandru Petrescu wrote: > Le 15/02/2013 11:05, Roberto Baldessari a =C3=A9crit : >> 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. > > 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 > >> >> Best regards, >> >> Roberto >> >> >> >>> >>> Best regards, >>> >>> Roberto >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org >>> Subject: Re: [its] IP over 802.11p >>> >>> Le 11/02/2013 14:50, Dowdell, John a =C3=A9crit : >>>> 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 >>> >>>> >>>> John >>>> >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] >>>> IP over 802.11p >>>> >>>> Le 31/01/2013 14:47, Thierry Ernst a =C3=A9crit : >>>>> >>>>> 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 =C3=A9crit : >>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>>> 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: its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>>>> Petrescu Sent: Wednesday, January 30, 2013 12:00 PM >>>>>>>>> To: its@ietf.org 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 =C3=A9crit : >>>>>>>>>> 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:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry >>>>>>>>>> Ernst *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>>> *To:* its@ietf.org *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 >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> 900002 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> 20_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 =C3=A9crit : >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > r >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> s.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 >>>>>>>>>> >>>>>>>>>> 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 =C3=A9crit >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C **Cordialeme= nt, Regards* * * * * >>>>>>>>>> *=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88Na= bil 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 its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org 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 >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From abdussalambaryun@gmail.com Sun Feb 17 03:34:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949BE21F87B6 for ; Sun, 17 Feb 2013 03:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9prtMMKI-vtI for ; Sun, 17 Feb 2013 03:34:54 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBB21F87B1 for ; Sun, 17 Feb 2013 03:34:53 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id v40so2033716dad.35 for ; Sun, 17 Feb 2013 03:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=WUV2hAxYUcDvco5bioieUIdU+wjKuIRZRrZUYxrZYTU=; b=0pucmevQfdyQ7UlzINZqIxQwd7N1DuoCQ6UhbaSrkP5lpEWVV2Vj7qnYpfYO4Ej9et m3p+w7gITPhVsrTyMpsaHgJolXhri6+RJ0/YIc90/gTCGCWloSwwCGQEvJ5pv4JH9VrJ Najo7u7C6bZIyzEIvmTm6wBCazg38vvb1Zq3UntUvoHxXK/QoP/rdf4wzrvFNWXS4xG+ qIUooEyTHOHuyC8/Uiv7vhPxN4ggjZrnCHiwnWcYOpGYH6wZ/cTN9NMWJjhUhLMv+82P hRwOGOKipKUMPhE/P0S+d0TQQgxYnUCL7S2xWxBPqJMfZzho/mZ6AEfqHtpUNPEWflgP jt6g== MIME-Version: 1.0 X-Received: by 10.68.189.169 with SMTP id gj9mr21239800pbc.67.1361100893677; Sun, 17 Feb 2013 03:34:53 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 17 Feb 2013 03:34:53 -0800 (PST) Date: Sun, 17 Feb 2013 12:34:53 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "its@ietf.org" Subject: [its] New IETF Networking For ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 11:34:54 -0000 Hi Folks, For smart cities and their transportation (including communities), I support the advise below of considering ETSI IPv6 over GeoNetworking standard, however we may consider to add to it the OLSRv2 standard as well because used in community networks. The geo-aware can be included in OLSRv2. However, IMO a hybrid routing is a good alternative choice for ITS, but also may consider I2R architecture [1] as a part in ITS framework. The hybrid route design approach maybe similar to a suggested one [2]. I recommend this to be into framework-draft or discussed, but not into the proposed charter because it will take time untill we agree on the final approach of ITS networking, [1] http://www.ietf.org/mail-archive/web/i2rs/current/msg00523.html [2] http://www.ietf.org/mail-archive/web/manet/current/msg14738.html AB Sub: Re: [its] IPv6 and geonetworking (was: IP over 802.11p) On 2/15/13, Alexandru Petrescu wrote: > Le 15/02/2013 11:05, Roberto Baldessari a =E9crit : >> 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. > > 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 > From abdussalambaryun@gmail.com Mon Feb 18 03:04:41 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6428721F8818 for ; Mon, 18 Feb 2013 03:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-1.360, BAYES_00=-2.599, FRT_POSSIBLE=2.697, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdLU4O-FOpGQ for ; Mon, 18 Feb 2013 03:04:41 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id EFF6021F87F7 for ; Mon, 18 Feb 2013 03:04:40 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so2410005daj.22 for ; Mon, 18 Feb 2013 03:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b3oX0qBuBMqB92Qb4pA6+UB7R2BpuebtuXdqPSmNg6U=; b=rzAYcOAyIe3qtVZZD97pukhY8o7gY/4Mc8znTsD3a0eC4dtKKo0+G2ZyqUt095L5KL m+dG/BhETwaV9TP2Nff49vTbxbOwvx3hJ33uG6//k7T0mCfn3k3u+m6Fvspa96NEHiMm V+un5mD3x9W1KWrdY6kGRBEsWkFZs8zaUvJAiszVSAyB7T8jwl4o24UVTDw7idS9upj6 /YF/vA2vHttfiUeHgej7xxnnI7+pxmeBCqZYhY6/91i1LScmBshz1WI02OH2aLeiLyNs PVfbbm/qB33xnVTnwkWK2JkE3MemIhEEgvfereUDkXNUKrlEV0SluYztg1cHFbxsGeh7 xLtA== MIME-Version: 1.0 X-Received: by 10.68.189.169 with SMTP id gj9mr29167986pbc.67.1361185474150; Mon, 18 Feb 2013 03:04:34 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 18 Feb 2013 03:04:33 -0800 (PST) In-Reply-To: <511F8A00.4080408@gmail.com> References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> Date: Mon, 18 Feb 2013 12:04:33 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "jari.arkko@piuha.net" , "Pascal Thubert \(pthubert\)" , Ryuji Wakikawa , "its@ietf.org" Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:04:41 -0000 >> RPL has the exact properties that we were looking for at the time. > > But Pascal, RPL is something which could do anything? I thought it were > only for wireless sensor networks, low-power and lossy links. In V2V > one needs high-power links and in-vehicle one appreciates the non-lossy > reliability of Ethernet. > > Where would RPL fit? > I mean to use the RPL not fully fit in the ITS, a hybrid routing of RPL, OLSR, and other may be suitable. I think RPL can be used on/in the Vehicles (i.e. many small devices needed), its links and devices are possibile to failure, I don't think Ethernet reliability can solve all situations. The ITS environment is a lossy one with high probability of damage. Do you think the ITS is reliable because of the Ethernet techniques? AB From abdussalambaryun@gmail.com Mon Feb 18 03:43:32 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CA121F8919 for ; Mon, 18 Feb 2013 03:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+XQG8CQ+6UT for ; Mon, 18 Feb 2013 03:43:32 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2294821F8904 for ; Mon, 18 Feb 2013 03:43:32 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kl14so2752361pab.18 for ; Mon, 18 Feb 2013 03:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y3bXE9r9W5JRmpaleGi4fOorShH/hplKqNHI4cD8XWA=; b=pv+e/wCBTQX/Inv9JL5kEIbATyntRVQHKxD5Lb4mUfwRVtyhiBnwtb+t649cNGjbR7 oMxPC12SxYnY+w+zd1hkmCi45lOu+Xpzh7wr+Cfbmmijo3Ly+bg9FOalySVJhb30ieym TzzeGsYMTYWmfs3GlDMKceJ+yJzgTRCEUzeb+FvqaLCxvTzTiDVvBcxhLx1e52niUeNj CvTC/NzQhLVHa11BUPJGcDoRT7o0B6EwpcbzsWAJEDKok2vWa3kw0yJuY9mGrsSFNWZv Po1Jx5EigqfiiiCuV5/rYeDVyJix87RpUXBgkJYkZDUpHIv/imnzBcr4t7LPl8e9j8HL /Z7g== MIME-Version: 1.0 X-Received: by 10.68.7.106 with SMTP id i10mr29123677pba.43.1361187811917; Mon, 18 Feb 2013 03:43:31 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 18 Feb 2013 03:43:31 -0800 (PST) In-Reply-To: <511F8808.8000306@gmail.com> References: <511E914B.6010702@gmail.com> <511F8808.8000306@gmail.com> Date: Mon, 18 Feb 2013 12:43:31 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] RoLL and Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:43:33 -0000 On 2/16/13, Alexandru Petrescu wrote: > RoLL stands for Routing over Low-Power and Lossy Links. ROLL is Routing over LLN, its lossy network not only lossy links, I think ITS is runing for lossy networks, > But with V2V > one would be looking more at high-power links, because the higher the > power the higher the speed of vehicles (e.g. in France at 100mW WiFi a > V2V entertaining videoconference allows for two convoyed vehicles speed > of around 90km/h, because the 100mW corresponds to approximately 50meter > distance, which is the security distance in France for speed of 90km/h, > no more). This would mean it's impossible to use RoLL > on a highway where the recommended speed is much above 90km/h. ROLL is not for high power, but don't forget that Vehicles are not all large as cars or trucks, they may be small transporters machines in buildings/homes. > > RoLL is designed for links in the short-range family, like 802.15.4. > Whereas for V2V one would look at longer-range. Why we make the scope narrow to longer-range, I think ITS needs both long and short range to become intelligent otherwise it will not become intelligent, > > Inside a vehicle, RoLL would run ok on lossy links. But we also > consider in a vehicle to use more reliable links, like Ethernet cable, > OBD-II interfaces, CAN. Currently AUTOSAR SDO seems interested in IP in > vehicles, but I am not sure whether they mention RoLL? Yes I like to have cables and/or wireless inside vehicles, depends on the transport resource and reason actually. > > Now of course, one could say that the RPL protocol could run on > anything, not necessarily low-power links and lossy links. At which > point I could reply that there are other routing protocols which could > run on anything as well. The bueaty of RPL is that it used for buildings and homes, so it can be used in our intelligence for our ITS. Most transports in the world are between buildings and homes :-) > > But what RoLL doesn't have and what we'd propose to do here is a > mechanism to exchange routes, and to do address autoconfiguration for > vehicles. > IMO, we only need to use the RoLL techniques which help in our scope and ignore its techniques that is not related. We may take some other techniques as well or create a new mechanism depending which is better way on the discussion table. > Depending on these aspects, we need to identify how to add RoLL in the > ITS picture. Yes, I agree totally, > > What do you think? > I think we are on the right track to best transports :) From abdussalambaryun@gmail.com Mon Feb 18 04:00:55 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8235721F88F5 for ; Mon, 18 Feb 2013 04:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3lT2TjHZAAH for ; Mon, 18 Feb 2013 04:00:55 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 211A021F883E for ; Mon, 18 Feb 2013 04:00:52 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so1629248pbc.22 for ; Mon, 18 Feb 2013 04:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BzeMgvah9UeJy66xHvlw7horbumplU71YGSPVfOIcFs=; b=KoLoP8Z25Ii4a2Y6ITFs/D/BVgk5jMsKzRQKnWbRAaVyj+vQipJKTAd5c2J6XQ2ifi V/BOrqsk50BgJ03fagCjoYjcpV8rA46AkaWlpjQ6693OOz7aoKg9cnlji1W0SP1FHhRK uyAY1gKNzHl3FkfCNDRnFApz37NDy8SikmzzxlHpO7sZnb6CXiDaRxQqpPPhfjG06reE /I2srx4Bq3RTNR+Exuf7msVv/AvohlLF+nMOTIQ9rguZf+AhHcVwMtbyxEUsV4sg7X78 YD9zbWyUjINdFpqIArsdRB9tAhPNyaNykXUGKAOW8myf0/8WZmn6mMS6HERao2Rty5sV KZCQ== MIME-Version: 1.0 X-Received: by 10.66.85.161 with SMTP id i1mr34939705paz.67.1361188851932; Mon, 18 Feb 2013 04:00:51 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 18 Feb 2013 04:00:51 -0800 (PST) In-Reply-To: References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> Date: Mon, 18 Feb 2013 13:00:51 +0100 Message-ID: From: Abdussalam Baryun To: its Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 12:00:55 -0000 I suggest to consider the [1] [2] and [3] into the proposal if possible, or I may send my proposal when available, which is based on the following: a) ITS use-case or applicability: transportation within a city and country, and between countries. The purpose of transport, the transporter-resources and its networking is important to be defined for ITS. b) The framework of ITS should consider techniques used in IETF which maybe related to ITS (as all related to Internet IP), however, the framework should be a new approach that is scoped for ITS. c) work needed to be done including milestones. [1] http://www.ietf.org/mail-archive/web/its/current/msg00224.html [2] http://www.ietf.org/mail-archive/web/its/current/msg00237.html [3] http://www.ietf.org/mail-archive/web/its/current/msg00235.html AB From fjros@um.es Mon Feb 18 09:28:32 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB67D21F8C38 for ; Mon, 18 Feb 2013 09:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shnGumOBc2Vk for ; Mon, 18 Feb 2013 09:28:30 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0386F21F8C0C for ; Mon, 18 Feb 2013 09:28:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 45A384C22D; Mon, 18 Feb 2013 18:28:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xTnOUwKVYLXU; Mon, 18 Feb 2013 18:28:26 +0100 (CET) Received: from eduroam_um-230-192.inf.um.es (eduroam_um-230-192.inf.um.es [155.54.230.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon12.um.es (Postfix) with ESMTPSA id E0F974C229; Mon, 18 Feb 2013 18:28:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <511BF0AB.7090808@fischer-tech.eu> Date: Mon, 18 Feb 2013 18:28:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <511A26F9.4080809@gmail.com> <511B9E19.5040500@gmail.com> <511BF0AB.70 90808@fischer-tech.eu> To: Dr. Hans-Joachim Fischer X-Mailer: Apple Mail (2.1085) Cc: its@ietf.org Subject: Re: [its] IP over 802.11p - frequencies local X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:28:32 -0000 Hi Hans-Joachim, El 13/02/2013, a las 20:59, Dr. Hans-Joachim Fischer escribi=C3=B3: >=20 > 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. >=20 > 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. >=20 > 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. >=20 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. >=20 >=20 > Hans-Joachim >=20 > Am 13.02.2013 15:07, schrieb Alexandru Petrescu: >> Le 13/02/2013 11:31, Romain KUNTZ a =C3=A9crit : >>> Hello Alexandru, >>>=20 >>> On Feb 12, 2013, at 12:26 , Alexandru Petrescu >>> wrote: >>>> Le 11/02/2013 23:03, Romain KUNTZ a =C3=A9crit : >>>>> Hello Alexandru, >>>>>=20 >>>>> On Feb 11, 2013, at 16:30 , Alexandru Petrescu >>>>> wrote: >>>>>> I think yes 802.11p is mandated for ITS in Europe by ETSI ITS. >>>>>>=20 >>>>>> 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). >>>>>=20 >>>>> Do you have any reference that supports this statement? I have >>>>> never heard of such restrictions in France so far. >>>>=20 >>>> Hello Romain, >>>>=20 >>>> What channel/frequency would one consider in France, for >>>> IP-over-80211p-w/o-geonet? >>>>=20 >>>> About references - the quick study I did is on references from >>>> ARCEP and ETSI, simplified below. >>>>=20 >>>> The site of ARCEP[*] says only the following frequencies are >>>> reserved for ITS: 5 875 - 5 905 MHz "ITS" >>>>=20 >>>> 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. >>>>=20 >>>> Crossing ARCEP with ETSI one notices that only G5CC, G5SC2 and >>>> G5SC1 can be used in France for 'ITS'. >>>>=20 >>>> 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". >>>>=20 >>>> 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'. >>>=20 >>> Thank you for the pointers. =46rom 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. >>=20 >> There would be no risk if I send entertainment vlc videostreams on = the >> Control Channel? >>=20 >> Could I really send whatever I want on this channel? >>=20 >> Alex >>=20 >>>=20 >>> Romain >>>=20 >>>=20 >>>> It is for thess reasons that I speculate >>>> IP-over-80211p-without-geonet is not possible in France. >>>>=20 >>>> I may be missing something? >>>>=20 >>>> Alex [*] ARCEP "Autorit=C3=A9 de r=C3=A9gulation des comm. = =C3=A9lectroniques et >>>> des postes" https://www.espectre.arcep.fr/index.php (filled in >>>> "Fr=C3=A9quence Inf=C3=A9rieure" as 5470MHz and "Fr=C3=A9quence = Sup=C3=A9rieure" 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 >>>>=20 >>>> = http://www.etsi.org/deliver/etsi_es/202600_202699/202663/01.01.00_50/es_20= 2663v010100m.pdf=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >> Thank you, Romain >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Although I may sound relatively pessimistic, I also consider I >>>>>> may be wrong in my reasoning above. >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>>>=20 >>>>>>> John >>>>>>>=20 >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>>>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: >>>>>>> [its] IP over 802.11p >>>>>>>=20 >>>>>>> Le 31/01/2013 14:47, Thierry Ernst a =C3=A9crit : >>>>>>>>=20 >>>>>>>> Well, we do actually run IPv6 over 11p (with or without >>>>>>>> GeoNetworking), so I don't see what kind of issues there >>>>>>>> might be ... >>>>>>>=20 >>>>>>> I have some clarification questions about EtherType and >>>>>>> 802.11p and GeoNetworking. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> (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). >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> (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). >>>>>>>=20 >>>>>>> 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"). >>>>>>>=20 >>>>>>> For another example - is all the security on these links >>>>>>> entirely relaying on IP layer security (IPsec, SeND, EAP, >>>>>>> PANA)? >>>>>>>=20 >>>>>>> I think finding consensus on some of these questions could >>>>>>> lead to interoperability. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, Thierry >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> One of the things to say would be whether or not this is >>>>>>>>> IPv6 only or IPv4 also. >>>>>>>>>=20 >>>>>>>>> This would say how this would work _without_ >>>>>>>>> GeoNetworking. >>>>>>>>>=20 >>>>>>>>> It would agree on the EtherType and/or whether there are >>>>>>>>> new ones, several or only one, or reusing existing >>>>>>>>> EtherTypes. >>>>>>>>>=20 >>>>>>>>> It could be as simple as to say that IP works over >>>>>>>>> 802.11p just as it works over 802.11b - no >>>>>>>>> modifications. >>>>>>>>>=20 >>>>>>>>> What do you think? >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>> Le 30/01/2013 11:10, Alexandru Petrescu a =C3=A9crit : >>>>>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>>>>>> Hi Alexandru, >>>>>>>>>>>=20 >>>>>>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> I just watend to make sure. >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Dan >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] >>>>>>>>>>>> On Behalf Of Alexandru Petrescu Sent: Wednesday, >>>>>>>>>>>> January 30, 2013 12:00 PM To: its@ietf.org >>>>>>>>>>>> Subject: Re: [its] What do we need to make ITS WG >>>>>>>>>>>> go forward? - EtherType for ITS >>>>>>>>>>>>=20 >>>>>>>>>>>> Hello Dan, >>>>>>>>>>>>=20 >>>>>>>>>>>> Thank you for the email. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we definitely need a good interface with >>>>>>>>>>>> IEEE about this. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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). >>>>>>>>>>>>=20 >>>>>>>>>>>> Also, I am interested to learn whether this >>>>>>>>>>>> deserves being reserved at IANA. >>>>>>>>>>>>=20 >>>>>>>>>>>> Alex >>>>>>>>>>>>=20 >>>>>>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =C3=A9crit >>>>>>>>>>>> : >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >> and according to this list the value 8947 is not allocated. >>>>>>>>>>>>> Now, the public listing information for >>>>>>>>>>>>> EtherTypes bears a disclaimer that says >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * This is a partial listing of all assigned >>>>>>>>>>>>> EtherType Fields. Not >>>>>>>>>>>> all >>>>>>>>>>>>> recipients wish to publish their assignment at >>>>>>>>>>>>> this time. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Did ETSI require for this information not to be >>>>>>>>>>>>> published? It does not look useful if they want >>>>>>>>>>>>> to encourage interoperability >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Value 0707 mentioned in the thread is not >>>>>>>>>>>>> allocated either. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Let me know if I can help (as IETF liaison to the >>>>>>>>>>>>> IEEE-SA). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Dan >>>>>>>>>>>>>=20 >>>>>>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, >>>>>>>>>>>>> 2013 11:11 AM *To:* its@ietf.org *Subject:* Re: >>>>>>>>>>>>> [its] What do we need to make ITS WG go forward? >>>>>>>>>>>>> - EtherType for ITS >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Alex, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ITS(13)000020 >>>>>>>>>>>>> = >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >> 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=20= >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, Thierry. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Le 28/01/2013 14:16, Joe Klein a =C3=A9crit : >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I really dislike the fact that ISO is charging >>>>>>>>>>>>> for the ISO 21217 - Architecture & ISO 21210 - >>>>>>>>>>>>> IPv6 Networking. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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? >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> EtherType 0x0707 described in ITS documents, >>>>>>>>>>>>> implemented, but not specified by IEEE nor >>>>>>>>>>>>> reserved at IANA - does not make it >>>>>>>>>>>>> interoperable. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> One wouldn't think that this 0x0707 ethertype be >>>>>>>>>>>>> reserved by >>>>>>>>>>>> somebody >>>>>>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> (see a good example of interoperability: IPv6 >>>>>>>>>>>>> 0x86dd ethertype is reserved at IEEE and at IANA >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml)=20= >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >> Alex >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Or should these standards remain in >>>>>>>>>>>>>=20 >>>>>>>>>>>>> the public domain, for researches to review and >>>>>>>>>>>>> validate? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Just my 2 cents. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Joe >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This said, as mentioned earlier, ITS is not only >>>>>>>>>>>>> about vehicular communications, though the >>>>>>>>>>>>> issues listed by Alexandru below mostly consider >>>>>>>>>>>>> vehicular communications. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, Thierry. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a >>>>>>>>>>>>> =C3=A9crit : >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> All, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Stan, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thank you for the offer. I considered this offer >>>>>>>>>>>>> since some time. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please let me know. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yours, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Alex >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, Stan >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Nabil, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> AB >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 1/26/13, Nabil Benamar >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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 ? >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> AB >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C = **Cordialement, Regards* * * * * >>>>>>>>>>>>> *=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88= 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/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> = ----------------------------------------------------------------------=20= >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >> ---------- >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> * >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> its >>>>>>>>>>>>> mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its >>>>>>>>>>>> mailing >>>>>>>>>>>>> list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its mailing >>>>>>>>>>>> list >>>>>>>>>>>>> its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ its >>>>>>>>>>>> mailing list its@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its mailing >>>>>>>> list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org 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 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 > --=20 > = --------------------------------------------------------------------------= ---- > http://its-standards.info/ESF-News-2012-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 > = --------------------------------------------------------------------------= ---- >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From fjros@um.es Mon Feb 18 09:51:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E395521F8B0F for ; Mon, 18 Feb 2013 09:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QKrKYPuRwru for ; Mon, 18 Feb 2013 09:51:20 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id B5FAA21F8AE7 for ; Mon, 18 Feb 2013 09:51:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 657565D6CA; Mon, 18 Feb 2013 18:51:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6KrG9gsb4VIh; Mon, 18 Feb 2013 18:51:15 +0100 (CET) Received: from eduroam_um-230-192.inf.um.es (eduroam_um-230-192.inf.um.es [155.54.230.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon13.um.es (Postfix) with ESMTPSA id B06385D6C9; Mon, 18 Feb 2013 18:51:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> Date: Mon, 18 Feb 2013 18:51:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5 875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> To: Roberto Baldessari X-Mailer: Apple Mail (2.1085) Cc: Alexandru Petrescu , "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:51:23 -0000 Hi Roberto, El 15/02/2013, a las 11:05, Roberto Baldessari escribi=C3=B3: > Hi Alex, >=20 >> I read the comment. We could discuss it separately, in a separate = thread. =20 >> Basically, I think inserting geography in such internal workings = which is IP=20 >> 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. >=20 > I think this is the right thread to discuss this point. But you can = rename the subject if you prefer. >=20 > 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. >=20 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 > 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. >=20 > Best regards, >=20 > Roberto >=20 >=20 >=20 >>=20 >> Best regards, >>=20 >> Roberto >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- From: its-bounces@ietf.org=20 >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org Subject: >> Re: [its] IP over 802.11p >>=20 >> Le 11/02/2013 14:50, Dowdell, John a =C3=A9crit : >>> Alex >>>=20 >>> Is anyone making 802.11p radios commercially at reasonable cost? >>> The few I have seen seem to be very expensive (few k$) and there=20 >>> appears to be little support in Linux. 802.11s on the other hand is=20= >>> available on standard Wi-Fi dongles (from $15) and drivers are=20 >>> already available in Linux. Is it correct that 802.11p is mandated =20= >>> for ITS in some regions? >>=20 >> John, >>=20 >> Without advertising, we use finalized 802.11p hardware (OBU, RSU, >> etc.) and support from ITRI Taiwan. The complete package (drivers,=20= >> geonetworking, SDKs) is expensive yes in the range of thousands of=20 >> USDollars. >>=20 >> 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=20 >> PC-like platforms. I believe these cards may be relatively cheap. = I=20 >> don't know whether Unex offer drivers for these cards (be them = binary=20 >> or open source), we use the binary drivers from ITRI. >>=20 >> I think yes, there seem to be little if any open source GPL driver=20 >> support in linux for 802.11p. I am interested to learn if this = exists=20 >> somewhere, even in a prototypical form. We're only aware of SPITS=20 >> project, but were not very successful at trying it. >>=20 >> One advantage of .p is that it is regulated such as no need to pay a =20= >> license and still allowed to emit at high power levels (33dBm EU,=20 >> 40dBm US, compared to hundreds of milliWats for WiFi). I.e. it is=20 >> possible to have two independent vehicles distanced by kilometers,=20 >> without infrastructure, and communicate, and without requiring = license=20 >> from government (whereas in the case of WiFi one can't legally do = more=20 >> than a hundred meters or so). >>=20 >> I am not sure this is the case for .s(?) Could .s use high power=20 >> levels like EIRP 40dBm and without license? >>=20 >>=20 >> Then, >>=20 >> I think yes 802.11p is mandated for ITS in Europe by ETSI ITS. >>=20 >> But unfortuntaly for me, the situation in the country I live (France)=20= >> seems to be that one is not allowed to use IP-over-802.11p without=20 >> geonetworking (i.e. not allowed to use the frequencies allocated to=20= >> ITS for 802.11p without using ETSI ITS i.e. geonetworking). >>=20 >> These factors seem to strongly hamper the development of vehicular=20 >> specific communication technology at IETF: - lack of open-source=20 >> driver codes for 802.11p - lack of open and free-of-charge access to =20= >> ETSI standards - lack of open access to ETSI interoperability results=20= >> - lack of cheap hardware implementations of 802.11p - lack of =20 >> unregulated/unlicensed frequency allocated for IP-over-80211p for = long=20 >> range. - technical misunderstanding between the ETSI point of view of=20= >> what is IP and the IETF of same. >>=20 >> Although I may sound relatively pessimistic, I also consider I may be=20= >> wrong in my reasoning above. >>=20 >> Alex >>=20 >>>=20 >>> John >>>=20 >>> -----Original Message----- From: its-bounces@ietf.org=20 >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP=20= >>> over 802.11p >>>=20 >>> Le 31/01/2013 14:47, Thierry Ernst a =C3=A9crit : >>>>=20 >>>> Well, we do actually run IPv6 over 11p (with or without=20 >>>> GeoNetworking), so I don't see what kind of issues there might be=20= >>>> ... >>>=20 >>> I have some clarification questions about EtherType and 802.11p and=20= >>> GeoNetworking. >>>=20 >>> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20= >>> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20= >>> over 11p without GeoNetworking, the Ethernet header uses EtherType=20= >>> 0x86DD. This is just a supposition, I don't know how you run it. >>>=20 >>> Also, if I run IPv4 over 11p with GeoNetworking - should I use=20 >>> EtherType soon-to-be-0x8947? Or other? I suppose that if I run >>> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800, =20= >>> and if it's ARP over 802.11p still without GeoNetworking then I=20 >>> should use EtherType 0x0806. >>>=20 >>> (the letter we've seen recently is not clear whether that allocation=20= >>> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 >>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not=20= >>> clear either whether GeoNetworking supports IPv4 or not, or under=20 >>> what form). >>>=20 >>> I also have some questions about the relationship between the nature=20= >>> of some 802.11p links (no ESSID, absence of link-layer security - as=20= >>> opposed to WiFi which has ESSID and link-layer >>> security) and IP. >>>=20 >>> For example - will V2V prefix exchange using Router Advertisements=20= >>> work easier on 802.11p links (easier than on WiFi), because the = ESSID=20 >>> does not need to be discovered, the ad-hoc network does not need to=20= >>> be formed - suffices it to send packets on a certain channel. >>>=20 >>> (in a V2V draft one seems to say that the presence of Access Point =20= >>> is absolutely necessary in order for 802.11p to work; but in our=20 >>> experimentations this is not the case - it is possible to establish=20= >>> direct vehicle-to-vehicle IP-over-802.11p communications without the=20= >>> presence of a fixed 802.11p Access Point). >>>=20 >>> For another example - will IP prefer that the 802.11p channel in=20 >>> France be 176, 178 or 180? (with WiFi, IP does not care because it =20= >>> can work on any of the 11 channels equally well, but with 802.11p =20= >>> each of these three channels seem to be reserved for "Services",=20 >>> "Control" and "Services"). >>>=20 >>> For another example - is all the security on these links entirely=20 >>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>>=20 >>> I think finding consensus on some of these questions could lead to=20= >>> interoperability. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Regards, Thierry >>>>=20 >>>>=20 >>>>=20 >>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>> Given current discussions, I think it may be worth considering a=20= >>>>> work item about how to run IP over 802.11p. >>>>>=20 >>>>> One of the things to say would be whether or not this is IPv6 only=20= >>>>> or IPv4 also. >>>>>=20 >>>>> This would say how this would work _without_ GeoNetworking. >>>>>=20 >>>>> It would agree on the EtherType and/or whether there are new ones,=20= >>>>> several or only one, or reusing existing EtherTypes. >>>>>=20 >>>>> It could be as simple as to say that IP works over 802.11p just as=20= >>>>> it works over 802.11b - no modifications. >>>>>=20 >>>>> What do you think? >>>>>=20 >>>>> Alex >>>>>=20 >>>>> Le 30/01/2013 11:10, Alexandru Petrescu a =C3=A9crit : >>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>> Hi Alexandru, >>>>>>>=20 >>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>=20 >>>>>> I tend to agree that #8947 is a hexadecimal notation also because=20= >>>>>> the sharp sign preceding it, and because if it were decimal it=20 >>>>>> would convert to 22F3 which is already reserved for trill. >>>>>>=20 >>>>>> I just watend to make sure. >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Dan >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20= >>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG=20= >>>>>>>> go forward? - EtherType for ITS >>>>>>>>=20 >>>>>>>> Hello Dan, >>>>>>>>=20 >>>>>>>> Thank you for the email. >>>>>>>>=20 >>>>>>>> I think we definitely need a good interface with IEEE about=20 >>>>>>>> this. >>>>>>>>=20 >>>>>>>> Maybe you could ask them whether this number is hexa or = decimal,=20 >>>>>>>> so we know what to put in implementation (e.g. >>>>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>>>> implementations). >>>>>>>>=20 >>>>>>>> Also, I am interested to learn whether this deserves being=20 >>>>>>>> reserved at IANA. >>>>>>>>=20 >>>>>>>> Alex >>>>>>>>=20 >>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> The documents that you are referring (on the ETSI >>>>>>>>> server) are not freely accessible. A password is required, and=20= >>>>>>>>> probably only ETSI members have the access information. >>>>>>>>>=20 >>>>>>>>> The responsibility for assigning EtherType values is with the=20= >>>>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>>>> (updated daily) at=20 >>>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 > and according to this list the value 8947 is not allocated. >>>>>>>>> Now, the public listing information for EtherTypes bears a=20 >>>>>>>>> disclaimer that says >>>>>>>>>=20 >>>>>>>>> * This is a partial listing of all assigned EtherType Fields.=20= >>>>>>>>> Not >>>>>>>> all >>>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>>>=20 >>>>>>>>> Did ETSI require for this information not to be published? It=20= >>>>>>>>> does not look useful if they want to encourage = interoperability >>>>>>>>>=20 >>>>>>>>> Value 0707 mentioned in the thread is not allocated either. >>>>>>>>>=20 >>>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA). >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Dan >>>>>>>>>=20 >>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst=20 >>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>> *To:* its@ietf.org *Subject:* Re: [its] What do we need to = make=20 >>>>>>>>> ITS WG go forward? - EtherType for ITS >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Alex, >>>>>>>>>=20 >>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS = use=20 >>>>>>>>> (ETSI TC ITS's GeoNetworking). Check the following document=20 >>>>>>>>> available on the ETSI server: >>>>>>>>>=20 >>>>>>>>> ITS(13)000020 >>>>>>>>> = >>>>>>>> 2 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 > 900002 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >> 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 >>>>>>>>> 0 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 > 20_Eth >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>=20 >>>>>>>>> Regards, Thierry. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>=20 >>>>>>>>> Le 28/01/2013 14:16, Joe Klein a =C3=A9crit : >>>>>>>>>=20 >>>>>>>>> I really dislike the fact that ISO is charging for the ISO=20 >>>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>>=20 >>>>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>>>> cybersecurity and safety liability if the specification leads=20= >>>>>>>>> to deaths and damage to property? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>=20 >>>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20= >>>>>>>>> not specified by IEEE nor reserved at IANA - does not make it=20= >>>>>>>>> interoperable. >>>>>>>>>=20 >>>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by >>>>>>>> somebody >>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>=20 >>>>>>>>> (see a good example of interoperability: IPv6 0x86dd ethertype=20= >>>>>>>>> is reserved at IEEE and at IANA >>>>>>>>>=20 >>>>>>>>> = http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbe >>>>>>>>> r >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 > s.xml) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >> Alex >>>>>>>>>=20 >>>>>>>>> Or should these standards remain in >>>>>>>>>=20 >>>>>>>>> the public domain, for researches to review and validate? >>>>>>>>>=20 >>>>>>>>> Just my 2 cents. >>>>>>>>>=20 >>>>>>>>> Joe >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst=20 >>>>>>>>> = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Dear all, >>>>>>>>>=20 >>>>>>>>> At this stage, I don't think a new working group is needed.=20 >>>>>>>>> First, it would need a charter, and support from the industry.=20= >>>>>>>>> But more importantly, IETF WGs are not usually sector-driven,=20= >>>>>>>>> so it means the different issues pertaining to ITS should be=20= >>>>>>>>> brought to >>>>>>>> VARIOUS >>>>>>>>> existing WGs, and a WG should only be created if there is an=20= >>>>>>>>> important issue for which there is no existing WG that could=20= >>>>>>>>> work on it. >>>>>>>>>=20 >>>>>>>>> This said, as mentioned earlier, ITS is not only about =20 >>>>>>>>> vehicular communications, though the issues listed by =20 >>>>>>>>> Alexandru below mostly consider vehicular communications. >>>>>>>>>=20 >>>>>>>>> What ITS really needs is the definition of a common=20 >>>>>>>>> communication architecture and the definition of what features=20= >>>>>>>>> should be comprised for an IPv6 networking stack deployed for=20= >>>>>>>>> ITS use cases. This cannot be done at IETF, and actually=20 >>>>>>>>> already exists at ISO: - ISO >>>>>>>>> 21217 - Architecture - ISO 21210 - IPv6 Networking >>>>>>>>>=20 >>>>>>>>> As an input to the discussion, please consider reading =20 >>>>>>>>> documents D2.1 and D2.2 available on the ITSSv6 project web=20 >>>>>>>>> page: http://www.itssv6.eu/documentation/ >>>>>>>>> D2.2 provides an analysis of the currently published version = of=20 >>>>>>>>> ISO 21210, but new work items have been launched since then to=20= >>>>>>>>> address remaining issues. >>>>>>>>>=20 >>>>>>>>> Regards, Thierry. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =C3=A9crit : >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> All, >>>>>>>>>=20 >>>>>>>>> This is just one opinion, but I'd like to understand why ITS=20= >>>>>>>>> would need its own IETF group. The work here is the same = (IMO)=20 >>>>>>>>> as what is taking place in MANET. I would vote that this work=20= >>>>>>>>> be taken up in MANET. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Stan, >>>>>>>>>=20 >>>>>>>>> Thank you for the offer. I considered this offer since some=20= >>>>>>>>> time. >>>>>>>>>=20 >>>>>>>>> I try to understand whether some of these items on which I = have=20 >>>>>>>>> interest could be brought in in MANET WG: >>>>>>>>> - V2V using prefix exchange - VIN-based IP addressing scheme=20= >>>>>>>>> - ND Prefix Delegation - PMIP-based network mobility - IPv6=20 >>>>>>>>> single-address connecion 'sharing' with a cellular operator = and=20 >>>>>>>>> a vehicular moving network (type '64share' of v6ops). - = Default=20 >>>>>>>>> Route with DHCPv6. >>>>>>>>>=20 >>>>>>>>> Please let me know. >>>>>>>>>=20 >>>>>>>>> Yours, >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, Stan >>>>>>>>>=20 >>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Nabil, >>>>>>>>>=20 >>>>>>>>> I think we already done some steps but not sure how far now. = We=20 >>>>>>>>> will need to propose the WG and provide the WG charter, as use=20= >>>>>>>>> cases and work to be done in this group. This charter needs to=20= >>>>>>>>> be approved by the IESG. I have not attended the last meeting=20= >>>>>>>>> so not sure about the status now, >>>>>>>>>=20 >>>>>>>>> AB >>>>>>>>>=20 >>>>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi All, >>>>>>>>>=20 >>>>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>>>> previously heard to make it a working group. So what should = we=20 >>>>>>>>> exactly do, to achieve this goal ? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>> >>>>>>>>> >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi All, >>>>>>>>>=20 >>>>>>>>> I was interested in this group but not sure where are we so=20 >>>>>>>>> far. Is there progress, or is there issues/efforts that need = to=20 >>>>>>>>> be completed and volunteered. >>>>>>>>>=20 >>>>>>>>> AB _______________________________________________ its = mailing=20 >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C = **Cordialement, Regards* * * * * *=D9=86=D8=A8=D9=8A=D9=84=20 >>>>>>>>> =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88Nabil Benamar* Professor = of computer sciences Simulation=20 >>>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20= >>>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6=20= >>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>>=20 >>>>>>>>> * >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> = --------------------------------------------------------------- >>>>>>>>> - >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 > ------ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >> ---------- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> * >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>> its >>>>>>>>> mailing list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing >>>>>>>> list >>>>>>>>> its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org 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 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From sofiane.imadali.ietf@gmail.com Mon Feb 18 10:47:20 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1758121F8BCE for ; Mon, 18 Feb 2013 10:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKU6fQvxHxvP for ; Mon, 18 Feb 2013 10:47:19 -0800 (PST) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 30C5821F8B1A for ; Mon, 18 Feb 2013 10:47:18 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq12so5689168lab.5 for ; Mon, 18 Feb 2013 10:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=3Tbul7NsiydMaSHa3v/x/ByTzdEF/exrONllZvLH9Io=; b=UBJSEhNZSehHe/yvWLCHWIk4PuVH/QLifqyBGVK9A1Lk7ZaPDnzs1rr+UE4O3ZHtr4 snDcDeQSB/z68XeilUOPprN5Alz83V0eqiyaafYlqctnGgDhUnfXwtDbZea9jLq93T1u oPDLnkSBHX6IKyMdfVKdQdQAr0OfqLwphsjSJJnEKrt8E10HUibLZk75Adc2XFCVWRL+ kGeTwvqocohn7oU50aKjOI5qq7vaDka6Ww6rNRyVq56OcqnfNn5cBwGyERxry68a1Rqb IhelA+fABtq1AFwLriBT3rwLEkPzJpC0UJG7yKvG+wdLvwWgzNT60WAhuDszmsb+1zgC lzzQ== MIME-Version: 1.0 X-Received: by 10.112.50.98 with SMTP id b2mr6248657lbo.114.1361213238075; Mon, 18 Feb 2013 10:47:18 -0800 (PST) Received: by 10.152.127.6 with HTTP; Mon, 18 Feb 2013 10:47:17 -0800 (PST) Date: Mon, 18 Feb 2013 19:47:17 +0100 Message-ID: From: sofiane Imadali To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [its] Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:47:20 -0000 Hello ITS folks, I would like to announce, on behalf of the co-authors, the submission of 2 drafts relating to VIN-based IPv6 addressing. VIN stands for Vehicle Identification Number, and it is specifically used in a context of IPv6 vehicular communications. These proposals aim at providing discussion about a new mapping/conversion method from VIN to ULA prefixes (guaranteed unique) and Interface Identifiers. Please find the above mentioned documents at: 1) Vehicle Identification Number-Based IPv6 Interface Identifier (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast Addresses (VULA), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00 Your comments are welcome, Cheers, Sofiane. From Roberto.Baldessari@neclab.eu Tue Feb 19 00:25:00 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9521F8D52 for ; Tue, 19 Feb 2013 00:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWizF2or8z6T for ; Tue, 19 Feb 2013 00:24:57 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F021F8BA1 for ; Tue, 19 Feb 2013 00:24:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C6FFB1032BB; Tue, 19 Feb 2013 09:24:55 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubn5Mw3ZUJSn; Tue, 19 Feb 2013 09:24:55 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A7FD71032BE; Tue, 19 Feb 2013 09:24:35 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 09:24:14 +0100 From: Roberto Baldessari To: =?utf-8?B?RnJhbmNpc2NvIEphdmllciBSb3MgTXXDsW96?= Thread-Topic: [its] IP over 802.11p Thread-Index: AQHN/8X6j5rs2KjOqkeDe7ySghK2Xph0vJ9ggAAMZwCAA1H1wP//+HQAgAKsVCCABTEBAIABAuOQ Date: Tue, 19 Feb 2013 08:24:00 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F859F6A93E@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5 875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Alexandru Petrescu , "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:25:00 -0000 SGkgRnJhbmNpc2NvLA0KDQpJIGFncmVlIHdpdGggeW91IHRvIGtlZXAgdGhlIHNvbHV0aW9uIHNw YWNlIGJyb2FkIGZvciBJRVRGLiBJIGp1c3QgZGVzY3JpYmVkIHRoZSBhcHByb2FjaCBmb2xsb3dl ZCBieSBFVFNJLiBUaGUgcmF0aW9uYWxlIG9mIHRoZSBFVFNJIGFwcHJvYWNoIGlzIHRvIGtlZXAg SVB2NiBhcy1pcy4gQmVzaWRlcyBoYXZpbmcgYSBzaG9ydGVyIHRpbWUgdG8gbWFya2V0LCB0aGlz IGFsc28gYWxsb3dzIHRvIHJlLXVzZSBwcm92ZW4gYW5kIHdpZGUgc3ByZWFkIElQdjYgaW1wbGVt ZW50YXRpb25zIHVudG91Y2hlZC4gQW55d2F5LCB0aGlzIGdyb3VwIGlzIGZyZWUgdG8gcHJvcG9z ZSBhbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgSSBhbSBub3QgdHJ5aW5nIHRvIHN0ZWVyIHRoaXMg Z3JvdXAuIEkganVzdCB3YW50IHRoZSBwZW9wbGUgdG8gdW5kZXJzdGFuZCB0aGUgcmVhc29ucyBv ZiBjZXJ0YWluIGNob2ljZXMuDQoNCkJlc3QgcmVnYXJkcywNCg0KUm9iZXJ0bw0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJhbmNpc2NvIEphdmllciBSb3MgTXXDsW96IFtt YWlsdG86Zmpyb3NAdW0uZXNdIA0KU2VudDogMTggRmVicnVhcnkgMjAxMyAxODo1MQ0KVG86IFJv YmVydG8gQmFsZGVzc2FyaQ0KQ2M6IEFsZXhhbmRydSBQZXRyZXNjdTsgRG93ZGVsbCwgSm9objsg aXRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2l0c10gSVAgb3ZlciA4MDIuMTFwDQoNCkhpIFJv YmVydG8sDQoNCkVsIDE1LzAyLzIwMTMsIGEgbGFzIDExOjA1LCBSb2JlcnRvIEJhbGRlc3Nhcmkg ZXNjcmliacOzOg0KDQo+IEhpIEFsZXgsDQo+IA0KPj4gSSByZWFkIHRoZSBjb21tZW50LiAgV2Ug Y291bGQgZGlzY3VzcyBpdCBzZXBhcmF0ZWx5LCBpbiBhIHNlcGFyYXRlIHRocmVhZC4gIA0KPj4g QmFzaWNhbGx5LCBJIHRoaW5rIGluc2VydGluZyBnZW9ncmFwaHkgaW4gc3VjaCBpbnRlcm5hbCB3 b3JraW5ncyANCj4+IHdoaWNoIGlzIElQIGFkZHJlc3NpbmcgY2hhbmdlcyB0aGUgbmF0dXJlIG9m IHRoaXMgbGF0dGVyLCBhbmQgbWF5IA0KPj4gbG9vc2UgaXRzIHdpZGVzcHJlYWQgaW50ZXJvcGVy YWJpbGl0eS4gIEFuZCB5ZXMsIEkgc2hvdWxkIGxvb2sgZmlyc3QgYXQgaXRzIGFkdmFudGFnZXMu ICBMRXQncyBkaXNjdXNzIHNlcGFyYXRlbHkuDQo+IA0KPiBJIHRoaW5rIHRoaXMgaXMgdGhlIHJp Z2h0IHRocmVhZCB0byBkaXNjdXNzIHRoaXMgcG9pbnQuIEJ1dCB5b3UgY2FuIHJlbmFtZSB0aGUg c3ViamVjdCBpZiB5b3UgcHJlZmVyLg0KPiANCj4gV2l0aCBJUHY2IG92ZXIgR2VvTmV0d29ya2lu ZyB3ZSBkbyBub3QgbW9kaWZ5IElQdjYsIHdlIG9ubHkgdHJhbnNwb3J0IGl0LiBTbyB3ZSBhcmUg cGVyZmVjdGx5IGluIGxpbmUgd2l0aCB3aGF0IHlvdSBzYWlkIChtYXhpbWl6ZSBpbnRlcm9wZXJh YmlsaXR5KS4NCj4gVGhhdCdzIHdoeSB3ZSBtYXAgSVB2NiBtdWx0aWNhc3QgaW50byBsb3dlciBs YXllciAoR2VvTmV0d29ya2luZykgZ2VvY2FzdCBhbmQgd2UgZG8gbm90IG1ha2UgSVB2NiBnZW8t YXdhcmUuDQo+IA0KWWVzLCB0aGF0J3MgYSBwZXJmZWN0bHkgZmluZSBhcHByb2FjaC4gSG93ZXZl ciwgZW1iZWRkaW5nIGdlb2dyYXBoaWMgaW5mb3JtYXRpb24gd2l0aGluIElQdjYgaXMgdGVjaG5p Y2FsbHkgcG9zc2libGUgYW5kIGludGVyb3BlcmFiaWxpdHkgaXNuJ3QgYnJva2VuLiBXZSBpbXBs ZW1lbnRlZCBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXMgc29tZSB5ZWFycyBhZ28gYnkgZXhw bG9pdGluZyBob3AtYnktaG9wIGV4dGVuc2lvbiBoZWFkZXJzLiBBZHZhbnRhZ2VzOiBubyBuZWVk IGZvciB0dW5uZWxpbmcsIG5vIG5lZWQgZm9yIGdhdGV3YXlzIGJldHdlZW4gdGhlIHZlaGljdWxh ciBuZXR3b3JrIGFuZCB0aGUgSW50ZXJuZXQsIGFuZCBzdGFuZGFyZCBJUHY2IG5vZGVzIGNhbiBy ZWNlaXZlIGFuZCBwcm9jZXNzIChtYXliZSByb3V0ZT8pIHRoZSBtZXNzYWdlLiBPZiBjb3Vyc2Ug dGhlcmUgYXJlIGRpc2FkdmFudGFnZXMgdG9vLg0KDQpBbHNvLCBJIGNhbid0IHNlZSB3aHkgdGhp cyB3b3VsZCBicmVhayBpbnRlcm5hbCB3b3JraW5nIG9mIElQIChhdCBsZWFzdCBubyBtb3JlIHRo YW4gQU9EViwgRFNSLCBvciBhbnkgb3RoZXIgTUFORVQgcmVhY3RpdmUgcHJvdG9jb2wgZG9lcyku IFJvdXRpbmcgdGFibGUgbG9va3VwcyBhcmUgcGVyZm9ybWVkIGFzIHVzdWFsLiBXaGVuIGFuIGVu dHJ5IGlzIG5vdCBmb3VuZCwgdGhlIHJvdXRpbmcgcHJvdG9jb2wgaXMgaW52b2tlZCB0byBmaW5k IG9uZS4gRm9yIHVuaWNhc3QgKG11bHRpY2FzdCkgY29tbXVuaWNhdGlvbnMgdGhlIHJvdXRpbmcg dGFibGUgKE9JTCkgaXMgdXBkYXRlZC4gVGhlbiwgdGhlIG1lc3NhZ2UgaXMgZm9yd2FyZGVkIChv ciBkcm9wcGVkIGlmIG5vIGVudHJ5IG1hdGNoZXMpLg0KDQpJJ20gbm90IGFyZ3VpbmcgdGhhdCB0 aGlzIHNvbHV0aW9uIGlzIGJldHRlciB0aGFuIHRoZSBHZW9OZXR3b3JraW5nIHdheS4gSnVzdCB3 YW50ZWQgdG8gbm90ZSB0aGF0IHRoZSBzb2x1dGlvbiBzcGFjZSBjb3VsZCBiZSBicm9hZGVyIHRo YW4gdGhlIG9uZSB0aGlzIHRocmVhZCBpcyBhc3N1bWluZy4NCg0KQmVzdCwNCmZyYW4NCg0KPiBB Y3R1YWxseSwgYXQgdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoaXMgZ3JvdXAncyBkaXNjdXNzaW9u LCBJIGFza2VkIGlmIHRoZSBncm91cCBjb3VsZCByZXZpZXcgdGhlIEVUU0kgSVB2NiBvdmVyIEdl b05ldHdvcmtpbmcgc3RhbmRhcmQuIEl0IHdvdWxkIGhhdmUgYmVlbiB1c2VmdWwgdG8gcmVjZWl2 ZSBzb21lIElFVEYgaW5wdXQuIFdlIGhhdmUgbm93IHN1Ym1pdHRlZCBhbiB1cGRhdGUgd2l0aGlu IEVUU0kgSVRTLiBJZiBhcHByb3ZlZCwgaXQgd2lsbCBiZSBwdWJsaXNoZWQgc29vbiAoPCAxIG1v bnRoKS4gTm90ZSB0aGF0IHBlb3BsZSB3aG8gYWxzbyBwYXJ0aWNpcGF0ZShkKSBpbiBJRVRGIGNv bnRyaWJ1dGVkIHRvIHRoZSBFVFNJIHN0YW5kYXJkLiBTbywgSSB3b3VsZCBub3QgdGFsayBhYm91 dCBJRVRGL0VUU0kgYXMgdHdvIHNlcGFyYXRlIHdvcmxkcy4gUmF0aGVyLCB3aGF0IGlzIG1pc3Np bmcgaXMgc29tZSBvZmZpY2lhbC9zdHJ1Y3R1cmVkIGNvb3BlcmF0aW9uIHRvIGJ1aWxkIG9uIGVh Y2ggb3RoZXIncyBleHBlcnRpc2Uvc3RhbmRhcmRzLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiAN Cj4gUm9iZXJ0bw0KPiANCj4gDQo+IA0KPj4gDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiANCj4+IFJv YmVydG8NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gRnJvbTogaXRzLWJvdW5jZXNAaWV0Zi5vcmcgDQo+PiBbbWFpbHRvOml0 cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleGFuZHJ1IFBldHJlc2N1IFNlbnQ6 DQo+PiAxMSBGZWJydWFyeSAyMDEzIDE2OjMwIFRvOiBEb3dkZWxsLCBKb2huIENjOiBpdHNAaWV0 Zi5vcmcgU3ViamVjdDoNCj4+IFJlOiBbaXRzXSBJUCBvdmVyIDgwMi4xMXANCj4+IA0KPj4gTGUg MTEvMDIvMjAxMyAxNDo1MCwgRG93ZGVsbCwgSm9obiBhIMOpY3JpdCA6DQo+Pj4gQWxleA0KPj4+ IA0KPj4+IElzIGFueW9uZSBtYWtpbmcgODAyLjExcCByYWRpb3MgY29tbWVyY2lhbGx5IGF0IHJl YXNvbmFibGUgY29zdD8NCj4+PiBUaGUgZmV3IEkgaGF2ZSBzZWVuIHNlZW0gdG8gYmUgdmVyeSBl eHBlbnNpdmUgKGZldyBrJCkgYW5kIHRoZXJlIA0KPj4+IGFwcGVhcnMgdG8gYmUgbGl0dGxlIHN1 cHBvcnQgaW4gTGludXguIDgwMi4xMXMgb24gdGhlIG90aGVyIGhhbmQgaXMgDQo+Pj4gYXZhaWxh YmxlIG9uIHN0YW5kYXJkIFdpLUZpIGRvbmdsZXMgKGZyb20gJDE1KSBhbmQgZHJpdmVycyBhcmUg DQo+Pj4gYWxyZWFkeSBhdmFpbGFibGUgaW4gTGludXguIElzIGl0IGNvcnJlY3QgdGhhdCA4MDIu MTFwIGlzIG1hbmRhdGVkIA0KPj4+IGZvciBJVFMgaW4gc29tZSByZWdpb25zPw0KPj4gDQo+PiBK b2huLA0KPj4gDQo+PiBXaXRob3V0IGFkdmVydGlzaW5nLCB3ZSB1c2UgZmluYWxpemVkIDgwMi4x MXAgaGFyZHdhcmUgKE9CVSwgUlNVLA0KPj4gZXRjLikgYW5kIHN1cHBvcnQgZnJvbSBJVFJJIFRh aXdhbi4gIFRoZSBjb21wbGV0ZSBwYWNrYWdlIChkcml2ZXJzLCANCj4+IGdlb25ldHdvcmtpbmcs IFNES3MpIGlzIGV4cGVuc2l2ZSB5ZXMgaW4gdGhlIHJhbmdlIG9mIHRob3VzYW5kcyBvZiANCj4+ IFVTRG9sbGFycy4NCj4+IA0KPj4gVGhpcyB1c2VzIE1pbmlQQ0kgODAyLjExcCBjYXJkcyBmcm9t IFVuZXggVGVjaG5vbG9neSBlLmcuDQo+PiBodHRwOi8vdW5leC5jb20udHcvZHNyYy13YXZlIHdo aWNoIGNvdWxkIGJlIGluc2VydGVkIGluIG90aGVyIA0KPj4gbm9uLUlUUkkgUEMtbGlrZSBwbGF0 Zm9ybXMuICBJIGJlbGlldmUgdGhlc2UgY2FyZHMgbWF5IGJlIHJlbGF0aXZlbHkgIA0KPj4gY2hl YXAuICBJIGRvbid0IGtub3cgd2hldGhlciBVbmV4IG9mZmVyIGRyaXZlcnMgZm9yIHRoZXNlIGNh cmRzIChiZSAgDQo+PiB0aGVtIGJpbmFyeSBvciBvcGVuIHNvdXJjZSksIHdlIHVzZSB0aGUgYmlu YXJ5IGRyaXZlcnMgZnJvbSBJVFJJLg0KPj4gDQo+PiBJIHRoaW5rIHllcywgdGhlcmUgc2VlbSB0 byBiZSBsaXR0bGUgaWYgYW55IG9wZW4gc291cmNlIEdQTCBkcml2ZXIgDQo+PiBzdXBwb3J0IGlu IGxpbnV4IGZvciA4MDIuMTFwLiAgSSBhbSBpbnRlcmVzdGVkIHRvIGxlYXJuIGlmIHRoaXMgDQo+ PiBleGlzdHMgc29tZXdoZXJlLCBldmVuIGluIGEgcHJvdG90eXBpY2FsIGZvcm0uICBXZSdyZSBv bmx5IGF3YXJlIG9mIA0KPj4gU1BJVFMgcHJvamVjdCwgYnV0IHdlcmUgbm90IHZlcnkgc3VjY2Vz c2Z1bCBhdCB0cnlpbmcgaXQuDQo+PiANCj4+IE9uZSBhZHZhbnRhZ2Ugb2YgLnAgaXMgdGhhdCBp dCBpcyByZWd1bGF0ZWQgc3VjaCBhcyBubyBuZWVkIHRvIHBheSBhIA0KPj4gbGljZW5zZSBhbmQg c3RpbGwgYWxsb3dlZCB0byBlbWl0IGF0IGhpZ2ggcG93ZXIgbGV2ZWxzICgzM2RCbSBFVSwgDQo+ PiA0MGRCbSBVUywgY29tcGFyZWQgdG8gaHVuZHJlZHMgb2YgbWlsbGlXYXRzIGZvciBXaUZpKS4g IEkuZS4gaXQgaXMgDQo+PiBwb3NzaWJsZSB0byBoYXZlIHR3byBpbmRlcGVuZGVudCB2ZWhpY2xl cyBkaXN0YW5jZWQgYnkga2lsb21ldGVycywgDQo+PiB3aXRob3V0IGluZnJhc3RydWN0dXJlLCBh bmQgY29tbXVuaWNhdGUsIGFuZCB3aXRob3V0IHJlcXVpcmluZyANCj4+IGxpY2Vuc2UgZnJvbSBn b3Zlcm5tZW50ICh3aGVyZWFzIGluIHRoZSBjYXNlIG9mIFdpRmkgb25lIGNhbid0IA0KPj4gbGVn YWxseSBkbyBtb3JlIHRoYW4gYSBodW5kcmVkIG1ldGVycyBvciBzbykuDQo+PiANCj4+IEkgYW0g bm90IHN1cmUgdGhpcyBpcyB0aGUgY2FzZSBmb3IgLnMoPykgIENvdWxkIC5zIHVzZSBoaWdoIHBv d2VyIA0KPj4gbGV2ZWxzIGxpa2UgRUlSUCA0MGRCbSBhbmQgd2l0aG91dCBsaWNlbnNlPw0KPj4g DQo+PiANCj4+IFRoZW4sDQo+PiANCj4+IEkgdGhpbmsgeWVzIDgwMi4xMXAgaXMgbWFuZGF0ZWQg Zm9yIElUUyBpbiBFdXJvcGUgYnkgRVRTSSBJVFMuDQo+PiANCj4+IEJ1dCB1bmZvcnR1bnRhbHkg Zm9yIG1lLCB0aGUgc2l0dWF0aW9uIGluIHRoZSBjb3VudHJ5IEkgbGl2ZSAoRnJhbmNlKSANCj4+ IHNlZW1zIHRvIGJlIHRoYXQgb25lIGlzIG5vdCBhbGxvd2VkIHRvIHVzZSBJUC1vdmVyLTgwMi4x MXAgd2l0aG91dCANCj4+IGdlb25ldHdvcmtpbmcgKGkuZS4gbm90IGFsbG93ZWQgdG8gdXNlIHRo ZSBmcmVxdWVuY2llcyBhbGxvY2F0ZWQgdG8gDQo+PiBJVFMgZm9yIDgwMi4xMXAgd2l0aG91dCB1 c2luZyBFVFNJIElUUyBpLmUuIGdlb25ldHdvcmtpbmcpLg0KPj4gDQo+PiBUaGVzZSBmYWN0b3Jz IHNlZW0gdG8gc3Ryb25nbHkgaGFtcGVyIHRoZSBkZXZlbG9wbWVudCBvZiB2ZWhpY3VsYXIgDQo+ PiBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIHRlY2hub2xvZ3kgYXQgSUVURjogLSBsYWNrIG9mIG9w ZW4tc291cmNlIA0KPj4gZHJpdmVyIGNvZGVzIGZvciA4MDIuMTFwIC0gbGFjayBvZiBvcGVuIGFu ZCBmcmVlLW9mLWNoYXJnZSBhY2Nlc3MgdG8gDQo+PiBFVFNJIHN0YW5kYXJkcyAtIGxhY2sgb2Yg b3BlbiBhY2Nlc3MgdG8gRVRTSSBpbnRlcm9wZXJhYmlsaXR5IHJlc3VsdHMNCj4+IC0gbGFjayBv ZiBjaGVhcCBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnMgb2YgODAyLjExcCAtIGxhY2sgb2YgDQo+ PiB1bnJlZ3VsYXRlZC91bmxpY2Vuc2VkIGZyZXF1ZW5jeSBhbGxvY2F0ZWQgZm9yIElQLW92ZXIt ODAyMTFwIGZvciANCj4+IGxvbmcgcmFuZ2UuIC0gdGVjaG5pY2FsIG1pc3VuZGVyc3RhbmRpbmcg YmV0d2VlbiB0aGUgRVRTSSBwb2ludCBvZiANCj4+IHZpZXcgb2Ygd2hhdCBpcyBJUCBhbmQgdGhl IElFVEYgb2Ygc2FtZS4NCj4+IA0KPj4gQWx0aG91Z2ggSSBtYXkgc291bmQgcmVsYXRpdmVseSBw ZXNzaW1pc3RpYywgSSBhbHNvIGNvbnNpZGVyIEkgbWF5IGJlIA0KPj4gd3JvbmcgaW4gbXkgcmVh c29uaW5nIGFib3ZlLg0KPj4gDQo+PiBBbGV4DQo+PiANCj4+PiANCj4+PiBKb2huDQo+Pj4gDQo+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogaXRzLWJvdW5jZXNAaWV0Zi5vcmcg DQo+Pj4gW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRy dSBQZXRyZXNjdQ0KPj4+IFNlbnQ6IDMxIEphbnVhcnkgMjAxMyAxNToxNyBUbzogaXRzQGlldGYu b3JnIFN1YmplY3Q6IFJlOiBbaXRzXSBJUCANCj4+PiBvdmVyIDgwMi4xMXANCj4+PiANCj4+PiBM ZSAzMS8wMS8yMDEzIDE0OjQ3LCBUaGllcnJ5IEVybnN0IGEgw6ljcml0IDoNCj4+Pj4gDQo+Pj4+ IFdlbGwsIHdlIGRvIGFjdHVhbGx5IHJ1biBJUHY2IG92ZXIgMTFwICh3aXRoIG9yIHdpdGhvdXQg DQo+Pj4+IEdlb05ldHdvcmtpbmcpLCBzbyBJIGRvbid0IHNlZSB3aGF0IGtpbmQgb2YgaXNzdWVz IHRoZXJlIG1pZ2h0IGJlIA0KPj4+PiAuLi4NCj4+PiANCj4+PiBJIGhhdmUgc29tZSBjbGFyaWZp Y2F0aW9uIHF1ZXN0aW9ucyBhYm91dCBFdGhlclR5cGUgYW5kIDgwMi4xMXAgYW5kIA0KPj4+IEdl b05ldHdvcmtpbmcuDQo+Pj4gDQo+Pj4gSSBndWVzcyB3aGVuIHlvdSBydW4gSVB2NiBvdmVyIDEx cCB3aXRoIEdlb05ldHdvcmtpbmcsIHRoZSBFdGhlcm5ldCANCj4+PiBoZWFkZXIgdXNlcyBFdGhl clR5cGUgc29vbi10by1iZS0weDg5NDcsIHdoZXJlYXMgd2hlbiB5b3UgcnVuIElQdjYgDQo+Pj4g b3ZlciAxMXAgd2l0aG91dCBHZW9OZXR3b3JraW5nLCB0aGUgRXRoZXJuZXQgaGVhZGVyIHVzZXMg RXRoZXJUeXBlIA0KPj4+IDB4ODZERC4gVGhpcyBpcyBqdXN0IGEgc3VwcG9zaXRpb24sIEkgZG9u J3Qga25vdyBob3cgeW91IHJ1biBpdC4NCj4+PiANCj4+PiBBbHNvLCBpZiBJIHJ1biBJUHY0IG92 ZXIgMTFwIHdpdGggR2VvTmV0d29ya2luZyAtIHNob3VsZCBJIHVzZSANCj4+PiBFdGhlclR5cGUg c29vbi10by1iZS0weDg5NDc/ICBPciBvdGhlcj8gIEkgc3VwcG9zZSB0aGF0IGlmIEkgcnVuDQo+ Pj4gSVB2NCBvdmVyIDExcCB3aXRob3V0IEdlb05ldHdvcmtpbmcgSSBzaG91bGQgdXNlIEV0aGVy VHlwZSAweDA4MDAsIA0KPj4+IGFuZCBpZiBpdCdzIEFSUCBvdmVyIDgwMi4xMXAgc3RpbGwgd2l0 aG91dCBHZW9OZXR3b3JraW5nIHRoZW4gSSANCj4+PiBzaG91bGQgdXNlIEV0aGVyVHlwZSAweDA4 MDYuDQo+Pj4gDQo+Pj4gKHRoZSBsZXR0ZXIgd2UndmUgc2VlbiByZWNlbnRseSBpcyBub3QgY2xl YXIgd2hldGhlciB0aGF0IGFsbG9jYXRpb24gDQo+Pj4gaXMgZm9yIEdlb05ldHdvcmtpbmcsIGZv ciBJUC1vdmVyLTgwMi4xMXAsIGZvciBFVFNJIElUUywgZm9yIA0KPj4+IEdlb05ldHdvcmtpbmcg Zm9yIElQdjYsIGZvciBHZW9OZXR3b3JraW5nIGZvciBJUHY0LCBldGMuIEl0IGlzIG5vdCANCj4+ PiBjbGVhciBlaXRoZXIgd2hldGhlciBHZW9OZXR3b3JraW5nIHN1cHBvcnRzIElQdjQgb3Igbm90 LCBvciB1bmRlciANCj4+PiB3aGF0IGZvcm0pLg0KPj4+IA0KPj4+IEkgYWxzbyBoYXZlIHNvbWUg cXVlc3Rpb25zIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgbmF0dXJlIA0KPj4+ IG9mIHNvbWUgODAyLjExcCBsaW5rcyAobm8gRVNTSUQsIGFic2VuY2Ugb2YgbGluay1sYXllciBz ZWN1cml0eSAtIGFzIA0KPj4+IG9wcG9zZWQgdG8gV2lGaSB3aGljaCBoYXMgRVNTSUQgYW5kIGxp bmstbGF5ZXINCj4+PiBzZWN1cml0eSkgYW5kIElQLg0KPj4+IA0KPj4+IEZvciBleGFtcGxlIC0g d2lsbCBWMlYgcHJlZml4IGV4Y2hhbmdlIHVzaW5nIFJvdXRlciBBZHZlcnRpc2VtZW50cyANCj4+ PiB3b3JrIGVhc2llciBvbiA4MDIuMTFwIGxpbmtzIChlYXNpZXIgdGhhbiBvbiBXaUZpKSwgYmVj YXVzZSB0aGUgDQo+Pj4gRVNTSUQgZG9lcyBub3QgbmVlZCB0byBiZSBkaXNjb3ZlcmVkLCB0aGUg YWQtaG9jIG5ldHdvcmsgZG9lcyBub3QgDQo+Pj4gbmVlZCB0byBiZSBmb3JtZWQgLSBzdWZmaWNl cyBpdCB0byBzZW5kIHBhY2tldHMgb24gYSBjZXJ0YWluIGNoYW5uZWwuDQo+Pj4gDQo+Pj4gKGlu IGEgVjJWIGRyYWZ0IG9uZSBzZWVtcyB0byBzYXkgdGhhdCB0aGUgcHJlc2VuY2Ugb2YgQWNjZXNz IFBvaW50IA0KPj4+IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5IGluIG9yZGVyIGZvciA4MDIuMTFw IHRvIHdvcms7IGJ1dCBpbiBvdXIgDQo+Pj4gZXhwZXJpbWVudGF0aW9ucyB0aGlzIGlzIG5vdCB0 aGUgY2FzZSAtIGl0IGlzIHBvc3NpYmxlIHRvIGVzdGFibGlzaCANCj4+PiBkaXJlY3QgdmVoaWNs ZS10by12ZWhpY2xlIElQLW92ZXItODAyLjExcCBjb21tdW5pY2F0aW9ucyB3aXRob3V0IHRoZSAN Cj4+PiBwcmVzZW5jZSBvZiBhIGZpeGVkIDgwMi4xMXAgQWNjZXNzIFBvaW50KS4NCj4+PiANCj4+ PiBGb3IgYW5vdGhlciBleGFtcGxlIC0gd2lsbCBJUCBwcmVmZXIgdGhhdCB0aGUgODAyLjExcCBj aGFubmVsIGluIA0KPj4+IEZyYW5jZSBiZSAxNzYsIDE3OCBvciAxODA/ICh3aXRoIFdpRmksIElQ IGRvZXMgbm90IGNhcmUgYmVjYXVzZSBpdCANCj4+PiBjYW4gd29yayBvbiBhbnkgb2YgdGhlIDEx IGNoYW5uZWxzIGVxdWFsbHkgd2VsbCwgYnV0IHdpdGggODAyLjExcCANCj4+PiBlYWNoIG9mIHRo ZXNlIHRocmVlIGNoYW5uZWxzIHNlZW0gdG8gYmUgcmVzZXJ2ZWQgZm9yICJTZXJ2aWNlcyIsIA0K Pj4+ICJDb250cm9sIiBhbmQgIlNlcnZpY2VzIikuDQo+Pj4gDQo+Pj4gRm9yIGFub3RoZXIgZXhh bXBsZSAtIGlzIGFsbCB0aGUgc2VjdXJpdHkgb24gdGhlc2UgbGlua3MgZW50aXJlbHkgDQo+Pj4g cmVsYXlpbmcgb24gSVAgbGF5ZXIgc2VjdXJpdHkgKElQc2VjLCBTZU5ELCBFQVAsIFBBTkEpPw0K Pj4+IA0KPj4+IEkgdGhpbmsgZmluZGluZyBjb25zZW5zdXMgb24gc29tZSBvZiB0aGVzZSBxdWVz dGlvbnMgY291bGQgbGVhZCB0byANCj4+PiBpbnRlcm9wZXJhYmlsaXR5Lg0KPj4+IA0KPj4+IEFs ZXgNCj4+PiANCj4+Pj4gDQo+Pj4+IFJlZ2FyZHMsIFRoaWVycnkNCj4+Pj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gT24gMzEvMDEvMTMgMTM6NTUsIEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCj4+ Pj4+IEdpdmVuIGN1cnJlbnQgZGlzY3Vzc2lvbnMsIEkgdGhpbmsgaXQgbWF5IGJlIHdvcnRoIGNv bnNpZGVyaW5nICBhIA0KPj4+Pj4gd29yayBpdGVtIGFib3V0IGhvdyB0byBydW4gSVAgb3ZlciA4 MDIuMTFwLg0KPj4+Pj4gDQo+Pj4+PiBPbmUgb2YgdGhlIHRoaW5ncyB0byBzYXkgd291bGQgYmUg d2hldGhlciBvciBub3QgdGhpcyBpcyBJUHY2IG9ubHkgDQo+Pj4+PiBvciBJUHY0IGFsc28uDQo+ Pj4+PiANCj4+Pj4+IFRoaXMgd291bGQgc2F5IGhvdyB0aGlzIHdvdWxkIHdvcmsgX3dpdGhvdXRf IEdlb05ldHdvcmtpbmcuDQo+Pj4+PiANCj4+Pj4+IEl0IHdvdWxkIGFncmVlIG9uIHRoZSBFdGhl clR5cGUgYW5kL29yIHdoZXRoZXIgdGhlcmUgYXJlIG5ldyBvbmVzLCANCj4+Pj4+IHNldmVyYWwg b3Igb25seSBvbmUsIG9yIHJldXNpbmcgZXhpc3RpbmcgRXRoZXJUeXBlcy4NCj4+Pj4+IA0KPj4+ Pj4gSXQgY291bGQgYmUgYXMgc2ltcGxlIGFzIHRvIHNheSB0aGF0IElQIHdvcmtzIG92ZXIgODAy LjExcCBqdXN0IGFzIA0KPj4+Pj4gaXQgd29ya3Mgb3ZlciA4MDIuMTFiIC0gbm8gbW9kaWZpY2F0 aW9ucy4NCj4+Pj4+IA0KPj4+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+Pj4+PiANCj4+Pj4+IEFs ZXgNCj4+Pj4+IA0KPj4+Pj4gTGUgMzAvMDEvMjAxMyAxMToxMCwgQWxleGFuZHJ1IFBldHJlc2N1 IGEgw6ljcml0IDoNCj4+Pj4+PiBMZSAzMC8wMS8yMDEzIDExOjA0LCBSb21hc2NhbnUsIERhbiAo RGFuKSBhIMOpY3JpdCA6DQo+Pj4+Pj4+IEhpIEFsZXhhbmRydSwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IElFRUUgdGFsayBvbmx5IGhleGEgaW4gdGhlaXIgRXRoZXJ0eXBlIGZpbGVzLg0KPj4+Pj4+IA0K Pj4+Pj4+IEkgdGVuZCB0byBhZ3JlZSB0aGF0ICM4OTQ3IGlzIGEgaGV4YWRlY2ltYWwgbm90YXRp b24gYWxzbyBiZWNhdXNlIA0KPj4+Pj4+IHRoZSBzaGFycCBzaWduIHByZWNlZGluZyBpdCwgYW5k IGJlY2F1c2UgaWYgaXQgd2VyZSBkZWNpbWFsIGl0IA0KPj4+Pj4+IHdvdWxkIGNvbnZlcnQgdG8g MjJGMyB3aGljaCBpcyBhbHJlYWR5IHJlc2VydmVkIGZvciAgdHJpbGwuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gSSBqdXN0IHdhdGVuZCB0byBtYWtlIHN1cmUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWxleA0KPj4+ Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERhbg0K Pj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGl0cy1ib3VuY2VzQGlldGYub3JnIA0KPj4+Pj4+Pj4g W21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRydSBQZXRy ZXNjdQ0KPj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDEzIDEyOjAwIFBN IFRvOg0KPj4+Pj4+Pj4gaXRzQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbaXRzXSBXaGF0IGRvIHdl IG5lZWQgdG8gbWFrZSBJVFMgV0cgDQo+Pj4+Pj4+PiBnbyBmb3J3YXJkPyAtIEV0aGVyVHlwZSBm b3IgSVRTDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEhlbGxvIERhbiwNCj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gVGhhbmsgeW91IGZvciB0aGUgZW1haWwuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEkgdGhpbmsg d2UgZGVmaW5pdGVseSBuZWVkIGEgZ29vZCBpbnRlcmZhY2Ugd2l0aCBJRUVFIGFib3V0IA0KPj4+ Pj4+Pj4gdGhpcy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTWF5YmUgeW91IGNvdWxkIGFzayB0aGVt IHdoZXRoZXIgdGhpcyBudW1iZXIgaXMgaGV4YSBvciANCj4+Pj4+Pj4+IGRlY2ltYWwsIHNvIHdl IGtub3cgd2hhdCB0byBwdXQgaW4gaW1wbGVtZW50YXRpb24gKGUuZy4NCj4+Pj4+Pj4+IHdpcmVz aGFyayBwYWNrZXQgYW5hbHl6ZXJzLCBhbmQgODAyLjExcC9ldHNpLWl0cyANCj4+Pj4+Pj4+IGlt cGxlbWVudGF0aW9ucykuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFsc28sIEkgYW0gaW50ZXJlc3Rl ZCB0byBsZWFybiB3aGV0aGVyIHRoaXMgZGVzZXJ2ZXMgYmVpbmcgDQo+Pj4+Pj4+PiByZXNlcnZl ZCBhdCBJQU5BLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBBbGV4DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IExlIDMwLzAxLzIwMTMgMTA6NDksIFJvbWFzY2FudSwgRGFuIChEYW4pIGEgw6ljcml0IDoNCj4+ Pj4+Pj4+PiBIaSwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUaGUgZG9jdW1lbnRzIHRoYXQgeW91 IGFyZSByZWZlcnJpbmcgKG9uIHRoZSBFVFNJDQo+Pj4+Pj4+Pj4gc2VydmVyKSBhcmUgbm90IGZy ZWVseSBhY2Nlc3NpYmxlLiBBIHBhc3N3b3JkIGlzIHJlcXVpcmVkLCBhbmQgDQo+Pj4+Pj4+Pj4g cHJvYmFibHkgb25seSBFVFNJIG1lbWJlcnMgaGF2ZSB0aGUgYWNjZXNzIGluZm9ybWF0aW9uLg0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoZSByZXNwb25zaWJpbGl0eSBmb3IgYXNzaWduaW5nIEV0 aGVyVHlwZSB2YWx1ZXMgaXMgd2l0aCB0aGUgDQo+Pj4+Pj4+Pj4gSUVFRSBSZWdpc3RyYXRpb24g QXV0aG9yaXR5LiBUaGV5IG1haW50YWluIGEgcHVibGljIGxpc3QgDQo+Pj4+Pj4+Pj4gKHVwZGF0 ZWQgZGFpbHkpIGF0IA0KPj4+Pj4+Pj4+IGh0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZGV2ZWxv cC9yZWdhdXRoL2V0aGVydHlwZS9ldGgudHh0DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+PiANCj4gYW5kIGFjY29yZGluZyB0byB0aGlzIGxpc3QgdGhlIHZhbHVlIDg5NDcg aXMgbm90IGFsbG9jYXRlZC4NCj4+Pj4+Pj4+PiBOb3csIHRoZSBwdWJsaWMgbGlzdGluZyBpbmZv cm1hdGlvbiBmb3IgRXRoZXJUeXBlcyBiZWFycyBhIA0KPj4+Pj4+Pj4+IGRpc2NsYWltZXIgdGhh dCBzYXlzDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gKiBUaGlzIGlzIGEgcGFydGlhbCBsaXN0aW5n IG9mIGFsbCBhc3NpZ25lZCBFdGhlclR5cGUgRmllbGRzLiANCj4+Pj4+Pj4+PiBOb3QNCj4+Pj4+ Pj4+IGFsbA0KPj4+Pj4+Pj4+IHJlY2lwaWVudHMgd2lzaCB0byBwdWJsaXNoIHRoZWlyIGFzc2ln bm1lbnQgYXQgdGhpcyB0aW1lLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IERpZCBFVFNJIHJlcXVp cmUgZm9yIHRoaXMgaW5mb3JtYXRpb24gbm90IHRvIGJlIHB1Ymxpc2hlZD8gSXQgDQo+Pj4+Pj4+ Pj4gZG9lcyBub3QgbG9vayB1c2VmdWwgaWYgdGhleSB3YW50IHRvIGVuY291cmFnZSANCj4+Pj4+ Pj4+PiBpbnRlcm9wZXJhYmlsaXR5DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVmFsdWUgMDcwNyBt ZW50aW9uZWQgaW4gdGhlIHRocmVhZCBpcyBub3QgYWxsb2NhdGVkIGVpdGhlci4NCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiBMZXQgbWUga25vdyBpZiBJIGNhbiBoZWxwIChhcyBJRVRGIGxpYWlzb24g dG8gdGhlIElFRUUtU0EpLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gRGFuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gKkZyb206Kml0cy1ib3Vu Y2VzQGlldGYub3JnDQo+Pj4+Pj4+Pj4gW21haWx0bzppdHMtYm91bmNlc0BpZXRmLm9yZ10gKk9u IEJlaGFsZiBPZiAqVGhpZXJyeSBFcm5zdA0KPj4+Pj4+Pj4+ICpTZW50OiogV2VkbmVzZGF5LCBK YW51YXJ5IDMwLCAyMDEzIDExOjExIEFNDQo+Pj4+Pj4+Pj4gKlRvOiogaXRzQGlldGYub3JnICpT dWJqZWN0OiogUmU6IFtpdHNdIFdoYXQgZG8gd2UgbmVlZCB0byANCj4+Pj4+Pj4+PiBtYWtlIElU UyBXRyBnbyBmb3J3YXJkPyAtIEV0aGVyVHlwZSBmb3IgSVRTDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gQWxleCwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJRUVFIGhhdmUgYXNz aWduZWQgRXRoZXJuZXQgVHlwZSBGaWVsZCBudW1iZXIgIzg5NDcgZm9yIElUUyANCj4+Pj4+Pj4+ PiB1c2UgKEVUU0kgVEMgSVRTJ3MgR2VvTmV0d29ya2luZykuIENoZWNrIHRoZSBmb2xsb3dpbmcg DQo+Pj4+Pj4+Pj4gZG9jdW1lbnQgYXZhaWxhYmxlIG9uIHRoZSBFVFNJIHNlcnZlcjoNCj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+PiBJVFMoMTMpMDAwMDIwDQo+Pj4+Pj4+Pj4gPGh0dHA6Ly9kb2Nib3gu ZXRzaS5vcmcvSVRTL0lUUy8wNS1DT05UUklCVVRJT05TLzIwMTMvSVRTJTI4MTMNCj4+Pj4+Pj4+ PiAlDQo+Pj4+Pj4+Pj4gMg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IA0KPiA5MDAwMDINCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4gMF9FdGhlcm5l dF9UeXBlX0ZpZWxkX251bWJlcl9mb3JfR2VvTmV0d29ya2luZy5wZGY+DQo+Pj4+Pj4+Pj4gRXRo ZXJuZXQgVHlwZSBGaWVsZCBudW1iZXIgZm9yIEdlb05ldHdvcmtpbmcNCj4+Pj4+Pj4+PiBodHRw Oi8vZG9jYm94LmV0c2kub3JnL0lUUy9JVFMvMDUtQ09OVFJJQlVUSU9OUy8yMDEzL0lUUygxMykw MA0KPj4+Pj4+Pj4+IDANCj4+Pj4+Pj4+PiAwDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+IDIwX0V0aA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+ PiBlcm5ldF9UeXBlX0ZpZWxkX251bWJlcl9mb3JfR2VvTmV0d29ya2luZy5wZGYNCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiBSZWdhcmRzLCBUaGllcnJ5Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+IE9uIDI4LzAxLzEzIDE0OjI4LCBBbGV4YW5kcnUgUGV0cmVzY3Ugd3JvdGU6DQo+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTGUgMjgvMDEvMjAxMyAxNDoxNiwgSm9lIEtsZWluIGEgw6lj cml0IDoNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJIHJlYWxseSBkaXNsaWtlIHRoZSBmYWN0IHRo YXQgSVNPIGlzIGNoYXJnaW5nIGZvciB0aGUgIElTTw0KPj4+Pj4+Pj4+IDIxMjE3IC0gQXJjaGl0 ZWN0dXJlICYgSVNPIDIxMjEwIC0gSVB2NiBOZXR3b3JraW5nLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+IERvZXMgdGhpcyBtYWtlIGl0IGFueSBiZXR0ZXI/IFNhZmVyPyAgU2hvdWxkIElTTyBub3cg aGF2ZSANCj4+Pj4+Pj4+PiBjeWJlcnNlY3VyaXR5IGFuZCBzYWZldHkgbGlhYmlsaXR5IGlmIHRo ZSBzcGVjaWZpY2F0aW9uIGxlYWRzIA0KPj4+Pj4+Pj4+IHRvIGRlYXRocyBhbmQgZGFtYWdlIHRv IHByb3BlcnR5Pw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IERvZXMgaXQgbWFr ZSBhbnkgYmV0dGVyIGludGVyb3BlcmFibGUgYXMgd2VsbD8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ PiBFdGhlclR5cGUgMHgwNzA3IGRlc2NyaWJlZCBpbiBJVFMgZG9jdW1lbnRzLCBpbXBsZW1lbnRl ZCwgYnV0IA0KPj4+Pj4+Pj4+IG5vdCBzcGVjaWZpZWQgYnkgSUVFRSBub3IgcmVzZXJ2ZWQgYXQg IElBTkEgLSBkb2VzIG5vdCBtYWtlIGl0IA0KPj4+Pj4+Pj4+IGludGVyb3BlcmFibGUuDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gT25lIHdvdWxkbid0IHRoaW5rIHRoYXQgdGhpcyAweDA3MDcgZXRo ZXJ0eXBlIGJlIHJlc2VydmVkIGJ5DQo+Pj4+Pj4+PiBzb21lYm9keQ0KPj4+Pj4+Pj4+IHdobyBp cyBub3QgSUFOQSBub3IgSUVFRT8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAoc2VlIGEgZ29vZCBl eGFtcGxlIG9mIGludGVyb3BlcmFiaWxpdHk6IElQdjYgMHg4NmRkIGV0aGVydHlwZSANCj4+Pj4+ Pj4+PiBpcyByZXNlcnZlZCBhdCBJRUVFIGFuZCBhdCBJQU5BDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9pZWVlLTgwMi1udW1iZXJzL2llZWUt ODAyLW51bWINCj4+Pj4+Pj4+PiBlDQo+Pj4+Pj4+Pj4gcg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPiBzLnhtbCkNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4gQWxleA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9yIHNob3Vs ZCB0aGVzZSBzdGFuZGFyZHMgcmVtYWluIGluDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gdGhlIHB1 YmxpYyBkb21haW4sIGZvciByZXNlYXJjaGVzIHRvIHJldmlldyBhbmQgdmFsaWRhdGU/DQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSnVzdCBteSAyIGNlbnRzLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IEpvZQ0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIE1v biwgSmFuIDI4LCAyMDEzIGF0IDY6MzEgQU0sIFRoaWVycnkgRXJuc3QgDQo+Pj4+Pj4+Pj4gPHRo aWVycnkuZXJuc3RAaW5yaWEuZnI+IDxtYWlsdG86dGhpZXJyeS5lcm5zdEBpbnJpYS5mcj4gd3Jv dGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gRGVhciBhbGwsDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gQXQgdGhpcyBzdGFnZSwgSSBkb24ndCB0aGluayBhIG5ldyB3b3JraW5n IGdyb3VwIGlzIG5lZWRlZC4gDQo+Pj4+Pj4+Pj4gRmlyc3QsIGl0IHdvdWxkIG5lZWQgYSBjaGFy dGVyLCBhbmQgc3VwcG9ydCBmcm9tIHRoZSBpbmR1c3RyeS4gDQo+Pj4+Pj4+Pj4gQnV0IG1vcmUg aW1wb3J0YW50bHksIElFVEYgV0dzIGFyZSBub3QgdXN1YWxseSBzZWN0b3ItZHJpdmVuLCANCj4+ Pj4+Pj4+PiBzbyBpdCBtZWFucyB0aGUgZGlmZmVyZW50IGlzc3VlcyBwZXJ0YWluaW5nIHRvIElU UyBzaG91bGQgYmUgDQo+Pj4+Pj4+Pj4gYnJvdWdodCB0bw0KPj4+Pj4+Pj4gVkFSSU9VUw0KPj4+ Pj4+Pj4+IGV4aXN0aW5nIFdHcywgYW5kIGEgV0cgc2hvdWxkIG9ubHkgYmUgY3JlYXRlZCBpZiB0 aGVyZSAgaXMgYW4gDQo+Pj4+Pj4+Pj4gaW1wb3J0YW50IGlzc3VlIGZvciB3aGljaCB0aGVyZSBp cyBubyBleGlzdGluZyBXRyB0aGF0IGNvdWxkIA0KPj4+Pj4+Pj4+IHdvcmsgb24gaXQuDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gVGhpcyBzYWlkLCBhcyBtZW50aW9uZWQgZWFybGllciwgSVRTIGlz IG5vdCBvbmx5IGFib3V0IA0KPj4+Pj4+Pj4+IHZlaGljdWxhciBjb21tdW5pY2F0aW9ucywgdGhv dWdoIHRoZSBpc3N1ZXMgbGlzdGVkIGJ5IA0KPj4+Pj4+Pj4+IEFsZXhhbmRydSBiZWxvdyBtb3N0 bHkgY29uc2lkZXIgdmVoaWN1bGFyIGNvbW11bmljYXRpb25zLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+IFdoYXQgSVRTIHJlYWxseSBuZWVkcyBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhIGNvbW1vbiAN Cj4+Pj4+Pj4+PiBjb21tdW5pY2F0aW9uIGFyY2hpdGVjdHVyZSBhbmQgdGhlIGRlZmluaXRpb24g b2Ygd2hhdCBmZWF0dXJlcyANCj4+Pj4+Pj4+PiBzaG91bGQgYmUgY29tcHJpc2VkIGZvciBhbiBJ UHY2IG5ldHdvcmtpbmcgc3RhY2sgZGVwbG95ZWQgZm9yIA0KPj4+Pj4+Pj4+IElUUyB1c2UgY2Fz ZXMuIFRoaXMgY2Fubm90IGJlIGRvbmUgYXQgSUVURiwgYW5kIGFjdHVhbGx5IA0KPj4+Pj4+Pj4+ IGFscmVhZHkgZXhpc3RzIGF0IElTTzogLSBJU08NCj4+Pj4+Pj4+PiAyMTIxNyAtIEFyY2hpdGVj dHVyZSAtIElTTyAyMTIxMCAtIElQdjYgTmV0d29ya2luZw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IEFzIGFuIGlucHV0IHRvIHRoZSBkaXNjdXNzaW9uLCBwbGVhc2UgY29uc2lkZXIgcmVhZGluZyAN Cj4+Pj4+Pj4+PiBkb2N1bWVudHMgRDIuMSBhbmQgRDIuMiBhdmFpbGFibGUgb24gdGhlIElUU1N2 NiBwcm9qZWN0IHdlYg0KPj4+Pj4+Pj4+IHBhZ2U6IGh0dHA6Ly93d3cuaXRzc3Y2LmV1L2RvY3Vt ZW50YXRpb24vDQo+Pj4+Pj4+Pj4gRDIuMiBwcm92aWRlcyBhbiBhbmFseXNpcyBvZiB0aGUgY3Vy cmVudGx5IHB1Ymxpc2hlZCB2ZXJzaW9uIA0KPj4+Pj4+Pj4+IG9mIElTTyAyMTIxMCwgYnV0IG5l dyB3b3JrIGl0ZW1zIGhhdmUgYmVlbiBsYXVuY2hlZCBzaW5jZSB0aGVuIA0KPj4+Pj4+Pj4+IHRv IGFkZHJlc3MgcmVtYWluaW5nIGlzc3Vlcy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBSZWdhcmRz LCBUaGllcnJ5Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIDI4LzAxLzEzIDExOjA4LCBBbGV4YW5kcnUgUGV0 cmVzY3Ugd3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gTGUgMjgvMDEv MjAxMyAwNTowMiwgU3RhbiBSYXRsaWZmIChzcmF0bGlmZikgYSDDqWNyaXQgOg0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEFsbCwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUaGlz IGlzIGp1c3Qgb25lIG9waW5pb24sIGJ1dCBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIHdoeSAgSVRT IA0KPj4+Pj4+Pj4+IHdvdWxkIG5lZWQgaXRzIG93biBJRVRGIGdyb3VwLiBUaGUgd29yayBoZXJl IGlzIHRoZSAgc2FtZSANCj4+Pj4+Pj4+PiAoSU1PKSBhcyB3aGF0IGlzIHRha2luZyBwbGFjZSBp biBNQU5FVC4gSSAgd291bGQgdm90ZSB0aGF0IA0KPj4+Pj4+Pj4+IHRoaXMgd29yayBiZSB0YWtl biB1cCBpbiBNQU5FVC4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBTdGFuLA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoYW5rIHlvdSBmb3IgdGhlIG9mZmVy LiAgSSBjb25zaWRlcmVkIHRoaXMgb2ZmZXIgc2luY2Ugc29tZSANCj4+Pj4+Pj4+PiB0aW1lLg0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEkgdHJ5IHRvIHVuZGVyc3RhbmQgd2hldGhlciBzb21lIG9m IHRoZXNlIGl0ZW1zIG9uIHdoaWNoIEkgDQo+Pj4+Pj4+Pj4gaGF2ZSBpbnRlcmVzdCBjb3VsZCBi ZSBicm91Z2h0IGluIGluIE1BTkVUIFdHOg0KPj4+Pj4+Pj4+IC0gVjJWIHVzaW5nIHByZWZpeCBl eGNoYW5nZSAtIFZJTi1iYXNlZCBJUCBhZGRyZXNzaW5nICBzY2hlbWUNCj4+Pj4+Pj4+PiAtIE5E IFByZWZpeCBEZWxlZ2F0aW9uIC0gUE1JUC1iYXNlZCBuZXR3b3JrIG1vYmlsaXR5IC0gSVB2NiAN Cj4+Pj4+Pj4+PiBzaW5nbGUtYWRkcmVzcyBjb25uZWNpb24gJ3NoYXJpbmcnIHdpdGggYSBjZWxs dWxhciBvcGVyYXRvciANCj4+Pj4+Pj4+PiBhbmQgYSB2ZWhpY3VsYXIgbW92aW5nIG5ldHdvcmsg KHR5cGUgJzY0c2hhcmUnIG9mIHY2b3BzKS4gLSANCj4+Pj4+Pj4+PiBEZWZhdWx0IFJvdXRlIHdp dGggREhDUHY2Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFBsZWFzZSBsZXQgbWUga25vdy4NCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBBbGV4DQo+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gUmVnYXJkcywgU3Rh bg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIEphbiAyNiwgMjAxMywgYXQgOTozNCBBTSwgQWJk dXNzYWxhbSBCYXJ5dW4gd3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g SGkgTmFiaWwsDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gSSB0aGluayB3ZSBhbHJlYWR5IGRvbmUg c29tZSBzdGVwcyBidXQgbm90IHN1cmUgaG93IGZhciBub3cuIA0KPj4+Pj4+Pj4+IFdlIHdpbGwg bmVlZCB0byBwcm9wb3NlIHRoZSBXRyBhbmQgcHJvdmlkZSB0aGUgV0cgY2hhcnRlciwgYXMgDQo+ Pj4+Pj4+Pj4gdXNlIGNhc2VzIGFuZCB3b3JrIHRvIGJlIGRvbmUgaW4gdGhpcyBncm91cC4gVGhp cyBjaGFydGVyIA0KPj4+Pj4+Pj4+IG5lZWRzIHRvIGJlIGFwcHJvdmVkIGJ5IHRoZSBJRVNHLiBJ IGhhdmUgbm90IGF0dGVuZGVkIHRoZSBsYXN0IA0KPj4+Pj4+Pj4+IG1lZXRpbmcgc28gbm90IHN1 cmUgYWJvdXQgdGhlIHN0YXR1cyBub3csDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQUINCj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+PiBPbiAxLzI2LzEzLCBOYWJpbCBCZW5hbWFyIDxiZW5hbWFyNzNAZ21h aWwuY29tPiANCj4+Pj4+Pj4+PiA8bWFpbHRvOmJlbmFtYXI3M0BnbWFpbC5jb20+IHdyb3RlOg0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhpIEFsbCwNCj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiBJJ20gc3RpbGwgaW50ZXJlc3RlZCBpbiB0aGlzIGxpc3QgYW5kIHdhbnQgdG8gam9p biB2b2ljZXMgDQo+Pj4+Pj4+Pj4gcHJldmlvdXNseSBoZWFyZCB0byBtYWtlIGl0IGEgd29ya2lu ZyBncm91cC4gU28gIHdoYXQgc2hvdWxkIA0KPj4+Pj4+Pj4+IHdlIGV4YWN0bHkgZG8sIHRvIGFj aGlldmUgdGhpcyBnb2FsID8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAyMDEz LzEvMjYgQWJkdXNzYWxhbSBCYXJ5dW4NCj4+Pj4+Pj4+PiA8YWJkdXNzYWxhbWJhcnl1bkBnbWFp bC5jb20+DQo+Pj4+Pj4+Pj4gPG1haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT4NCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBIaSBBbGwsDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gSSB3YXMgaW50ZXJlc3RlZCBpbiB0aGlzIGdyb3VwIGJ1dCBub3Qgc3VyZSB3aGVyZSBh cmUgd2Ugc28gDQo+Pj4+Pj4+Pj4gZmFyLiBJcyB0aGVyZSBwcm9ncmVzcywgb3IgaXMgdGhlcmUg aXNzdWVzL2VmZm9ydHMgdGhhdCBuZWVkIA0KPj4+Pj4+Pj4+IHRvIGJlIGNvbXBsZXRlZCBhbmQg dm9sdW50ZWVyZWQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQUIgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzICANCj4+Pj4+Pj4+PiBtYWlsaW5nIGxp c3QgaXRzQGlldGYub3JnIDxtYWlsdG86aXRzQGlldGYub3JnPiANCj4+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IC0tICogKiAq2KrYrdmK2KfYqtmK INiMICoqQ29yZGlhbGVtZW50LCBSZWdhcmRzKiAqICogKiAqICrZhtio2YrZhCANCj4+Pj4+Pj4+ PiDYqNmG2LnZhdix2YhOYWJpbCBCZW5hbWFyKiBQcm9mZXNzb3Igb2YgY29tcHV0ZXIgc2NpZW5j ZXMgU2ltdWxhdGlvbiANCj4+Pj4+Pj4+PiBhbmQgTW9kZWxpc2F0aW9uIExhYm9yYXRvcnkgSHVt YW4gU2NpZW5jZXMgRmFjdWx0eSBvZiBNZWtuZXMgDQo+Pj4+Pj4+Pj4gTW91bGF5IElzbWFpbCog KlVuaXZlcnNpdHkqIE1la25lcywgTW9yb2NjbyAqR1NNOiAqICorIDIxMiA2DQo+Pj4+Pj4+Pj4g NzA4MzIyMzYgaHR0cDovL25hYmlsYmVuYW1hci5jb20vDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g Kg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+Pj4gLQ0K Pj4+Pj4+Pj4+IC0NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ PiANCj4gLS0tLS0tDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+IC0tLS0tLS0tLS0NCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+PiAqDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IGl0cw0KPj4+Pj4+Pj4+IG1haWxp bmcgbGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gaXRzDQo+Pj4+Pj4+PiBtYWlsaW5nDQo+Pj4+Pj4+Pj4gbGlz dCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gaXRzDQo+Pj4+Pj4+PiBtYWlsaW5nDQo+Pj4+Pj4+Pj4gbGlzdCBpdHNA aWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18gaXRzIG1haWxpbmcNCj4+Pj4+Pj4+IGxpc3QNCj4+Pj4+Pj4+ PiBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzIG1haWxp bmcgDQo+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0K Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaXRzIG1haWxpbmcgDQo+Pj4+Pj4+Pj4g bGlzdCBpdHNAaWV0Zi5vcmcgPG1haWx0bzppdHNAaWV0Zi5vcmc+IA0KPj4+Pj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gaXRzIG1haWxpbmcgDQo+Pj4+Pj4+Pj4gbGlzdCBpdHNAaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyANCj4+Pj4+Pj4+IGxpc3QgaXRzQGll dGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gaXRzIG1haWxpbmcNCj4+Pj4+PiBsaXN0IGl0c0BpZXRmLm9yZyBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGl0cyBtYWlsaW5n DQo+Pj4+PiBsaXN0IGl0c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2l0cw0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyBpdHMgbWFpbGluZyBsaXN0DQo+Pj4+IGl0c0Bp ZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4+PiAN Cj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBpdHMgbWFpbGluZyBsaXN0DQo+Pj4gaXRzQGlldGYub3JnIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzIFRoZQ0KPj4+IGluZm9ybWF0aW9uIGNvbnRhaW5l ZCB3aXRoaW4gdGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRhY2hlZCB0bw0KPj4+IHRoaXMg ZS1tYWlsIGlzIHByaXZhdGUgYW5kIGluIGFkZGl0aW9uIG1heSBpbmNsdWRlIGNvbW1lcmNpYWxs eQ0KPj4+IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWls IGFyZSBmb3IgdGhlDQo+Pj4gaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkgYW5kIHRoZXJlZm9yZSBp ZiB5b3Ugd2lzaCB0byBkaXNjbG9zZSB0aGUNCj4+PiBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0 aGluIHRoaXMgZS1tYWlsIG9yIGF0dGFjaGVkIGZpbGVzLCBwbGVhc2UNCj4+PiBjb250YWN0IHRo ZSBzZW5kZXIgcHJpb3IgdG8gYW55IHN1Y2ggZGlzY2xvc3VyZS4gSWYgeW91IGFyZSBub3QgdGhl DQo+Pj4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0 cmlidXRpb24gaXMNCj4+PiBwcm9oaWJpdGVkLiBQbGVhc2UgYWxzbyBjb250YWN0IHRoZSBzZW5k ZXIgYW5kIGluZm9ybSB0aGVtIG9mIHRoZQ0KPj4+IGVycm9yIGFuZCBkZWxldGUgdGhlIGUtbWFp bCwgaW5jbHVkaW5nIGFueSBhdHRhY2hlZCBmaWxlcyBmcm9tIHlvdXINCj4+PiBzeXN0ZW0uIENh c3NpZGlhbiBMaW1pdGVkLCBSZWdpc3RlcmVkIE9mZmljZSA6IFF1YWRyYW50IEhvdXNlLA0KPj4+ IENlbHRpYyBTcHJpbmdzLCBDb2Vka2VybmV3LCBOZXdwb3J0LCBOUDEwIDhGWiBDb21wYW55IE5v OiAwNDE5MTAzNg0KPj4+IGh0dHA6Ly93d3cuY2Fzc2lkaWFuLmNvbQ0KPj4+IA0KPj4+IA0KPj4g DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IGl0cyBtYWlsaW5nIGxpc3QNCj4+IGl0c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2l0cw0KPj4gDQo+PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpdHMgbWFpbGluZyBsaXN0DQo+IGl0 c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBpdHMg bWFpbGluZyBsaXN0DQo+IGl0c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2l0cw0KDQotLQ0KRnJhbmNpc2NvIEouIFJvcywgUGhEDQpEZXB0LiBvZiBJ bmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcNClVuaXZlcnNpdHkgb2Yg TXVyY2lhLCBNdXJjaWEgKFNwYWluKQ0KaHR0cDovL21hc2ltdW0uaW5mLnVtLmVzL2Zqcm0vDQoN Cg0KDQoNCg== From Roberto.Baldessari@neclab.eu Tue Feb 19 00:29:36 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CCE21F8598 for ; Tue, 19 Feb 2013 00:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.312 X-Spam-Level: X-Spam-Status: No, score=-5.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWNC1DpA1PY2 for ; Tue, 19 Feb 2013 00:29:34 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE2621F859C for ; Tue, 19 Feb 2013 00:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C366F1032C4; Tue, 19 Feb 2013 09:29:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTbWuEby5Ppa; Tue, 19 Feb 2013 09:29:32 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A22D31032C1; Tue, 19 Feb 2013 09:29:17 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 19 Feb 2013 09:28:43 +0100 From: Roberto Baldessari To: Alexandru Petrescu Thread-Topic: [its] IPv6 and geonetworking (was: IP over 802.11p) Thread-Index: AQHOC4m4rVCsgI3t30usFhRJKoPPIZiA3emw Date: Tue, 19 Feb 2013 08:28:43 +0000 Message-ID: <81154EB5875DC143AFAA75562B06D1F859F6A96D@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E478F.8020003@gmail.com> In-Reply-To: <511E478F.8020003@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.217] Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IPv6 and geonetworking (was: IP over 802.11p) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:29:36 -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 ty= pe of station. This is v1.1.1, published some time ago. However, now ETSI already has a ne= w draft with important changes, but the geonetworking address approach is n= ot 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: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 15 February 2013 15:35 To: Roberto Baldessari Cc: Dowdell, John; its@ietf.org Subject: Re: [its] IPv6 and geonetworking (was: IP over 802.11p) Le 15/02/2013 11:05, Roberto Baldessari a =E9crit : > Hi Alex, > >> I read the comment. We could discuss it separately, in a separate =20 >> thread. Basically, I think inserting geography in such internal=20 >> workings which is IP addressing changes the nature of this latter, =20 >> and may loose its widespread interoperability. And yes, I should =20 >> look first at its advantages. LEt's discuss separately. > > I think this is the right thread to discuss this point. But you can=20 > rename the subject if you prefer. > > With IPv6 over GeoNetworking we do not modify IPv6, we only transport=20 > it. So we are perfectly in line with what you said (maximize=20 > 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 geograp= hy. In some aspects, geonetworking is not only multicast. There may be more ab= out geonetworking I still need to re-discover, but here is one particular a= spect: '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 Id= entification 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 discus= sion. > Actually, at the very beginning of this group's discussion, I asked if=20 > 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 ha= ppen publicly, in an organized manner - working group, public discussion, p= ublic decisions. As a counter-example: my oppinion sent to you in private (even though I oft= en participate at IETF) should not be qualified as an "IETF input". It's not that the IETF 'usual suspects' participate at another SDO that tha= t input is IETF input. We need documents, WG items, Charters for that to h= appen. > We have now submitted an update within ETSI ITS. If approved, it will=20 > 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=20 > ETSI standard. So, I would not talk about IETF/ETSI as two separate=20 > worlds. Rather, what is missing is some official/structured=20 > 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 > > Best regards, > > Roberto > > > >> >> Best regards, >> >> Roberto >> >> >> >> >> >> >> >> -----Original Message----- From: its-bounces@ietf.org=20 >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org >> Subject: Re: [its] IP over 802.11p >> >> Le 11/02/2013 14:50, Dowdell, John a =E9crit : >>> 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=20 >>> appears to be little support in Linux. 802.11s on the other hand is=20 >>> available on standard Wi-Fi dongles (from $15) and drivers are=20 >>> already available in Linux. Is it correct that 802.11p is mandated=20 >>> 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,=20 >> geonetworking, SDKs) is expensive yes in the range of thousands of=20 >> USDollars. >> >> This uses MiniPCI 802.11p cards from Unex Technology e.g. >> http://unex.com.tw/dsrc-wave which could be inserted in other=20 >> non-ITRI PC-like platforms. I believe these cards may be relatively =20 >> cheap. I don't know whether Unex offer drivers for these cards (be =20 >> 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=20 >> support in linux for 802.11p. I am interested to learn if this=20 >> exists somewhere, even in a prototypical form. We're only aware of=20 >> 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=20 >> license and still allowed to emit at high power levels (33dBm EU,=20 >> 40dBm US, compared to hundreds of milliWats for WiFi). I.e. it is=20 >> possible to have two independent vehicles distanced by kilometers,=20 >> without infrastructure, and communicate, and without requiring=20 >> license from government (whereas in the case of WiFi one can't=20 >> legally do more than a hundred meters or so). >> >> I am not sure this is the case for .s(?) Could .s use high power=20 >> 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=20 >> without geonetworking (i.e. not allowed to use the frequencies=20 >> allocated to ITS for 802.11p without using ETSI ITS i.e. >> geonetworking). >> >> These factors seem to strongly hamper the development of vehicular=20 >> specific communication technology at IETF: - lack of open-source=20 >> driver codes for 802.11p - lack of open and free-of-charge access to=20 >> ETSI standards - lack of open access to ETSI interoperability results=20 >> - lack of cheap hardware implementations of 802.11p - lack of=20 >> unregulated/unlicensed frequency allocated for IP-over-80211p for=20 >> long range. - technical misunderstanding between the ETSI point of=20 >> view of what is IP and the IETF of same. >> >> Although I may sound relatively pessimistic, I also consider I may =20 >> be wrong in my reasoning above. >> >> Alex >> >>> >>> John >>> >>> -----Original Message----- From: its-bounces@ietf.org=20 >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP=20 >>> over 802.11p >>> >>> Le 31/01/2013 14:47, Thierry Ernst a =E9crit : >>>> >>>> Well, we do actually run IPv6 over 11p (with or without=20 >>>> GeoNetworking), so I don't see what kind of issues there might be=20 >>>> ... >>> >>> I have some clarification questions about EtherType and 802.11p and=20 >>> GeoNetworking. >>> >>> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20 >>> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20 >>> over 11p without GeoNetworking, the Ethernet header uses EtherType=20 >>> 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=20 >>> EtherType soon-to-be-0x8947? Or other? I suppose that if I run >>> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800,=20 >>> and if it's ARP over 802.11p still without GeoNetworking then I=20 >>> should use EtherType 0x0806. >>> >>> (the letter we've seen recently is not clear whether that allocation=20 >>> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 >>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. >>> It is not clear either whether GeoNetworking supports IPv4 or not,=20 >>> or under what form). >>> >>> I also have some questions about the relationship between the nature=20 >>> of some 802.11p links (no ESSID, absence of link-layer security - as=20 >>> opposed to WiFi which has ESSID and link-layer >>> security) and IP. >>> >>> For example - will V2V prefix exchange using Router Advertisements=20 >>> work easier on 802.11p links (easier than on WiFi), because the=20 >>> ESSID does not need to be discovered, the ad-hoc network does not=20 >>> need to be formed - suffices it to send packets on a certain=20 >>> channel. >>> >>> (in a V2V draft one seems to say that the presence of Access Point=20 >>> is absolutely necessary in order for 802.11p to work; but in our=20 >>> experimentations this is not the case - it is possible to establish=20 >>> direct vehicle-to-vehicle IP-over-802.11p communications without the=20 >>> presence of a fixed 802.11p Access Point). >>> >>> For another example - will IP prefer that the 802.11p channel in=20 >>> France be 176, 178 or 180? (with WiFi, IP does not care because it=20 >>> can work on any of the 11 channels equally well, but with 802.11p=20 >>> each of these three channels seem to be reserved for "Services",=20 >>> "Control" and "Services"). >>> >>> For another example - is all the security on these links entirely=20 >>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>> >>> I think finding consensus on some of these questions could lead to=20 >>> interoperability. >>> >>> Alex >>> >>>> >>>> Regards, Thierry >>>> >>>> >>>> >>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>> Given current discussions, I think it may be worth considering a=20 >>>>> 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=20 >>>>> or IPv4 also. >>>>> >>>>> This would say how this would work _without_ GeoNetworking. >>>>> >>>>> It would agree on the EtherType and/or whether there are new =20 >>>>> 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=20 >>>>> it works over 802.11b - no modifications. >>>>> >>>>> What do you think? >>>>> >>>>> Alex >>>>> >>>>> Le 30/01/2013 11:10, Alexandru Petrescu a =E9crit : >>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =E9crit : >>>>>>> Hi Alexandru, >>>>>>> >>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>> >>>>>> I tend to agree that #8947 is a hexadecimal notation also because=20 >>>>>> the sharp sign preceding it, and because if it were decimal it=20 >>>>>> would convert to 22F3 which is already reserved for trill. >>>>>> >>>>>> I just watend to make sure. >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 >>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM >>>>>>>> To: its@ietf.org Subject: Re: [its] What do we need to make ITS=20 >>>>>>>> WG go forward? - EtherType for ITS >>>>>>>> >>>>>>>> Hello Dan, >>>>>>>> >>>>>>>> Thank you for the email. >>>>>>>> >>>>>>>> I think we definitely need a good interface with IEEE about=20 >>>>>>>> this. >>>>>>>> >>>>>>>> Maybe you could ask them whether this number is hexa or=20 >>>>>>>> decimal, so we know what to put in implementation (e.g. >>>>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>>>> implementations). >>>>>>>> >>>>>>>> Also, I am interested to learn whether this deserves being=20 >>>>>>>> reserved at IANA. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =E9crit : >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The documents that you are referring (on the ETSI >>>>>>>>> server) are not freely accessible. A password is required, and=20 >>>>>>>>> probably only ETSI members have the access information. >>>>>>>>> >>>>>>>>> The responsibility for assigning EtherType values is with the=20 >>>>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>>>> (updated daily) at=20 >>>>>>>>> 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=20 >>>>>>>>> disclaimer that says >>>>>>>>> >>>>>>>>> * This is a partial listing of all assigned EtherType Fields.=20 >>>>>>>>> Not >>>>>>>> all >>>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>>> >>>>>>>>> Did ETSI require for this information not to be published? It=20 >>>>>>>>> does not look useful if they want to encourage=20 >>>>>>>>> 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:*its-bounces@ietf.org >>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst=20 >>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>> *To:* its@ietf.org *Subject:* Re: [its] What do we need to=20 >>>>>>>>> make ITS WG go forward? - EtherType for ITS >>>>>>>>> >>>>>>>>> >>>>>>>>> Alex, >>>>>>>>> >>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS=20 >>>>>>>>> use (ETSI TC ITS's GeoNetworking). Check the following=20 >>>>>>>>> document available on the ETSI server: >>>>>>>>> >>>>>>>>> ITS(13)000020 >>>>>>>>> >>>>>>>> % >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > 900002 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> 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)00 >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > 20_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 =E9crit : >>>>>>>>> >>>>>>>>> I really dislike the fact that ISO is charging for the ISO=20 >>>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>> >>>>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>>>> cybersecurity and safety liability if the specification leads=20 >>>>>>>>> to deaths and damage to property? >>>>>>>>> >>>>>>>>> >>>>>>>>> Does it make any better interoperable as well? >>>>>>>>> >>>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20 >>>>>>>>> not specified by IEEE nor reserved at IANA - does not make it=20 >>>>>>>>> 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 =20 >>>>>>>>> ethertype is reserved at IEEE and at IANA >>>>>>>>> >>>>>>>>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numb >>>>>>>>> e >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> r >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > s.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=20 >>>>>>>>> =20 >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> At this stage, I don't think a new working group is needed.=20 >>>>>>>>> First, it would need a charter, and support from the industry.=20 >>>>>>>>> But more importantly, IETF WGs are not usually sector-driven,=20 >>>>>>>>> so it means the different issues pertaining to ITS should be=20 >>>>>>>>> brought to >>>>>>>> VARIOUS >>>>>>>>> existing WGs, and a WG should only be created if there is an=20 >>>>>>>>> important issue for which there is no existing WG that could=20 >>>>>>>>> work on it. >>>>>>>>> >>>>>>>>> This said, as mentioned earlier, ITS is not only about=20 >>>>>>>>> vehicular communications, though the issues listed by=20 >>>>>>>>> Alexandru below mostly consider vehicular communications. >>>>>>>>> >>>>>>>>> What ITS really needs is the definition of a common=20 >>>>>>>>> communication architecture and the definition of what features=20 >>>>>>>>> should be comprised for an IPv6 networking stack deployed for=20 >>>>>>>>> ITS use cases. This cannot be done at IETF, and actually=20 >>>>>>>>> already exists at ISO: - ISO >>>>>>>>> 21217 - Architecture - ISO 21210 - IPv6 Networking >>>>>>>>> >>>>>>>>> As an input to the discussion, please consider reading=20 >>>>>>>>> documents D2.1 and D2.2 available on the >>>>>>>>> ITSSv6 project web page: >>>>>>>>> http://www.itssv6.eu/documentation/ D2.2 provides an analysis=20 >>>>>>>>> of the currently published version of ISO 21210, but new work=20 >>>>>>>>> items have been launched since then to address remaining=20 >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> Regards, Thierry. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =E9crit >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> This is just one opinion, but I'd like to understand why ITS=20 >>>>>>>>> would need its own IETF group. The work here is the same=20 >>>>>>>>> (IMO) as what is taking place in MANET. I would vote that=20 >>>>>>>>> this work be taken up in MANET. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Stan, >>>>>>>>> >>>>>>>>> Thank you for the offer. I considered this offer since some=20 >>>>>>>>> time. >>>>>>>>> >>>>>>>>> I try to understand whether some of these items on which I=20 >>>>>>>>> have interest could be brought in in MANET >>>>>>>>> WG: - V2V using prefix exchange - VIN-based IP addressing =20 >>>>>>>>> scheme - ND Prefix Delegation - PMIP-based network mobility -=20 >>>>>>>>> IPv6 single-address connecion 'sharing' with a cellular=20 >>>>>>>>> operator and a vehicular moving network (type '64share' of=20 >>>>>>>>> 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.=20 >>>>>>>>> We will need to propose the WG and provide the WG charter, as=20 >>>>>>>>> use cases and work to be done in this group. This charter=20 >>>>>>>>> needs to be approved by the IESG. I have not attended the=20 >>>>>>>>> last meeting so not sure about the status now, >>>>>>>>> >>>>>>>>> AB >>>>>>>>> >>>>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>>>> previously heard to make it a working group. >>>>>>>>> So what should we exactly do, to achieve this goal ? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I was interested in this group but not sure where are we so=20 >>>>>>>>> far. Is there progress, or is there issues/efforts that need=20 >>>>>>>>> to be completed and volunteered. >>>>>>>>> >>>>>>>>> AB _______________________________________________ >>>>>>>>> its mailing list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- * * *=CA=CD=ED=C7=CA=ED =A1 **Cordialement, Regards* * * * * *= =E4=C8=ED=E1=20 >>>>>>>>> =C8=E4=DA=E3=D1=E6Nabil Benamar* Professor of computer sciences S= imulation=20 >>>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20 >>>>>>>>> Moulay Ismail* >>>>>>>>> *University* Meknes, Morocco *GSM: * *+ 212 6 >>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > ------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> ---------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>> its >>>>>>>>> mailing list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>> mailing >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its mailing >>>>>>>> list >>>>>>>>> its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org =20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org 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 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From abdussalambaryun@gmail.com Tue Feb 19 01:39:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E4C21F87A4 for ; Tue, 19 Feb 2013 01:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrGUs9lmjHLQ for ; Tue, 19 Feb 2013 01:39:30 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 75B9721F8692 for ; Tue, 19 Feb 2013 01:39:30 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id hz1so3313094pad.24 for ; Tue, 19 Feb 2013 01:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2SYycEtmxpqjQNF/zvKxa1vbDIhKH6neCN89peyRRrM=; b=rycMRrU0bluA+qzkCcnPgs3V2NvEMlPSedK1wSwk+ZvzVisSuqnpWcYEA0ujZp9tEC 1asfSogH19TyFMCAjqoVc3bLabTbCzjKRc+O8hrh+uu5Hvq4j/36PvaCLLkyjksJVGBR RJH8B3pKIgZ2Xh4kTT1apHNt71kS4cX5yxNN+anDNjE+iw2IP959ntsYRX+z8ozdvSDo UuL+gOz9WXNkyd4pdcX+0Wl18n21ojudx0L/ThAIXvY9+5zt8VSlR5iBRMsAqthkE/QZ gc3Dh89PgmWmfMlEty5sPCavTWjnWcjRKQsRkL6etU0spa8q4jdWRyjYkhA+xBt5tV+z 3Ceg== MIME-Version: 1.0 X-Received: by 10.68.211.103 with SMTP id nb7mr27312695pbc.140.1361266768942; Tue, 19 Feb 2013 01:39:28 -0800 (PST) Received: by 10.68.33.132 with HTTP; Tue, 19 Feb 2013 01:39:28 -0800 (PST) In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> Date: Tue, 19 Feb 2013 10:39:28 +0100 Message-ID: From: Abdussalam Baryun To: Roberto Baldessari Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:39:31 -0000 On 2/15/13, Roberto Baldessari 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 > each other's expertise/standards. 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 fjros@um.es Tue Feb 19 01:42:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E6921F87A4 for ; Tue, 19 Feb 2013 01:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.2 X-Spam-Level: X-Spam-Status: No, score=-7.2 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17STwZEwAq+e for ; Tue, 19 Feb 2013 01:42:20 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id DEDFF21F8692 for ; Tue, 19 Feb 2013 01:42:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 66D54537B2; Tue, 19 Feb 2013 10:42:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RVkevbN4TN02; Tue, 19 Feb 2013 10:42:14 +0100 (CET) Received: from eduroam_um-229-124.inf.um.es (eduroam_um-229-124.inf.um.es [155.54.229.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon11.um.es (Postfix) with ESMTPSA id 5719D537A7; Tue, 19 Feb 2013 10:42:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F6A93E@PALLENE.office.hd> Date: Tue, 19 Feb 2013 10:42:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5 875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <81154EB5875DC143AFAA75562B06D1F859F6A93E@PALLENE.office.hd> To: Roberto Baldessari X-Mailer: Apple Mail (2.1085) Cc: Alexandru Petrescu , "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IP over 802.11p X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:42:22 -0000 Roberto, Then we're on the same page here, I'm not advocating either option, just = showing alternatives. Best, fran El 19/02/2013, a las 09:24, Roberto Baldessari escribi=C3=B3: > Hi Francisco, >=20 > 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. >=20 > Best regards, >=20 > Roberto >=20 > -----Original Message----- > From: Francisco Javier Ros Mu=C3=B1oz [mailto:fjros@um.es]=20 > Sent: 18 February 2013 18:51 > To: Roberto Baldessari > Cc: Alexandru Petrescu; Dowdell, John; its@ietf.org > Subject: Re: [its] IP over 802.11p >=20 > Hi Roberto, >=20 > El 15/02/2013, a las 11:05, Roberto Baldessari escribi=C3=B3: >=20 >> Hi Alex, >>=20 >>> I read the comment. We could discuss it separately, in a separate = thread. =20 >>> Basically, I think inserting geography in such internal workings=20 >>> which is IP addressing changes the nature of this latter, and may=20 >>> loose its widespread interoperability. And yes, I should look first = at its advantages. LEt's discuss separately. >>=20 >> I think this is the right thread to discuss this point. But you can = rename the subject if you prefer. >>=20 >> 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. >>=20 > 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. >=20 > 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). >=20 > 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. >=20 > Best, > fran >=20 >> 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. >>=20 >> Best regards, >>=20 >> Roberto >>=20 >>=20 >>=20 >>>=20 >>> Best regards, >>>=20 >>> Roberto >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- From: its-bounces@ietf.org=20 >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >>> 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org Subject: >>> Re: [its] IP over 802.11p >>>=20 >>> Le 11/02/2013 14:50, Dowdell, John a =C3=A9crit : >>>> Alex >>>>=20 >>>> Is anyone making 802.11p radios commercially at reasonable cost? >>>> The few I have seen seem to be very expensive (few k$) and there=20 >>>> appears to be little support in Linux. 802.11s on the other hand is=20= >>>> available on standard Wi-Fi dongles (from $15) and drivers are=20 >>>> already available in Linux. Is it correct that 802.11p is mandated=20= >>>> for ITS in some regions? >>>=20 >>> John, >>>=20 >>> Without advertising, we use finalized 802.11p hardware (OBU, RSU, >>> etc.) and support from ITRI Taiwan. The complete package (drivers,=20= >>> geonetworking, SDKs) is expensive yes in the range of thousands of=20= >>> USDollars. >>>=20 >>> This uses MiniPCI 802.11p cards from Unex Technology e.g. >>> http://unex.com.tw/dsrc-wave which could be inserted in other=20 >>> non-ITRI PC-like platforms. I believe these cards may be relatively = =20 >>> cheap. I don't know whether Unex offer drivers for these cards (be =20= >>> them binary or open source), we use the binary drivers from ITRI. >>>=20 >>> I think yes, there seem to be little if any open source GPL driver=20= >>> support in linux for 802.11p. I am interested to learn if this=20 >>> exists somewhere, even in a prototypical form. We're only aware of=20= >>> SPITS project, but were not very successful at trying it. >>>=20 >>> One advantage of .p is that it is regulated such as no need to pay a=20= >>> license and still allowed to emit at high power levels (33dBm EU,=20 >>> 40dBm US, compared to hundreds of milliWats for WiFi). I.e. it is=20= >>> possible to have two independent vehicles distanced by kilometers,=20= >>> without infrastructure, and communicate, and without requiring=20 >>> license from government (whereas in the case of WiFi one can't=20 >>> legally do more than a hundred meters or so). >>>=20 >>> I am not sure this is the case for .s(?) Could .s use high power=20 >>> levels like EIRP 40dBm and without license? >>>=20 >>>=20 >>> Then, >>>=20 >>> I think yes 802.11p is mandated for ITS in Europe by ETSI ITS. >>>=20 >>> But unfortuntaly for me, the situation in the country I live = (France)=20 >>> seems to be that one is not allowed to use IP-over-802.11p without=20= >>> geonetworking (i.e. not allowed to use the frequencies allocated to=20= >>> ITS for 802.11p without using ETSI ITS i.e. geonetworking). >>>=20 >>> These factors seem to strongly hamper the development of vehicular=20= >>> specific communication technology at IETF: - lack of open-source=20 >>> driver codes for 802.11p - lack of open and free-of-charge access to=20= >>> ETSI standards - lack of open access to ETSI interoperability = results >>> - lack of cheap hardware implementations of 802.11p - lack of=20 >>> unregulated/unlicensed frequency allocated for IP-over-80211p for=20 >>> long range. - technical misunderstanding between the ETSI point of=20= >>> view of what is IP and the IETF of same. >>>=20 >>> Although I may sound relatively pessimistic, I also consider I may = be=20 >>> wrong in my reasoning above. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> John >>>>=20 >>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 31 January 2013 15:17 To: its@ietf.org Subject: Re: [its] IP=20= >>>> over 802.11p >>>>=20 >>>> Le 31/01/2013 14:47, Thierry Ernst a =C3=A9crit : >>>>>=20 >>>>> Well, we do actually run IPv6 over 11p (with or without=20 >>>>> GeoNetworking), so I don't see what kind of issues there might be=20= >>>>> ... >>>>=20 >>>> I have some clarification questions about EtherType and 802.11p and=20= >>>> GeoNetworking. >>>>=20 >>>> I guess when you run IPv6 over 11p with GeoNetworking, the Ethernet=20= >>>> header uses EtherType soon-to-be-0x8947, whereas when you run IPv6=20= >>>> over 11p without GeoNetworking, the Ethernet header uses EtherType=20= >>>> 0x86DD. This is just a supposition, I don't know how you run it. >>>>=20 >>>> Also, if I run IPv4 over 11p with GeoNetworking - should I use=20 >>>> EtherType soon-to-be-0x8947? Or other? I suppose that if I run >>>> IPv4 over 11p without GeoNetworking I should use EtherType 0x0800,=20= >>>> and if it's ARP over 802.11p still without GeoNetworking then I=20 >>>> should use EtherType 0x0806. >>>>=20 >>>> (the letter we've seen recently is not clear whether that = allocation=20 >>>> is for GeoNetworking, for IP-over-802.11p, for ETSI ITS, for=20 >>>> GeoNetworking for IPv6, for GeoNetworking for IPv4, etc. It is not=20= >>>> clear either whether GeoNetworking supports IPv4 or not, or under=20= >>>> what form). >>>>=20 >>>> I also have some questions about the relationship between the = nature=20 >>>> of some 802.11p links (no ESSID, absence of link-layer security - = as=20 >>>> opposed to WiFi which has ESSID and link-layer >>>> security) and IP. >>>>=20 >>>> For example - will V2V prefix exchange using Router Advertisements=20= >>>> work easier on 802.11p links (easier than on WiFi), because the=20 >>>> ESSID does not need to be discovered, the ad-hoc network does not=20= >>>> need to be formed - suffices it to send packets on a certain = channel. >>>>=20 >>>> (in a V2V draft one seems to say that the presence of Access Point=20= >>>> is absolutely necessary in order for 802.11p to work; but in our=20 >>>> experimentations this is not the case - it is possible to establish=20= >>>> direct vehicle-to-vehicle IP-over-802.11p communications without = the=20 >>>> presence of a fixed 802.11p Access Point). >>>>=20 >>>> For another example - will IP prefer that the 802.11p channel in=20 >>>> France be 176, 178 or 180? (with WiFi, IP does not care because it=20= >>>> can work on any of the 11 channels equally well, but with 802.11p=20= >>>> each of these three channels seem to be reserved for "Services",=20 >>>> "Control" and "Services"). >>>>=20 >>>> For another example - is all the security on these links entirely=20= >>>> relaying on IP layer security (IPsec, SeND, EAP, PANA)? >>>>=20 >>>> I think finding consensus on some of these questions could lead to=20= >>>> interoperability. >>>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>> Regards, Thierry >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 31/01/13 13:55, Alexandru Petrescu wrote: >>>>>> Given current discussions, I think it may be worth considering a=20= >>>>>> work item about how to run IP over 802.11p. >>>>>>=20 >>>>>> One of the things to say would be whether or not this is IPv6 = only=20 >>>>>> or IPv4 also. >>>>>>=20 >>>>>> This would say how this would work _without_ GeoNetworking. >>>>>>=20 >>>>>> It would agree on the EtherType and/or whether there are new = ones,=20 >>>>>> several or only one, or reusing existing EtherTypes. >>>>>>=20 >>>>>> It could be as simple as to say that IP works over 802.11p just = as=20 >>>>>> it works over 802.11b - no modifications. >>>>>>=20 >>>>>> What do you think? >>>>>>=20 >>>>>> Alex >>>>>>=20 >>>>>> Le 30/01/2013 11:10, Alexandru Petrescu a =C3=A9crit : >>>>>>> Le 30/01/2013 11:04, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>>> Hi Alexandru, >>>>>>>>=20 >>>>>>>> IEEE talk only hexa in their Ethertype files. >>>>>>>=20 >>>>>>> I tend to agree that #8947 is a hexadecimal notation also = because=20 >>>>>>> the sharp sign preceding it, and because if it were decimal it=20= >>>>>>> would convert to 22F3 which is already reserved for trill. >>>>>>>=20 >>>>>>> I just watend to make sure. >>>>>>>=20 >>>>>>> Alex >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Dan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- From: its-bounces@ietf.org=20 >>>>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>>>>>> Sent: Wednesday, January 30, 2013 12:00 PM To: >>>>>>>>> its@ietf.org Subject: Re: [its] What do we need to make ITS WG=20= >>>>>>>>> go forward? - EtherType for ITS >>>>>>>>>=20 >>>>>>>>> Hello Dan, >>>>>>>>>=20 >>>>>>>>> Thank you for the email. >>>>>>>>>=20 >>>>>>>>> I think we definitely need a good interface with IEEE about=20 >>>>>>>>> this. >>>>>>>>>=20 >>>>>>>>> Maybe you could ask them whether this number is hexa or=20 >>>>>>>>> decimal, so we know what to put in implementation (e.g. >>>>>>>>> wireshark packet analyzers, and 802.11p/etsi-its=20 >>>>>>>>> implementations). >>>>>>>>>=20 >>>>>>>>> Also, I am interested to learn whether this deserves being=20 >>>>>>>>> reserved at IANA. >>>>>>>>>=20 >>>>>>>>> Alex >>>>>>>>>=20 >>>>>>>>> Le 30/01/2013 10:49, Romascanu, Dan (Dan) a =C3=A9crit : >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> The documents that you are referring (on the ETSI >>>>>>>>>> server) are not freely accessible. A password is required, = and=20 >>>>>>>>>> probably only ETSI members have the access information. >>>>>>>>>>=20 >>>>>>>>>> The responsibility for assigning EtherType values is with the=20= >>>>>>>>>> IEEE Registration Authority. They maintain a public list=20 >>>>>>>>>> (updated daily) at=20 >>>>>>>>>> http://standards.ieee.org/develop/regauth/ethertype/eth.txt >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >> and according to this list the value 8947 is not allocated. >>>>>>>>>> Now, the public listing information for EtherTypes bears a=20 >>>>>>>>>> disclaimer that says >>>>>>>>>>=20 >>>>>>>>>> * This is a partial listing of all assigned EtherType Fields.=20= >>>>>>>>>> Not >>>>>>>>> all >>>>>>>>>> recipients wish to publish their assignment at this time. >>>>>>>>>>=20 >>>>>>>>>> Did ETSI require for this information not to be published? It=20= >>>>>>>>>> does not look useful if they want to encourage=20 >>>>>>>>>> interoperability >>>>>>>>>>=20 >>>>>>>>>> Value 0707 mentioned in the thread is not allocated either. >>>>>>>>>>=20 >>>>>>>>>> Let me know if I can help (as IETF liaison to the IEEE-SA). >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Dan >>>>>>>>>>=20 >>>>>>>>>> *From:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of *Thierry Ernst >>>>>>>>>> *Sent:* Wednesday, January 30, 2013 11:11 AM >>>>>>>>>> *To:* its@ietf.org *Subject:* Re: [its] What do we need to=20 >>>>>>>>>> make ITS WG go forward? - EtherType for ITS >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Alex, >>>>>>>>>>=20 >>>>>>>>>> IEEE have assigned Ethernet Type Field number #8947 for ITS=20= >>>>>>>>>> use (ETSI TC ITS's GeoNetworking). Check the following=20 >>>>>>>>>> document available on the ETSI server: >>>>>>>>>>=20 >>>>>>>>>> ITS(13)000020 >>>>>>>>>> = >>>>>>>>> % >>>>>>>>>> 2 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >> 900002 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>> 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)00 >>>>>>>>>> 0 >>>>>>>>>> 0 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >> 20_Eth >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>> ernet_Type_Field_number_for_GeoNetworking.pdf >>>>>>>>>>=20 >>>>>>>>>> Regards, Thierry. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 28/01/13 14:28, Alexandru Petrescu wrote: >>>>>>>>>>=20 >>>>>>>>>> Le 28/01/2013 14:16, Joe Klein a =C3=A9crit : >>>>>>>>>>=20 >>>>>>>>>> I really dislike the fact that ISO is charging for the ISO >>>>>>>>>> 21217 - Architecture & ISO 21210 - IPv6 Networking. >>>>>>>>>>=20 >>>>>>>>>> Does this make it any better? Safer? Should ISO now have=20 >>>>>>>>>> cybersecurity and safety liability if the specification leads=20= >>>>>>>>>> to deaths and damage to property? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Does it make any better interoperable as well? >>>>>>>>>>=20 >>>>>>>>>> EtherType 0x0707 described in ITS documents, implemented, but=20= >>>>>>>>>> not specified by IEEE nor reserved at IANA - does not make = it=20 >>>>>>>>>> interoperable. >>>>>>>>>>=20 >>>>>>>>>> One wouldn't think that this 0x0707 ethertype be reserved by >>>>>>>>> somebody >>>>>>>>>> who is not IANA nor IEEE? >>>>>>>>>>=20 >>>>>>>>>> (see a good example of interoperability: IPv6 0x86dd = ethertype=20 >>>>>>>>>> is reserved at IEEE and at IANA >>>>>>>>>>=20 >>>>>>>>>> = http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numb >>>>>>>>>> e >>>>>>>>>> r >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >> s.xml) >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>> Alex >>>>>>>>>>=20 >>>>>>>>>> Or should these standards remain in >>>>>>>>>>=20 >>>>>>>>>> the public domain, for researches to review and validate? >>>>>>>>>>=20 >>>>>>>>>> Just my 2 cents. >>>>>>>>>>=20 >>>>>>>>>> Joe >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst=20 >>>>>>>>>> = wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Dear all, >>>>>>>>>>=20 >>>>>>>>>> At this stage, I don't think a new working group is needed.=20= >>>>>>>>>> First, it would need a charter, and support from the = industry.=20 >>>>>>>>>> But more importantly, IETF WGs are not usually sector-driven,=20= >>>>>>>>>> so it means the different issues pertaining to ITS should be=20= >>>>>>>>>> brought to >>>>>>>>> VARIOUS >>>>>>>>>> existing WGs, and a WG should only be created if there is an=20= >>>>>>>>>> important issue for which there is no existing WG that could=20= >>>>>>>>>> work on it. >>>>>>>>>>=20 >>>>>>>>>> This said, as mentioned earlier, ITS is not only about=20 >>>>>>>>>> vehicular communications, though the issues listed by=20 >>>>>>>>>> Alexandru below mostly consider vehicular communications. >>>>>>>>>>=20 >>>>>>>>>> What ITS really needs is the definition of a common=20 >>>>>>>>>> communication architecture and the definition of what = features=20 >>>>>>>>>> should be comprised for an IPv6 networking stack deployed for=20= >>>>>>>>>> ITS use cases. This cannot be done at IETF, and actually=20 >>>>>>>>>> already exists at ISO: - ISO >>>>>>>>>> 21217 - Architecture - ISO 21210 - IPv6 Networking >>>>>>>>>>=20 >>>>>>>>>> As an input to the discussion, please consider reading=20 >>>>>>>>>> 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=20= >>>>>>>>>> of ISO 21210, but new work items have been launched since = then=20 >>>>>>>>>> to address remaining issues. >>>>>>>>>>=20 >>>>>>>>>> Regards, Thierry. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =C3=A9crit : >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> All, >>>>>>>>>>=20 >>>>>>>>>> This is just one opinion, but I'd like to understand why ITS=20= >>>>>>>>>> would need its own IETF group. The work here is the same=20 >>>>>>>>>> (IMO) as what is taking place in MANET. I would vote that=20 >>>>>>>>>> this work be taken up in MANET. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Stan, >>>>>>>>>>=20 >>>>>>>>>> Thank you for the offer. I considered this offer since some=20= >>>>>>>>>> time. >>>>>>>>>>=20 >>>>>>>>>> I try to understand whether some of these items on which I=20 >>>>>>>>>> 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=20= >>>>>>>>>> single-address connecion 'sharing' with a cellular operator=20= >>>>>>>>>> and a vehicular moving network (type '64share' of v6ops). -=20= >>>>>>>>>> Default Route with DHCPv6. >>>>>>>>>>=20 >>>>>>>>>> Please let me know. >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>>=20 >>>>>>>>>> Alex >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, Stan >>>>>>>>>>=20 >>>>>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi Nabil, >>>>>>>>>>=20 >>>>>>>>>> I think we already done some steps but not sure how far now.=20= >>>>>>>>>> We will need to propose the WG and provide the WG charter, as=20= >>>>>>>>>> use cases and work to be done in this group. This charter=20 >>>>>>>>>> needs to be approved by the IESG. I have not attended the = last=20 >>>>>>>>>> meeting so not sure about the status now, >>>>>>>>>>=20 >>>>>>>>>> AB >>>>>>>>>>=20 >>>>>>>>>> On 1/26/13, Nabil Benamar =20 >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> I'm still interested in this list and want to join voices=20 >>>>>>>>>> previously heard to make it a working group. So what should=20= >>>>>>>>>> we exactly do, to achieve this goal ? >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Hi All, >>>>>>>>>>=20 >>>>>>>>>> I was interested in this group but not sure where are we so=20= >>>>>>>>>> far. Is there progress, or is there issues/efforts that need=20= >>>>>>>>>> to be completed and volunteered. >>>>>>>>>>=20 >>>>>>>>>> AB _______________________________________________ its =20 >>>>>>>>>> mailing list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C = **Cordialement, Regards* * * * * *=D9=86=D8=A8=D9=8A=D9=84=20 >>>>>>>>>> =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88Nabil Benamar* Professor = of computer sciences Simulation=20 >>>>>>>>>> and Modelisation Laboratory Human Sciences Faculty of Meknes=20= >>>>>>>>>> Moulay Ismail* *University* Meknes, Morocco *GSM: * *+ 212 6 >>>>>>>>>> 70832236 http://nabilbenamar.com/ >>>>>>>>>>=20 >>>>>>>>>> * >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> = -------------------------------------------------------------- >>>>>>>>>> - >>>>>>>>>> - >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >> ------ >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>> ---------- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> * >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>> its >>>>>>>>>> mailing list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its mailing=20= >>>>>>>>>> list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its mailing=20= >>>>>>>>>> list its@ietf.org =20 >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ its mailing=20= >>>>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ its mailing=20 >>>>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ its mailing >>>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org 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 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 > -- > Francisco J. Ros, PhD > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ >=20 >=20 >=20 >=20 -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From alexandru.petrescu@gmail.com Tue Feb 19 05:38:37 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527E421F8930 for ; Tue, 19 Feb 2013 05:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.466 X-Spam-Level: X-Spam-Status: No, score=-11.466 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4to4-xBlQJnl for ; Tue, 19 Feb 2013 05:38:35 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF821F88F0 for ; Tue, 19 Feb 2013 05:38:34 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r1JDcWAV002354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 14:38:32 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r1JDcWrC006500; Tue, 19 Feb 2013 14:38:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r1JDcMjh029034; Tue, 19 Feb 2013 14:38:31 +0100 Message-ID: <5123804E.4020800@gmail.com> Date: Tue, 19 Feb 2013 14:38:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roberto Baldessari References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <9904FB1B0159DA42B0B887B7FA8119CA07A49E@AZ-FFEXMB04.global.avaya.com> <5108EF0B.5050002@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA07A517@AZ-FFEXMB04.global.avaya.com> <5108F18E.7010104@gmail.com> <510A69D7.40806@gmail.com> <510A75F8.7080508@inria.fr> <603F5FD847B5174CBDA37A9DC00532FB06AC631A@SUCNPTEXM02.com.ad.uk.ds.corp> <51190E7E.4040001@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F4FF8C@PALLENE.office.hd> <511BD128.8070907@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F5E07D@PALLENE.office.hd> <511E478F.8020003@gmail.com> <81154EB5875DC143AFAA75562B06D1F859F6A96D@PALLENE.office! .hd> In-Reply-To: <81154EB5875DC143AFAA75562B06D1F859F6A96D@PALLENE.office.hd> Content-Type: text/plain; charset=windows-1256; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] IPv6 and geonetworking X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 13:38:37 -0000 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 > http://www.etsi.org/deliver/etsi_ts/102600_102699/1026360401/01.01.01_60/ts_1026360401v010101p.pdf > >See section 6.3. 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 > > Best regards, > > Roberto > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > 15 February 2013 15:35 To: Roberto Baldessari Cc: Dowdell, John; > its@ietf.org Subject: Re: [its] IPv6 and geonetworking (was: IP over > 802.11p) > > Le 15/02/2013 11:05, Roberto Baldessari a écrit : >> 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. > > 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 > >> >> Best regards, >> >> Roberto >> >> >> >>> >>> Best regards, >>> >>> Roberto >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 11 February 2013 16:30 To: Dowdell, John Cc: its@ietf.org >>> Subject: Re: [its] IP over 802.11p >>> >>> 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 >>> >>>> >>>> John >>>> >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 31 January 2013 15:17 To: its@ietf.org 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: >>>>>>>>> its-bounces@ietf.org [mailto:its-bounces@ietf.org] On >>>>>>>>> Behalf Of Alexandru Petrescu Sent: Wednesday, January >>>>>>>>> 30, 2013 12:00 PM To: its@ietf.org 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:*its-bounces@ietf.org >>>>>>>>>> [mailto:its-bounces@ietf.org] *On Behalf Of >>>>>>>>>> *Thierry Ernst *Sent:* Wednesday, January 30, 2013 >>>>>>>>>> 11:11 AM *To:* its@ietf.org *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 >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> % >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> 900002 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> 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)00 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > 0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> 20_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-numb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> e >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > r >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> s.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 >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 its@ietf.org >>>>>>>>>> >>>>>>>>>> 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 its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> its >>>>>>>>> mailing >>>>>>>>>> list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing >>>>>>>>> list >>>>>>>>>> its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ its >>>>>>>>>> mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ its >>>>>>>>> mailing list its@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> _______________________________________________ its >>>>>> mailing list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org 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 >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From pthubert@cisco.com Tue Feb 19 09:28:53 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D9121F8853 for ; Tue, 19 Feb 2013 09:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U-SYVskHbKR for ; Tue, 19 Feb 2013 09:28:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C621F8841 for ; Tue, 19 Feb 2013 09:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3868; q=dns/txt; s=iport; t=1361294918; x=1362504518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zeRKuIIENJF/IwNiH4J1b+sUFzWV7WksAt8APZuBo/0=; b=BmkTYhypBV866CRduoIT2qsSe2V9XjTbhH3sHmpSoTUcnst4sCCWzm7R flLh3EZgfUbnN9b3einQU0c2NBx8TkJAqBt/MgQuNmSJx4YbeTv7Pu09h 28ap4j1krbVZAn4+aJiIgqYwkgYVaM0bzLD1Y48pShCnJs7mDElQTDi3R M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvANABi1I1GtJXG8/2dsb2JhbABEFoQtu3mBDBZzghgHAQEBAgEBAQEBawQHBQcEAgEIEQQBAQsdBycLFAkIAgQOBQiFQQeCPAYMsD6QHo09EYEPJgsHBoJZYQOIMI8YjzuDB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,696,1355097600"; d="scan'208";a="178797089" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2013 17:28:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JHSauI028468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 17:28:36 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 11:28:36 -0600 From: "Pascal Thubert (pthubert)" To: Alexandru Petrescu Thread-Topic: [its] Draft Charter proposal Thread-Index: AQHOC7Wf0KvHa2AQckye0Zlo0wYHDJh8Ib4AgAAHJoCAALflAP//ycGQ Date: Tue, 19 Feb 2013 17:28:35 +0000 Deferred-Delivery: Tue, 19 Feb 2013 17:28:00 +0000 Message-ID: References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> In-Reply-To: <511F8A00.4080408@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.94.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jari.arkko@piuha.net" , Ryuji Wakikawa , "its@ietf.org" , Abdussalam Baryun Subject: Re: [its] Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:28:53 -0000 Hello Alex > RPL has the exact properties that we were looking for at the time. But Pascal, RPL is something which could do anything? I thought it were on= ly for wireless sensor networks, low-power and lossy links. In V2V one nee= ds high-power links and in-vehicle one appreciates the non-lossy reliabilit= y of Ethernet. [Pascal] RPL can be economical but is not restricted to that. RPL builds sp= anning graphs from/to particular destinations, whne other IGPs otimize any = to any.=20 Where would RPL fit? [Pascal] Well, 6TSCH could fit inside a car to save heavy wiring, and 6TSCH= uses RPL. (6TSCH is a non WG ML under Internet area https://www.ietf.org/= mailman/listinfo/6tsch )=20 RPL could also fit between cars when they move as a fleet, but not between = unrelated cars going around one another. I understand that geo addresses ar= e proven to work well in that case. > The global mobility can be achieved a number of ways, but is seems=20 > that making the road side unit the locator is the simple thing. Please explain, what does it mean to make the RSU the locator. [Pascal] Examples of that is the RSU acts a MIP4 foreign agent, a PMIP MAG,= or a LISP RLOC. Say you have a fleet in motion, that runs RPL inside the f= leet for local interconnection. When the fleet approaches the RSU, it can u= se the RSU for global mobility. In some cases RSUs are needed, and in other cases direct V2V communications= between vehicles are needed as well (w/o infrastructure). For these V2V cases, RPL would not be needed, right? [Pascal] Well, then again it can be a scenario thing. RPL could be used for= a convoy but not for unrelated cars going in unrelated directions. > In that case, we have a number of possibilities of the shelf,=20 > including LISP, PMIP, or MIP/NEMO-proxy such as discussed in global=20 > HAHA for DMM. I think I agree. PMIP with an RSU as MAG is tempting. Sandra wrote private email about VIP-= WAVE which is documented in a quality paper at http://bbcr.uwaterloo.ca/~sl= cesped/i/preprintVIPWAVE.pdf LISP yes could be analyzed to see how it fits the OBU/RSU distinction. GlobalHAHA would need to be suggested to DMM, not here, right? (I don't kn= ow what you meant?). [Pascal] One aspect in global HAHA is the proxy Home Agent. Proxies are wi= dely deployed (SGSNs, RSUs ...). Proxies do not have home links but have a = trust relationship with Home agents. The MN binds to the proxy, the proxy = binds to the MN HA. Then proxies to Route Optimization to one another and b= ypass home agents. I need to modify the Charter proposal according to your suggestions. I wil= l do so soon. [pascal] cool, thanks Alex. > > Cheers, > > Pascal > > -----Original Message----- From: its-bounces@ietf.org=20 > [mailto:its-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: > samedi 16 f=E9vrier 2013 03:07 To: Alexandru Petrescu Cc: its@ietf.org > Subject: Re: [its] Draft Charter proposal > > Hi Alex, > >> A number of IETF protocols are being considered in the context of=20 >> Intelligent Transportation Systems - most notably IPv6, Mobile IPv6,=20 >> ND, ULA, DHCPv6. Others are not excluded. At IETF several Working=20 >> Groups such as IPv6, V6OPS, DHC, MIF, MANET, DMM, produce work which=20 >> is highly pertinent to the ITS context. > > What about ROLL, I think it is more related to ITS, I think we should=20 > consider that our intelligent systems/devices need use some of ROLL=20 > techniques in V2V and V2I > > ITS =3D ROLL + MANET > > IMHO, that the chater proposed, mentions the ITS applicability that=20 > should include MANET applicability and ROLL applicability. > > AB _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From sofiane.imadali.ietf@gmail.com Wed Feb 20 09:14:35 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3521F886B; Wed, 20 Feb 2013 09:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5udIQB0-wodI; Wed, 20 Feb 2013 09:14:34 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 058B321F84C7; Wed, 20 Feb 2013 09:14:33 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so7956134lab.27 for ; Wed, 20 Feb 2013 09:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Wqspu2H0/XjTcKVMSfuM+cs8e9YbCJcu6AlmM146Jxw=; b=tD/cAUCZKfKX/0Ykh/VK42HS0xwjIExV2WzoEixMALnGo6j2TUzw2WAkxjA91BgGuj 2gemmEYpM5u7g0x5ZWdGCjzpDCt/urzUdglscLXeGgXxgZKRpHiDdDe3VveC5oDUcq13 rUxnCaclnVClQ/FYy+wAmCVx4oPJFENB97trUjXep8Qyx8pU385GMzgK/ZMDQpdJCnbG BeQnT0BxwCIntmkVNjVG8/SvDQ83hNJN8ofJ+c8Khj3t1EX6Hw6iR5mzmnu8JqGS8dlF xKO4b50kDlEVtQTV82tis1yTouYjuiJAb4CwumK9PsIHKxttuoHfmUBsmZY07Oxan6TP QIwg== MIME-Version: 1.0 X-Received: by 10.112.13.200 with SMTP id j8mr5277990lbc.68.1361380472803; Wed, 20 Feb 2013 09:14:32 -0800 (PST) Received: by 10.152.127.6 with HTTP; Wed, 20 Feb 2013 09:14:32 -0800 (PST) Date: Wed, 20 Feb 2013 18:14:32 +0100 Message-ID: From: sofiane Imadali To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, its@ietf.org Subject: Re: [its] Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:14:36 -0000 Hi, Thanks for your interest Roger, your question is very pertinent and I wanted to share it with the group (hope you don't mind bringing this offlist mail to the list). Indeed, one needs to understand the context before understanding the possible uses of the method. First, a bit of state of the art that couldn't appear in the drafts. VIN is not a private information. It is meant to be public. I gave a list of ISO specifications that say exactly How a VIN is built, Where it should appear, How to reverse engineer it. In a nutshell, the VIN is alphanumeric, it appears on your wind shield, and you can break it down to 3 pieces: the manufacturer ID, the vehicle's description, and the vehicle ID. - What networking questions/perspectives should these VIN-related data trigger ? - Today in a closed operator domain, the vehicle (Mobile Router) can generate a ULA prefix for site-scoped communications. It is subject to collisions if used on a large number of vehicles (10^4 or more - RFC4193). In the vehicular context you're facing this limitation. For applications such as remote diagnosis, or other services (involving access to in-vehicle Machines), the solution we propose allows to create a predictable (deterministic manner) unique (collision-free) prefix, that in a closed loop (operator domain, manufacturer domain) allows you to determine which vehicle to access with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any other additional artefact involved. Again, with this proposal, if you are an operator/manufacturer with a list of your vehicles fleet, you can determine a list of ULA prefixes to access each one of them: No additional protocol involved, no collisions. - What applications can be enabled by the use of this kind of VIN-based Prefixes and IDs ? - This also answers the question of regarding those 2 proposals only from a privacy-concerns standpoint. Vendor web-based apps where you give a VIN code and returns the history of a vehicle already exists. When selling your car, a buyer can look up your VIN in a database and get a history of car accidents, repairs ...etc all related to your vehicle. This is no science-fiction, it has already been used in the US for quite a while. Here is on example googling the keywords (second hand car VIN history): http://www.edmunds.com/car-buying/vin-check.html - About the privacy concerns. - I am no expert in the field of privacy. I do understand the concerns though, and this is why I chose to trigger them in the draft and in my research work before it is evoked in the mailling list. My humble opinion about the subject is that we should not mistake VIN for a MAC. Not compare them, and not apply blindly the concepts of MAC randomization for VIN-based IIDs/Prefixes. The compromise of (Uniqueness/randomization And Privacy) that is studied and standardized in RFC 4941 for IID, should not directly apply to VIN with no regard to the nature of the object we are using. Please have a look at: http://en.wikipedia.org/wiki/VIN_Etching, which should inform you more about another possible application of VIN (in general, not just networking) which is car theft prevention, to understand why *your VIN is a public good and not a private property that you buy with your car*. To sum up; in order not to trigger (too soon) the privacy concerns and be blocked by that, the primal use case (domain, site) would be a closed operator network, or car manufacturer in the manufacture (closed loop). This method allows us to set internal routing to access the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix. No additional protocol is needed to do that. Any service provided by this devices (monitoring vehicle state for example) is a use case that applies to this addressing approach. Thanks for reading and feedback; Cheers Sofiane On Mon, Feb 18, 2013 at 11:11 PM, Roger J=F8rgensen wrot= e: > Hi, > > What I wonder about is why we need this, what are the usecases and the > _intention_ behind these two draft from you? > > just... why? > > > The reason I ask is that I try to understand it, and see if the > privacy option is a real concern in _your_ context or not. > > > > --- Roger J --- > > On Mon, Feb 18, 2013 at 7:49 PM, sofiane Imadali > wrote: >> Hello 6MAN folks, >> >> I would like to announce, on behalf of the co-authors, the submission >> of 2 drafts relating to VIN-based IPv6 addressing. >> VIN stands for Vehicle Identification Number, and it is specifically >> used in a context of IPv6 vehicular communications. These proposals >> aim at providing discussion about a new mapping/conversion method from >> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers. >> >> Please find the above mentioned documents at: >> 1) Vehicle Identification Number-Based IPv6 Interface Identifier >> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 >> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast >> Addresses (VULA), at: >> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00 >> >> Your comments are welcome, >> >> Cheers, >> Sofiane. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > > -- > > Roger Jorgensen | ROJO9-RIPE > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no From rogerj@gmail.com Wed Feb 20 14:03:04 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80FF21E8053; Wed, 20 Feb 2013 14:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hgWx-DwRwA3; Wed, 20 Feb 2013 14:03:03 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id C62D121E8051; Wed, 20 Feb 2013 14:03:03 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id i10so8693637oag.14 for ; Wed, 20 Feb 2013 14:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lLRHxiFzL4QlUmbyEFiOpViTidVlYtWajJqDzze37UM=; b=DBb3vvIshXp/jh+vqol/m2STZ2qbtno46sbKmIYKaosif2aVjj5Jjlsl2XaWBzhKTA VikyCUjvsFPLRvUxbvTggw0SM7xB/o4Wh2jBUUE6G/BvhDY6a0EuKVyQ8dGXO1tBQb1G n/HwtG3jvI1AzzhfyO2LdJlE84/Hg9IoXWw08YbgWJOvJvwBIqJ6JD2MtitfRe8x7Ncx vgcI5aIaHSCBRWnDbvyLUZ8VlfmSPwpzEGZnKBOkoFKQJ6HHZDXP3/Y1RSeU/Hz2ihXX tSguf6WDFWrASmTCkX2Sq8QOX/EQtUgM1h+yLWWdJzBOV+cFjY90ysT2Xjnxgi8/0lj0 EaeQ== MIME-Version: 1.0 X-Received: by 10.182.49.102 with SMTP id t6mr9794628obn.75.1361397783287; Wed, 20 Feb 2013 14:03:03 -0800 (PST) Received: by 10.76.167.106 with HTTP; Wed, 20 Feb 2013 14:03:03 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 23:03:03 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: sofiane Imadali Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sun, 24 Feb 2013 07:55:54 -0800 Cc: ipv6@ietf.org, its@ietf.org Subject: Re: [its] Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:03:04 -0000 On Wed, Feb 20, 2013 at 6:14 PM, sofiane Imadali wrote: > Hi, > Thanks for your interest Roger, your question is very pertinent and I > wanted to share it with the group (hope you don't mind bringing this > offlist mail to the list). no I don't mind, I'll comment on your answer inline > - Today in a closed operator domain, the vehicle (Mobile Router) > can generate a ULA prefix for site-scoped communications. It is > subject to collisions if used on a large number of vehicles (10^4 or > more - RFC4193). In the vehicular context you're facing this > limitation. > For applications such as remote diagnosis, or other services > (involving access to in-vehicle Machines), the solution we propose > allows to create a predictable (deterministic manner) unique > (collision-free) prefix, that in a closed loop (operator domain, > manufacturer domain) allows you to determine which vehicle to access > with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any > other additional artefact involved. > Again, with this proposal, if you are an operator/manufacturer with a > list of your vehicles fleet, you can determine a list of ULA prefixes > to access each one of them: No additional protocol involved, no > collisions. I don't think it's clear enough in the draft that we're talking about closed circuit system, not communicated initiated from within the car to outside, any outside device including other cars. The case of accessing the car's network from a service point of view are still inside the car's domain. Am I understanding this correct? Another issue is the use of the term site, you could explain how you are using that term. I personal would consider any inner car communication to be within a site, including when I connect my phone to the on-board media-system to stream music or movie. Any communication toward outside the car are out of the site. > To sum up; in order not to trigger (too soon) the privacy concerns and > be blocked by that, the primal use case (domain, site) would be a > closed operator network, or car manufacturer in the manufacture > (closed loop). This method allows us to set internal routing to access > the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix. > No additional protocol is needed to do that. Any service provided by > this devices (monitoring vehicle state for example) is a use case that > applies to this addressing approach. as said above, I understand those two draft to talk about inner car communication, not communication toward _any_ device outside the car. That include communication to other nearby cars, parking automate and more. Or to sum it up as I see it with regard to the privacy issue - the issue is when the car, or someone in the car use an IP toward _any_ outside device that can be traced back to the VIN of any car (vehicles). > Thanks for reading and feedback; no problem, good to get such a good explanation back :) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no From v6ops@globis.net Thu Feb 21 02:12:34 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EB321F8E3E; Thu, 21 Feb 2013 02:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8btSzDxSmKUQ; Thu, 21 Feb 2013 02:12:33 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 98EC521F8E45; Thu, 21 Feb 2013 02:12:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 38944870099; Thu, 21 Feb 2013 11:02:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLQ+4MeiOr3d; Thu, 21 Feb 2013 11:01:42 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 58B2087005B; Thu, 21 Feb 2013 11:01:42 +0100 (CET) Message-ID: <5125F080.90100@globis.net> Date: Thu, 21 Feb 2013 11:01:36 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: sofiane Imadali References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 24 Feb 2013 07:55:54 -0800 Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , ipv6@ietf.org, its@ietf.org Subject: Re: [its] Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 10:12:34 -0000 A similar issue is likely to emerge with other mobile device - mobile device communication,where there are a large number of mobile devices circulating globally, but relatively few of them are present in any one given area at any given time e.g. wearable computing, medical monitors, RFID tags attached to small articles in transit, pet ID chips that warn the owner if they stray...... IMHO it is a bad idea to define any sort of static mapping between L8 identifiers and L3/L2. 64 bits of IID are simply not going to be enough to encode adequate semantics for all envisioned mobile applications. SLAAC (using MAC as the universal seed) is almost certainly going to be less likely to suffer collisions than any number of competing industry-specific standards that overload the IID space. IMHVO The industry should generate prefixes/addresses based on existing standards, and then perform any dynamic VIN / Pet ID / L8 ID mapping via some (industry-specific) protocol to identify the specific vehicle/ pet/ shirt as appropriate. There is perhaps a role here for the IETF to assist in defining a L3<->L8 mapping protocol, especially for links with rapidly changing members, and which includes an industry identifier and an industry specific portion. regards, RayH sofiane Imadali wrote: > Hi, > Thanks for your interest Roger, your question is very pertinent and I > wanted to share it with the group (hope you don't mind bringing this > offlist mail to the list). > > Indeed, one needs to understand the context before understanding the > possible uses of the method. > > First, a bit of state of the art that couldn't appear in the drafts. > VIN is not a private information. It is meant to be public. I gave a > list of ISO specifications that say exactly How a VIN is built, Where > it should appear, How to reverse engineer it. In a nutshell, the VIN > is alphanumeric, it appears on your wind shield, and you can break it > down to 3 pieces: the manufacturer ID, the vehicle's description, and > the vehicle ID. > > - What networking questions/perspectives should these VIN-related > data trigger ? > - Today in a closed operator domain, the vehicle (Mobile Router) > can generate a ULA prefix for site-scoped communications. It is > subject to collisions if used on a large number of vehicles (10^4 or > more - RFC4193). In the vehicular context you're facing this > limitation. > For applications such as remote diagnosis, or other services > (involving access to in-vehicle Machines), the solution we propose > allows to create a predictable (deterministic manner) unique > (collision-free) prefix, that in a closed loop (operator domain, > manufacturer domain) allows you to determine which vehicle to access > with which prefix: No DNS, No Prefix Delegation, No DHCPv6, nor any > other additional artefact involved. > Again, with this proposal, if you are an operator/manufacturer with a > list of your vehicles fleet, you can determine a list of ULA prefixes > to access each one of them: No additional protocol involved, no > collisions. > > - What applications can be enabled by the use of this kind of > VIN-based Prefixes and IDs ? > - This also answers the question of regarding those 2 proposals > only from a privacy-concerns standpoint. Vendor web-based apps where > you give a VIN code and returns the history of a vehicle already > exists. When selling your car, a buyer can look up your VIN in a > database and get a history of car accidents, repairs ...etc all > related to your vehicle. This is no science-fiction, it has already > been used in the US for quite a while. Here is on example googling the > keywords (second hand car VIN history): > http://www.edmunds.com/car-buying/vin-check.html > > - About the privacy concerns. > - I am no expert in the field of privacy. I do understand the > concerns though, and this is why I chose to trigger them in the draft > and in my research work before it is evoked in the mailling list. My > humble opinion about the subject is that we should not mistake VIN for > a MAC. Not compare them, and not apply blindly the concepts of MAC > randomization for VIN-based IIDs/Prefixes. The compromise of > (Uniqueness/randomization And Privacy) that is studied and > standardized in RFC 4941 for IID, should not directly apply to VIN > with no regard to the nature of the object we are using. Please have a > look at: http://en.wikipedia.org/wiki/VIN_Etching, which should inform > you more about another possible application of VIN (in general, not > just networking) which is car theft prevention, to understand why > *your VIN is a public good and not a private property that you buy > with your car*. > > To sum up; in order not to trigger (too soon) the privacy concerns and > be blocked by that, the primal use case (domain, site) would be a > closed operator network, or car manufacturer in the manufacture > (closed loop). This method allows us to set internal routing to access > the in-vehicle devices, by a deterministic manner: VIN --> ULA prefix. > No additional protocol is needed to do that. Any service provided by > this devices (monitoring vehicle state for example) is a use case that > applies to this addressing approach. > > Thanks for reading and feedback; > Cheers > Sofiane > > > > > On Mon, Feb 18, 2013 at 11:11 PM, Roger Jørgensen wrote: >> Hi, >> >> What I wonder about is why we need this, what are the usecases and the >> _intention_ behind these two draft from you? >> >> just... why? >> >> >> The reason I ask is that I try to understand it, and see if the >> privacy option is a real concern in _your_ context or not. >> >> >> >> --- Roger J --- >> >> On Mon, Feb 18, 2013 at 7:49 PM, sofiane Imadali >> wrote: >>> Hello 6MAN folks, >>> >>> I would like to announce, on behalf of the co-authors, the submission >>> of 2 drafts relating to VIN-based IPv6 addressing. >>> VIN stands for Vehicle Identification Number, and it is specifically >>> used in a context of IPv6 vehicular communications. These proposals >>> aim at providing discussion about a new mapping/conversion method from >>> VIN to ULA prefixes (guaranteed unique) and Interface Identifiers. >>> >>> Please find the above mentioned documents at: >>> 1) Vehicle Identification Number-Based IPv6 Interface Identifier >>> (VIID), at: http://tools.ietf.org/html/draft-imadali-its-vinipv6-viid-00 >>> 2) Vehicle Identification Number-Based Unique Local IPv6 Unicast >>> Addresses (VULA), at: >>> http://tools.ietf.org/html/draft-imadali-its-vinipv6-vula-00 >>> >>> Your comments are welcome, >>> >>> Cheers, >>> Sofiane. >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> -- >> >> Roger Jorgensen | ROJO9-RIPE >> rogerj@gmail.com | - IPv6 is The Key! >> http://www.jorgensen.no | roger@jorgensen.no >