From nobody Tue Nov 4 06:28:16 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FA31A888D for ; Tue, 4 Nov 2014 06:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZWsmnk7r8wk for ; Tue, 4 Nov 2014 06:28:12 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3190D1A889F for ; Tue, 4 Nov 2014 06:28:11 -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 sA4ES9TQ014241 for ; Tue, 4 Nov 2014 15:28:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B23722025A6 for ; Tue, 4 Nov 2014 15:28:15 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A002A202582 for ; Tue, 4 Nov 2014 15:28:15 +0100 (CET) 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 sA4ES3dR029623 for ; Tue, 4 Nov 2014 15:28:09 +0100 Message-ID: <5458E273.8060900@gmail.com> Date: Tue, 04 Nov 2014 15:28:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/WTYZxMAhIs74_V_kGJwvv2ugjwU Subject: [geonet/its] status X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:28:15 -0000 Hello, This is a status update about geonet/its. 1. moving to a Research Group: please contact Dimitri Papadimitriou and copy me. We need help building up the proposal of a Research Group. Among other things needed an idea was floated about an Internet Draft which overviews the following IETF documents pertinent to geonet/its. These documents have been mentioned by several people: - ZRP - Zone Routing Protocol draft-ietf-manet-zone-zrp-04.txt - ETSI ITS GeoNetworking Part 3: NetworkArchitecture document - RFC 3825 DHCP option for location configuration - RFC 4119 PIDF-LO format - Geo- information in IP headers draft-skeen-6man-ipv6geo-01.txt - PI format using geo-location draft-hain-ipv6-pi-addr-10.txt 2. progress the vehicle-to-vehicle IP communications discussion: how? 3. implementations: - what are the advancements towards an open-source driver for 802.11p? Alex From nobody Tue Nov 4 06:45:46 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C921A8947 for ; Tue, 4 Nov 2014 06:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lz97ETEl6aUB for ; Tue, 4 Nov 2014 06:45:43 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCF51A8951 for ; Tue, 4 Nov 2014 06:45:43 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id z60so7578928qgd.8 for ; Tue, 04 Nov 2014 06:45:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D7qTdMboBjtY5HGRB3yG0U/pROjKcOZn//AUlwVb6Hc=; b=uxUxo5CgkgQGISZWKwu4Hy+VHESOhxZI5qrDMJdJWsGmqA9BHg6s7LeqG5ReQyp3R5 IfjX1k8KF/Fn3qH+pNahYaIgWW+ul+qpaInGNNkJ+NsYGpLaEjLurlTxbCBy1YhT4a2P AwMYRT1su+cTyn9grAsNGgBR1lNeTC7TE5kpq4ZUJq2CXq7U+P2IojzR4pa71aSpVcfI t2BVC3KZgD04FVKuaNLPQUUFlaT3rC1Hzug/22FrT4uRloXsSKZxgeVRgvvttp3NA56Y zje4203dTUVRWs2Ld1MsZ3ScJ5MoNqKwNVCigEEcKohXqqZm33Tp2Q2h1W54Tel3do5x xLOQ== X-Received: by 10.229.53.133 with SMTP id m5mr76705722qcg.28.1415112342302; Tue, 04 Nov 2014 06:45:42 -0800 (PST) Received: from [192.168.1.37] (pool-72-92-10-132.phlapa.east.verizon.net. [72.92.10.132]) by mx.google.com with ESMTPSA id u7sm523620qau.17.2014.11.04.06.45.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 06:45:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dino Farinacci In-Reply-To: <5458E273.8060900@gmail.com> Date: Tue, 4 Nov 2014 06:45:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <5458E273.8060900@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/its/-d7Opirkg4CSO8jsRcBih_sXP20 Cc: "its@ietf.org" Subject: Re: [geonet/its] status X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:45:44 -0000 > This is a status update about geonet/its. Are we meeting at IETF next week? Dino From nobody Tue Nov 4 06:58:05 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FB51A0358 for ; Tue, 4 Nov 2014 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95xReJ_gCZFL for ; Tue, 4 Nov 2014 06:58:01 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923231A896D for ; Tue, 4 Nov 2014 06:57:58 -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 sA4EvtXr021126; Tue, 4 Nov 2014 15:57:55 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2430C202602; Tue, 4 Nov 2014 15:58:02 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0F58620254B; Tue, 4 Nov 2014 15:58:02 +0100 (CET) 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 sA4Evi6B018896; Tue, 4 Nov 2014 15:57:55 +0100 Message-ID: <5458E968.8000105@gmail.com> Date: Tue, 04 Nov 2014 15:57:44 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dino Farinacci References: <5458E273.8060900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/MmqMMVpGLgmRpdFoxfE3cReY3hY Cc: "its@ietf.org" Subject: Re: [geonet/its] meet in HNL X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:58:03 -0000 Le 04/11/2014 15:45, Dino Farinacci a écrit : >> This is a status update about geonet/its. > > Are we meeting at IETF next week? Yes, let us meet at the IETF next week. I propose Tuesday at 17h30 for one hour or so. Alex > > Dino > > > From nobody Tue Nov 4 06:59:57 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0E61A8954 for ; Tue, 4 Nov 2014 06:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y48KfgYB9QB6 for ; Tue, 4 Nov 2014 06:59:54 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C454A1A702A for ; Tue, 4 Nov 2014 06:59:53 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id q108so10531369qgd.21 for ; Tue, 04 Nov 2014 06:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E+AQYPNL5EZSjzymliJhSv1nShUn6LRfRgKAFtqImXM=; b=MBtuMjI6gc55P8owls+5iyzzmnbFRoq3qDcAURdt+Xx5PAIbn9b5bmmXTScYpqreAd Sat44my6hkb6SswI/xipPBMS5jdJXmYwcGlqyRjKAjDlGEf8fXhgmsyPam/OIIan4reZ EMGAld0Yp55t2NeTsa63C1h1iO5Eml/I7nbzgMNFfpxCEho2+KQpA+RF/BYZVoogAxBd lhaWXXo7RghkjYD/mB04zOVQ/2Yfpk2ysiYtzFq37X+605xL5erP3p8QCV8AgVlPu18f E9SKdb1hb3wAstAmR5cAGrbJxf4+cXN1nHLHeLurfIahMyT+WreQnAhb9tLjIYogDLvA M+tQ== X-Received: by 10.140.21.36 with SMTP id 33mr45912162qgk.61.1415113192666; Tue, 04 Nov 2014 06:59:52 -0800 (PST) Received: from [192.168.1.37] (pool-72-92-10-132.phlapa.east.verizon.net. [72.92.10.132]) by mx.google.com with ESMTPSA id j11sm528930qaa.47.2014.11.04.06.59.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 06:59:52 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dino Farinacci In-Reply-To: <5458E968.8000105@gmail.com> Date: Tue, 4 Nov 2014 06:59:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A383107-ABD0-44D6-A298-D9E8D863DD45@gmail.com> References: <5458E273.8060900@gmail.com> <5458E968.8000105@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/its/9KEl_jnuTqHqLt43TzhUfO8ELZk Cc: "its@ietf.org" Subject: Re: [geonet/its] meet in HNL X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 14:59:55 -0000 Works for me. Dino > On Nov 4, 2014, at 6:57 AM, Alexandru Petrescu = wrote: >=20 > Le 04/11/2014 15:45, Dino Farinacci a =E9crit : >>> This is a status update about geonet/its. >>=20 >> Are we meeting at IETF next week? >=20 > Yes, let us meet at the IETF next week. >=20 > I propose Tuesday at 17h30 for one hour or so. >=20 > Alex >=20 >>=20 >> Dino >>=20 >>=20 >>=20 >=20 >=20 From kkarco2@g.uky.edu Tue Nov 4 08:42:42 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D661A9097 for ; Tue, 4 Nov 2014 08:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZUMTYhStlxu for ; Tue, 4 Nov 2014 08:42:39 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837111A9091 for ; Tue, 4 Nov 2014 08:42:20 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so9969472wiv.0 for ; Tue, 04 Nov 2014 08:42:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ySTHWMkIiNHLE18rA+lk/f5hGxyxfTKeb70u07esPB0=; b=gXW//37w0tAJrjHzn86HoFseSCT4v3lrWrlqq70CDm8dG6sfhbTcrwP4pOQriGAmum J3T9O8EObW+5eXyxbpCLeEP/ptBjkq7w74GPnjnmdY+VQgd/U9MB11ymNpd2n5n/NDiy TFA0y1BmFKega7EqfH+0ENS2u0obalA5WpI4Qkv42nyJ6C/Dku2Rwjd5hLiBDDAmaHY6 qvrtgEQVcIGgBofDFypZQEwZOwWuQUsMBZz+ZXVw1Y6FLfgrPn+kdZIwUHcJ9c6mxAO3 Bl8h0Nq7k9iEj3Ocw9fbmEBOm5ETJiahwiVuoExwX9Cbh3DIs44kTcW7QIsuaW3QqPyb dVFw== X-Gm-Message-State: ALoCoQl0yhovjIBMpVMkcWc2IGx8NYG/plal2JYGrgSRnJpEVIdeLe2LamTTizSsSGE+ooY4SyVy MIME-Version: 1.0 X-Received: by 10.180.11.227 with SMTP id t3mr25532482wib.45.1415119339133; Tue, 04 Nov 2014 08:42:19 -0800 (PST) Received: by 10.194.243.230 with HTTP; Tue, 4 Nov 2014 08:42:19 -0800 (PST) Date: Tue, 4 Nov 2014 11:42:19 -0500 Message-ID: From: "Arcot, Kiran K" To: its@ietf.org Content-Type: multipart/alternative; boundary=001a11c2400c8636ec05070b253e Archived-At: http://mailarchive.ietf.org/arch/msg/its/Coz1Q6eWFcvBItgNx1OUVgSiGiY X-Mailman-Approved-At: Wed, 05 Nov 2014 07:59:00 -0800 Subject: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 16:55:23 -0000 --001a11c2400c8636ec05070b253e Content-Type: text/plain; charset=UTF-8 Hello All, I am a graduate student at the University of Kentucky and I am looking at using 802.11p for communication between out quad-copters. To that end is anyone aware of any 802.11p USB dongles on the market? Are there any open source drivers (Linux specifically) that are in semi-usable state or in development? If so where can one find such a driver for 802.11p cards/USB dongles? Thanks, Kiran Arcot. --001a11c2400c8636ec05070b253e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,

I am a graduate student at t= he University of Kentucky and I am looking at using 802.11p for communicati= on between out quad-copters. To that end is anyone aware of any 802.11p USB= dongles on the market? Are there any open source drivers (Linux specifical= ly) that are in semi-usable state or in development?=C2=A0=C2=A0If so where can one find s= uch a=C2=A0driver for 802.11p cards/USB dongles?

Thanks,
= Kiran Arcot.
--001a11c2400c8636ec05070b253e-- From nobody Thu Nov 6 08:05:50 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0AB1A87F0 for ; Thu, 6 Nov 2014 08:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TW5AXXHr2sy for ; Thu, 6 Nov 2014 08:05:38 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F421A6F0E for ; Thu, 6 Nov 2014 08:04:11 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id ex7so1947162wid.10 for ; Thu, 06 Nov 2014 08:04:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=soRd9q6Tupm3ZW9zlJTW84v/4rJ11cNkZB7jjec5/tc=; b=Iin+eWQmR0qlvtY28ncn48UYnd8kbaaVqbuJJLRzryf23XHHa36Y0gvGK+IOb/Gngt ZKRMaJB0TKfCSmmSQaFNWyRl29q704VTR4TQnmoSc2f75/YckGCQ42jj5+YQxa4EwyKb ttup6N5MbKHJumX86yfWF1xY6zK1FYsJQP1kIRzukeN22YTkpHO0bu+kmAX/yxXwJMkN zrVSVS3BEFh66qY0wLUceNmOwunzKjjLv45ddCvdx89M0EoNpnZdzRTXwfyLec/ylrN9 iEUJ6k51b0K68TYYW2mUd+MXq/ATF5w6l6fFnwUZ9xNhb4Gorf9LssY72z39GUiOU02p GR5Q== X-Gm-Message-State: ALoCoQmAMRIKg6UW5mK9VlpEo2hMb4lrHsV6JKWvAC6S/q2/xjwVsxGVvBjAR2JlVqDtwoo3nxYJ MIME-Version: 1.0 X-Received: by 10.180.212.110 with SMTP id nj14mr42574123wic.45.1415289849777; Thu, 06 Nov 2014 08:04:09 -0800 (PST) Received: by 10.194.243.230 with HTTP; Thu, 6 Nov 2014 08:04:09 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Nov 2014 11:04:09 -0500 Message-ID: From: "Arcot, Kiran K" To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=001a11c34160c02288050732d869 Archived-At: http://mailarchive.ietf.org/arch/msg/its/V4qOjiPPekXcLJEAkdGcahoBlvw Cc: its@ietf.org Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 16:05:47 -0000 --001a11c34160c02288050732d869 Content-Type: text/plain; charset=UTF-8 Hello RR, The idea indeed is to comply with the standards and regulation already present. Thanks, Kiran. On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy wrote: > I'd suggest you look for 802.11a compliant dongles that have mad-wifi > or some other open source driver you can modify. I'd also recommend you > NOT use the 5.850-5.925GHz band since that band is reserved for ITS, > unless, of course, you plan on complying with the number of standards and > regulations already in place for use of the band. > > > > Cheers, > > > > RR > > > ------------------------------ > > *From:* Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Tuesday, November 04, 2014 10:42 AM > *To:* its@ietf.org > *Subject:* [geonet/its] 802.11p USB dongles? > > > > Hello All, > > > > I am a graduate student at the University of Kentucky and I am looking at > using 802.11p for communication between out quad-copters. To that end is > anyone aware of any 802.11p USB dongles on the market? Are there any open > source drivers (Linux specifically) that are in semi-usable state or in > development? If so where can one find such a driver for 802.11p > cards/USB dongles? > > > > Thanks, > > Kiran Arcot. > --001a11c34160c02288050732d869 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello RR,=C2=A0

The idea indeed is to c= omply with the standards and regulation already present.

Thanks,
Kiran.

<= div class=3D"gmail_quote">On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <= dickroy@alum.mit.edu> wrote:

I'd suggest you look for = 802.11a compliant dongles that have mad-wifi or some other open source driver you can modify.= =C2=A0 I'd also recommend you NOT use the 5.850-5.925GHz band since that band = is reserved for ITS, =C2=A0unless, of course, you plan on complying with the n= umber of standards and regulations already in place for use of the band.

=C2=A0

Cheers,<= /font>

=C2=A0

RR

=C2=A0

From: Arcot, Kir= an K [mailto:kiranarcot@= uky.edu]
Sent: Tuesday, November 04, = 2014 10:42 AM
To: its@ietf.org
Subject: [geonet/its] 802.11= p USB dongles?

=C2=A0

Hello All,

=C2=A0

I am a graduate student at the Univers= ity of Kentucky and I am looking at using 802.11p for communication between out quad-copter= s. To that end is anyone aware of any 802.11p USB dongles on the market? Are t= here any open source drivers (Linux specifically) that are in semi-usable state = or in development?=C2=A0=C2=A0If so where can one find su= ch a=C2=A0driver for 802.11p cards/USB dongles?

=C2=A0

Thanks,

Kiran Arcot.


--001a11c34160c02288050732d869-- From nobody Thu Nov 6 08:44:52 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156E1A8895 for ; Thu, 6 Nov 2014 08:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apm80yqPFvwy for ; Thu, 6 Nov 2014 08:44:49 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1385D1A888A for ; Thu, 6 Nov 2014 08:44:48 -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 sA6GiiOh011407; Thu, 6 Nov 2014 17:44:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09A45205CE2; Thu, 6 Nov 2014 17:44:54 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EE410205CB5; Thu, 6 Nov 2014 17:44:53 +0100 (CET) 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 sA6GiX7q022024; Thu, 6 Nov 2014 17:44:44 +0100 Message-ID: <545BA571.5010502@gmail.com> Date: Thu, 06 Nov 2014 17:44:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Arcot, Kiran K" , dickroy@alum.mit.edu References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/pnWJ4qoYmrAmxqr5ogUfsV7q6GE Cc: its@ietf.org Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 16:44:51 -0000 Well - there may be ways to comply to the legislation of 5.9GHz and high power levels for ITS, if the flying experimentation happens indoors (hangar). But coming back to the original question: is there an USB dongle 802.11p? The manufacturer I am familiar with (UNEX, not to name it) only does mini-PCI 802.11p cards. An 802.11p USB dongle format may be useful to some of the most constrained linux platforms which feature USB rather than mini-PCI. If this is done, and given the easiness of running IP on 802.11p, I'd be thrilled to see IP between flying objects. Alex Le 06/11/2014 17:04, Arcot, Kiran K a écrit : > Hello RR, > > The idea indeed is to comply with the standards and regulation already > present. > > Thanks, > Kiran. > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > wrote: > > __ __ __ > > I'd suggest you look for 802.11a compliant dongles that have > mad-wifi or some other open source driver you can modify. I'd also > recommend you NOT use the 5.850-5.925GHz band since that band is > reserved for ITS, unless, of course, you plan on complying with the > number of standards and regulations already in place for use of the > band.____ > > __ __ > > Cheers,____ > > __ __ > > RR ____ > > __ __ > > ------------------------------------------------------------------------ > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > ] > *Sent:* Tuesday, November 04, 2014 10:42 AM > *To:* its@ietf.org > *Subject:* [geonet/its] 802.11p USB dongles?____ > > __ __ > > Hello All,____ > > __ __ > > I am a graduate student at the ____University__ of __Kentucky____ > and I am looking at using 802.11p for communication between out > quad-copters. To that end is anyone aware of any 802.11p USB dongles > on the market? Are there any open source drivers (Linux > specifically) that are in semi-usable state or in development? If > so where can one find such a driver for 802.11p cards/USB dongles?____ > > __ __ > > Thanks,____ > > Kiran Arcot.____ > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Fri Nov 7 04:52:18 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7171ACFCF for ; Fri, 7 Nov 2014 04:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_uVaFSvg_iq for ; Fri, 7 Nov 2014 04:52:13 -0800 (PST) Received: from radmz1.prettl-elektronik.de (radmz1.prettl-elektronik.de [212.185.50.242]) by ietfa.amsl.com (Postfix) with ESMTP id 852421ACFCD for ; Fri, 7 Nov 2014 04:52:12 -0800 (PST) Received: from rasrv02.prettl-elektronik.de ([10.76.0.20]:1756) by utm.prettl-electronics.com with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xmj1N-0000zJ-2o; Fri, 07 Nov 2014 13:52:09 +0100 Received: from RASRV50.prettl-elektronik.de ([10.76.0.50]) by RASRV02.prettl-elektronik.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Nov 2014 13:52:09 +0100 Received: from RASRV50.prettl-elektronik.de ([::1]) by RASRV50.prettl-elektronik.de ([::1]) with mapi id 14.02.0298.004; Fri, 7 Nov 2014 13:52:09 +0100 From: "Varadi , Andras (lesswire AG Ungarn)" To: "Arcot, Kiran K" Thread-Topic: [geonet/its] 802.11p USB dongles? Thread-Index: AQHP+RF1za9YJSv2j0WIIdEjwpncfpxTxPdo///6BICAAWCe4A== Date: Fri, 7 Nov 2014 12:52:08 +0000 Message-ID: References: <545BA571.5010502@gmail.com> In-Reply-To: <545BA571.5010502@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.100.61] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2014 12:52:09.0814 (UTC) FILETIME=[A4B9D760:01CFFA89] Archived-At: http://mailarchive.ietf.org/arch/msg/its/77SzXcRtNB-PV3KindJ2ZR8UsLY Cc: "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 12:52:17 -0000 Hi Kiran I also have some serious concerns about outdoor usage of ETSI G5 in the EU.= .. Just for an example: how will You tolerate DCC (Decentralized Congestion Co= ntrol) in Your use case? (which will not let You transmit just any time - a= nd You need DCC to transmit and comply the standards) USB 11p module (available next year) - http://www.lesswire.com/en/products/= wireless-modules/car2x/wibear-its-car2x/overview/ More info on availibility from the distributors: http://www.lesswire.com/en= /distributors/commercials-new/ =DCdv=F6zlettel / Best regards, =A0=A0 Andr=E1s V=E1radi =A0=A0=A0 =A0Project Manager - C2X/ITS Systems Customer Support Wireless Modules =A0=A0=A0=A0 Automotive & WLAN Group=20 =A0=A0=A0=A0 lesswire=A0=A0 Hungary | Office: +36 23521 667 | Email: Varadi= @lesswire.com=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, November 06, 2014 5:45 PM To: Arcot, Kiran K; dickroy@alum.mit.edu Cc: its@ietf.org Subject: Re: [geonet/its] 802.11p USB dongles? Well - there may be ways to comply to the legislation of 5.9GHz and high po= wer levels for ITS, if the flying experimentation happens indoors (hangar). But coming back to the original question: is there an USB dongle 802.11p? The manufacturer I am familiar with (UNEX, not to name it) only does mini-P= CI 802.11p cards. An 802.11p USB dongle format may be useful to some of the most constrained = linux platforms which feature USB rather than mini-PCI. If this is done, and given the easiness of running IP on 802.11p, I'd be th= rilled to see IP between flying objects. Alex Le 06/11/2014 17:04, Arcot, Kiran K a =E9crit : > Hello RR, > > The idea indeed is to comply with the standards and regulation already=20 > present. > > Thanks, > Kiran. > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > wrote: > > __ __ __ > > I'd suggest you look for 802.11a compliant dongles that have > mad-wifi or some other open source driver you can modify. I'd also > recommend you NOT use the 5.850-5.925GHz band since that band is > reserved for ITS, unless, of course, you plan on complying with the > number of standards and regulations already in place for use of the > band.____ > > __ __ > > Cheers,____ > > __ __ > > RR ____ > > __ __ > > =20 > ---------------------------------------------------------------------- > -- > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > ] > *Sent:* Tuesday, November 04, 2014 10:42 AM > *To:* its@ietf.org > *Subject:* [geonet/its] 802.11p USB dongles?____ > > __ __ > > Hello All,____ > > __ __ > > I am a graduate student at the ____University__ of __Kentucky____ > and I am looking at using 802.11p for communication between out > quad-copters. To that end is anyone aware of any 802.11p USB dongles > on the market? Are there any open source drivers (Linux > specifically) that are in semi-usable state or in development? If > so where can one find such a driver for 802.11p cards/USB=20 > dongles?____ > > __ __ > > Thanks,____ > > Kiran Arcot.____ > > > > > _______________________________________________ > 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 nobody Fri Nov 7 10:04:24 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FED1AD3D3 for ; Fri, 7 Nov 2014 10:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiOZsuXknAse for ; Fri, 7 Nov 2014 10:04:18 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E44D1AD3C2 for ; Fri, 7 Nov 2014 10:04:18 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so5308213wiv.15 for ; Fri, 07 Nov 2014 10:04:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y2ywVLIthoGvusOMaQOrWRiaboGOyW09T3bSJZqFZOI=; b=eY39T0DN9kVqwg6QjbK/e1Qx9ZutdH8aeQMbKogdNsnIbVn1Gm3stZ6LOMbUkcBa1X xX4/NUreY7zp8HFJ0tdAUa5ajPksvkWKlG07bmHGJ3EU7khSEaqOqS6TYDDTAsGgk2gK KngjKNHR321GS9XQkwHTGpMwb99ITEsJ2urA6Sz6tIEVjpAprBIsC7sVCw6476N1y7EO uiCtChM6/uOHRr1ksAB6+ugeXRtmyNuIIFjTctkKUASJjV4Od0TtzP+EpH6Qqi3KPava bycLEJA/t6b4/DwzjMTr3sjoRSxSttrFKYTGPd0eXRq5N8iQKdb22SjuSOBacX4tYLft Z4WA== X-Gm-Message-State: ALoCoQmKyZNAFj7fdYBKOlfJvFJdQXL0fkz2p48Km0EVRiRUnJR0CPY8wAuQeftI+isA18/WZMKK MIME-Version: 1.0 X-Received: by 10.194.71.84 with SMTP id s20mr16083918wju.128.1415383456894; Fri, 07 Nov 2014 10:04:16 -0800 (PST) Received: by 10.194.243.230 with HTTP; Fri, 7 Nov 2014 10:04:16 -0800 (PST) In-Reply-To: References: <545BA571.5010502@gmail.com> Date: Fri, 7 Nov 2014 13:04:16 -0500 Message-ID: From: "Arcot, Kiran K" To: "Varadi , Andras (lesswire AG Ungarn)" Content-Type: multipart/alternative; boundary=047d7bfced302b752a050748a460 Archived-At: http://mailarchive.ietf.org/arch/msg/its/5CyPRREFoZ6Il9tc0W8fUgi6j0Y Cc: "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:04:22 -0000 --047d7bfced302b752a050748a460 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Andras, Thanks for the links. Will there be support from lesswire for Linux systems for these USB modules or will the users have to come up with the drivers themselves? Also, what do you think the price of USB module will be? Or is it better to ask one of the distributors that question? As for your DCC question, I have only now started looking in to the whole 802.11p shebang and haven't completely dug in to the requirements to comply with the standards yet. I have been asking questions of Alexandru Petrescu in another email chain and following his suggestions of first trying to find a hardware/driver combination that will allow me to transmit in the 802.11p frequency band with IP. In short, to answer your question about DCC, I don't know how to handle that just yet. Thanks, Kiran. On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) < Varadi@lesswire.com> wrote: > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI G5 in the > EU... > Just for an example: how will You tolerate DCC (Decentralized Congestion > Control) in Your use case? (which will not let You transmit just any time= - > and You need DCC to transmit and comply the standards) > > USB 11p module (available next year) - > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car= 2x/overview/ > More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > =C3=9Cdv=C3=B6zlettel / Best regards, > Andr=C3=A1s V=C3=A1radi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 | Email: > Varadi@lesswire.com > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of 5.9GHz and high > power levels for ITS, if the flying experimentation happens indoors > (hangar). > > But coming back to the original question: is there an USB dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) only does > mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most constraine= d > linux platforms which feature USB rather than mini-PCI. > > If this is done, and given the easiness of running IP on 802.11p, I'd be > thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit : > > Hello RR, > > > > The idea indeed is to comply with the standards and regulation already > > present. > > > > Thanks, > > Kiran. > > > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > > wrote: > > > > __ __ __ > > > > I'd suggest you look for 802.11a compliant dongles that have > > mad-wifi or some other open source driver you can modify. I'd also > > recommend you NOT use the 5.850-5.925GHz band since that band is > > reserved for ITS, unless, of course, you plan on complying with th= e > > number of standards and regulations already in place for use of the > > band.____ > > > > __ __ > > > > Cheers,____ > > > > __ __ > > > > RR ____ > > > > __ __ > > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > > ] > > *Sent:* Tuesday, November 04, 2014 10:42 AM > > *To:* its@ietf.org > > *Subject:* [geonet/its] 802.11p USB dongles?____ > > > > __ __ > > > > Hello All,____ > > > > __ __ > > > > I am a graduate student at the ____University__ of __Kentucky____ > > and I am looking at using 802.11p for communication between out > > quad-copters. To that end is anyone aware of any 802.11p USB dongle= s > > on the market? Are there any open source drivers (Linux > > specifically) that are in semi-usable state or in development? If > > so where can one find such a driver for 802.11p cards/USB > > dongles?____ > > > > __ __ > > > > Thanks,____ > > > > Kiran Arcot.____ > > > > > > > > > > _______________________________________________ > > 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 > --047d7bfced302b752a050748a460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andras,

Thanks for the links. Will t= here be support from lesswire for Linux systems for these USB modules or wi= ll the users have to come up with the drivers themselves? Also, what do you= think the price of USB module will be? Or is it better to ask one of the d= istributors that question?

As for your DCC questio= n, I have only now started looking in to the whole 802.11p shebang and have= n't completely dug in to the requirements to comply with the standards = yet. I have been asking questions of Alexandru Petrescu in another email ch= ain and following his suggestions of first trying to find a hardware/driver= combination that will allow me to transmit in the 802.11p frequency band w= ith IP.

In short, to answer your question about DC= C, I don't know how to handle that just yet.

<= br>
Thanks,
Kiran.


<= div>

On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) <Varadi@lesswire.com> wrote:
http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-= car2x/overview/
More info on availibility from the distributors: http://www.les= swire.com/en/distributors/commercials-new/

=C3=9Cdv=C3=B6zlettel / Best regards,
=C2=A0=C2=A0 Andr=C3=A1s V=C3=A1radi

=C2=A0=C2=A0=C2=A0 =C2=A0Project Manager - C2X/ITS Systems
=C2=A0 =C2=A0 =C2=A0Customer Support Wireless Modules

=C2=A0=C2=A0=C2=A0=C2=A0 Automotive & WLAN Group
=C2=A0=C2=A0=C2=A0=C2=A0 lesswire=C2=A0=C2=A0 Hungary | Office: +36 23521 667 | Email: <= a href=3D"mailto:Varadi@lesswire.com">Varadi@lesswire.com


-----Original Message-----
From: its [mailto:its-bounces@ietf.= org] On Behalf Of Alexandru Petrescu
Sent: Thursday, November 06, 2014 5:45 PM
To: Arcot, Kiran K; dickroy@alum.mi= t.edu
Cc: its@ietf.org
Subject: Re: [geonet/its] 802.11p USB dongles?

Well - there may be ways to = comply to the legislation of 5.9GHz and high power levels for ITS, if the f= lying experimentation happens indoors (hangar).

But coming back to the original question: is there an USB dongle 802.11p?
The manufacturer I am familiar with (UNEX, not to name it) only does mini-P= CI 802.11p cards.

An 802.11p USB dongle format may be useful to some of the most constrained = linux platforms which feature USB rather than mini-PCI.

If this is done, and given the easiness of running IP on 802.11p, I'd b= e thrilled to see IP between flying objects.

Alex


Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit :
> Hello RR,
>
> The idea indeed is to comply with the standards and regulation already=
> present.
>
> Thanks,
> Kiran.
>
> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <dickroy@alum.mit.edu
> <mailto:dickroy@alum.mit.ed= u>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0__ __ __
>
>=C2=A0 =C2=A0 =C2=A0I'd suggest you look for 802.11a compliant dong= les that have
>=C2=A0 =C2=A0 =C2=A0mad-wifi or some other open source driver you can m= odify. I'd also
>=C2=A0 =C2=A0 =C2=A0recommend you NOT use the 5.850-5.925GHz band since= that band is
>=C2=A0 =C2=A0 =C2=A0reserved for ITS,=C2=A0 unless, of course, you plan= on complying with the
>=C2=A0 =C2=A0 =C2=A0number of standards and regulations already in plac= e for use of the
>=C2=A0 =C2=A0 =C2=A0band.____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Cheers,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0RR ____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>
> ----------------------------------------------------------------------=
> --
>
>=C2=A0 =C2=A0 =C2=A0*From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu
>=C2=A0 =C2=A0 =C2=A0<mailto:ki= ranarcot@uky.edu>]
>=C2=A0 =C2=A0 =C2=A0*Sent:* Tuesday, November 04, 2014 10:42 AM
>=C2=A0 =C2=A0 =C2=A0*To:* its@ietf.org<= /a> <mailto:its@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* [geonet/its] 802.11p USB dongles?____ >
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Hello All,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0I am a graduate student at the ____University__ of = __Kentucky____
>=C2=A0 =C2=A0 =C2=A0and I am looking at using 802.11p for communication= between out
>=C2=A0 =C2=A0 =C2=A0quad-copters. To that end is anyone aware of any 80= 2.11p USB dongles
>=C2=A0 =C2=A0 =C2=A0on the market? Are there any open source drivers (L= inux
>=C2=A0 =C2=A0 =C2=A0specifically) that are in semi-usable state or in d= evelopment?=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0so where can one find such a driver for 802.11p car= ds/USB
> dongles?____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Thanks,____
>
>=C2=A0 =C2=A0 =C2=A0Kiran Arcot.____
>
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>


_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its

--047d7bfced302b752a050748a460-- From nobody Fri Nov 7 14:23:06 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50E1A1B7C for ; Fri, 7 Nov 2014 14:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWyECG9AkUC0 for ; Fri, 7 Nov 2014 14:23:01 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE241A1B5B for ; Fri, 7 Nov 2014 14:23:01 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so6754977iga.8 for ; Fri, 07 Nov 2014 14:23:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xZ+Axk4j7xrZ25X49/PPYH3B3bgmJm3ULrZVb130Tv8=; b=AdLNxXfOfTbix+S6n28qP/Ie1q1erJFYlbCWFnf16VPPHiioqIBQJM9J7FEoF7/CLb /CLwYRK6dSduqwPqMgsOKFG+VxPEyt5p8FOFDlkZfvPRcOIjdbg3yoDacKEvGIvNkVFN Ct8p6bDKhVu5dtoQDDYfzeEyjteRxFtO84j2Gu9Qjl/L7j3UcAfO4TajRjiQoTOImsuV DOl7jxqurh6gMifculivViGtPZX+S3tbHD1RwDkgKSNbFbdIAItQaXz4M+uRLFgYsOs2 vO3fPll9StBiT9dAFRXQfWaln4zr9dnsYyH1yVZXzvgFJ/Uwh5w/Jfj4zyJq4pmKir/b klMQ== X-Gm-Message-State: ALoCoQlqa+p8JY35mEJIXTEPOa3kdeBkl31arnOgyJhzPrQnQqDVKbb+37lEpFT2uUXYpZWMCp9Z MIME-Version: 1.0 X-Received: by 10.107.138.159 with SMTP id c31mr5787581ioj.88.1415398980748; Fri, 07 Nov 2014 14:23:00 -0800 (PST) Received: by 10.64.230.232 with HTTP; Fri, 7 Nov 2014 14:23:00 -0800 (PST) In-Reply-To: References: <545BA571.5010502@gmail.com> Date: Fri, 7 Nov 2014 17:23:00 -0500 Message-ID: From: "Arcot, Kiran K" To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=001a113feb7676d3e405074c4160 Archived-At: http://mailarchive.ietf.org/arch/msg/its/NqdQZnV_kEcmaZytQtT0bZkBsSw Cc: "Varadi , Andras \(lesswire AG Ungarn\)" , "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 22:23:05 -0000 --001a113feb7676d3e405074c4160 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy wrote: > A few things to remember: > > > > 1) DCC is not yet mandatory anywhere and hopefully that situation will no= t > change. > > 2) What needs to be done to address the congestion problem is to use 21rs= t > century MAC/PHY technology, not 20th century technology, and it's > technology that's available now. > > 2) If DCC does become mandatory, it is likely to be only be conditionally > so (at least in Europe), conditioned on the use of ETSI's GeoNetworking > protocol, and there is little to no chance of that protocol getting out o= f > the research labs. > > 3) The coupling that people seem to believe exists between 11p and IPv6 i= s > a fiction in their minds. There is NO coupling. IPv6 can be used as wit= h > any other lower layer protocols independent of anything to do with 11p. > That said, there are issues of how to set up addresses in ad hoc networks > of vehicles, but bridges and meshes (layer 2 addressing) are much better > suited for that. > > 4) IPv6 networking is only required when attempting to use networks to > communicate between peers. I'm guessing your aviation application is not > attempting to control a helicopter over the internet from your home. Any > use of a non-deterministic network for such applications is ... well ... > just not a good idea. > > Hehehe. No, I am not trying to control a helicopter over the internet :-) As I mentioned in the original post, I want to be able to communicate between the quad-copters while they are in flight. I know there are methods where you can communicate over 802.11 b/g/n with WiFi-P2P/Direct (not sure which term is more appropriate, Direct probably) where one quad-copter could act as a soft AP and the others could act as clients. And, I also know that there are people who already stream video while the quad-copters are in flight over Wi-Fi as well as actually controlling the flying objects with a Wi-Fi controller. But, that is not what I am looking for. I want to be able to send direction/speed/heading information from the quads to each other while they are in flight. A radar application so to speak, where each quad essentially is aware of the other quads in the vicinity. Mind you, the direction/speed/heading is just the first piece of information that I want to share among the quads while they are in flight. If I can achieve this I want to be able to do more than just information sharing. Since, I don't want to set up a quad-copter as a soft AP I thought 802.11p is appropriate since that operates outside of a BSS context. I may be wrong. I just don't know. I am researching this stuff to figure out what is feasible and what is not. > > > Finally, as I suggested in a previous posting, you can modify a .11a USB > dongle to run in the 5.9GHz band (i.e. create a .11p dongle) if you have > access to the firmware. > Indeed, I have been looking at USB 802.11a dongles as you suggested and I can find dual band dongles with chipsets such as RALink RT3572. This is just an example. And http://wireless.kernel.org/en/users/Drivers indicates that there are drivers available for RALink chipsets. So, theoretically, it may be possible to modify the driver. But I have not yet researched if firmware for the actual chipset is available or not. And the spec sheets of the chipsets that I have looked at indicate that the frequency range of the 802.11a dongles goes up to only 5825 MHz (802.11a compliance). I assume that is the reason you say I need access to the firmware so that I can push the frequency range between 5855 MHz and 5925 MHz for 802.11p compliance. Thanks, Kiran. > > > RR > ------------------------------ > > *From:* Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Friday, November 07, 2014 12:04 PM > *To:* Varadi , Andras (lesswire AG Ungarn) > > *Cc:* its@ietf.org > *Subject:* Re: [geonet/its] 802.11p USB dongles? > > > > Hi Andras, > > > > Thanks for the links. Will there be support from lesswire for Linux > systems for these USB modules or will the users have to come up with the > drivers themselves? Also, what do you think the price of USB module will > be? Or is it better to ask one of the distributors that question? > > > > As for your DCC question, I have only now started looking in to the whole > 802.11p shebang and haven't completely dug in to the requirements to comp= ly > with the standards yet. I have been asking questions of Alexandru Petresc= u > in another email chain and following his suggestions of first trying to > find a hardware/driver combination that will allow me to transmit in the > 802.11p frequency band with IP. > > > > In short, to answer your question about DCC, I don't know how to handle > that just yet. > > > > > > Thanks, > > Kiran. > > > > > > > > > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) < > Varadi@lesswire.com> wrote: > > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI G5 in the > EU... > Just for an example: how will You tolerate DCC (Decentralized Congestion > Control) in Your use case? (which will not let You transmit just any time= - > and You need DCC to transmit and comply the standards) > > USB 11p module (available next year) - > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car= 2x/overview/ > More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > =C3=9Cdv=C3=B6zlettel / Best regards, > Andr=C3=A1s V=C3=A1radi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 | Email: > Varadi@lesswire.com > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of 5.9GHz and high > power levels for ITS, if the flying experimentation happens indoors > (hangar). > > But coming back to the original question: is there an USB dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) only does > mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most constraine= d > linux platforms which feature USB rather than mini-PCI. > > If this is done, and given the easiness of running IP on 802.11p, I'd be > thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit : > > Hello RR, > > > > The idea indeed is to comply with the standards and regulation already > > present. > > > > Thanks, > > Kiran. > > > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > > wrote: > > > > __ __ __ > > > > I'd suggest you look for 802.11a compliant dongles that have > > mad-wifi or some other open source driver you can modify. I'd also > > recommend you NOT use the 5.850-5.925GHz band since that band is > > reserved for ITS, unless, of course, you plan on complying with th= e > > number of standards and regulations already in place for use of the > > band.____ > > > > __ __ > > > > Cheers,____ > > > > __ __ > > > > RR ____ > > > > __ __ > > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > > ] > > *Sent:* Tuesday, November 04, 2014 10:42 AM > > *To:* its@ietf.org > > *Subject:* [geonet/its] 802.11p USB dongles?____ > > > > __ __ > > > > Hello All,____ > > > > __ __ > > > > I am a graduate student at the ____University__ of __Kentucky____ > > and I am looking at using 802.11p for communication between out > > quad-copters. To that end is anyone aware of any 802.11p USB dongle= s > > on the market? Are there any open source drivers (Linux > > specifically) that are in semi-usable state or in development? If > > so where can one find such a driver for 802.11p cards/USB > > dongles?____ > > > > __ __ > > > > Thanks,____ > > > > Kiran Arcot.____ > > > > > > > > > > _______________________________________________ > > 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 > > > --001a113feb7676d3e405074c4160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy <dickroy@alum.mit.edu> wrote:

A few things to remember:

=C2=A0

1) DCC is not yet mandatory any= where and hopefully that situation will not change.=C2=A0

2) What needs to be done to add= ress the congestion problem is to use 21rst century MAC/PHY technology, not 20th cen= tury technology, and it's technology that's available now.=

2) If DCC does become mandatory= , it is likely to be only be conditionally so (at least in Europe), conditioned on the use of ETSI's GeoNetworking protocol, and there is l= ittle to no chance of that protocol getting out of the research labs.<= /span>

3) The coupling that people see= m to believe exists between 11p and IPv6 is a fiction in their minds.=C2=A0 Ther= e is NO coupling.=C2=A0 IPv6 can be used as with any other lower layer protocols in= dependent of anything to do with 11p.=C2=A0 That said, there are issues of how to set= up addresses in ad hoc networks of vehicles, but bridges and meshes (layer 2 addressing) are much better suited for that.

4) IPv6 networking is only requ= ired when attempting to use networks to communicate between peers.=C2=A0 I'm gues= sing your aviation application is not attempting to control a helicopter over the internet from your home.=C2=A0 Any use of a non-deterministic network for s= uch applications is ... well ... just not a good idea.

=

Hehehe. No, I am not trying to contr= ol a helicopter over the internet :-) =C2=A0As I mentioned in the original = post, I want to be able to communicate between the quad-copters while they = are in flight. I know there are methods where you can communicate over 802.= 11 b/g/n with WiFi-P2P/Direct (not sure which term is more appropriate, Dir= ect probably) where one quad-copter could act as a soft AP and the others c= ould act as clients. And, I also know that there are people who already str= eam video while the quad-copters are in flight over Wi-Fi as well as actual= ly controlling the flying objects with a Wi-Fi controller.

But, that is not what I am looking for. I want to be able to send = direction/speed/heading information from the quads to each other while they= are in flight. A radar application so to speak, where each quad essentiall= y is aware of the other quads in the vicinity. Mind you, the direction/spee= d/heading is just the first piece of information that I want to share among= the quads while they are in flight. If I can achieve this I want to be abl= e to do more than just information sharing. Since, I don't want to set = up a quad-copter as a soft AP I thought 802.11p is appropriate since that o= perates outside of a BSS context. I may be wrong. I just don't know. I = am researching this stuff to figure out what is feasible and what is not.

=C2=A0

=C2=A0

Finally, as I suggested in a pr= evious posting, you can modify a .11a USB dongle to run in the 5.9GHz band (i.e. c= reate a .11p dongle) if you have access to the firmware.

<= /div>

Indeed, I have been looking at USB 80= 2.11a dongles as you suggested and I can find dual band dongles with chipse= ts such as RALink RT3572. This is just an example. And=C2=A0http://wireless.kernel.org/en/user= s/Drivers indicates that there are drivers available for RALink chipset= s. So, theoretically, it may be possible to modify the driver. But I have n= ot yet researched if firmware for the actual chipset is available or not. A= nd the spec sheets of the chipsets that I have looked at indicate that the = frequency range of the 802.11a dongles goes up to only 5825 MHz (802.11a co= mpliance).

I assume that is the reason you say I n= eed access to the firmware so that I can push the frequency range between 5= 855 MHz and 5925 MHz for 802.11p compliance.

Thank= s,
Kiran.
=C2=A0

=C2=A0

RR<= /p>

From: Arcot, Kiran= K [mailto:kiranarcot@= uky.edu]
Sent: Friday, November 07, 2= 014 12:04 PM
To: Varadi , Andras (lesswir= e AG Ungarn)


Cc: its@ietf.org
Subject: Re: [geonet/its] 80= 2.11p USB dongles?

=C2=A0

Hi Andras,

=C2=A0

Thanks for the links. Will there be support from lessw= ire for Linux systems for these USB modules or will the users have to come up with the drivers themselves? Also, what do you think the price of USB module will be= ? Or is it better to ask one of the distributors that question?

=C2=A0

As for your DCC question, I have only now started look= ing in to the whole 802.11p shebang and haven't completely dug in to the requirements= to comply with the standards yet. I have been asking questions of Alexandru Petrescu in another email chain and following his suggestions of first tryi= ng to find a hardware/driver combination that will allow me to transmit in the 802.11p frequency band with IP.

=C2=A0

In short, to answer your question about DCC, I don'= ;t know how to handle that just yet.

=C2=A0

=C2=A0

Thanks,

Kiran.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lessw= ire AG Ungarn) <Varadi@lesswir= e.com> wrote:

Hi Kiran

I also have some serious concerns about outdoor usage of ETSI G5 in the EU.= ..
Just for an example: how will You tolerate DCC (Decentralized Congestion Control) in Your use case? (which will not let You transmit just any time -= and You need DCC to transmit and comply the standards)

USB 11p module (available next year) - http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-= car2x/overview/
More info on availibility from the distributors: http://www.lesswire.com/en/distributors/commercia= ls-new/

=C3=9Cdv=C3=B6zlettel / Best regards,
=C2=A0=C2=A0 Andr=C3=A1s V=C3=A1radi

=C2=A0=C2=A0=C2=A0 =C2=A0Project Manager - C2X/ITS Systems
=C2=A0 =C2=A0 =C2=A0Customer Support Wireless Modules

=C2=A0=C2=A0=C2=A0=C2=A0 Automotive & WLAN Group
=C2=A0=C2=A0=C2=A0=C2=A0 lesswire=C2=A0=C2=A0 Hungary<= u> | Office: +36 23521 667 | Email: Varadi@lesswire.com


-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Thursday, November 06, 2014 5:45 PM
To: Arcot, Kiran K; dickroy@alum.mit.edu
Cc: its@ietf.org
Subject: Re: [geonet/its] 802.11p USB dongles?

Well - there may be ways to comply to the legislation = of 5.9GHz and high power levels for ITS, if the flying experimentation happens indoors (hangar).

But coming back to the original question: is there an USB dongle 802.11p?
The manufacturer I am familiar with (UNEX, not to name it) only does mini-P= CI 802.11p cards.

An 802.11p USB dongle format may be useful to some of the most constrained linux platforms which feature USB rather than mini-PCI.

If this is done, and given the easiness of running IP on 802.11p, I'd b= e thrilled to see IP between flying objects.

Alex


Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit :
> Hello RR,
>
> The idea indeed is to comply with the standards and regulation already=
> present.
>
> Thanks,
> Kiran.
>
> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <dickroy@alum.mit.edu
> <mailto:d= ickroy@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0__ __ __
>
>=C2=A0 =C2=A0 =C2=A0I'd suggest you look for 802.11a compliant dong= les that have
>=C2=A0 =C2=A0 =C2=A0mad-wifi or some other open source driver you can modify. I'd also
>=C2=A0 =C2=A0 =C2=A0recommend you NOT use the 5.850-5.925GHz band since that band is
>=C2=A0 =C2=A0 =C2=A0reserved for ITS,=C2=A0 unless, of course, you plan= on complying with the
>=C2=A0 =C2=A0 =C2=A0number of standards and regulations already in plac= e for use of the
>=C2=A0 =C2=A0 =C2=A0band.____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Cheers,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0RR ____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>
> ----------------------------------------------------------------------=
> --
>
>=C2=A0 =C2=A0 =C2=A0*From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu
>=C2=A0 =C2=A0 =C2=A0<mailto:kiranarcot@uky.edu>]
>=C2=A0 =C2=A0 =C2=A0*Sent:* Tuesday, November 04, 2014 10:42 AM
>=C2=A0 =C2=A0 =C2=A0*To:* its@ietf.org <mailto:its@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* [geonet/its] 802.11p USB dongles?____ >
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Hello All,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0I am a graduate student at the ____University__ of __Kentucky____
>=C2=A0 =C2=A0 =C2=A0and I am looking at using 802.11p for communication between out
>=C2=A0 =C2=A0 =C2=A0quad-copters. To that end is anyone aware of any 802.11p USB dongles
>=C2=A0 =C2=A0 =C2=A0on the market? Are there any open source drivers (L= inux
>=C2=A0 =C2=A0 =C2=A0specifically) that are in semi-usable state or in development?=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0so where can one find such a driver for 802.11p cards/USB
> dongles?____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Thanks,____
>
>=C2=A0 =C2=A0 =C2=A0Kiran Arcot.____
>
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>


_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its

=C2=A0


--001a113feb7676d3e405074c4160-- From nobody Fri Nov 7 16:24:55 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09D1A0086 for ; Fri, 7 Nov 2014 16:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YCygo_hiMHf for ; Fri, 7 Nov 2014 16:24:49 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DB11A000E for ; Fri, 7 Nov 2014 16:24:49 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id ft15so4227967pdb.35 for ; Fri, 07 Nov 2014 16:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=uRNhRe5zxlrNo1VLp40rqjBVu0xlnG7pLJmcIgXLqsg=; b=W0cDSeEM8t1LbSduVr/JJKcSMj7tVyh5U6Rzv5Z52Tyt4se8Cc1yQeJ5D488bu2Wis r2teT2pGF7AzAXixzSHKcA0Al7KiYXMABoa4w1TXQNA4ldqyPbMLou9GW5BeU7IIuV6z osJf+qQBwdTjqXmF0J29Dg1cfY8jAKwrTGQ5Ds7h0wH5zrCjAlh/nEM1qo0hG2bOxwaV Ng3ASEAcEXoJ6tYIKAw6EImylnCLbTvMFqFyoWWueToNRTowzon0MQFbwei8Od9qcljY GRxTRDuUrNMgnSy5V1bAQgbeynqg2aWODw9lJxbD3D9I5vjJcbL8O5SbrxCtQVEqbm+c amEA== X-Received: by 10.68.189.136 with SMTP id gi8mr15857682pbc.54.1415406288687; Fri, 07 Nov 2014 16:24:48 -0800 (PST) Received: from [192.168.1.103] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id gy5sm9774432pbc.68.2014.11.07.16.24.47 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Fri, 07 Nov 2014 16:24:48 -0800 (PST) Message-ID: <1415406286.23933.58.camel@localhost.localdomain> From: Rex Buddenberg To: "Arcot, Kiran K" Date: Fri, 07 Nov 2014 16:24:46 -0800 In-Reply-To: References: <545BA571.5010502@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/b_MxWUSS0kpY-MlyPdpflTjYPuU Cc: dickroy@alum.mit.edu, "Varadi , Andras \(lesswire AG Ungarn\)" , "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:24:53 -0000 Kiran, Some suggested amendments to the dialog below: DCC is a congestion control scheme; as such it falls in the general category of QoS control. MACs are access control algorithms and applicable to a single network segment. Don't confuse the two. More below... On Fri, 2014-11-07 at 17:23 -0500, Arcot, Kiran K wrote: > > > On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy > wrote: > A few things to remember: > > > > 1) DCC is not yet mandatory anywhere and hopefully that > situation will not change. > > 2) What needs to be done to address the congestion problem is > to use 21rst century MAC/PHY technology, not 20th century > technology, and it's technology that's available now. I differ with RR on terminology and a look back in radio history pre-Internet is why. There are two kinds of MACs out there: contention and contention-free. In Ye Olde Radio days, operators had these algorithms embedded in their operating protocols: Contention access was known in YORD as 'free net'. Contention-free access was known as 'directed net'. Free nets are, of course, simple -- a few rules like listen before talk so you don't stomp on somebody else's transmission. There's an assumption that everybody can hear everybody else -- if you can't hear someone else, then your set up to unwittingly jam that station. A pure CSMA/CD network has no station in charge -- all are theoretically equal [abusers]. The overload characteristics of free nets are identical to those of CSMA MACs today: since everybody is fighting every packet onto the network, it's unstable under overload -- collisions beget collisions and shoving more packets onto the network segment only worsens the problem. That's the worst part. But CSMA networks are bandwidth-inefficient -- the congestion kicks in at depressingly low levels of baseband utilization. There are several efficiency schemes like slotting and partial centralization (changing CD to CA with the busy tone) that only postpone the congestion problem -- they do not shape the (Poisson?) shape of the curve. Further, there are precious little resources in the way of network segment management to decant off enough demand to get back to a workable network segment. State of the industry. Ethernet MACs were written in software until the late '80s when we started seeing them embedded in ethernet chips. A decade later the same thing happened with WiFi, except faster -- the migration to chips had taken place before it became popular. Directed net protocols entail having a base station (BS, there have been several other archaic names like Net Control). And a bunch of subscriber stations (SS). There most definitely is someone in charge. Almost all contention-free MACs use a time-slice system where each SS is allocated a transmit window and is obliged not to transmit at other times. The interesting protocol work has to do with how the BS allocates the time slices to allow new SS to enter the network and to afford some fairness (multiple definitions). In WiFi, there's exactly one MAC message (the busy tone); in directed nets such as IEEE 802.16 and TIA LTE there are about four dozen MAC messages. The complexity and multi-vendor testing that is required is much greater. Those constraints, however, do solve some of the problems present in CSMA nets. A directed net is stable under overload. Bandwidth efficiency is much greater: depending on configurations, into the 90+% territory. Further, because every SS (and BS) is guaranteed at least some time to transmit every frame the network segment can be positively managed. Without this control, effectiveness of schemes like DCC strike me as very iffy. > > 2) If DCC does become mandatory, it is likely to be only be > conditionally so (at least in Europe), conditioned on the use > of ETSI's GeoNetworking protocol, and there is little to no > chance of that protocol getting out of the research labs. > > 3) The coupling that people seem to believe exists between 11p > and IPv6 is a fiction in their minds. There is NO coupling. > IPv6 can be used as with any other lower layer protocols > independent of anything to do with 11p. That said, there are > issues of how to set up addresses in ad hoc networks of > vehicles, but bridges and meshes (layer 2 addressing) are much > better suited for that. RR is exactly right here. All IEEE 802 networks have an interface at the top of layer 2 that is pretty much the same -- they pass the contents of the payload through the interface along with an ethertype. There are about 5 pages of appendix of different ethertypes that were allocated but 0800 denotes IPv4 datagrams and 86DD (both hex) denote IPv6. In reality most routers ignore the ethertype, simply throwing away any chunks of data that are not IP (and which version is code in the first byte). What this means is that IPv4, IPv6 and those other 5 pages worth of frames can all be passed over the network segment. While I think a design goal for [its] should be IPv6, I'm not rabid about it. (I've been victim of many US DoD attempts at mandating IPv6, all of which flopped. IETF has been very careful to accommodate both versions in just about every RFC in the past few years. IEEE 802 protocols are generally agnostic except for things like the MIB which is agnostic if you write that section of the standard with care. IPv6 testing can be fun -- not all the advertising claims are true.) > > 4) IPv6 networking is only required when attempting to use > networks to communicate between peers. I'm guessing your > aviation application is not attempting to control a helicopter > over the internet from your home. Any use of a > non-deterministic network for such applications is ... > well ... just not a good idea. RR got a couple concepts crossed up here. Working upward: determinism (or near-determinism) is a characteristic of contention-free MACs (and definitely NOT CSMA MACs). I don't understand what RR is trying to say with the IPv6 and peers. IPv4 has been doing peer-peer comms for several decades now. But if he's thinking about some other protocols (e.g. IPX, Appletalk, 1609??) then he may be right. But the concept of peer-peer is essentially a layer 3 issue not a layer 2 one. > > > > Hehehe. No, I am not trying to control a helicopter over the > internet :-) As I mentioned in the original post, I want to be able > to communicate between the quad-copters while they are in flight. I > know there are methods where you can communicate over 802.11 b/g/n > with WiFi-P2P/Direct (not sure which term is more appropriate, Direct > probably) where one quad-copter could act as a soft AP and the others > could act as clients. And, I also know that there are people who > already stream video while the quad-copters are in flight over Wi-Fi > as well as actually controlling the flying objects with a Wi-Fi > controller. You've got a host of ifs ands and buts here and it's worth sorting them out. If you want n quad-coptors to talk to each other, one way is to equip them all with some flavor of WiFi and go to it. All one segment. Or one collision domain. If the number of coptors is low this can work. The protocol problems are the free-net ones outlined above -- you'll have them all. With hidden hosts and the whole bit. At the RF level, you'll have the distance / interference issues to deal with. On trick is to steer the beam -- it's been implemented many times. But with the randomness of CSMA MACs, this could be problematic (I know some 802.16 vendors where were wiretapping the upload map to inform the beam steering -- clever trick, but it won't work with WiFi because there is not upload map). There's a stand-back-for-perspective issue as well. Do you need to communicate directly between the coptors or can you tie each one of them into terrestrial internet and use it? If you can, then you beat the congestion issue into submission by overprovisioning -- it works everywhere except in the last, wireless LAN, segment at each end of the catenet. (making DCC issues kinda problematic). > > > But, that is not what I am looking for. I want to be able to send > direction/speed/heading information from the quads to each other while > they are in flight. A radar application so to speak, where each quad > essentially is aware of the other quads in the vicinity. Mind you, the > direction/speed/heading is just the first piece of information that I > want to share among the quads while they are in flight. If I can > achieve this I want to be able to do more than just information > sharing. Since, I don't want to set up a quad-copter as a soft AP I > thought 802.11p is appropriate since that operates outside of a BSS > context. I may be wrong. I just don't know. I am researching this > stuff to figure out what is feasible and what is not. This is not new. The airlines have been wrestling with the problems for years, with all the myopias of limited understanding of the internet. I first got exposed to the US FAA's Aviation Tracking Network about 1990. In my experience, you're better off planning in the other direction. Rather than starting with the flying (or otherwise mobile) platform and flogging all the radio problems, work the problem by 'extending the internet to mobile platforms'. That allows you to leverage the assets (like essentially unlimited bandwidth -- about four orders of magnitude more) of the fixed internet to offset those iron limits in RF. > > > > > > > Finally, as I suggested in a previous posting, you can modify > a .11a USB dongle to run in the 5.9GHz band (i.e. create > a .11p dongle) if you have access to the firmware. > > > > > Indeed, I have been looking at USB 802.11a dongles as you suggested > and I can find dual band dongles with chipsets such as RALink RT3572. > This is just an example. > And http://wireless.kernel.org/en/users/Drivers indicates that there > are drivers available for RALink chipsets. So, theoretically, it may > be possible to modify the driver. But I have not yet researched if > firmware for the actual chipset is available or not. And the spec > sheets of the chipsets that I have looked at indicate that the > frequency range of the 802.11a dongles goes up to only 5825 MHz > (802.11a compliance). > > > I assume that is the reason you say I need access to the firmware so > that I can push the frequency range between 5855 MHz and 5925 MHz for > 802.11p compliance. > No comments on the dongles; can't help you there. But any help on the rest? > > Thanks, > Kiran. > > > > RR > > > ______________________________________________________________ > From: Arcot, Kiran K [mailto:kiranarcot@uky.edu] > Sent: Friday, November 07, 2014 12:04 PM > To: Varadi , Andras (lesswire AG Ungarn) > > > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > > Hi Andras, > > > > > Thanks for the links. Will there be support from lesswire for > Linux systems for these USB modules or will the users have to > come up with the drivers themselves? Also, what do you think > the price of USB module will be? Or is it better to ask one of > the distributors that question? > > > > > > As for your DCC question, I have only now started looking in > to the whole 802.11p shebang and haven't completely dug in to > the requirements to comply with the standards yet. I have been > asking questions of Alexandru Petrescu in another email chain > and following his suggestions of first trying to find a > hardware/driver combination that will allow me to transmit in > the 802.11p frequency band with IP. > > > > > > In short, to answer your question about DCC, I don't know how > to handle that just yet. > > > > > > > > > Thanks, > > > Kiran. > > > > > > > > > > > > > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG > Ungarn) wrote: > > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI > G5 in the EU... > Just for an example: how will You tolerate DCC (Decentralized > Congestion Control) in Your use case? (which will not let You > transmit just any time - and You need DCC to transmit and > comply the standards) > > USB 11p module (available next year) - > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car2x/overview/ > More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > Ãœdvözlettel / Best regards, > András Váradi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 | Email: > Varadi@lesswire.com > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru > Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of > 5.9GHz and high power levels for ITS, if the flying > experimentation happens indoors (hangar). > > But coming back to the original question: is there an USB > dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) > only does mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most > constrained linux platforms which feature USB rather than > mini-PCI. > > If this is done, and given the easiness of running IP on > 802.11p, I'd be thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a écrit : > > Hello RR, > > > > The idea indeed is to comply with the standards and > regulation already > > present. > > > > Thanks, > > Kiran. > > > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > > > wrote: > > > > __ __ __ > > > > I'd suggest you look for 802.11a compliant dongles that > have > > mad-wifi or some other open source driver you can > modify. I'd also > > recommend you NOT use the 5.850-5.925GHz band since that > band is > > reserved for ITS, unless, of course, you plan on > complying with the > > number of standards and regulations already in place for > use of the > > band.____ > > > > __ __ > > > > Cheers,____ > > > > __ __ > > > > RR ____ > > > > __ __ > > > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > > ] > > *Sent:* Tuesday, November 04, 2014 10:42 AM > > *To:* its@ietf.org > > *Subject:* [geonet/its] 802.11p USB dongles?____ > > > > __ __ > > > > Hello All,____ > > > > __ __ > > > > I am a graduate student at the ____University__ of > __Kentucky____ > > and I am looking at using 802.11p for communication > between out > > quad-copters. To that end is anyone aware of any 802.11p > USB dongles > > on the market? Are there any open source drivers (Linux > > specifically) that are in semi-usable state or in > development? If > > so where can one find such a driver for 802.11p > cards/USB > > dongles?____ > > > > __ __ > > > > Thanks,____ > > > > Kiran Arcot.____ > > > > > > > > > > _______________________________________________ > > 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 nobody Sat Nov 8 15:32:51 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8761A02BE for ; Sat, 8 Nov 2014 15:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_65=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrEuz5JyMSK5 for ; Sat, 8 Nov 2014 15:32:48 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55EA1A0130 for ; Sat, 8 Nov 2014 15:32:47 -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 sA8NWgVL029920; Sun, 9 Nov 2014 00:32:42 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6FD18206699; Sun, 9 Nov 2014 00:32:55 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 626A7206677; Sun, 9 Nov 2014 00:32:55 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.4]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sA8NWcYW032646; Sun, 9 Nov 2014 00:32:40 +0100 Message-ID: <545EA815.3000406@gmail.com> Date: Sun, 09 Nov 2014 00:32:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Konstantin A. Khait" References: <1287452018.20130927130616@componentality.com> In-Reply-To: <1287452018.20130927130616@componentality.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/FDg6eCmoNAdPWor7ydIBz9KCg8o Cc: "its@ietf.org" Subject: Re: [geonet/its] [its] Open WAVE implementation: looking for contributors X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 23:32:50 -0000 Kostia - would you please give us an update about this effort? Is it still ongoing? In particular, what kind of 802.11p driver is it using? Alex Le 27/09/2013 11:06, Konstantin A. Khait a écrit : > Ladies and gentlemen, > > My name is Konstantin Khait, chief engineer in Componentality Oy, member > of Linux Foundation and Automotive Grade Linux SC. We're doing open HW > and SW solutions for automotive multimedia, navigation and communication. > > Currently we launch the initiative to create reference OSS > implementation of IEEE 1609, WAVE. WAVE is a fresh and rapidly > institutionalizing standard for vehicle to vehicle and vehicle to > infrastructure communication, now becoming the main and "must have" > approach in ITS, collision prevention and road automation areas. > Componentality Oy is willing to provide a hardware platform supporting > IEEE 802.11p radio and do coordination of development efforts. However, > we need your architectural, engineering and intellectual resources to > make this asset together. WAVE is big enough, relatively complex and > multifunctional, so only joint community may guarantee it being done in > a reasonable time frame and with automotive quality. Fortunately, when > we do it, we all will have the most needed asset in V2X and probably it > becomes an industrial reference and standard for a long time. > > In the timeframe since January when we joined AGL to now we did a lot of > consultations with key market players to understand the potential of > such solution. Now we know that almost every company working on V2X/ITS > solutions demands for such solution. We offer making it together. > > Componentality is open for the dialog of what and how to be done for > that. By default, we assume to create an OSS Linux stack available for > everybody under GPL license. It is what we start since October 1st. If > it will be some contributor with any special legal requirements, we're > ready to re-review licensing approach and... all other organizational > aspects. We plan to make this job done by April, 2014. Now we form the > team and WELCOME TO JOIN US! > > Simply write me if you have any comments, questions or you want to > participate. Hope, later AGL will establish some mailing list, forum and > other infrastructure for us. > > And thank you all, even who deleted this email before reading :) > > Kostia > > > ----- > > > ----- > Konstantin A. Khait > Componentality Oy > Tel: +358(0)465662016 > +7(921)9005780 > Skype: kostia.khait > E-Mail: khait@componentality.com > 53100 Finland > Ratakatu 47 > Lappeenranta > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From nobody Mon Nov 10 12:13:07 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1681AC44D for ; Mon, 10 Nov 2014 12:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jC2viYWNVoM for ; Mon, 10 Nov 2014 12:12:55 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7055B1A6F04 for ; Mon, 10 Nov 2014 12:12:54 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id ex7so11741842wid.8 for ; Mon, 10 Nov 2014 12:12:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wzTlDs6wKpGnBhRNo4J7cqwA8ALqqJZv9LTzHV1qRc4=; b=emPTqz/huCCpRUTwk9s1U+XmOIaf5uzY54rxBf8sXgOGq36DI77n643ra3QTIsiKeH BokE6cAbPFtzy40CtLsESdswnmwxhe39O79YNFW5nzPAmCGLgcf9xV8NLRrYS9eJADzJ d0D0mfeCegkN8Tnfgo8kUSQnf6ZdL0MnOfFfIyL5rW3wBI3OAoseukecWZNwqnLXpYxt a2V/x8THCwFqSMMTutZ+ipQ8A0+bG9atCVRuqB5h8LEYB6eByz6Wi1N+1onjOc2QDLqu BfqKzyjGEKtjfp1QaxeJWOUh71DQ4x+YdrEire2KZeHc9H11Q01e6585Bnr5KkfWRqwL XaUQ== X-Gm-Message-State: ALoCoQmXtFnoo4GgZenhjNOyCelGEH7O2Z/Akw61GDclOjh3jjDoGVgMhLHw+9ZCnRPor+FmnJqt MIME-Version: 1.0 X-Received: by 10.194.71.84 with SMTP id s20mr15974865wju.128.1415650371294; Mon, 10 Nov 2014 12:12:51 -0800 (PST) Received: by 10.194.243.230 with HTTP; Mon, 10 Nov 2014 12:12:51 -0800 (PST) In-Reply-To: <1415406286.23933.58.camel@localhost.localdomain> References: <545BA571.5010502@gmail.com> <1415406286.23933.58.camel@localhost.localdomain> Date: Mon, 10 Nov 2014 15:12:51 -0500 Message-ID: From: "Arcot, Kiran K" To: Rex Buddenberg Content-Type: multipart/alternative; boundary=047d7bfced3081ea27050786c91f Archived-At: http://mailarchive.ietf.org/arch/msg/its/gCJqGB9s_mVc8mA_5BTFHuLlcP8 Cc: Richard Roy , "Varadi , Andras \(lesswire AG Ungarn\)" , "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:13:05 -0000 --047d7bfced3081ea27050786c91f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rex, Thanks for the detailed explanation of the 'contention' and 'contention-free' MACs. I have answered your questions below. Thanks, Kiran. On Fri, Nov 7, 2014 at 7:24 PM, Rex Buddenberg wrote: > Kiran, > > Some suggested amendments to the dialog below: > > DCC is a congestion control scheme; as such it falls in the general > category of QoS control. > > MACs are access control algorithms and applicable to a single network > segment. > > Don't confuse the two. > > More below... > > On Fri, 2014-11-07 at 17:23 -0500, Arcot, Kiran K wrote: > > > > > > On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy > > wrote: > > A few things to remember: > > > > > > > > 1) DCC is not yet mandatory anywhere and hopefully that > > situation will not change. > > > > 2) What needs to be done to address the congestion problem is > > to use 21rst century MAC/PHY technology, not 20th century > > technology, and it's technology that's available now. > > I differ with RR on terminology and a look back in radio history > pre-Internet is why. There are two kinds of MACs out there: contention > and contention-free. In Ye Olde Radio days, operators had these > algorithms embedded in their operating protocols: > > Contention access was known in YORD as 'free net'. Contention-free > access was known as 'directed net'. > > Free nets are, of course, simple -- a few rules like listen before talk > so you don't stomp on somebody else's transmission. There's an > assumption that everybody can hear everybody else -- if you can't hear > someone else, then your set up to unwittingly jam that station. A pure > CSMA/CD network has no station in charge -- all are theoretically equal > [abusers]. > The overload characteristics of free nets are identical to those of > CSMA MACs today: since everybody is fighting every packet onto the > network, it's unstable under overload -- collisions beget collisions and > shoving more packets onto the network segment only worsens the problem. > That's the worst part. But CSMA networks are bandwidth-inefficient -- > the congestion kicks in at depressingly low levels of baseband > utilization. There are several efficiency schemes like slotting and > partial centralization (changing CD to CA with the busy tone) that only > postpone the congestion problem -- they do not shape the (Poisson?) > shape of the curve. Further, there are precious little resources in the > way of network segment management to decant off enough demand to get > back to a workable network segment. > State of the industry. Ethernet MACs were written in software > until the late '80s when we started seeing them embedded in ethernet > chips. A decade later the same thing happened with WiFi, except faster > -- the migration to chips had taken place before it became popular. > > Directed net protocols entail having a base station (BS, there have been > several other archaic names like Net Control). And a bunch of > subscriber stations (SS). There most definitely is someone in charge. > Almost all contention-free MACs use a time-slice system where each SS is > allocated a transmit window and is obliged not to transmit at other > times. The interesting protocol work has to do with how the BS > allocates the time slices to allow new SS to enter the network and to > afford some fairness (multiple definitions). > In WiFi, there's exactly one MAC message (the busy tone); in > directed nets such as IEEE 802.16 and TIA LTE there are about four dozen > MAC messages. The complexity and multi-vendor testing that is required > is much greater. > Those constraints, however, do solve some of the problems present > in CSMA nets. A directed net is stable under overload. Bandwidth > efficiency is much greater: depending on configurations, into the 90+% > territory. Further, because every SS (and BS) is guaranteed at least > some time to transmit every frame the network segment can be positively > managed. Without this control, effectiveness of schemes like DCC strike > me as very iffy. > > > > > 2) If DCC does become mandatory, it is likely to be only be > > conditionally so (at least in Europe), conditioned on the use > > of ETSI's GeoNetworking protocol, and there is little to no > > chance of that protocol getting out of the research labs. > > > > 3) The coupling that people seem to believe exists between 11p > > and IPv6 is a fiction in their minds. There is NO coupling. > > IPv6 can be used as with any other lower layer protocols > > independent of anything to do with 11p. That said, there are > > issues of how to set up addresses in ad hoc networks of > > vehicles, but bridges and meshes (layer 2 addressing) are much > > better suited for that. > > RR is exactly right here. All IEEE 802 networks have an interface at > the top of layer 2 that is pretty much the same -- they pass the > contents of the payload through the interface along with an ethertype. > There are about 5 pages of appendix of different ethertypes that were > allocated but 0800 denotes IPv4 datagrams and 86DD (both hex) denote > IPv6. In reality most routers ignore the ethertype, simply throwing > away any chunks of data that are not IP (and which version is code in > the first byte). > > What this means is that IPv4, IPv6 and those other 5 pages worth of > frames can all be passed over the network segment. While I think a > design goal for [its] should be IPv6, I'm not rabid about it. > (I've been victim of many US DoD attempts at mandating IPv6, all of > which flopped. IETF has been very careful to accommodate both versions > in just about every RFC in the past few years. IEEE 802 protocols are > generally agnostic except for things like the MIB which is agnostic if > you write that section of the standard with care. IPv6 testing can be > fun -- not all the advertising claims are true.) > > > > > 4) IPv6 networking is only required when attempting to use > > networks to communicate between peers. I'm guessing your > > aviation application is not attempting to control a helicopter > > over the internet from your home. Any use of a > > non-deterministic network for such applications is ... > > well ... just not a good idea. > > RR got a couple concepts crossed up here. > > Working upward: determinism (or near-determinism) is a characteristic of > contention-free MACs (and definitely NOT CSMA MACs). > > I don't understand what RR is trying to say with the IPv6 and peers. > IPv4 has been doing peer-peer comms for several decades now. But if > he's thinking about some other protocols (e.g. IPX, Appletalk, 1609??) > then he may be right. But the concept of peer-peer is essentially a > layer 3 issue not a layer 2 one. > > > > > > > > Hehehe. No, I am not trying to control a helicopter over the > > internet :-) As I mentioned in the original post, I want to be able > > to communicate between the quad-copters while they are in flight. I > > know there are methods where you can communicate over 802.11 b/g/n > > with WiFi-P2P/Direct (not sure which term is more appropriate, Direct > > probably) where one quad-copter could act as a soft AP and the others > > could act as clients. And, I also know that there are people who > > already stream video while the quad-copters are in flight over Wi-Fi > > as well as actually controlling the flying objects with a Wi-Fi > > controller. > > You've got a host of ifs ands and buts here and it's worth sorting them > out. > > If you want n quad-coptors to talk to each other, one way is to equip > them all with some flavor of WiFi and go to it. All one segment. Or > one collision domain. If the number of coptors is low this can work. > The protocol problems are the free-net ones outlined above -- > you'll have them all. With hidden hosts and the whole bit. > At the RF level, you'll have the distance / interference issues to > deal with. On trick is to steer the beam -- it's been implemented many > times. But with the randomness of CSMA MACs, this could be problematic > (I know some 802.16 vendors where were wiretapping the upload map to > inform the beam steering -- clever trick, but it won't work with WiFi > because there is not upload map). > > There's a stand-back-for-perspective issue as well. Do you need to > communicate directly between the coptors or can you tie each one of them > into terrestrial internet and use it? If you can, then you beat the > congestion issue into submission by overprovisioning -- it works > everywhere except in the last, wireless LAN, segment at each end of the > catenet. (making DCC issues kinda problematic). > > Yes, I want the copters to communicate directly, but don't want to tie them to the internet access. It is not important at the present time if the copters have access to the "greater world" over the the internet. Just communication between copters is required without being tied to a terrestrial internet. > > > > > > But, that is not what I am looking for. I want to be able to send > > direction/speed/heading information from the quads to each other while > > they are in flight. A radar application so to speak, where each quad > > essentially is aware of the other quads in the vicinity. Mind you, the > > direction/speed/heading is just the first piece of information that I > > want to share among the quads while they are in flight. If I can > > achieve this I want to be able to do more than just information > > sharing. Since, I don't want to set up a quad-copter as a soft AP I > > thought 802.11p is appropriate since that operates outside of a BSS > > context. I may be wrong. I just don't know. I am researching this > > stuff to figure out what is feasible and what is not. > > This is not new. The airlines have been wrestling with the problems for > years, with all the myopias of limited understanding of the internet. I > first got exposed to the US FAA's Aviation Tracking Network about > 1990. > In my experience, you're better off planning in the other > direction. Rather than starting with the flying (or otherwise mobile) > platform and flogging all the radio problems, work the problem by > 'extending the internet to mobile platforms'. That allows you to > leverage the assets (like essentially unlimited bandwidth -- about four > orders of magnitude more) of the fixed internet to offset those iron > limits in RF. > > > > > > > > > > > > > > Finally, as I suggested in a previous posting, you can modify > > a .11a USB dongle to run in the 5.9GHz band (i.e. create > > a .11p dongle) if you have access to the firmware. > > > > > > > > > > Indeed, I have been looking at USB 802.11a dongles as you suggested > > and I can find dual band dongles with chipsets such as RALink RT3572. > > This is just an example. > > And http://wireless.kernel.org/en/users/Drivers indicates that there > > are drivers available for RALink chipsets. So, theoretically, it may > > be possible to modify the driver. But I have not yet researched if > > firmware for the actual chipset is available or not. And the spec > > sheets of the chipsets that I have looked at indicate that the > > frequency range of the 802.11a dongles goes up to only 5825 MHz > > (802.11a compliance). > > > > > > I assume that is the reason you say I need access to the firmware so > > that I can push the frequency range between 5855 MHz and 5925 MHz for > > 802.11p compliance. > > > No comments on the dongles; can't help you there. But any help on the > rest? > > > > > > Thanks, > > Kiran. > > > > > > > > RR > > > > > > ______________________________________________________________ > > From: Arcot, Kiran K [mailto:kiranarcot@uky.edu] > > Sent: Friday, November 07, 2014 12:04 PM > > To: Varadi , Andras (lesswire AG Ungarn) > > > > > > Cc: its@ietf.org > > Subject: Re: [geonet/its] 802.11p USB dongles? > > > > > > Hi Andras, > > > > > > > > > > Thanks for the links. Will there be support from lesswire for > > Linux systems for these USB modules or will the users have to > > come up with the drivers themselves? Also, what do you think > > the price of USB module will be? Or is it better to ask one of > > the distributors that question? > > > > > > > > > > > > As for your DCC question, I have only now started looking in > > to the whole 802.11p shebang and haven't completely dug in to > > the requirements to comply with the standards yet. I have been > > asking questions of Alexandru Petrescu in another email chain > > and following his suggestions of first trying to find a > > hardware/driver combination that will allow me to transmit in > > the 802.11p frequency band with IP. > > > > > > > > > > > > In short, to answer your question about DCC, I don't know how > > to handle that just yet. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Kiran. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG > > Ungarn) wrote: > > > > Hi Kiran > > > > I also have some serious concerns about outdoor usage of ETSI > > G5 in the EU... > > Just for an example: how will You tolerate DCC (Decentralized > > Congestion Control) in Your use case? (which will not let You > > transmit just any time - and You need DCC to transmit and > > comply the standards) > > > > USB 11p module (available next year) - > > > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car= 2x/overview/ > > More info on availibility from the distributors: > > http://www.lesswire.com/en/distributors/commercials-new/ > > > > =C3=9Cdv=C3=B6zlettel / Best regards, > > Andr=C3=A1s V=C3=A1radi > > > > Project Manager - C2X/ITS Systems > > Customer Support Wireless Modules > > > > Automotive & WLAN Group > > lesswire Hungary | Office: +36 23521 667 | Email: > > Varadi@lesswire.com > > > > > > -----Original Message----- > > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru > > Petrescu > > Sent: Thursday, November 06, 2014 5:45 PM > > To: Arcot, Kiran K; dickroy@alum.mit.edu > > Cc: its@ietf.org > > Subject: Re: [geonet/its] 802.11p USB dongles? > > > > Well - there may be ways to comply to the legislation of > > 5.9GHz and high power levels for ITS, if the flying > > experimentation happens indoors (hangar). > > > > But coming back to the original question: is there an USB > > dongle 802.11p? > > > > The manufacturer I am familiar with (UNEX, not to name it) > > only does mini-PCI 802.11p cards. > > > > An 802.11p USB dongle format may be useful to some of the most > > constrained linux platforms which feature USB rather than > > mini-PCI. > > > > If this is done, and given the easiness of running IP on > > 802.11p, I'd be thrilled to see IP between flying objects. > > > > Alex > > > > > > Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit : > > > Hello RR, > > > > > > The idea indeed is to comply with the standards and > > regulation already > > > present. > > > > > > Thanks, > > > Kiran. > > > > > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > > > > > wrote: > > > > > > __ __ __ > > > > > > I'd suggest you look for 802.11a compliant dongles that > > have > > > mad-wifi or some other open source driver you can > > modify. I'd also > > > recommend you NOT use the 5.850-5.925GHz band since that > > band is > > > reserved for ITS, unless, of course, you plan on > > complying with the > > > number of standards and regulations already in place for > > use of the > > > band.____ > > > > > > __ __ > > > > > > Cheers,____ > > > > > > __ __ > > > > > > RR ____ > > > > > > __ __ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > > > ] > > > *Sent:* Tuesday, November 04, 2014 10:42 AM > > > *To:* its@ietf.org > > > *Subject:* [geonet/its] 802.11p USB dongles?____ > > > > > > __ __ > > > > > > Hello All,____ > > > > > > __ __ > > > > > > I am a graduate student at the ____University__ of > > __Kentucky____ > > > and I am looking at using 802.11p for communication > > between out > > > quad-copters. To that end is anyone aware of any 802.11p > > USB dongles > > > on the market? Are there any open source drivers (Linux > > > specifically) that are in semi-usable state or in > > development? If > > > so where can one find such a driver for 802.11p > > cards/USB > > > dongles?____ > > > > > > __ __ > > > > > > Thanks,____ > > > > > > Kiran Arcot.____ > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > --047d7bfced3081ea27050786c91f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rex,

Thanks for the detailed explana= tion of the 'contention' and 'contention-free' =C2=A0MACs. = I have answered your questions below.

Thanks,
Kiran.

On Fri, Nov 7, 2014 at 7:24 PM, Rex Buddenberg <buddenbergr@gmail.com= > wrote:
Kiran,

Some suggested amendments to the dialog below:

DCC is a congestion control scheme; as such it falls in the general
category of QoS control.

MACs are access control algorithms and applicable to a single network
segment.

Don't confuse the two.

More below...

On Fri, 2014-11-07 at 17:23 -0500, Arcot, Kiran K wrote:
>
>
> On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy <dickroy@alum.mit.edu>
> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few things to remember:
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) DCC is not yet mandatory anywhere = and hopefully that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0situation will not change.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) What needs to be done to address t= he congestion problem is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to use 21rst century MAC/PHY technolo= gy, not 20th century
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0technology, and it's technology t= hat's available now.

I differ with RR on terminology and a look back in radio history
pre-Internet is why.=C2=A0 There are two kinds of MACs out there: contentio= n
and contention-free.=C2=A0 In Ye Olde Radio days, operators had these
algorithms embedded in their operating protocols:

Contention access was known in YORD as 'free net'.=C2=A0 Contention= -free
access was known as 'directed net'.

Free nets are, of course, simple -- a few rules like listen before talk
so you don't stomp on somebody else's transmission.=C2=A0 There'= ;s an
assumption that everybody can hear everybody else -- if you can't hear<= br> someone else, then your set up to unwittingly jam that station.=C2=A0 A pur= e
CSMA/CD network has no station in charge -- all are theoretically equal
[abusers].
=C2=A0 =C2=A0 The overload characteristics of free nets are identical to th= ose of
CSMA MACs today: since everybody is fighting every packet onto the
network, it's unstable under overload -- collisions beget collisions an= d
shoving more packets onto the network segment only worsens the problem.
That's the worst part.=C2=A0 But CSMA networks are bandwidth-inefficien= t --
the congestion kicks in at depressingly low levels of baseband
utilization.=C2=A0 There are several efficiency schemes like slotting and partial centralization (changing CD to CA with the busy tone) that only
postpone the congestion problem -- they do not shape the (Poisson?)
shape of the curve.=C2=A0 Further, there are precious little resources in t= he
way of network segment management to decant off enough demand to get
back to a workable network segment.
=C2=A0 =C2=A0 =C2=A0State of the industry.=C2=A0 Ethernet MACs were written= in software
until the late '80s when we started seeing them embedded in ethernet chips.=C2=A0 A decade later the same thing happened with WiFi, except faste= r
-- the migration to chips had taken place before it became popular.

Directed net protocols entail having a base station (BS, there have been several other archaic names like Net Control).=C2=A0 And a bunch of
subscriber stations (SS).=C2=A0 There most definitely is someone in charge.=
Almost all contention-free MACs use a time-slice system where each SS is allocated a transmit window and is obliged not to transmit at other
times.=C2=A0 The interesting protocol work has to do with how the BS
allocates the time slices to allow new SS to enter the network and to
afford some fairness (multiple definitions).
=C2=A0 =C2=A0 =C2=A0In WiFi, there's exactly one MAC message (the busy = tone); in
directed nets such as IEEE 802.16 and TIA LTE there are about four dozen MAC messages.=C2=A0 The complexity and multi-vendor testing that is require= d
is much greater.
=C2=A0 =C2=A0 =C2=A0Those constraints, however, do solve some of the proble= ms present
in CSMA nets.=C2=A0 A directed net is stable under overload.=C2=A0 Bandwidt= h
efficiency is much greater: depending on configurations, into the 90+%
territory.=C2=A0 Further, because every SS (and BS) is guaranteed at least<= br> some time to transmit every frame the network segment can be positively
managed.=C2=A0 Without this control, effectiveness of schemes like DCC stri= ke
me as very iffy.

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) If DCC does become mandatory, it i= s likely to be only be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0conditionally so (at least in Europe)= , conditioned on the use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of ETSI's GeoNetworking protocol,= and there is little to no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chance of that protocol getting out o= f the research labs.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) The coupling that people seem to b= elieve exists between 11p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and IPv6 is a fiction in their minds.= =C2=A0 There is NO coupling.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 can be used as with any other lo= wer layer protocols
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0independent of anything to do with 11= p.=C2=A0 That said, there are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issues of how to set up addresses in = ad hoc networks of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vehicles, but bridges and meshes (lay= er 2 addressing) are much
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0better suited for that.

RR is exactly right here.=C2=A0 All IEEE 802 networks have an interf= ace at
the top of layer 2 that is pretty much the same -- they pass the
contents of the payload through the interface along with an ethertype.
There are about 5 pages of appendix of different ethertypes that were
allocated but 0800 denotes IPv4 datagrams and 86DD (both hex) denote
IPv6.=C2=A0 In reality most routers ignore the ethertype, simply throwing away any chunks of data that are not IP (and which version is code in
the first byte).

What this means is that IPv4, IPv6 and those other 5 pages worth of
frames can all be passed over the network segment.=C2=A0 While I think a design goal for [its] should be IPv6, I'm not rabid about it.
=C2=A0 =C2=A0 (I've been victim of many US DoD attempts at mandating IP= v6, all of
which flopped.=C2=A0 IETF has been very careful to accommodate both version= s
in just about every RFC in the past few years.=C2=A0 IEEE 802 protocols are=
generally agnostic except for things like the MIB which is agnostic if
you write that section of the standard with care.=C2=A0 IPv6 testing can be=
fun -- not all the advertising claims are true.)

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04) IPv6 networking is only required w= hen attempting to use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks to communicate between peers= .=C2=A0 I'm guessing your
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0aviation application is not attemptin= g to control a helicopter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over the internet from your home.=C2= =A0 Any use of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0non-deterministic network for such ap= plications is ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0well ... just not a good idea.

RR got a couple concepts crossed up here.

Working upward: determinism (or near-determinism) is a characteristic of contention-free MACs (and definitely NOT CSMA MACs).

I don't understand what RR is trying to say with the IPv6 and peers. IPv4 has been doing peer-peer comms for several decades now.=C2=A0 But if he's thinking about some other protocols (e.g. IPX, Appletalk, 1609??)<= br> then he may be right.=C2=A0 But the concept of peer-peer is essentially a layer 3 issue not a layer 2 one.
>
>
>
> Hehehe. No, I am not trying to control a helicopter over the
> internet :-)=C2=A0 As I mentioned in the original post, I want to be a= ble
> to communicate between the quad-copters while they are in flight. I > know there are methods where you can communicate over 802.11 b/g/n
> with WiFi-P2P/Direct (not sure which term is more appropriate, Direct<= br> > probably) where one quad-copter could act as a soft AP and the others<= br> > could act as clients. And, I also know that there are people who
> already stream video while the quad-copters are in flight over Wi-Fi > as well as actually controlling the flying objects with a Wi-Fi
> controller.

You've got a host of ifs ands and buts here and it's worth s= orting them
out.

If you want n quad-coptors to talk to each other, one way is to equip
them all with some flavor of WiFi and go to it.=C2=A0 All one segment.=C2= =A0 Or
one collision domain.=C2=A0 If the number of coptors is low this can work.<= br> =C2=A0 =C2=A0 =C2=A0The protocol problems are the free-net ones outlined ab= ove --
you'll have them all.=C2=A0 With hidden hosts and the whole bit.
=C2=A0 =C2=A0 =C2=A0At the RF level, you'll have the distance / interfe= rence issues to
deal with.=C2=A0 On trick is to steer the beam -- it's been implemented= many
times.=C2=A0 But with the randomness of CSMA MACs, this could be problemati= c
(I know some 802.16 vendors where were wiretapping the upload map to
inform the beam steering -- clever trick, but it won't work with WiFi because there is not upload map).

There's a stand-back-for-perspective issue as well.=C2=A0 Do you need t= o
communicate directly between the coptors or can you tie each one of them into terrestrial internet and use it?=C2=A0 If you can, then you beat the congestion issue into submission by overprovisioning -- it works
everywhere except in the last, wireless LAN, segment at each end of the
catenet.=C2=A0 (making DCC issues kinda problematic).

Yes, I want the copters to co= mmunicate directly, but don't want to tie them to the internet access. = It is not important at the present time if the copters have access to the &= quot;greater world" over the the internet. Just communication between = copters is required without being tied to a terrestrial internet.=C2=A0

=C2=A0
>
>
> But, that is not what I am looking for. I want to be able to send
> direction/speed/heading information from the quads to each other while=
> they are in flight. A radar application so to speak, where each quad > essentially is aware of the other quads in the vicinity. Mind you, the=
> direction/speed/heading is just the first piece of information that I<= br> > want to share among the quads while they are in flight. If I can
> achieve this I want to be able to do more than just information
> sharing. Since, I don't want to set up a quad-copter as a soft AP = I
> thought 802.11p is appropriate since that operates outside of a BSS > context. I may be wrong. I just don't know. I am researching this<= br> > stuff to figure out what is feasible and what is not.

This is not new.=C2=A0 The airlines have been wrestling with the pro= blems for
years, with all the myopias of limited understanding of the internet.=C2=A0= I
first got exposed to the US FAA's Aviation Tracking Network about
1990.
=C2=A0 =C2=A0 =C2=A0In my experience, you're better off planning in the= other
direction.=C2=A0 Rather than starting with the flying (or otherwise mobile)=
platform and flogging all the radio problems, work the problem by
'extending the internet to mobile platforms'.=C2=A0 That allows you= to
leverage the assets (like essentially unlimited bandwidth -- about four
orders of magnitude more) of the fixed internet to offset those iron
limits in RF.
>
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Finally, as I suggested in a previous= posting, you can modify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a .11a USB dongle to run in the 5.9GH= z band (i.e. create
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a .11p dongle) if you have access to = the firmware.
>
>
>
>
> Indeed, I have been looking at USB 802.11a dongles as you suggested > and I can find dual band dongles with chipsets such as RALink RT3572.<= br> > This is just an example.
> And http://wireless.kernel.org/en/users/Drivers indicates that ther= e
> are drivers available for RALink chipsets. So, theoretically, it may > be possible to modify the driver. But I have not yet researched if
> firmware for the actual chipset is available or not. And the spec
> sheets of the chipsets that I have looked at indicate that the
> frequency range of the 802.11a dongles goes up to only 5825 MHz
> (802.11a compliance).
>
>
> I assume that is the reason you say I need access to the firmware so > that I can push the frequency range between 5855 MHz and 5925 MHz for<= br> > 802.11p compliance.
>
No comments on the dongles; can't help you there.=C2=A0 But any = help on the
rest?


>
> Thanks,
> Kiran.
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RR
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= _________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0From: Arcot, Kiran K [mailto:kiran= arcot@uky.edu]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Friday, November 07, 2014 12:04= PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Varadi , Andras (lesswire AG Unga= rn)
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: i= ts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: [geonet/its] 802.11p USB= dongles?
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Andras,
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks for the links. Will there be s= upport from lesswire for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Linux systems for these USB modules o= r will the users have to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0come up with the drivers themselves? = Also, what do you think
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the price of USB module will be? Or i= s it better to ask one of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the distributors that question?
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As for your DCC question, I have only= now started looking in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the whole 802.11p shebang and have= n't completely dug in to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the requirements to comply with the s= tandards yet. I have been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asking questions of Alexandru Petresc= u in another email chain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and following his suggestions of firs= t trying to find a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hardware/driver combination that will= allow me to transmit in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the 802.11p frequency band with IP. >
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In short, to answer your question abo= ut DCC, I don't know how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to handle that just yet.
>
>
>
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Kiran.
>
>
>
>
>
>
>
>
>
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 7, 2014 at 7:52 AM, Varad= i , Andras (lesswire AG
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ungarn) <Varadi@lesswire.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Kiran
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also have some serious concerns abo= ut outdoor usage of ETSI
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G5 in the EU...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just for an example: how will You tol= erate DCC (Decentralized
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Congestion Control) in Your use case?= (which will not let You
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transmit just any time - and You need= DCC to transmit and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comply the standards)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB 11p module (available next year) = -
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-c= ar2x/overview/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0More info on availibility from the di= stributors:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.lesswire.com/e= n/distributors/commercials-new/
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C3=9Cdv=C3=B6zlettel / Best regards,=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andr=C3=A1s V=C3=A1radi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Project Manager - C2X/= ITS Systems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Customer Support Wirel= ess Modules
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Automotive & WLAN = Group
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lesswire=C2=A0 =C2=A0H= ungary | Office: = +36 23521 667 | Email:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Varadi@lesswire.com
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-----Original Message-----
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Petrescu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Thursday, November 06, 2014 5:4= 5 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Arcot, Kiran K; dickroy@alum.mit.edu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: i= ts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: [geonet/its] 802.11p USB= dongles?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well - there may be ways to comply to= the legislation of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05.9GHz and high power levels for ITS,= if the flying
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0experimentation happens indoors (hang= ar).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But coming back to the original quest= ion: is there an USB
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dongle 802.11p?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The manufacturer I am familiar with (= UNEX, not to name it)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0only does mini-PCI 802.11p cards.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An 802.11p USB dongle format may be u= seful to some of the most
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0constrained linux platforms which fea= ture USB rather than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mini-PCI.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If this is done, and given the easine= ss of running IP on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0802.11p, I'd be thrilled to see I= P between flying objects.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alex
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Le 06/11/2014 17:04, Arcot, Kiran K a= =C3=A9crit :
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hello RR,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> The idea indeed is to comply wit= h the standards and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regulation already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> present.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Kiran.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Nov 5, 2014 at 3:08 PM, = Richard Roy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<dickroy@alum.mit.edu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> <mailto:dickroy@alum.mit.edu>> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I'd sugge= st you look for 802.11a compliant dongles that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0mad-wifi or s= ome other open source driver you can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modify. I'd also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0recommend you= NOT use the 5.850-5.925GHz band since that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0band is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0reserved for = ITS,=C2=A0 unless, of course, you plan on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0complying with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0number of sta= ndards and regulations already in place for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0band.____
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Cheers,____ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0RR ____
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------= ---------------------------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0*From:*Arcot,= Kiran K [mailto:kiranarcot@uky.edu
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<mailto:kiranarcot@uky.edu>]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0*Sent:* Tuesd= ay, November 04, 2014 10:42 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0*To:* its@ietf.org <mailto:its@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0*Subject:* [g= eonet/its] 802.11p USB dongles?____
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Hello All,___= _
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I am a gradua= te student at the ____University__ of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__Kentucky____
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0and I am look= ing at using 802.11p for communication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between out
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0quad-copters.= To that end is anyone aware of any 802.11p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USB dongles
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0on the market= ? Are there any open source drivers (Linux
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0specifically)= that are in semi-usable state or in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0development?=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0so where can = one find such a driver for 802.11p
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cards/USB
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> dongles?____
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0__ __
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Thanks,____ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Kiran Arcot._= ___
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ________________________________= _______________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> its mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> = its@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listin= fo/its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its@i= etf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/it= s
>
>
>
>
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its



--047d7bfced3081ea27050786c91f-- From nobody Mon Nov 10 12:27:04 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36531ACDC6 for ; Mon, 10 Nov 2014 12:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l53oO3kSpBbK for ; Mon, 10 Nov 2014 12:26:55 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C655F1ACE49 for ; Mon, 10 Nov 2014 12:25:37 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so10242645wgh.41 for ; Mon, 10 Nov 2014 12:25:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z9LafOWmlel7z03159dtj3DHEmcalawvYcfip0E8Nq0=; b=WpkJxUSVjSLFMBIqJTtNf+2eArD1kYVyY1cz2L1uLJbMs/wvP5ZAKDbSzayHuHipsT XJ6BDlSdH16sILZ8ALD9nrjiiimjLsMaSdMxiMu6SP7NeCiDpR1lXtkgTA672DTgXo7i lwYQKCKtCV+qfxLX4o2STmaPosICif2kcu7tmawCWcdjllFat19HaBLnQpaYvuZ6Bn0d ipeLHC+Hqs8B2C+GjqeTlVPOrfbYboc32BxlvfBM4MApJwI0fkkPRT0caiDl2ya1G6pz gJGrfnIp4qOL4qDmeVGHpnzKYFiMHQ3sOYWZC/iy7meb5nd1CD9psgKgsTTznTaBtlHo Q44w== X-Gm-Message-State: ALoCoQm0xXwB0/SZUZ7rj9Y+DcEcVwpBe51zYICyFo4raOyVphMwHD8rbzN8OCSB/oNzb2QDLDlv MIME-Version: 1.0 X-Received: by 10.194.92.82 with SMTP id ck18mr46429863wjb.103.1415651135467; Mon, 10 Nov 2014 12:25:35 -0800 (PST) Received: by 10.194.243.230 with HTTP; Mon, 10 Nov 2014 12:25:35 -0800 (PST) In-Reply-To: <7DB710AF8F2E4B71B2B1DCA48175A5A2@SRA4> References: <545BA571.5010502@gmail.com> <7DB710AF8F2E4B71B2B1DCA48175A5A2@SRA4> Date: Mon, 10 Nov 2014 15:25:35 -0500 Message-ID: From: "Arcot, Kiran K" To: Richard Roy Content-Type: multipart/alternative; boundary=047d7bd9201a0e47d1050786f792 Archived-At: http://mailarchive.ietf.org/arch/msg/its/BlDn-iTSZrzc9FjgPcQn-N7DL7I Cc: "Varadi , Andras \(lesswire AG Ungarn\)" , "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 20:27:03 -0000 --047d7bd9201a0e47d1050786f792 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi RR, What you describe may be what I need to use. Here is a unit I found from Arada systems. http://www.aradasystems.com/locomate-mini-obu/ It shows the size of the unit with reference to a smartphone in a car. It also looks like they have a version 2: the LocomateMini2. And the datasheet has all the acronyms that you mention. http://www.aradasystems.com/wp-content/uploads/2014/10/LocoMate_mini_Datash= eet_Oct14.pdf It also mentions an SDK for development of applications. I will need to look at the pricing (at this point I am guessing it is relatively expensive) and the SDK to see if it matches my requirements. Although, it is not obvious from the datasheet if it can be interfaced with a development boards such as a Raspberry Pi, Beagleboard, Odroid XU3 etc. Thanks, Kiran. On Mon, Nov 10, 2014 at 12:34 PM, Richard Roy wrote: > Arcot, > > > > What you want to accomplish has already been done in numerous field trial= s > of V2V and V2I technology developed over the last 15 years in IEEE 1609 a= nd > SAE DSRC TC. You should look into getting a 1609.3 (soon to be v3) WAVE > compliant stack and look into the SAE J2735 message set to put on top of > your layer 2 802.11p dongle. These are layer 3 (null-networking actually= ) > and above protocols and message sets for accomplishing exactly what you > want to do. You don't need IP for this, and as far as 11p > (dot11OCBActivated is true) operations, they are exactly what you need. > > > > Cheers, > > > > RR > > > > PS. You might also want to consider a little security (IEEE 1609.2) if yo= u > are at all concerned about getting hacked (someone sending false BSMs to > confuse your squadron:^))) > > > > *From:* Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Friday, November 07, 2014 2:23 PM > *To:* dickroy@alum.mit.edu > *Cc:* Varadi , Andras (lesswire AG Ungarn); its@ietf.org > > *Subject:* Re: [geonet/its] 802.11p USB dongles? > > > > > > > > On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy wrote: > > A few things to remember: > > > > 1) DCC is not yet mandatory anywhere and hopefully that situation will no= t > change. > > 2) What needs to be done to address the congestion problem is to use 21rs= t > century MAC/PHY technology, not 20th century technology, and it's > technology that's available now. > > 2) If DCC does become mandatory, it is likely to be only be conditionally > so (at least in Europe), conditioned on the use of ETSI's GeoNetworking > protocol, and there is little to no chance of that protocol getting out o= f > the research labs. > > 3) The coupling that people seem to believe exists between 11p and IPv6 i= s > a fiction in their minds. There is NO coupling. IPv6 can be used as wit= h > any other lower layer protocols independent of anything to do with 11p. > That said, there are issues of how to set up addresses in ad hoc networks > of vehicles, but bridges and meshes (layer 2 addressing) are much better > suited for that. > > 4) IPv6 networking is only required when attempting to use networks to > communicate between peers. I'm guessing your aviation application is not > attempting to control a helicopter over the internet from your home. Any > use of a non-deterministic network for such applications is ... well ... > just not a good idea. > > > > Hehehe. No, I am not trying to control a helicopter over the internet :-) > As I mentioned in the original post, I want to be able to communicate > between the quad-copters while they are in flight. I know there are metho= ds > where you can communicate over 802.11 b/g/n with WiFi-P2P/Direct (not sur= e > which term is more appropriate, Direct probably) where one quad-copter > could act as a soft AP and the others could act as clients. And, I also > know that there are people who already stream video while the quad-copter= s > are in flight over Wi-Fi as well as actually controlling the flying objec= ts > with a Wi-Fi controller. > > > > But, that is not what I am looking for. I want to be able to send > direction/speed/heading information from the quads to each other while > they are in flight. A radar application so to speak, where each quad > essentially is aware of the other quads in the vicinity. Mind you, the > direction/speed/heading is just the first piece of information that I > want to share among the quads while they are in flight. If I can achieve > this I want to be able to do more than just information sharing. Since, I > don't want to set up a quad-copter as a soft AP I thought 802.11p is > appropriate since that operates outside of a BSS context. I may be wrong.= I > just don't know. I am researching this stuff to figure out what is feasib= le > and what is not. > > > > > > > > Finally, as I suggested in a previous posting, you can modify a .11a USB > dongle to run in the 5.9GHz band (i.e. create a .11p dongle) if you have > access to the firmware. > > > > Indeed, I have been looking at USB 802.11a dongles as you suggested and I > can find dual band dongles with chipsets such as RALink RT3572. This is > just an example. And http://wireless.kernel.org/en/users/Drivers > indicates that there are drivers available for RALink chipsets. So, > theoretically, it may be possible to modify the driver. But I have not ye= t > researched if firmware for the actual chipset is available or not. And th= e > spec sheets of the chipsets that I have looked at indicate that the > frequency range of the 802.11a dongles goes up to only 5825 MHz (802.11a > compliance). > > > > I assume that is the reason you say I need access to the firmware so that > I can push the frequency range between 5855 MHz and 5925 MHz for 802.11p > compliance. > > > > Thanks, > > Kiran. > > > > > > RR > ------------------------------ > > *From:* Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Friday, November 07, 2014 12:04 PM > *To:* Varadi , Andras (lesswire AG Ungarn) > > > *Cc:* its@ietf.org > *Subject:* Re: [geonet/its] 802.11p USB dongles? > > > > Hi Andras, > > > > Thanks for the links. Will there be support from lesswire for Linux > systems for these USB modules or will the users have to come up with the > drivers themselves? Also, what do you think the price of USB module will > be? Or is it better to ask one of the distributors that question? > > > > As for your DCC question, I have only now started looking in to the whole > 802.11p shebang and haven't completely dug in to the requirements to comp= ly > with the standards yet. I have been asking questions of Alexandru Petresc= u > in another email chain and following his suggestions of first trying to > find a hardware/driver combination that will allow me to transmit in the > 802.11p frequency band with IP. > > > > In short, to answer your question about DCC, I don't know how to handle > that just yet. > > > > > > Thanks, > > Kiran. > > > > > > > > > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) < > Varadi@lesswire.com> wrote: > > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI G5 in the > EU... > Just for an example: how will You tolerate DCC (Decentralized Congestion > Control) in Your use case? (which will not let You transmit just any time= - > and You need DCC to transmit and comply the standards) > > USB 11p module (available next year) - > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car= 2x/overview/ > More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > =C3=9Cdv=C3=B6zlettel / Best regards, > Andr=C3=A1s V=C3=A1radi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 <%2B36%2023521%20667> | > Email: Varadi@lesswire.com > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of 5.9GHz and high > power levels for ITS, if the flying experimentation happens indoors > (hangar). > > But coming back to the original question: is there an USB dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) only does > mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most constraine= d > linux platforms which feature USB rather than mini-PCI. > > If this is done, and given the easiness of running IP on 802.11p, I'd be > thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit : > > Hello RR, > > > > The idea indeed is to comply with the standards and regulation already > > present. > > > > Thanks, > > Kiran. > > > > On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > > wrote: > > > > __ __ __ > > > > I'd suggest you look for 802.11a compliant dongles that have > > mad-wifi or some other open source driver you can modify. I'd also > > recommend you NOT use the 5.850-5.925GHz band since that band is > > reserved for ITS, unless, of course, you plan on complying with th= e > > number of standards and regulations already in place for use of the > > band.____ > > > > __ __ > > > > Cheers,____ > > > > __ __ > > > > RR ____ > > > > __ __ > > > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu > > ] > > *Sent:* Tuesday, November 04, 2014 10:42 AM > > *To:* its@ietf.org > > *Subject:* [geonet/its] 802.11p USB dongles?____ > > > > __ __ > > > > Hello All,____ > > > > __ __ > > > > I am a graduate student at the ____University__ of __Kentucky____ > > and I am looking at using 802.11p for communication between out > > quad-copters. To that end is anyone aware of any 802.11p USB dongle= s > > on the market? Are there any open source drivers (Linux > > specifically) that are in semi-usable state or in development? If > > so where can one find such a driver for 802.11p cards/USB > > dongles?____ > > > > __ __ > > > > Thanks,____ > > > > Kiran Arcot.____ > > > > > > > > > > _______________________________________________ > > 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 > > > > > --047d7bd9201a0e47d1050786f792 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi RR,

What you describe may be what I = need to use. Here is a unit I found from Arada systems.


It sh= ows the size of the unit with reference to a smartphone in a car. It also l= ooks like they have a version 2: the LocomateMini2. And the datasheet has a= ll the acronyms that you mention.



It = also mentions an SDK for development of applications. I will need to look a= t the pricing (at this point I am guessing it is relatively expensive) and = the SDK to see if it matches my requirements. Although, it is not obvious f= rom the datasheet if it can be interfaced with a development boards such as= a Raspberry Pi, Beagleboard, Odroid XU3 etc.

Than= ks,
Kiran.





= On Mon, Nov 10, 2014 at 12:34 PM, Richard Roy <dickroy@alum.mit.edu= > wrote:

Arcot,

=C2=A0

What you want to accomplish h= as already been done in numerous field trials of V2V and V2I technology developed over= the last 15 years in IEEE 1609 and SAE DSRC TC.=C2=A0 You should look into gett= ing a 1609.3 (soon to be v3) WAVE compliant stack and look into the SAE J2735 mes= sage set to put on top of your layer 2 802.11p dongle.=C2=A0 These are layer 3 (null-networking actually) and above protocols and message sets for accomplishing exactly what you want to do.=C2=A0 You don't need IP for = this, and as far as 11p (dot11OCBActivated is true) operations, they are exactly what yo= u need.

=C2=A0

Cheers,<= /font>

=C2=A0

RR

=C2=A0

PS. You might also want to co= nsider a little security (IEEE 1609.2) if you are at all concerned about getting hac= ked (someone sending false BSMs to confuse your squadron:^)))

=C2=A0

From: Arcot, Kir= an K [mailto:kiranarcot@= uky.edu]
Sent: Friday, November 07, 2= 014 2:23 PM
To: dickroy@alum.mit.edu
Cc: Varadi , Andras (lesswir= e AG Ungarn); its@ietf.org=


Subject: Re: [geonet/its] 80= 2.11p USB dongles?

=C2=A0

=C2=A0

=C2=A0

On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy <dickroy@alum.mit.edu<= /a>> wrote:

A few things to remember:

=C2=A0

1) DCC is not yet mandatory a= nywhere and hopefully that situation will not change.=C2=A0

2) What needs to be done to a= ddress the congestion problem is to use 21rst century MAC/PHY technology, not 20th century technology, and it&#= 39;s technology that's available now.

2) If DCC does become mandato= ry, it is likely to be only be conditionally so (at least in Europe), conditioned on the use of ETSI's GeoNetworking protocol, and there is l= ittle to no chance of that protocol getting out of the research labs.<= u>

3) The coupling that people s= eem to believe exists between 11p and IPv6 is a fiction in their minds.=C2=A0 There is NO coupling.=C2=A0 IPv6 ca= n be used as with any other lower layer protocols independent of anything to do = with 11p.=C2=A0 That said, there are issues of how to set up addresses in ad hoc networks of vehicles, but bridges and meshes (layer 2 addressing) are much better suited for that.

4) IPv6 networking is only re= quired when attempting to use networks to communicate between peers.=C2=A0 I'm guessing your aviation applicat= ion is not attempting to control a helicopter over the internet from your home.=C2= =A0 Any use of a non-deterministic network for such applications is ... well ..= . just not a good idea.

=C2=A0

Hehehe. No, I am not trying to control a helicopter = over the internet :-) =C2=A0As I mentioned in the original post, I want to be able to communi= cate between the quad-copters while they are in flight. I know there are methods where you can communicate over 802.11 b/g/n with WiFi-P2P/Direct (not sure which term is more appropriate, Direct probably) where one quad-copter coul= d act as a soft AP and the others could act as clients. And, I also know that there are people who already stream video while the quad-copters are in fli= ght over Wi-Fi as well as actually controlling the flying objects with a Wi-Fi controller.

=C2=A0

But, that is not what I am looking for. I want to be= able to send direction/speed/heading information from the quads to each other while they are in flight. A radar application = so to speak, where each quad essentially is aware of the other quads in the vicinity. Mind you, the direction/speed/heading is just the first piece of = information that I want to share among the quads while they are in flight. If I can achieve this I want to be able to do mor= e than just information sharing. Since, I don't want to set up a quad-copter as a soft AP I thought 802.= 11p is appropriate since that operates outside of a BSS context. I may be wrong. I just don't know. I am researching this stuff to figure out what is feas= ible and what is not.

=C2=A0

=C2=A0

=C2=A0

Finally, as I suggested in a = previous posting, you can modify a .11a USB dongle to run in the 5.9GHz band (i.e. create a .11p dongle) if yo= u have access to the firmware.

=C2=A0

Indeed, I have been looking at USB 802.11a dongles a= s you suggested and I can find dual band dongles with chipsets such as RALink RT3572. This is j= ust an example. And=C2=A0http://wireless.kernel.org/en/users/Drivers indicates that there are drivers available for RALink chipsets. So, theoret= ically, it may be possible to modify the driver. But I have not yet researched if firmware for the actual chipset is available or not. And the spec sheets of= the chipsets that I have looked at indicate that the frequency range of the 802= .11a dongles goes up to only 5825 MHz (802.11a compliance).=

=C2=A0

I assume that is the reason you say I need access to= the firmware so that I can push the frequency range between 5855 MHz and 5925 MHz for 802.1= 1p compliance.

=C2=A0

Thanks,

Kiran.

=C2=A0

=C2=A0

RR

From: Arcot, Kir= an K [mailto:kirana= rcot@uky.edu]
Sent: Friday, November 07, 2= 014 12:04 PM
To: Varadi , Andras (lesswir= e AG Ungarn)


Cc: its@ietf.org
Subject: Re: [geonet/its] 80= 2.11p USB dongles?

=C2=A0

Hi Andras,

=C2=A0

Thanks for the links. Will there be support from lesswire for Linux systems for these USB modules or will the users have to come up with the drivers themselves? Also= , what do you think the price of USB module will be? Or is it better to ask o= ne of the distributors that question?

=C2=A0

As for your DCC question, I have only now started looking in to the whole 802.11p shebang a= nd haven't completely dug in to the requirements to comply with the standa= rds yet. I have been asking questions of Alexandru Petrescu in another email chain a= nd following his suggestions of first trying to find a hardware/driver combina= tion that will allow me to transmit in the 802.11p frequency band with IP.

=C2=A0

In short, to answer your question about DCC, I don't know how to handle that just ye= t.

=C2=A0

=C2=A0

Thanks,

Kiran.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) <Varadi@lesswire.com> wrote:

Hi Kiran

I also have some serious concerns about outdoor usage of ETSI G5 in the EU.= ..
Just for an example: how will You tolerate DCC (Decentralized Congestion Control) in Your use case? (which will not let You transmit just any time -= and You need DCC to transmit and comply the standards)

USB 11p module (available next year) - http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-= car2x/overview/
More info on availibility from the distributors: http://www.lesswire.com/en/distributors/commercia= ls-new/

=C3=9Cdv=C3=B6zlettel / Best regards,
=C2=A0=C2=A0 Andr=C3=A1s V=C3=A1radi

=C2=A0=C2=A0=C2=A0 =C2=A0Project Manager - C2X/ITS Systems
=C2=A0 =C2=A0 =C2=A0Customer Support Wireless Modules

=C2=A0=C2=A0=C2=A0=C2=A0 Automotive & WLAN Group
=C2=A0=C2=A0=C2=A0=C2=A0 lesswire=C2=A0=C2=A0 Hungary<= u> | Office: +36 23521 667 | Email: V= aradi@lesswire.com


-----Original Message-----
From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu
Sent: Thursday, November 06, 2014 5:45 PM
To: Arcot, Kiran K; dickroy@alum.mit.edu
Cc: its@ietf.org
Subject: Re: [geonet/its] 802.11p USB dongles?<= /p>

Well - there may be ways to comply to the legislation of 5.9GHz and high power levels for IT= S, if the flying experimentation happens indoors (hangar).

But coming back to the original question: is there an USB dongle 802.11p?
The manufacturer I am familiar with (UNEX, not to name it) only does mini-P= CI 802.11p cards.

An 802.11p USB dongle format may be useful to some of the most constrained linux platforms which feature USB rather than mini-PCI.

If this is done, and given the easiness of running IP on 802.11p, I'd b= e thrilled to see IP between flying objects.

Alex


Le 06/11/2014 17:04, Arcot, Kiran K a =C3=A9crit :
> Hello RR,
>
> The idea indeed is to comply with the standards and regulation already=
> present.
>
> Thanks,
> Kiran.
>
> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <dickroy@alum.mit.edu
> <mailto:d= ickroy@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0__ __ __
>
>=C2=A0 =C2=A0 =C2=A0I'd suggest you look for 802.11a compliant dong= les that have
>=C2=A0 =C2=A0 =C2=A0mad-wifi or some other open source driver you can m= odify. I'd also
>=C2=A0 =C2=A0 =C2=A0recommend you NOT use the 5.850-5.925GHz band since that band is
>=C2=A0 =C2=A0 =C2=A0reserved for ITS,=C2=A0 unless, of course, you plan= on complying with the
>=C2=A0 =C2=A0 =C2=A0number of standards and regulations already in plac= e for use of the
>=C2=A0 =C2=A0 =C2=A0band.____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Cheers,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0RR ____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>
> ----------------------------------------------------------------------=
> --
>
>=C2=A0 =C2=A0 =C2=A0*From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu
>=C2=A0 =C2=A0 =C2=A0<mailto:kiranarcot@uky.edu>]
>=C2=A0 =C2=A0 =C2=A0*Sent:* Tuesday, November 04, 2014 10:42 AM
>=C2=A0 =C2=A0 =C2=A0*To:* its@ietf.org <mailto:its@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* [geonet/its] 802.11p USB dongles?____ >
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Hello All,____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0I am a graduate student at the ____University__ of __Kentucky____
>=C2=A0 =C2=A0 =C2=A0and I am looking at using 802.11p for communication between out
>=C2=A0 =C2=A0 =C2=A0quad-copters. To that end is anyone aware of any 802.11p USB dongles
>=C2=A0 =C2=A0 =C2=A0on the market? Are there any open source drivers (L= inux
>=C2=A0 =C2=A0 =C2=A0specifically) that are in semi-usable state or in development?=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0so where can one find such a driver for 802.11p cards/USB
> dongles?____
>
>=C2=A0 =C2=A0 =C2=A0__ __
>
>=C2=A0 =C2=A0 =C2=A0Thanks,____
>
>=C2=A0 =C2=A0 =C2=A0Kiran Arcot.____
>
>
>
>
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its
>


_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its

=C2=A0

=C2=A0


--047d7bd9201a0e47d1050786f792-- From nobody Mon Nov 10 13:41:17 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2230F1A1C06 for ; Mon, 10 Nov 2014 13:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI89XlvzTj4P for ; Mon, 10 Nov 2014 13:41:15 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCFA1A1AC5 for ; Mon, 10 Nov 2014 13:41:15 -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 sAALfCa6029847; Mon, 10 Nov 2014 22:41:12 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63A9A20710C; Mon, 10 Nov 2014 22:41:28 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4D6A6206E7A; Mon, 10 Nov 2014 22:41:28 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.94]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAALekgB016637; Mon, 10 Nov 2014 22:41:11 +0100 Message-ID: <546130DE.2070805@gmail.com> Date: Mon, 10 Nov 2014 22:40:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Dino Farinacci References: <5458E273.8060900@gmail.com> <5458E968.8000105@gmail.com> <2A383107-ABD0-44D6-A298-D9E8D863DD45@gmail.com> In-Reply-To: <2A383107-ABD0-44D6-A298-D9E8D863DD45@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/DqL9RMM7ImPFvdDU6uSaiAD3-R4 Cc: "its@ietf.org" Subject: Re: [geonet/its] meet in HNL X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:41:17 -0000 Ok tomorrow Tuesday 17h30 - at IETF Registration Desk. 3 people confirmed they'll be there. It is prior to the Social. I dont think I go to it, but 30minutes should be good enough otherwise we'll reschedule. Remember the status we discuss: - RG - progress the V2V discussion - how? - 802.11p driver and hardware availability. Alex Le 04/11/2014 15:59, Dino Farinacci a écrit : > Works for me. > > Dino > >> On Nov 4, 2014, at 6:57 AM, Alexandru Petrescu wrote: >> >> Le 04/11/2014 15:45, Dino Farinacci a écrit : >>>> This is a status update about geonet/its. >>> >>> Are we meeting at IETF next week? >> >> Yes, let us meet at the IETF next week. >> >> I propose Tuesday at 17h30 for one hour or so. >> >> Alex >> >>> >>> Dino >>> >>> >>> >> >> > > > From nobody Mon Nov 10 16:59:31 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D21A87EB for ; Mon, 10 Nov 2014 16:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVnH4DLr65bN for ; Mon, 10 Nov 2014 16:59:28 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B9E1A3BA5 for ; Mon, 10 Nov 2014 16:59:28 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id z12so10354415wgg.37 for ; Mon, 10 Nov 2014 16:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BbzmZz5mZ1vCSXsd0vRWL2eAXtzKH8XTj8j5gegzUiE=; b=kcIODKjKsMsViB9IFnBPjnjiesEnIhv35fl1VsezhkmV5dbvXj2O3iHYazRvt8hMi7 /m7AKLfL0e1bsoEIlr4wbdjBCu43Q0EtasIt/sHbpzwpI8W9PYwxehkg0+YrVeazBVSH x6a1SqW2C7qzieFn9DJnWNorOKkOQ9xAmESYrdIphihuWIfOSk2Bx5DVR8F0a4aS+u3l IOK25OKpqI0ajbwJL+gI0y9JgHE2KvSvMS1jBx5bYTk8AJDpXtZDb6LGJCNubaHi25vT urSHbhjuU5UmxnQ6VA+xpUIShvvC7whQnYSTyu9mQBzIbBbaKAR8InT5xArdCf2gLLpH YRqg== X-Received: by 10.194.6.195 with SMTP id d3mr36643037wja.57.1415667567408; Mon, 10 Nov 2014 16:59:27 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:a520:88ad:b110:9dd2? (t2001067c03700160a52088adb1109dd2.wireless.v6.meeting.ietf.org. [2001:67c:370:160:a520:88ad:b110:9dd2]) by mx.google.com with ESMTPSA id mw7sm15400955wib.14.2014.11.10.16.59.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 16:59:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (12B411) In-Reply-To: <546130DE.2070805@gmail.com> Date: Mon, 10 Nov 2014 14:59:24 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <05E0DE23-C0A8-4790-ACA3-077CF417D200@gmail.com> References: <5458E273.8060900@gmail.com> <5458E968.8000105@gmail.com> <2A383107-ABD0-44D6-A298-D9E8D863DD45@gmail.com> <546130DE.2070805@gmail.com> To: Alexandru Petrescu Archived-At: http://mailarchive.ietf.org/arch/msg/its/daJ6qS9ZBsNC3eFXbd2dxJ0VRwY Cc: "its@ietf.org" Subject: Re: [geonet/its] meet in HNL X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 00:59:30 -0000 Ack. I'll be there.=20 Dino > On Nov 10, 2014, at 11:40 AM, Alexandru Petrescu wrote: >=20 > Ok tomorrow Tuesday 17h30 - at IETF Registration Desk. >=20 > 3 people confirmed they'll be there. >=20 > It is prior to the Social. I dont think I go to it, but 30minutes should b= e good enough otherwise we'll reschedule. >=20 > Remember the status we discuss: > - RG > - progress the V2V discussion - how? > - 802.11p driver and hardware availability. >=20 > Alex >=20 > Le 04/11/2014 15:59, Dino Farinacci a =C3=A9crit : >> Works for me. >>=20 >> Dino >>=20 >>> On Nov 4, 2014, at 6:57 AM, Alexandru Petrescu wrote: >>>=20 >>> Le 04/11/2014 15:45, Dino Farinacci a =C3=A9crit : >>>>> This is a status update about geonet/its. >>>>=20 >>>> Are we meeting at IETF next week? >>>=20 >>> Yes, let us meet at the IETF next week. >>>=20 >>> I propose Tuesday at 17h30 for one hour or so. >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Dino >=20 >=20 From nobody Tue Nov 11 14:00:50 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C41A1AF2 for ; Tue, 11 Nov 2014 14:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJDjW_KAnal8 for ; Tue, 11 Nov 2014 14:00:47 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C991A1AF1 for ; Tue, 11 Nov 2014 14:00:47 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so12493302wgh.6 for ; Tue, 11 Nov 2014 14:00:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OxJ2RqBuhiGhFDNY4rAEjUWLRz1qUE3moBfsHsU6YNI=; b=gAqtp2zKFQ9E5RqUHbiaXIHlgVCiOA6SW7IjkwhGMCQyM+BgtpvTXcWLi4V0Z3o3ZE xAZg9PsX5q36ZbFB/NkxOKvsCJbOce4haKdvJW8dV5PeywINUFLcjC4PPB9ZSQiecwi1 oMq/bKTOLiBR2mrHrJ50lf8nZcb4vEcs4TKGXUJsAmEkCNzSltLZD4qz3F03IiSOuOwi 4Gr4Wkzbj3jxJ+s+YfbTWwIvayqbQm1LbR/biWBs3veMtGtRgwlaqMS+V95pYmgtmmYQ KdFVmlQ/QH6JeEoCoVwtOQe3PzFC0f/URdSpkUoxQJN5yMNx8w8/O/G8L0xWXbSUG0H9 rgCQ== X-Received: by 10.180.91.49 with SMTP id cb17mr203167wib.30.1415743246004; Tue, 11 Nov 2014 14:00:46 -0800 (PST) Received: from [31.133.162.62] (dhcp-a23e.meeting.ietf.org. [31.133.162.62]) by mx.google.com with ESMTPSA id gy4sm19151015wib.11.2014.11.11.14.00.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Nov 2014 14:00:45 -0800 (PST) From: Alexandru Petrescu X-Google-Original-From: Alexandru Petrescu Message-ID: <5462870A.1040100@cea.fr> Date: Tue, 11 Nov 2014 23:00:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu, 'Dino Farinacci' References: <5458E273.8060900@gmail.com> <5458E968.8000105@gmail.com> <2A383107-ABD0-44D6-A298-D9E8D863DD45@gmail.com> <546130DE.2070805@gmail.com> <05E0DE23-C0A8-4790-ACA3-077CF417D200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/4oDKlOCfaqqZvPeg4q1mr7y79No Cc: its@ietf.org Subject: Re: [geonet/its] meet in HNL X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 22:00:49 -0000 Depending on the Le 11/11/2014 22:13, Richard Roy a écrit : > Today Tuesday 11/11 at 8:30PM PST (5:30PM HST) does not work for me. I'm in > meetings until 9:30PM PST. Can it be moved to Wednesday? Depending on what we discuss this evening we may try to meet and discuss again tomorrow Wednesday. Stay in touch. Alex > > RR > >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Monday, November 10, 2014 4:59 PM >> To: Alexandru Petrescu >> Cc: its@ietf.org >> Subject: Re: [geonet/its] meet in HNL >> >> Ack. I'll be there. >> >> Dino >> >> >>> On Nov 10, 2014, at 11:40 AM, Alexandru Petrescu >> wrote: >>> >>> Ok tomorrow Tuesday 17h30 - at IETF Registration Desk. >>> >>> 3 people confirmed they'll be there. >>> >>> It is prior to the Social. I dont think I go to it, but 30minutes >> should be good enough otherwise we'll reschedule. >>> >>> Remember the status we discuss: >>> - RG >>> - progress the V2V discussion - how? >>> - 802.11p driver and hardware availability. >>> >>> Alex >>> >>> Le 04/11/2014 15:59, Dino Farinacci a écrit : >>>> Works for me. >>>> >>>> Dino >>>> >>>>> On Nov 4, 2014, at 6:57 AM, Alexandru Petrescu >> wrote: >>>>> >>>>> Le 04/11/2014 15:45, Dino Farinacci a écrit : >>>>>>> This is a status update about geonet/its. >>>>>> >>>>>> Are we meeting at IETF next week? >>>>> >>>>> Yes, let us meet at the IETF next week. >>>>> >>>>> I propose Tuesday at 17h30 for one hour or so. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> Dino >>> >>> >> > > > > From nobody Wed Nov 12 20:19:15 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF531A1B6A for ; Wed, 12 Nov 2014 20:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsFubGdy0z0E for ; Wed, 12 Nov 2014 20:19:12 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5DA1A1B07 for ; Wed, 12 Nov 2014 20:19: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 sAD4J9tf030303 for ; Thu, 13 Nov 2014 05:19:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ECFB52014B4 for ; Thu, 13 Nov 2014 05:19:28 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA80C201489 for ; Thu, 13 Nov 2014 05:19:28 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.13]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sAD4IkUd011536 for ; Thu, 13 Nov 2014 05:19:08 +0100 Message-ID: <54643126.7080806@gmail.com> Date: Thu, 13 Nov 2014 05:18:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/1HzCHZpnwZHGqZ0fV53FB12Z2mA Subject: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 04:19:13 -0000 Hello, Friday morning there will be a presentation about using geolocation information in IPv6 headers, in the 6man Working Group. https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo What do you think about this draft? Alex From nobody Thu Nov 13 12:10:54 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25C71ACE43 for ; Thu, 13 Nov 2014 12:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf3AppvqKtkz for ; Thu, 13 Nov 2014 12:10:40 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0650D1ACFFC for ; Thu, 13 Nov 2014 12:10:19 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id fa1so15829367pad.25 for ; Thu, 13 Nov 2014 12:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=Wzi0DbYF+ItZHy++aH6HMRHb6O4dqmDyhR+je/HxzHg=; b=1EG6oOvqdPh4eDy+ptD2pzFda8gQakZf6XHOUxZNuQJqTCeLIwjBZl+uz0I3WyKmyJ T+cOs+25/nWKja18ZCXcYfX4UMb/yIZgOqwvOdc2IaGUDhANMLYlU2oJEeNkYc2X/W2H 6n6XiRjv0AF0yby00hsAuucMfQknz+ShSjYZk+PJ8tKAq/uFM7VGjumvLJsb2sGNozHy 4a4XMTvdV1rucfN22mw2nUkU/zttXLlFWP8yd//QiT1qpT/ttgBX9njftQ9Njk2wrTaP 9gcIcCsGh0mzkbYr3SEEgFsRKq1IYNK3EKYqi41lobm3LErcZWpb7DV6cC4cp/8S7HK/ nNbQ== X-Received: by 10.66.161.3 with SMTP id xo3mr4906668pab.131.1415909419273; Thu, 13 Nov 2014 12:10:19 -0800 (PST) Received: from [192.168.1.105] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id xg4sm5802688pab.8.2014.11.13.12.10.18 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 13 Nov 2014 12:10:18 -0800 (PST) Message-ID: <1415909416.13262.7.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandru Petrescu Date: Thu, 13 Nov 2014 12:10:16 -0800 In-Reply-To: <54643126.7080806@gmail.com> References: <54643126.7080806@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/2CU2In25TEi5mN9dYTInbO4vLFg Cc: "its@ietf.org" Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:10:47 -0000 Alex, The ID is a good first step -- it illustrates at least one way to encode Lat/Lon/Alt at layer 3. IPv6 certainly has the flexibility to do such. My misgiving, which I haven't thought out in detail, is that use of header extensions in IPv6 opens a bunch of security issues. The security part of the ID is pretty blithe. The geo datum is not specified. At the ID stage that's hardly fatal but needs to get in eventually. The geo work should be followed by the header compression work in 6lowpan -- lots of bits means lots of spectrum use and lots of power (e.g. battery power) so you want to conserve. But do you want this content data at layer 3? Operational requirement... RFC6953 (PAWS) has just been read out by IETF. PAWS uses layer 7 geo encoding (and specified WGS84). Also worth reading through altho the geo here is used for a different purpose. b On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote: > Hello, > > Friday morning there will be a presentation about using geolocation > information in IPv6 headers, in the 6man Working Group. > https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html > > The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo > > What do you think about this draft? > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Thu Nov 13 12:36:27 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2221AD34E for ; Thu, 13 Nov 2014 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGQjyBk80v9H for ; Thu, 13 Nov 2014 12:36:17 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835B31AD34F for ; Thu, 13 Nov 2014 12:35: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 sADKZiXC023861; Thu, 13 Nov 2014 21:35:44 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 806A720473E; Thu, 13 Nov 2014 21:36:04 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 747422046F4; Thu, 13 Nov 2014 21:36:04 +0100 (CET) Received: from [127.0.0.1] ([132.166.84.166]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sADKZITT006842; Thu, 13 Nov 2014 21:35:42 +0100 Message-ID: <54651605.2070708@gmail.com> Date: Thu, 13 Nov 2014 21:35:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rex Buddenberg References: <54643126.7080806@gmail.com> <1415909416.13262.7.camel@localhost.localdomain> In-Reply-To: <1415909416.13262.7.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/yMSqmKaKCZIXdWcDh0Li6qZRyAE Cc: "its@ietf.org" Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:36:22 -0000 Le 13/11/2014 21:10, Rex Buddenberg a écrit : > Alex, > > The ID is a good first step -- it illustrates at least one way to encode > Lat/Lon/Alt at layer 3. IPv6 certainly has the flexibility to do > such. > My misgiving, which I haven't thought out in detail, is that use of > header extensions in IPv6 opens a bunch of security issues. The > security part of the ID is pretty blithe. I agree. A colleague IETFer also told me the privacy risk may be there. I wonder whether the Destinations Options header of IPv6 could be covered by the encryption part of an ESP (Encapsulating Security Payload of IPsec), or if otherwise DO must always travel in clear. > The geo datum is not specified. At the ID stage that's hardly > fatal but needs to get in eventually. I agree. This is a good remark. > The geo work should be followed by the header compression work in > 6lowpan -- lots of bits means lots of spectrum use and lots of power > (e.g. battery power) so you want to conserve. > > But do you want this content data at layer 3? Operational > requirement... This is a good question. Many remarks in geonet/its were about the fact that sending geo-position data should happen at app layer, not elsewhere. An official report tells a country's vehicular comm standards should not consider geo-position as strongly as another country's similar standard - naming the wrong situation at network layer as a reason. On another hand, many standards don't really feature application layers distinct from network layers. If all applications run in the network layer, is it still non-recommended to put geo-position in there? > RFC6953 (PAWS) has just been read out by IETF. PAWS uses layer 7 geo > encoding (and specified WGS84). Also worth reading through altho the > geo here is used for a different purpose. Ok, will look at this spectrum related document. The application seems to be different for PAWS (spectrum). HEre, if I understand correctly, IPv6 GEO may be useful for emergency kinds of apps. In that sense, one would like _any_ packet out of a node to tell its position, not necessarily the packets issues by one particular application. I.e. one may wonder what happens if some application in the computer crashes - will the control center loose computer's position? because the kernel may still echo requests from the control center, piggybacked with DO GEO IPv6. Alex > > > > b > > > On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote: >> Hello, >> >> Friday morning there will be a presentation about using geolocation >> information in IPv6 headers, in the 6man Working Group. >> https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html >> >> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >> >> What do you think about this draft? >> >> Alex >> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > > From nobody Thu Nov 13 13:40:09 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F61AD6F4 for ; Thu, 13 Nov 2014 13:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KedJ3mL1RxpW for ; Thu, 13 Nov 2014 13:40:00 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 905981AD6FC for ; Thu, 13 Nov 2014 13:39:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id ADCD394184; Thu, 13 Nov 2014 16:39:49 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3H0zKDwz6O2; Thu, 13 Nov 2014 16:39:45 -0500 (EST) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id AEA3B94183; Thu, 13 Nov 2014 16:39:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id A787BEE789E; Thu, 13 Nov 2014 16:39:45 -0500 (EST) Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d7QB_v5lAJc3; Thu, 13 Nov 2014 16:39:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id BB671EE7A63; Thu, 13 Nov 2014 16:39:41 -0500 (EST) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 546lSsTsXE8T; Thu, 13 Nov 2014 16:39:41 -0500 (EST) Received: from OfficeHP (c-75-71-122-141.hsd1.co.comcast.net [75.71.122.141]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 32C66EE789E; Thu, 13 Nov 2014 16:39:40 -0500 (EST) Message-ID: <0345CC670596442CBB36396EE6728D96@OfficeHP> From: "Carl Reed" To: "Alexandru Petrescu" , "Rex Buddenberg" References: <54643126.7080806@gmail.com> <1415909416.13262.7.camel@localhost.localdomain> <54651605.2070708@gmail.com> In-Reply-To: <54651605.2070708@gmail.com> Date: Thu, 13 Nov 2014 14:39:39 -0700 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/9x3X9TeRiJu1V7nu_jYOpdsZGQ4 Cc: George Percivall , its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:40:03 -0000 Alex - I would look at the DHCP Location extension to see how the datum is=20 specified. Also, if more than one datum (WGS 84) is required then I would= =20 consider using the appropriate EPSG codes, which the DHCP Location RFC al= so=20 uses. To whit: Datum Registry IANA has created and now maintains the Datum registry following the guidelines below. The registry consists of three values: Datum, Description, and Reference. These are described below. Datum: An integer, refers to the value used in the DHCPv4 GeoConf and the DHCPv4 and DHCPv6 GeoLoc options described in this document. Value 0 is Reserved. Values 1 - 3 are assigned. Values 4 - 7 are Unassigned [RFC5226]. Description: The description of the altitude described by this code. Reference: The reference to the document that describes the Datum code. This reference MUST include specification of both the horizontal and vertical datum, and MUST define the way that the 34-bit values and the respective 6-bit uncertainties are interpreted. Initial values are given below; new assignments are to be made following the "Standards Action" policies [RFC5226]. +------+----------------------------------------+--------------+ | # | Description | Reference | +------+----------------------------------------+--------------+ | 0 | Reserved | RFC 6225 | +------+----------------------------------------+--------------+ | 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 | | | CRS Code 4327 | | +------+----------------------------------------+--------------+ | 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 | | | CRS Code 4269 with North American | | | | Vertical Datum of 1988 (NAVD88) | | +------+----------------------------------------+--------------+ | 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 | | | CRS Code 4269 with Mean Lower Low Water| | | | (MLLW) as associated vertical datum | | +------+----------------------------------------+--------------+ | 4-7 | Unassigned | | +------+----------------------------------------+--------------+ >From https://tools.ietf.org/html/rfc6225#page-18 Cheers Carl -----Original Message-----=20 From: Alexandru Petrescu Sent: Thursday, November 13, 2014 1:35 PM To: Rex Buddenberg Cc: its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6= =20 headers - 6MAN Working Group Le 13/11/2014 21:10, Rex Buddenberg a =C3=A9crit : > Alex, > > The ID is a good first step -- it illustrates at least one way to encod= e > Lat/Lon/Alt at layer 3. IPv6 certainly has the flexibility to do > such. > My misgiving, which I haven't thought out in detail, is that use = of > header extensions in IPv6 opens a bunch of security issues. The > security part of the ID is pretty blithe. I agree. A colleague IETFer also told me the privacy risk may be there. I wonder whether the Destinations Options header of IPv6 could be covered by the encryption part of an ESP (Encapsulating Security Payload of IPsec), or if otherwise DO must always travel in clear. > The geo datum is not specified. At the ID stage that's hardly > fatal but needs to get in eventually. I agree. This is a good remark. > The geo work should be followed by the header compression work in > 6lowpan -- lots of bits means lots of spectrum use and lots of power > (e.g. battery power) so you want to conserve. > > But do you want this content data at layer 3? Operational > requirement... This is a good question. Many remarks in geonet/its were about the fact that sending geo-position data should happen at app layer, not elsewhere. An official report tells a country's vehicular comm standards should not consider geo-position as strongly as another country's similar standard - naming the wrong situation at network layer as a reason. On another hand, many standards don't really feature application layers distinct from network layers. If all applications run in the network layer, is it still non-recommended to put geo-position in there? > RFC6953 (PAWS) has just been read out by IETF. PAWS uses layer 7 geo > encoding (and specified WGS84). Also worth reading through altho the > geo here is used for a different purpose. Ok, will look at this spectrum related document. The application seems to be different for PAWS (spectrum). HEre, if I understand correctly, IPv6 GEO may be useful for emergency kinds of apps. In that sense, one would like _any_ packet out of a node to tell its position, not necessarily the packets issues by one particular application. I.e. one may wonder what happens if some application in the computer crashes - will the control center loose computer's position? because the kernel may still echo requests from the control center, piggybacked with DO GEO IPv6. Alex > > > > b > > > On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote: >> Hello, >> >> Friday morning there will be a presentation about using geolocation >> information in IPv6 headers, in the 6man Working Group. >> https://tools.ietf.org/wg/6man/agenda?item=3Dagenda-91-6man.html >> >> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >> >> What do you think about this draft? >> >> Alex >> >> _______________________________________________ >> 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 From nobody Tue Nov 18 11:02:21 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6D1A6F44 for ; Tue, 18 Nov 2014 11:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6X--WsUvBt9 for ; Tue, 18 Nov 2014 11:02:13 -0800 (PST) Received: from radmz1.prettl-elektronik.de (radmz1.prettl-elektronik.de [212.185.50.242]) by ietfa.amsl.com (Postfix) with ESMTP id 40C421A6F21 for ; Tue, 18 Nov 2014 11:02:11 -0800 (PST) Received: from rasrv02.prettl-elektronik.de ([10.76.0.20]:32209) by utm.prettl-electronics.com with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xqo2M-0003Kx-1g; Tue, 18 Nov 2014 20:02:02 +0100 Received: from RASRV50.prettl-elektronik.de ([10.76.0.50]) by RASRV02.prettl-elektronik.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Nov 2014 20:02:02 +0100 Received: from RASRV50.prettl-elektronik.de ([::1]) by RASRV50.prettl-elektronik.de ([::1]) with mapi id 14.02.0298.004; Tue, 18 Nov 2014 20:02:01 +0100 From: "Varadi , Andras (lesswire AG Ungarn)" To: "Arcot, Kiran K" , Richard Roy Thread-Topic: [geonet/its] 802.11p USB dongles? Thread-Index: AQHP+RF1za9YJSv2j0WIIdEjwpncfpxTxPdo///6BICAAWCe4IAAR/0AgBFjynA= Date: Tue, 18 Nov 2014 19:02:01 +0000 Message-ID: References: <545BA571.5010502@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.100.61] Content-Type: multipart/alternative; boundary="_000_ED899A19E313D540BE9D122C2B81599A02C9E6RASRV50prettlelek_" MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2014 19:02:02.0390 (UTC) FILETIME=[23137360:01D00362] Archived-At: http://mailarchive.ietf.org/arch/msg/its/21KDu7cployQkuS_P64h7LcrFVg Cc: "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:02:17 -0000 --_000_ED899A19E313D540BE9D122C2B81599A02C9E6RASRV50prettlelek_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBcmNvdCwgUmljaGFyZA0KDQpTb3JyeSBmb3IgdGhlIGxvbmcgZGVsYXksIEkgd2lsbCB0 cnkgdG8gYW5zd2VyIHNob3J0LA0KDQo+PiBXaWxsIHRoZXJlIGJlIHN1cHBvcnQgZnJvbSBsZXNz d2lyZSBmb3IgTGludXggc3lzdGVtcyBmb3IgdGhlc2UgVVNCIG1vZHVsZXMgb3Igd2lsbCB0aGUg dXNlcnMgaGF2ZSB0byBjb21lIHVwIHdpdGggdGhlIGRyaXZlcnMgdGhlbXNlbHZlcz8gQWxzbywg d2hhdCBkbyB5b3UgdGhpbmsgdGhlIHByaWNlIG9mIFVTQiBtb2R1bGUgd2lsbCBiZT8gT3IgaXMg aXQgYmV0dGVyIHRvIGFzayBvbmUgb2YgdGhlIGRpc3RyaWJ1dG9ycyB0aGF0IHF1ZXN0aW9uPw0K DQpBVjogV2UgcHJvdmlkZSBwcm9kdWN0cywgbm90IHB1cmUgSFcgYW5kIHRodXMgSSBkb250IHNl ZSBhIHdheSBmb3Igc2VsbGluZyBhbnl0aGluZyB3aXRob3V0IGEgZHJpdmVyLiBJIGRvIG5vdCBr bm93IHdobyB3aWxsIHN1cHBseSB0aGUgZHJpdmVyIHRob3VnaCwgdGhlIGRpc3RyaSwgdGhlIG1v ZHVsZSwgdGhlIGNoaXAgbWFudWZhY3R1cmVyIG9yIGFueW9uZSBlbHNlLiBUaGlzIHdpbGwgYmUg ZGV0ZXJtaW5lZCBvbmNlIHdlIHJlbGVhc2UgdGhlIHByb2R1Y3QuDQoNCi0tLS0tLS0tLS0NCnBs ZWFzZSBub3RlIHRoYXQgdGhlc2UgYXJlIG15IHBlcnNvbmFsIG9waW5pb25zIC8gZmVlbGluZ3M6 DQoNCg0KPj4gSW4gc2hvcnQsIHRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uIGFib3V0IERDQywgSSBk b24ndCBrbm93IGhvdyB0byBoYW5kbGUgdGhhdCBqdXN0IHlldC4NCj4+IDEpIERDQyBpcyBub3Qg eWV0IG1hbmRhdG9yeSBhbnl3aGVyZSBhbmQgaG9wZWZ1bGx5IHRoYXQgc2l0dWF0aW9uIHdpbGwg bm90IGNoYW5nZS4NCg0KQVY6IEluIHRoZSBFVSBhdCBsZWFzdCBmb3IgRzVBIHdlIGFyZSB0YWxr aW5nIGFib3V0IGEgc2FmZXR5IHN5c3RlbSB3aGljaCBuZWVkcyB0byBiZSB0cnVzdHdvcnRoeSwg aWYgbXkgY2FycyBzYWZldHkgc3lzdGVtIGZhaWxzIGluIGFuIHVyYmFuIGludGVyc2VjdGlvbiwg YmVjYXVzZSBzb21lb25lIGlzIGFsbG93ZWQgdG8gdHJhbnNtaXQgbm9uLXNhZmV0eSBkYXRhIG9u IHRob3NlIGNoYW5uZWxzLCB0aGVuIHRoZSB3aG9sZSBzeXN0ZW0gaXMgdXNlbGVzcy4NCihpbiB0 aGlzIHNlbnNlIGlmIFlvdSB0cmFuc21pdCBzYWZldHkgZGF0YSwgdGhlbiB5b3UgYXBwbHkgREND KQ0KDQo+PjIpIElmIERDQyBkb2VzIGJlY29tZSBtYW5kYXRvcnksIGl0IGlzIGxpa2VseSB0byBi ZSBvbmx5IGJlIGNvbmRpdGlvbmFsbHkgc28gKGF0IGxlYXN0IGluIEV1cm9wZSksIGNvbmRpdGlv bmVkIG9uIHRoZSB1c2Ugb2YgRVRTSSdzIEdlb05ldHdvcmtpbmcgcHJvdG9jb2wsIGFuZCB0aGVy ZSBpcyBsaXR0bGUgdG8gbm8gY2hhbmNlIG9mIHRoYXQgcHJvdG9jb2wgZ2V0dGluZyBvdXQgb2Yg dGhlIHJlc2VhcmNoIGxhYnMuDQoNCkl0cyBub3QgYW55IG1vcmUgaW4gdGhlIHJlc2VhcmNoIGxh YnM6DQpodHRwOi8vd3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV90ciU1QzEwMTYwMF8xMDE2OTkl NUMxMDE2MDclNUMwMS4wMS4wMV82MCU1Q3RyXzEwMTYwN3YwMTAxMDFwLnBkZg0KaHR0cDovL3d3 dy5ldHNpLm9yZy9uZXdzLWV2ZW50cy9uZXdzLzc1My0yMDE0LTAyLWpvaW50LW5ld3MtY2VuLWFu ZC1ldHNpLWRlbGl2ZXItZmlyc3Qtc2V0LW9mLXN0YW5kYXJkcy1mb3ItY29vcGVyYXRpdmUtaW50 ZWxsaWdlbnQtdHJhbnNwb3J0LXN5c3RlbXMtYy1pdHMNCihJZiBteSBsaW5rcyBhcmUgYnJva2Vu OiAgRVRTSSBUUiAxMDEgNjA3KQ0KDQo+PiBUaGUgY291cGxpbmcgdGhhdCBwZW9wbGUgc2VlbSB0 byBiZWxpZXZlIGV4aXN0cyBiZXR3ZWVuIDExcCBhbmQgSVB2NiBpcyBhIGZpY3Rpb24gaW4gdGhl aXIgbWluZHMuICBUaGVyZSBpcyBOTyBjb3VwbGluZy4NCg0KTm8gY291cGxpbmcsIGJ1dCBJUHY2 IGlzIGEgKG1heWJlIHRoZSBiZXN0KSB3YXkgdG8gZ2xvYmFsbHkgYWRkcmVzcyBmdXR1cmUgY2Fy cyAoY2hlY2sgSVRTU3Y2IGZvciBleGFtcGxlKSwgbmV2ZXJ0aGVsZXNzLCBmb3Igc2FmZXR5IG1l c3NhZ2VzIChub3JtYWwpIElQIGhhcyBqdXN0IHRvIGJpZyBvdmVyaGVhZCwgYSBDQU0gb3IgREVO TSBWMlYgbWVzc2FnZSBpcyBtdWNoIG1vcmUgY29tcGFjdCBhbmQgSVAgY2FuIG5vdCBmaWdodCB0 aGF0LiAoYW5kIHdlIG5lZWQgc2hvcnQvcXVpY2sgdHJhbnNtaXNzaW9uIHRpbWVzISEpDQoNCg0K w5xkdsO2emxldHRlbCAvIEJlc3QgcmVnYXJkcywNCiAgIEFuZHLDoXMgVsOhcmFkaQ0KDQogICAg IFByb2plY3QgTWFuYWdlciDigJMgQzJYL0lUUyBTeXN0ZW1zDQogICAgIEN1c3RvbWVyIFN1cHBv cnQgV2lyZWxlc3MgTW9kdWxlcw0KDQogICAgIEF1dG9tb3RpdmUgJiBXTEFOIEdyb3VwDQogICAg IGxlc3N3aXJlICAgSHVuZ2FyeSB8IE9mZmljZTogKzM2IDIzNTIxIDY2NyB8IEVtYWlsOiBWYXJh ZGlAbGVzc3dpcmUuY29tPG1haWx0bzpWYXJhZGlAbGVzc3dpcmUuY29tPg0KDQpGcm9tOiBBcmNv dCwgS2lyYW4gSyBbbWFpbHRvOmtpcmFuYXJjb3RAdWt5LmVkdV0NClNlbnQ6IEZyaWRheSwgTm92 ZW1iZXIgMDcsIDIwMTQgNzowNCBQTQ0KVG86IFZhcmFkaSAsIEFuZHJhcyAobGVzc3dpcmUgQUcg VW5nYXJuKQ0KQ2M6IGl0c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtnZW9uZXQvaXRzXSA4MDIu MTFwIFVTQiBkb25nbGVzPw0KDQpIaSBBbmRyYXMsDQoNClRoYW5rcyBmb3IgdGhlIGxpbmtzLiBX aWxsIHRoZXJlIGJlIHN1cHBvcnQgZnJvbSBsZXNzd2lyZSBmb3IgTGludXggc3lzdGVtcyBmb3Ig dGhlc2UgVVNCIG1vZHVsZXMgb3Igd2lsbCB0aGUgdXNlcnMgaGF2ZSB0byBjb21lIHVwIHdpdGgg dGhlIGRyaXZlcnMgdGhlbXNlbHZlcz8gQWxzbywgd2hhdCBkbyB5b3UgdGhpbmsgdGhlIHByaWNl IG9mIFVTQiBtb2R1bGUgd2lsbCBiZT8gT3IgaXMgaXQgYmV0dGVyIHRvIGFzayBvbmUgb2YgdGhl IGRpc3RyaWJ1dG9ycyB0aGF0IHF1ZXN0aW9uPw0KDQpBcyBmb3IgeW91ciBEQ0MgcXVlc3Rpb24s IEkgaGF2ZSBvbmx5IG5vdyBzdGFydGVkIGxvb2tpbmcgaW4gdG8gdGhlIHdob2xlIDgwMi4xMXAg c2hlYmFuZyBhbmQgaGF2ZW4ndCBjb21wbGV0ZWx5IGR1ZyBpbiB0byB0aGUgcmVxdWlyZW1lbnRz IHRvIGNvbXBseSB3aXRoIHRoZSBzdGFuZGFyZHMgeWV0LiBJIGhhdmUgYmVlbiBhc2tpbmcgcXVl c3Rpb25zIG9mIEFsZXhhbmRydSBQZXRyZXNjdSBpbiBhbm90aGVyIGVtYWlsIGNoYWluIGFuZCBm b2xsb3dpbmcgaGlzIHN1Z2dlc3Rpb25zIG9mIGZpcnN0IHRyeWluZyB0byBmaW5kIGEgaGFyZHdh cmUvZHJpdmVyIGNvbWJpbmF0aW9uIHRoYXQgd2lsbCBhbGxvdyBtZSB0byB0cmFuc21pdCBpbiB0 aGUgODAyLjExcCBmcmVxdWVuY3kgYmFuZCB3aXRoIElQLg0KDQpJbiBzaG9ydCwgdG8gYW5zd2Vy IHlvdXIgcXVlc3Rpb24gYWJvdXQgRENDLCBJIGRvbid0IGtub3cgaG93IHRvIGhhbmRsZSB0aGF0 IGp1c3QgeWV0Lg0KDQoNClRoYW5rcywNCktpcmFuLg0KDQoNCg0KDQpPbiBGcmksIE5vdiA3LCAy MDE0IGF0IDc6NTIgQU0sIFZhcmFkaSAsIEFuZHJhcyAobGVzc3dpcmUgQUcgVW5nYXJuKSA8VmFy YWRpQGxlc3N3aXJlLmNvbTxtYWlsdG86VmFyYWRpQGxlc3N3aXJlLmNvbT4+IHdyb3RlOg0KSGkg S2lyYW4NCg0KSSBhbHNvIGhhdmUgc29tZSBzZXJpb3VzIGNvbmNlcm5zIGFib3V0IG91dGRvb3Ig dXNhZ2Ugb2YgRVRTSSBHNSBpbiB0aGUgRVUuLi4NCkp1c3QgZm9yIGFuIGV4YW1wbGU6IGhvdyB3 aWxsIFlvdSB0b2xlcmF0ZSBEQ0MgKERlY2VudHJhbGl6ZWQgQ29uZ2VzdGlvbiBDb250cm9sKSBp biBZb3VyIHVzZSBjYXNlPyAod2hpY2ggd2lsbCBub3QgbGV0IFlvdSB0cmFuc21pdCBqdXN0IGFu eSB0aW1lIC0gYW5kIFlvdSBuZWVkIERDQyB0byB0cmFuc21pdCBhbmQgY29tcGx5IHRoZSBzdGFu ZGFyZHMpDQoNClVTQiAxMXAgbW9kdWxlIChhdmFpbGFibGUgbmV4dCB5ZWFyKSAtIGh0dHA6Ly93 d3cubGVzc3dpcmUuY29tL2VuL3Byb2R1Y3RzL3dpcmVsZXNzLW1vZHVsZXMvY2FyMngvd2liZWFy LWl0cy1jYXIyeC9vdmVydmlldy8NCk1vcmUgaW5mbyBvbiBhdmFpbGliaWxpdHkgZnJvbSB0aGUg ZGlzdHJpYnV0b3JzOiBodHRwOi8vd3d3Lmxlc3N3aXJlLmNvbS9lbi9kaXN0cmlidXRvcnMvY29t bWVyY2lhbHMtbmV3Lw0KDQrDnGR2w7Z6bGV0dGVsIC8gQmVzdCByZWdhcmRzLA0KICAgQW5kcsOh cyBWw6FyYWRpDQoNCiAgICAgUHJvamVjdCBNYW5hZ2VyIC0gQzJYL0lUUyBTeXN0ZW1zDQogICAg IEN1c3RvbWVyIFN1cHBvcnQgV2lyZWxlc3MgTW9kdWxlcw0KDQogICAgIEF1dG9tb3RpdmUgJiBX TEFOIEdyb3VwDQogICAgIGxlc3N3aXJlICAgSHVuZ2FyeSB8IE9mZmljZTogKzM2IDIzNTIxIDY2 Nzx0ZWw6JTJCMzYlMjAyMzUyMSUyMDY2Nz4gfCBFbWFpbDogVmFyYWRpQGxlc3N3aXJlLmNvbTxt YWlsdG86VmFyYWRpQGxlc3N3aXJlLmNvbT4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogaXRzIFttYWlsdG86aXRzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOml0cy1ib3Vu Y2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFsZXhhbmRydSBQZXRyZXNjdQ0KU2VudDogVGh1 cnNkYXksIE5vdmVtYmVyIDA2LCAyMDE0IDU6NDUgUE0NClRvOiBBcmNvdCwgS2lyYW4gSzsgZGlj a3JveUBhbHVtLm1pdC5lZHU8bWFpbHRvOmRpY2tyb3lAYWx1bS5taXQuZWR1Pg0KQ2M6IGl0c0Bp ZXRmLm9yZzxtYWlsdG86aXRzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtnZW9uZXQvaXRzXSA4 MDIuMTFwIFVTQiBkb25nbGVzPw0KV2VsbCAtIHRoZXJlIG1heSBiZSB3YXlzIHRvIGNvbXBseSB0 byB0aGUgbGVnaXNsYXRpb24gb2YgNS45R0h6IGFuZCBoaWdoIHBvd2VyIGxldmVscyBmb3IgSVRT LCBpZiB0aGUgZmx5aW5nIGV4cGVyaW1lbnRhdGlvbiBoYXBwZW5zIGluZG9vcnMgKGhhbmdhciku DQoNCkJ1dCBjb21pbmcgYmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb246IGlzIHRoZXJlIGFu IFVTQiBkb25nbGUgODAyLjExcD8NCg0KVGhlIG1hbnVmYWN0dXJlciBJIGFtIGZhbWlsaWFyIHdp dGggKFVORVgsIG5vdCB0byBuYW1lIGl0KSBvbmx5IGRvZXMgbWluaS1QQ0kgODAyLjExcCBjYXJk cy4NCg0KQW4gODAyLjExcCBVU0IgZG9uZ2xlIGZvcm1hdCBtYXkgYmUgdXNlZnVsIHRvIHNvbWUg b2YgdGhlIG1vc3QgY29uc3RyYWluZWQgbGludXggcGxhdGZvcm1zIHdoaWNoIGZlYXR1cmUgVVNC IHJhdGhlciB0aGFuIG1pbmktUENJLg0KDQpJZiB0aGlzIGlzIGRvbmUsIGFuZCBnaXZlbiB0aGUg ZWFzaW5lc3Mgb2YgcnVubmluZyBJUCBvbiA4MDIuMTFwLCBJJ2QgYmUgdGhyaWxsZWQgdG8gc2Vl IElQIGJldHdlZW4gZmx5aW5nIG9iamVjdHMuDQoNCkFsZXgNCg0KDQpMZSAwNi8xMS8yMDE0IDE3 OjA0LCBBcmNvdCwgS2lyYW4gSyBhIMOpY3JpdCA6DQo+IEhlbGxvIFJSLA0KPg0KPiBUaGUgaWRl YSBpbmRlZWQgaXMgdG8gY29tcGx5IHdpdGggdGhlIHN0YW5kYXJkcyBhbmQgcmVndWxhdGlvbiBh bHJlYWR5DQo+IHByZXNlbnQuDQo+DQo+IFRoYW5rcywNCj4gS2lyYW4uDQo+DQo+IE9uIFdlZCwg Tm92IDUsIDIwMTQgYXQgMzowOCBQTSwgUmljaGFyZCBSb3kgPGRpY2tyb3lAYWx1bS5taXQuZWR1 PG1haWx0bzpkaWNrcm95QGFsdW0ubWl0LmVkdT4NCj4gPG1haWx0bzpkaWNrcm95QGFsdW0ubWl0 LmVkdTxtYWlsdG86ZGlja3JveUBhbHVtLm1pdC5lZHU+Pj4gd3JvdGU6DQo+DQo+ICAgICBfXyBf XyBfXw0KPg0KPiAgICAgSSdkIHN1Z2dlc3QgeW91IGxvb2sgZm9yIDgwMi4xMWEgY29tcGxpYW50 IGRvbmdsZXMgdGhhdCBoYXZlDQo+ICAgICBtYWQtd2lmaSBvciBzb21lIG90aGVyIG9wZW4gc291 cmNlIGRyaXZlciB5b3UgY2FuIG1vZGlmeS4gSSdkIGFsc28NCj4gICAgIHJlY29tbWVuZCB5b3Ug Tk9UIHVzZSB0aGUgNS44NTAtNS45MjVHSHogYmFuZCBzaW5jZSB0aGF0IGJhbmQgaXMNCj4gICAg IHJlc2VydmVkIGZvciBJVFMsICB1bmxlc3MsIG9mIGNvdXJzZSwgeW91IHBsYW4gb24gY29tcGx5 aW5nIHdpdGggdGhlDQo+ICAgICBudW1iZXIgb2Ygc3RhbmRhcmRzIGFuZCByZWd1bGF0aW9ucyBh bHJlYWR5IGluIHBsYWNlIGZvciB1c2Ugb2YgdGhlDQo+ICAgICBiYW5kLl9fX18NCj4NCj4gICAg IF9fIF9fDQo+DQo+ICAgICBDaGVlcnMsX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgIFJS IF9fX18NCj4NCj4gICAgIF9fIF9fDQo+DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4NCj4g ICAgICpGcm9tOipBcmNvdCwgS2lyYW4gSyBbbWFpbHRvOmtpcmFuYXJjb3RAdWt5LmVkdTxtYWls dG86a2lyYW5hcmNvdEB1a3kuZWR1Pg0KPiAgICAgPG1haWx0bzpraXJhbmFyY290QHVreS5lZHU8 bWFpbHRvOmtpcmFuYXJjb3RAdWt5LmVkdT4+XQ0KPiAgICAgKlNlbnQ6KiBUdWVzZGF5LCBOb3Zl bWJlciAwNCwgMjAxNCAxMDo0MiBBTQ0KPiAgICAgKlRvOiogaXRzQGlldGYub3JnPG1haWx0bzpp dHNAaWV0Zi5vcmc+IDxtYWlsdG86aXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+Pg0K PiAgICAgKlN1YmplY3Q6KiBbZ2VvbmV0L2l0c10gODAyLjExcCBVU0IgZG9uZ2xlcz9fX19fDQo+ DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgSGVsbG8gQWxsLF9fX18NCj4NCj4gICAgIF9fIF9fDQo+ DQo+ICAgICBJIGFtIGEgZ3JhZHVhdGUgc3R1ZGVudCBhdCB0aGUgX19fX1VuaXZlcnNpdHlfXyBv ZiBfX0tlbnR1Y2t5X19fXw0KPiAgICAgYW5kIEkgYW0gbG9va2luZyBhdCB1c2luZyA4MDIuMTFw IGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gb3V0DQo+ICAgICBxdWFkLWNvcHRlcnMuIFRvIHRo YXQgZW5kIGlzIGFueW9uZSBhd2FyZSBvZiBhbnkgODAyLjExcCBVU0IgZG9uZ2xlcw0KPiAgICAg b24gdGhlIG1hcmtldD8gQXJlIHRoZXJlIGFueSBvcGVuIHNvdXJjZSBkcml2ZXJzIChMaW51eA0K PiAgICAgc3BlY2lmaWNhbGx5KSB0aGF0IGFyZSBpbiBzZW1pLXVzYWJsZSBzdGF0ZSBvciBpbiBk ZXZlbG9wbWVudD8gIElmDQo+ICAgICBzbyB3aGVyZSBjYW4gb25lIGZpbmQgc3VjaCBhIGRyaXZl ciBmb3IgODAyLjExcCBjYXJkcy9VU0INCj4gZG9uZ2xlcz9fX19fDQo+DQo+ICAgICBfXyBfXw0K Pg0KPiAgICAgVGhhbmtzLF9fX18NCj4NCj4gICAgIEtpcmFuIEFyY290Ll9fX18NCj4NCj4NCj4N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g aXRzIG1haWxpbmcgbGlzdA0KPiBpdHNAaWV0Zi5vcmc8bWFpbHRvOml0c0BpZXRmLm9yZz4NCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pdHMNCj4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXRzIG1haWxpbmcgbGlz dA0KaXRzQGlldGYub3JnPG1haWx0bzppdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2l0cw0KDQo= --_000_ED899A19E313D540BE9D122C2B81599A02C9E6RASRV50prettlelek_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMTczRkM2O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpIVTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkhVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPkRlYXIgQXJjb3Qs IFJpY2hhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+U29ycnkgZm9yIHRo ZSBsb25nIGRlbGF5LCBJIHdpbGwgdHJ5IHRvIGFuc3dlciBzaG9ydCwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMTczRkM2Ij4mZ3Q7Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC Ij5XaWxsIHRoZXJlIGJlIHN1cHBvcnQgZnJvbSBsZXNzd2lyZSBmb3IgTGludXggc3lzdGVtcyBm b3IgdGhlc2UgVVNCIG1vZHVsZXMgb3Igd2lsbCB0aGUgdXNlcnMgaGF2ZSB0byBjb21lIHVwIHdp dGggdGhlIGRyaXZlcnMgdGhlbXNlbHZlcz8gQWxzbywgd2hhdCBkbyB5b3UgdGhpbmsgdGhlIHBy aWNlIG9mIFVTQiBtb2R1bGUgd2lsbCBiZT8gT3IgaXMgaXQgYmV0dGVyIHRvIGFzayBvbmUgb2Yg dGhlIGRpc3RyaWJ1dG9ycw0KIHRoYXQgcXVlc3Rpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMTczRkM2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxNzNGQzYiPkFWOiBXZSBwcm92aWRlIHByb2R1Y3RzLCBub3QgcHVyZSBIVyBhbmQgdGh1 cyBJIGRvbnQgc2VlIGEgd2F5IGZvciBzZWxsaW5nIGFueXRoaW5nIHdpdGhvdXQgYSBkcml2ZXIu IEkgZG8gbm90IGtub3cgd2hvIHdpbGwgc3VwcGx5IHRoZSBkcml2ZXINCiB0aG91Z2gsIHRoZSBk aXN0cmksIHRoZSBtb2R1bGUsIHRoZSBjaGlwIG1hbnVmYWN0dXJlciBvciBhbnlvbmUgZWxzZS4g VGhpcyB3aWxsIGJlIGRldGVybWluZWQgb25jZSB3ZSByZWxlYXNlIHRoZSBwcm9kdWN0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij4tLS0tLS0tLS0tPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij5wbGVhc2Ugbm90ZSB0aGF0IHRoZXNlIGFy ZSBteSBwZXJzb25hbCBvcGluaW9ucyAvIGZlZWxpbmdzOjxvOnA+PC9vOnA+PC9zcGFuPjwvdT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzE3M0ZDNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMTczRkM2Ij4mZ3Q7Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj5JbiBzaG9ydCwg dG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24gYWJvdXQgRENDLCBJIGRvbid0IGtub3cgaG93IHRvIGhh bmRsZSB0aGF0IGp1c3QgeWV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3 M0ZDNiI+Jmd0OyZndDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij4xKSBEQ0MgaXMgbm90IHlldCBtYW5kYXRvcnkgYW55d2hlcmUgYW5k IGhvcGVmdWxseSB0aGF0IHNpdHVhdGlvbiB3aWxsIG5vdCBjaGFuZ2UuJm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+QVY6IEluIHRoZSBFVSBhdCBsZWFzdCBmb3Ig RzVBIHdlIGFyZSB0YWxraW5nIGFib3V0IGEgc2FmZXR5IHN5c3RlbSB3aGljaCBuZWVkcyB0byBi ZSB0cnVzdHdvcnRoeSwgaWYgbXkgY2FycyBzYWZldHkgc3lzdGVtIGZhaWxzIGluIGFuIHVyYmFu IGludGVyc2VjdGlvbiwNCiBiZWNhdXNlIHNvbWVvbmUgaXMgYWxsb3dlZCB0byB0cmFuc21pdCBu b24tc2FmZXR5IGRhdGEgb24gdGhvc2UgY2hhbm5lbHMsIHRoZW4gdGhlIHdob2xlIHN5c3RlbSBp cyB1c2VsZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+KGlu IHRoaXMgc2Vuc2UgaWYgWW91IHRyYW5zbWl0IHNhZmV0eSBkYXRhLCB0aGVuIHlvdSBhcHBseSBE Q0MpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPiZndDsmZ3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjIpIElmIERD QyBkb2VzIGJlY29tZSBtYW5kYXRvcnksIGl0IGlzIGxpa2VseQ0KIHRvIGJlIG9ubHkgYmUgY29u ZGl0aW9uYWxseSBzbyAoYXQgbGVhc3QgaW4gRXVyb3BlKSwgY29uZGl0aW9uZWQgb24gdGhlIHVz ZSBvZiBFVFNJJ3MgR2VvTmV0d29ya2luZyBwcm90b2NvbCwgYW5kIHRoZXJlIGlzIGxpdHRsZSB0 byBubyBjaGFuY2Ugb2YgdGhhdCBwcm90b2NvbCBnZXR0aW5nIG91dCBvZiB0aGUgcmVzZWFyY2gg bGFicy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+SXRzIG5vdCBhbnkgbW9y ZSBpbiB0aGUgcmVzZWFyY2ggbGFiczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxNzNGQzYiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX3RyJTVD MTAxNjAwXzEwMTY5OSU1QzEwMTYwNyU1QzAxLjAxLjAxXzYwJTVDdHJfMTAxNjA3djAxMDEwMXAu cGRmIj5odHRwOi8vd3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV90ciU1QzEwMTYwMF8xMDE2OTkl NUMxMDE2MDclNUMwMS4wMS4wMV82MCU1Q3RyXzEwMTYwN3YwMTAxMDFwLnBkZjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxhIGhyZWY9Imh0dHA6Ly93d3cu ZXRzaS5vcmcvbmV3cy1ldmVudHMvbmV3cy83NTMtMjAxNC0wMi1qb2ludC1uZXdzLWNlbi1hbmQt ZXRzaS1kZWxpdmVyLWZpcnN0LXNldC1vZi1zdGFuZGFyZHMtZm9yLWNvb3BlcmF0aXZlLWludGVs bGlnZW50LXRyYW5zcG9ydC1zeXN0ZW1zLWMtaXRzIj5odHRwOi8vd3d3LmV0c2kub3JnL25ld3Mt ZXZlbnRzL25ld3MvNzUzLTIwMTQtMDItam9pbnQtbmV3cy1jZW4tYW5kLWV0c2ktZGVsaXZlci1m aXJzdC1zZXQtb2Ytc3RhbmRhcmRzLWZvci1jb29wZXJhdGl2ZS1pbnRlbGxpZ2VudC10cmFuc3Bv cnQtc3lzdGVtcy1jLWl0czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx NzNGQzYiPihJZiBteSBsaW5rcyBhcmUgYnJva2VuOiAmbmJzcDtFVFNJIFRSIDEwMSA2MDcpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPiZndDsmZ3Q7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPiBUaGUgY291cGxpbmcg dGhhdCBwZW9wbGUgc2VlbSB0byBiZWxpZXZlIGV4aXN0cw0KIGJldHdlZW4gMTFwIGFuZCBJUHY2 IGlzIGEgZmljdGlvbiBpbiB0aGVpciBtaW5kcy4mbmJzcDsgVGhlcmUgaXMgTk8gY291cGxpbmcu Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzE3M0ZDNiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPk5vIGNvdXBs aW5nLCBidXQgSVB2NiBpcyBhIChtYXliZSB0aGUgYmVzdCkgd2F5IHRvIGdsb2JhbGx5IGFkZHJl c3MgZnV0dXJlIGNhcnMgKGNoZWNrIElUU1N2NiBmb3IgZXhhbXBsZSksIG5ldmVydGhlbGVzcywg Zm9yIHNhZmV0eSBtZXNzYWdlcyAobm9ybWFsKQ0KIElQIGhhcyBqdXN0IHRvIGJpZyBvdmVyaGVh ZCwgYSBDQU0gb3IgREVOTSBWMlYgbWVzc2FnZSBpcyBtdWNoIG1vcmUgY29tcGFjdCBhbmQgSVAg Y2FuIG5vdCBmaWdodCB0aGF0LiAoYW5kIHdlIG5lZWQgc2hvcnQvcXVpY2sgdHJhbnNtaXNzaW9u IHRpbWVzISEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+w5xkdsO2emxldHRlbCAvIEJl c3QgcmVnYXJkcyw8YnI+DQombmJzcDsmbmJzcDsgQW5kcsOhcyBWw6FyYWRpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMTczRkM2Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7UHJvamVjdCBN YW5hZ2VyIOKAkyBDMlgvSVRTIFN5c3RlbXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Q3VzdG9tZXIgU3VwcG9ydCBXaXJlbGVzcyBNb2R1bGVzPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB dXRvbW90aXZlICZhbXA7IFdMQU4gR3JvdXANCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3 M0ZDNiI+bGVzc3dpcmUmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+SHVuZ2FyeTwvc3Bhbj48Yj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPg0KPC9zcGFu PjwvYj48Yj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx NzNGQzYiPnw8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzE3M0ZDNiI+DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij5PZmZpY2U6ICYjNDM7MzYgMjM1MjEgNjY3 PC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzE3M0ZDNiI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzE3M0ZDNiI+fDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij4NCjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxNzNGQzYiPkVtYWlsOg0K PGEgaHJlZj0ibWFpbHRvOlZhcmFkaUBsZXNzd2lyZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MTczRkM2Ij5WYXJhZGlAbGVzc3dpcmUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6NC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMTczRkM2Ij4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBcmNvdCwgS2lyYW4gSyBbbWFpbHRvOmtp cmFuYXJjb3RAdWt5LmVkdV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDA3 LCAyMDE0IDc6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFZhcmFkaSAsIEFuZHJhcyAobGVzc3dpcmUg QUcgVW5nYXJuKTxicj4NCjxiPkNjOjwvYj4gaXRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbZ2VvbmV0L2l0c10gODAyLjExcCBVU0IgZG9uZ2xlcz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5IaSBBbmRyYXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+VGhhbmtzIGZvciB0aGUgbGlua3MuIFdpbGwgdGhlcmUgYmUgc3VwcG9ydCBmcm9tIGxl c3N3aXJlIGZvciBMaW51eCBzeXN0ZW1zIGZvciB0aGVzZSBVU0IgbW9kdWxlcyBvciB3aWxsIHRo ZSB1c2VycyBoYXZlIHRvIGNvbWUgdXAgd2l0aCB0aGUgZHJpdmVycyB0aGVtc2VsdmVzPyBBbHNv LCB3aGF0IGRvIHlvdSB0aGluayB0aGUgcHJpY2Ugb2YgVVNCIG1vZHVsZSB3aWxsIGJlPw0KIE9y IGlzIGl0IGJldHRlciB0byBhc2sgb25lIG9mIHRoZSBkaXN0cmlidXRvcnMgdGhhdCBxdWVzdGlv bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkFzIGZv ciB5b3VyIERDQyBxdWVzdGlvbiwgSSBoYXZlIG9ubHkgbm93IHN0YXJ0ZWQgbG9va2luZyBpbiB0 byB0aGUgd2hvbGUgODAyLjExcCBzaGViYW5nIGFuZCBoYXZlbid0IGNvbXBsZXRlbHkgZHVnIGlu IHRvIHRoZSByZXF1aXJlbWVudHMgdG8gY29tcGx5IHdpdGggdGhlIHN0YW5kYXJkcyB5ZXQuIEkg aGF2ZSBiZWVuIGFza2luZyBxdWVzdGlvbnMgb2YgQWxleGFuZHJ1IFBldHJlc2N1DQogaW4gYW5v dGhlciBlbWFpbCBjaGFpbiBhbmQgZm9sbG93aW5nIGhpcyBzdWdnZXN0aW9ucyBvZiBmaXJzdCB0 cnlpbmcgdG8gZmluZCBhIGhhcmR3YXJlL2RyaXZlciBjb21iaW5hdGlvbiB0aGF0IHdpbGwgYWxs b3cgbWUgdG8gdHJhbnNtaXQgaW4gdGhlIDgwMi4xMXAgZnJlcXVlbmN5IGJhbmQgd2l0aCBJUC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkluIHNob3J0 LCB0byBhbnN3ZXIgeW91ciBxdWVzdGlvbiBhYm91dCBEQ0MsIEkgZG9uJ3Qga25vdyBob3cgdG8g aGFuZGxlIHRoYXQganVzdCB5ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj5LaXJhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk9uIEZyaSwgTm92IDcsIDIw MTQgYXQgNzo1MiBBTSwgVmFyYWRpICwgQW5kcmFzIChsZXNzd2lyZSBBRyBVbmdhcm4pICZsdDs8 YSBocmVmPSJtYWlsdG86VmFyYWRpQGxlc3N3aXJlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlZhcmFk aUBsZXNzd2lyZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLUdCIj5IaSBLaXJhbjxicj4NCjxicj4NCkkgYWxzbyBoYXZlIHNvbWUgc2VyaW91cyBjb25j ZXJucyBhYm91dCBvdXRkb29yIHVzYWdlIG9mIEVUU0kgRzUgaW4gdGhlIEVVLi4uPGJyPg0KSnVz dCBmb3IgYW4gZXhhbXBsZTogaG93IHdpbGwgWW91IHRvbGVyYXRlIERDQyAoRGVjZW50cmFsaXpl ZCBDb25nZXN0aW9uIENvbnRyb2wpIGluIFlvdXIgdXNlIGNhc2U/ICh3aGljaCB3aWxsIG5vdCBs ZXQgWW91IHRyYW5zbWl0IGp1c3QgYW55IHRpbWUgLSBhbmQgWW91IG5lZWQgRENDIHRvIHRyYW5z bWl0IGFuZCBjb21wbHkgdGhlIHN0YW5kYXJkcyk8YnI+DQo8YnI+DQpVU0IgMTFwIG1vZHVsZSAo YXZhaWxhYmxlIG5leHQgeWVhcikgLSA8YSBocmVmPSJodHRwOi8vd3d3Lmxlc3N3aXJlLmNvbS9l bi9wcm9kdWN0cy93aXJlbGVzcy1tb2R1bGVzL2NhcjJ4L3dpYmVhci1pdHMtY2FyMngvb3ZlcnZp ZXcvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3Lmxlc3N3aXJlLmNvbS9lbi9wcm9kdWN0 cy93aXJlbGVzcy1tb2R1bGVzL2NhcjJ4L3dpYmVhci1pdHMtY2FyMngvb3ZlcnZpZXcvPC9hPjxi cj4NCk1vcmUgaW5mbyBvbiBhdmFpbGliaWxpdHkgZnJvbSB0aGUgZGlzdHJpYnV0b3JzOiA8YSBo cmVmPSJodHRwOi8vd3d3Lmxlc3N3aXJlLmNvbS9lbi9kaXN0cmlidXRvcnMvY29tbWVyY2lhbHMt bmV3LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5sZXNzd2lyZS5jb20vZW4vZGlzdHJp YnV0b3JzL2NvbW1lcmNpYWxzLW5ldy88L2E+PGJyPg0KPGJyPg0Kw5xkdsO2emxldHRlbCAvIEJl c3QgcmVnYXJkcyw8YnI+DQombmJzcDsmbmJzcDsgQW5kcsOhcyBWw6FyYWRpPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1Byb2plY3QgTWFuYWdlciAtIEMyWC9JVFMgU3lzdGVt czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Q3VzdG9tZXIgU3VwcG9ydCBXaXJlbGVzcyBNb2R1 bGVzPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dG9tb3RpdmUgJmFtcDsg V0xBTiBHcm91cDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZXNzd2lyZSZuYnNwOyZu YnNwOyBIdW5nYXJ5IHwgT2ZmaWNlOiA8YSBocmVmPSJ0ZWw6JTJCMzYlMjAyMzUyMSUyMDY2NyI+ JiM0MzszNiAyMzUyMSA2Njc8L2E+IHwgRW1haWw6DQo8YSBocmVmPSJtYWlsdG86VmFyYWRpQGxl c3N3aXJlLmNvbSI+VmFyYWRpQGxlc3N3aXJlLmNvbTwvYT48YnI+DQo8YnI+DQo8YnI+DQo8c3Bh biBjbGFzcz0iaW0iPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJpbSI+RnJvbTogaXRzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOml0cy1ib3VuY2Vz QGlldGYub3JnIj5pdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBBbGV4YW5k cnUgUGV0cmVzY3U8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5TZW50OiBUaHVyc2RheSwg Tm92ZW1iZXIgMDYsIDIwMTQgNTo0NSBQTTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPlRv OiBBcmNvdCwgS2lyYW4gSzsgPGEgaHJlZj0ibWFpbHRvOmRpY2tyb3lAYWx1bS5taXQuZWR1Ij5k aWNrcm95QGFsdW0ubWl0LmVkdTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5DYzog PGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyI+aXRzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaW0iPlN1YmplY3Q6IFJlOiBbZ2VvbmV0L2l0c10gODAyLjExcCBVU0Ig ZG9uZ2xlcz88L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+V2VsbCAtIHRoZXJlIG1heSBiZSB3 YXlzIHRvIGNvbXBseSB0byB0aGUgbGVnaXNsYXRpb24gb2YgNS45R0h6IGFuZCBoaWdoIHBvd2Vy IGxldmVscyBmb3IgSVRTLCBpZiB0aGUgZmx5aW5nIGV4cGVyaW1lbnRhdGlvbiBoYXBwZW5zIGlu ZG9vcnMgKGhhbmdhcikuPGJyPg0KPGJyPg0KQnV0IGNvbWluZyBiYWNrIHRvIHRoZSBvcmlnaW5h bCBxdWVzdGlvbjogaXMgdGhlcmUgYW4gVVNCIGRvbmdsZSA4MDIuMTFwPzxicj4NCjxicj4NClRo ZSBtYW51ZmFjdHVyZXIgSSBhbSBmYW1pbGlhciB3aXRoIChVTkVYLCBub3QgdG8gbmFtZSBpdCkg b25seSBkb2VzIG1pbmktUENJIDgwMi4xMXAgY2FyZHMuPGJyPg0KPGJyPg0KQW4gODAyLjExcCBV U0IgZG9uZ2xlIGZvcm1hdCBtYXkgYmUgdXNlZnVsIHRvIHNvbWUgb2YgdGhlIG1vc3QgY29uc3Ry YWluZWQgbGludXggcGxhdGZvcm1zIHdoaWNoIGZlYXR1cmUgVVNCIHJhdGhlciB0aGFuIG1pbmkt UENJLjxicj4NCjxicj4NCklmIHRoaXMgaXMgZG9uZSwgYW5kIGdpdmVuIHRoZSBlYXNpbmVzcyBv ZiBydW5uaW5nIElQIG9uIDgwMi4xMXAsIEknZCBiZSB0aHJpbGxlZCB0byBzZWUgSVAgYmV0d2Vl biBmbHlpbmcgb2JqZWN0cy48YnI+DQo8YnI+DQpBbGV4PGJyPg0KPGJyPg0KPGJyPg0KTGUgMDYv MTEvMjAxNCAxNzowNCwgQXJjb3QsIEtpcmFuIEsgYSDDqWNyaXQgOjxicj4NCiZndDsgSGVsbG8g UlIsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGlkZWEgaW5kZWVkIGlzIHRvIGNvbXBseSB3aXRo IHRoZSBzdGFuZGFyZHMgYW5kIHJlZ3VsYXRpb24gYWxyZWFkeTxicj4NCiZndDsgcHJlc2VudC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyBLaXJhbi48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBPbiBXZWQsIE5vdiA1LCAyMDE0IGF0IDM6MDggUE0sIFJpY2hhcmQgUm95ICZsdDs8 YSBocmVmPSJtYWlsdG86ZGlja3JveUBhbHVtLm1pdC5lZHUiPmRpY2tyb3lAYWx1bS5taXQuZWR1 PC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGlja3JveUBhbHVtLm1p dC5lZHUiPmRpY2tyb3lAYWx1bS5taXQuZWR1PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXyBfXzxicj4NCiZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtJJ2Qgc3VnZ2VzdCB5b3UgbG9vayBmb3IgODAyLjExYSBjb21w bGlhbnQgZG9uZ2xlcyB0aGF0IGhhdmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDttYWQt d2lmaSBvciBzb21lIG90aGVyIG9wZW4gc291cmNlIGRyaXZlciB5b3UgY2FuIG1vZGlmeS4gSSdk IGFsc288YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZWNvbW1lbmQgeW91IE5PVCB1c2Ug dGhlIDUuODUwLTUuOTI1R0h6IGJhbmQgc2luY2UgdGhhdCBiYW5kIGlzPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7cmVzZXJ2ZWQgZm9yIElUUywmbmJzcDsgdW5sZXNzLCBvZiBjb3Vyc2Us IHlvdSBwbGFuIG9uIGNvbXBseWluZyB3aXRoIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO251bWJlciBvZiBzdGFuZGFyZHMgYW5kIHJlZ3VsYXRpb25zIGFscmVhZHkgaW4gcGxhY2Ug Zm9yIHVzZSBvZiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtiYW5kLl9fX188YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hlZXJzLF9fX188YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7X18gX188YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7UlIgX19fXzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBf Xzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAt LTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsqRnJvbToqQXJjb3QsIEtp cmFuIEsgW21haWx0bzo8YSBocmVmPSJtYWlsdG86a2lyYW5hcmNvdEB1a3kuZWR1Ij5raXJhbmFy Y290QHVreS5lZHU8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86a2lyYW5hcmNvdEB1a3kuZWR1Ij5raXJhbmFyY290QHVreS5lZHU8L2E+ Jmd0O108YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsqU2VudDoqIFR1ZXNkYXksIE5vdmVt YmVyIDA0LCAyMDE0IDEwOjQyIEFNPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7KlRvOiog PGEgaHJlZj0ibWFpbHRvOml0c0BpZXRmLm9yZyI+aXRzQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzppdHNAaWV0Zi5vcmciPml0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7KlN1YmplY3Q6KiBbZ2VvbmV0L2l0c10gODAyLjExcCBV U0IgZG9uZ2xlcz9fX19fPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO19f IF9fPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0hlbGxvIEFsbCxfX19f PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO19fIF9fPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0kgYW0gYSBncmFkdWF0ZSBzdHVkZW50IGF0IHRo ZSBfX19fVW5pdmVyc2l0eV9fIG9mIF9fS2VudHVja3lfX19fPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7YW5kIEkgYW0gbG9va2luZyBhdCB1c2luZyA4MDIuMTFwIGZvciBjb21tdW5pY2F0 aW9uIGJldHdlZW4gb3V0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7cXVhZC1jb3B0ZXJz LiBUbyB0aGF0IGVuZCBpcyBhbnlvbmUgYXdhcmUgb2YgYW55IDgwMi4xMXAgVVNCIGRvbmdsZXM8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvbiB0aGUgbWFya2V0PyBBcmUgdGhlcmUgYW55 IG9wZW4gc291cmNlIGRyaXZlcnMgKExpbnV4PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 c3BlY2lmaWNhbGx5KSB0aGF0IGFyZSBpbiBzZW1pLXVzYWJsZSBzdGF0ZSBvciBpbiBkZXZlbG9w bWVudD8mbmJzcDsgSWY8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzbyB3aGVyZSBjYW4g b25lIGZpbmQgc3VjaCBhIGRyaXZlciBmb3IgODAyLjExcCBjYXJkcy9VU0I8YnI+DQomZ3Q7IGRv bmdsZXM/X19fXzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyBfXzxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGFua3MsX19fXzxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtLaXJhbiBBcmNvdC5fX19fPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGl0cyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzppdHNAaWV0Zi5vcmciPml0c0BpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXRzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pdHM8L2E+PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaXRzIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzppdHNAaWV0Zi5vcmciPml0c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2l0cyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ED899A19E313D540BE9D122C2B81599A02C9E6RASRV50prettlelek_-- From nobody Mon Nov 24 02:47:19 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4011A1EF9 for ; Mon, 24 Nov 2014 02:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfl6vYgjtTDE for ; Mon, 24 Nov 2014 02:47:13 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FAD1A1EF8 for ; Mon, 24 Nov 2014 02:47:12 -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 sAOAl9xT022218 for ; Mon, 24 Nov 2014 11:47:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC474206C25 for ; Mon, 24 Nov 2014 11:47:45 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A2BFD206C26 for ; Mon, 24 Nov 2014 11:47:45 +0100 (CET) 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 sAOAkqZa010806 for ; Mon, 24 Nov 2014 11:47:09 +0100 Message-ID: <54730C9C.5070300@gmail.com> Date: Mon, 24 Nov 2014 11:46:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: its@ietf.org References: <545BA571.5010502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/OoWBYpMwxreFu2-_KLPGI8Tr9og Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 10:47:17 -0000 Hello, Here are my thoughts. Le 18/11/2014 20:02, Varadi , Andras (lesswire AG Ungarn) a écrit : > Dear Arcot, Richard > > Sorry for the long delay, I will try to answer short, > >>> Will there be support from lesswire for Linux systems for these USB >>> modules or will the users have to come up with the drivers themselves? There is one 802.11p driver used extensively on many platforms. It is based on a modified version of the Atheros' ath5k driver. I guess it may be used on 802.11p USB dongles as well. The base ath5k driver is present in the linux kernel and is covered by a mixture of GPL/BSD-style licenses as well as a copyright notice. (see the licensing scheme in the top-level comments in this C file: http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath5k/base.c ) By this licensing scheme, it is not sure the source code of this athk-based 802.11p driver must or may be redistributed freely. It can "alternatively". Actually, I do think there is a strong need for an open-source GPL-style 802.11p driver to be maintained on many platforms. It is relatively easy to do one, starting from that ath5k. > AV: We provide products, not pure HW and thus I dont see a way for > selling anything without a driver. I do not know who will supply the > driver though, the distri, the module, the chip manufacturer or anyone > else. This will be determined once we release the product. > > ---------- > > _please note that these are my personal opinions / feelings:_ > >>> In short, to answer your question about DCC, I don't know how to > handle that just yet. > >>> 1) DCC is not yet mandatory anywhere and hopefully that situation will > not change. > > AV: In the EU at least for G5A we are talking about a safety system > which needs to be trustworthy, if my cars safety system fails in an > urban intersection, because someone is allowed to transmit non-safety > data on those channels, then the whole system is useless. > > (in this sense if You transmit safety data, then you apply DCC) DCC stands for Decentralized Congestion Control, as specified by document ETSI TS 102 687. It is a high-level medium access facilitator: power control (raise or lower emission power levels depending on noise), bandwidth control (raise or lower). There are other MAC access mechanisms already in place. Driving safety is indeed of paramount importance. However, it may be hard to rely solely on 802.11p for safety, even if it is enhanced with DCC. Because 5.9GHz is unlicensed spectrum - anyone can emit in this space without owning a license from authority - jammers are easy to do. Driving safety needs to rely on additional mechanisms such as 3D reconstruction based on video recognition, radar waves bouncing off obstacles (laser, lidar), and as a last resort - human sight, since ultimately it is a human that is in charge of all this. [...] >>> The coupling that people seem to believe exists between 11p and IPv6 is >>> a fiction in their minds. There is NO coupling. 11p and IP are natural fits though. Both IPv6 _and_ IPv4 work ok very easily on 802.11p. Additional layers between 11p and the IP networking layer may come at a cost. Enhanced IP layers (extension headers, IP control protocols) are another matter, of course. > No coupling, but IPv6 is a (maybe the best) way to globally address > future cars I agree. There is a real case manufacturers are confronted with when planning production and assigning IP addresses to them. IPv4 addresses no longer available, NAT clumsy remote software updates, strong IPv6 migration in the Internet core - are all factors impacting the addressing architecture in the long term for the future vehicles. > (check ITSSv6 for example), nevertheless, for safety > messages (normal) IP has just to big overhead, a CAM or DENM V2V message > is much more compact and IP can not fight that. (and we need short/quick > transmission times!!) Sorry, I disagree. The shortest IP message is 40byte long, it is not overhead. What is the shortest CAM or DENM message? The latency is precisely the same for both IP and CAM or DENM messages. (I agree with you though if the functionality of a CAM message like "here I am" is implemented in the form of an http/tcp/ip request-response "where are you/here I am" between a client and a server, with multiple 3-way handshakes). Alex > > Üdvözlettel / Best regards, > András Váradi > > Project Manager – C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary***|***Office: +36 23521 667***|***Email: > Varadi@lesswire.com > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Friday, November 07, 2014 7:04 PM > *To:* Varadi , Andras (lesswire AG Ungarn) > *Cc:* its@ietf.org > *Subject:* Re: [geonet/its] 802.11p USB dongles? > > Hi Andras, > > Thanks for the links. Will there be support from lesswire for Linux > systems for these USB modules or will the users have to come up with the > drivers themselves? Also, what do you think the price of USB module will > be? Or is it better to ask one of the distributors that question? > > As for your DCC question, I have only now started looking in to the > whole 802.11p shebang and haven't completely dug in to the requirements > to comply with the standards yet. I have been asking questions of > Alexandru Petrescu in another email chain and following his suggestions > of first trying to find a hardware/driver combination that will allow me > to transmit in the 802.11p frequency band with IP. > > In short, to answer your question about DCC, I don't know how to handle > that just yet. > > Thanks, > > Kiran. > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) > > wrote: > > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI G5 in the > EU... > Just for an example: how will You tolerate DCC (Decentralized Congestion > Control) in Your use case? (which will not let You transmit just any > time - and You need DCC to transmit and comply the standards) > > USB 11p module (available next year) - > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car2x/overview/ > More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > Üdvözlettel / Best regards, > András Váradi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 > | Email: Varadi@lesswire.com > > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org ] On > Behalf Of Alexandru Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of 5.9GHz and high > power levels for ITS, if the flying experimentation happens indoors > (hangar). > > But coming back to the original question: is there an USB dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) only does > mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most > constrained linux platforms which feature USB rather than mini-PCI. > > If this is done, and given the easiness of running IP on 802.11p, I'd be > thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a écrit : >> Hello RR, >> >> The idea indeed is to comply with the standards and regulation already >> present. >> >> Thanks, >> Kiran. >> >> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy >> >> wrote: >> >> __ __ __ >> >> I'd suggest you look for 802.11a compliant dongles that have >> mad-wifi or some other open source driver you can modify. I'd also >> recommend you NOT use the 5.850-5.925GHz band since that band is >> reserved for ITS, unless, of course, you plan on complying with the >> number of standards and regulations already in place for use of the >> band.____ >> >> __ __ >> >> Cheers,____ >> >> __ __ >> >> RR ____ >> >> __ __ >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu >> >] >> *Sent:* Tuesday, November 04, 2014 10:42 AM >> *To:*its@ietf.org > >> *Subject:* [geonet/its] 802.11p USB dongles?____ >> >> __ __ >> >> Hello All,____ >> >> __ __ >> >> I am a graduate student at the ____University__ of __Kentucky____ >> and I am looking at using 802.11p for communication between out >> quad-copters. To that end is anyone aware of any 802.11p USB dongles >> on the market? Are there any open source drivers (Linux >> specifically) that are in semi-usable state or in development? If >> so where can one find such a driver for 802.11p cards/USB >> dongles?____ >> >> __ __ >> >> Thanks,____ >> >> Kiran Arcot.____ >> >> >> >> >> _______________________________________________ >> 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 nobody Mon Nov 24 03:13:21 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD911A1EFD for ; Mon, 24 Nov 2014 03:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq2q9JNX-Qj6 for ; Mon, 24 Nov 2014 03:13:16 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DCE1A1F01 for ; Mon, 24 Nov 2014 03:13:13 -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 sAOBD9hq003782; Mon, 24 Nov 2014 12:13:09 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DDCE4206949; Mon, 24 Nov 2014 12:13:45 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D04462031EC; Mon, 24 Nov 2014 12:13:45 +0100 (CET) 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 sAOBCwvI001886; Mon, 24 Nov 2014 12:13:09 +0100 Message-ID: <547312BA.70201@gmail.com> Date: Mon, 24 Nov 2014 12:12:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: dickroy@alum.mit.edu References: <54643126.7080806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/EiP7BkSXKwQtvl6PQzGterc2hz0 Cc: its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 11:13:19 -0000 Richard, Le 15/11/2014 01:33, Richard Roy a écrit : > My initial comment on the draft is that the concept of a destination > options field is inappropriate and opens security holes and creates a > possible attack vector needlessly. But (1) a DO header must not be examined by intermediary routers, by definition, and (2) if the end node feels at risk, the Destinations Options (DO) header may be put after an Encapsulation Security Payload (ESP) header, and as such be hidden from unwanted scrutiny. > The destination of a packet is by definition a place where the ADU is > parsed/consumed. Any information intended only for the destination > should be carried ONLY in the ADU, not in any lower layer PDU. > Hence, the concept of "destination options" at a lower layer (i.e. > the network layer) amounts to a layer violation. YEs, layer violation may be what can happen. But in more detail, there are already many details in the networking layer that may differentiate it from layer violation - most extension headers carry info which may qualify as app by some, but are qualified as networking by others. Another indication that Geo-information may be fit in the networking layer is in the popular net analyzer Wireshark showing Source GeoIP and Destination GeoIP in all packets displayed, even if unknown. > The ONLY reason to carry GEO information in a layer 3 header is that > there are layer 3 processes/functions that require or will make use > of that information. If the information is only useful at the > destination, then the information belongs in a layer 4 header or > higher up the stack. I agree. But the location information itselfy can qualify as more app-layer or more 'net'-layer. I live on the 4th floor - that is the app-layer of saying location; I live at 2/49/WGS48 is more of a 'net'-layer. Second, the app layers are less reliable than the 'net'-layer. An UDP userspace application sending the GPS coordinates can crash at any time and as such track is lost of some object. On another hand, same data sent by the IP stack in the kernel as much less chances to crash - the kernel is much more reliable and less latency than the userspace space apps. It can be made even real time (rely on tangible hw features), whereas apps are hard to make real time. Third, other agreed non-IP networking layers already exchange geo-location information - are these net layers or app layers? > Since the document claims that "This document seeks to specify a > method for including the geolocation data in the IPv6 Destination > Options header", it clearly seems to be focused on peer-to-peer > exchange of GEO information. This is more safely accomplished at > layers above the network layer. Note that the ONLY example given of > an application involving layer 3 functionality was > > "Convergence of dynamic routing protocols in a wide variety of mobile > networks can benefit greatly from knowledge of the geographical > locations of prospective neighbors. This information is best > conveyed in the headers of IPv6 packets used for routing protocol > control message exchanges." I agree with this draft's point. The location information is a good hint for routing convergence. When most core links have similar speeds, better connect to the closer router. Router location is also good for a tie breaker when two destination have equal costs. > All the others involved sending source location to destination(s) and > that's NOT a layer 3 problem. > > Finally, the issue of coordinate systems was not addressed properly. > It's implied by the description in the text that WGS84 is used, > however, this system is subject to update and change. IF the IETF is > going to include GEO info in it's headers, there must be a field with > sufficient size to encode the coordinate system that is being used > and which version thereof. I agree. > Furthermore, the issue of uncertainly (estimate error covariance > really) was not addressed. All GEO locations are "estimates" and are > realizations of a vector random process that has an associated MD > PDF. The ability to also communicate other than jus the zeroth order > moment (i.e., the mean) is often important! I agree. Alex > > RR > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, November 12, >> 2014 8:19 PM To: its@ietf.org Subject: [geonet/its] Presentation of >> draft about geolocation in IPv6 headers - 6MAN Working Group >> >> Hello, >> >> Friday morning there will be a presentation about using >> geolocation information in IPv6 headers, in the 6man Working >> Group. >> https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html >> >> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >> >> What do you think about this draft? >> >> Alex >> > > > > From nobody Mon Nov 24 03:31:02 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6141A3BA7 for ; Mon, 24 Nov 2014 03:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIUT4vXcc1Uw for ; Mon, 24 Nov 2014 03:30:56 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139B71A3BA5 for ; Mon, 24 Nov 2014 03:30:55 -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 sAOBUntb009845; Mon, 24 Nov 2014 12:30:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 657A1206C75; Mon, 24 Nov 2014 12:31:25 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 53AED2036BC; Mon, 24 Nov 2014 12:31:25 +0100 (CET) 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 sAOBUUm3029711; Mon, 24 Nov 2014 12:30:49 +0100 Message-ID: <547316D6.2020408@gmail.com> Date: Mon, 24 Nov 2014 12:30:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Carl Reed , Rex Buddenberg , "Templin, Fred L" References: <54643126.7080806@gmail.com> <1415909416.13262.7.camel@localhost.localdomain> <54651605.2070708@gmail.com> <0345CC670596442CBB36396EE6728D96@OfficeHP> In-Reply-To: <0345CC670596442CBB36396EE6728D96@OfficeHP> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/_4zUVzmZ-eKXpOyJdRuQu6YVE0I Cc: its@ietf.org Subject: Re: [geonet/its] Results - presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 11:30:59 -0000 Carl, colleagues, Thank you for the remarks on this draft. Much of the argumentation was on the privacy aspects and appropriatedness at the networking layer, with pros and cons. The conclusion is that there should be more discussion on this. The audiolog of the presentation in 6MAN WG on Nov. 14th, and the discussion are online at: http://www.ietf.org/audio/ietf91/ ietf91-coral3-20141114-0900-am1.mp3 in the zone from 1hour 24min 35sec until 1h 47m 34s. Slides at: http://www.ietf.org/proceedings/91/slides/slides-91-6man-8.pdf Video of entire session at: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_6MAN&chapter=chapter_0 Alex Le 13/11/2014 22:39, Carl Reed a écrit : > Alex - > > I would look at the DHCP Location extension to see how the datum is > specified. Also, if more than one datum (WGS 84) is required then I > would consider using the appropriate EPSG codes, which the DHCP Location > RFC also uses. To whit: > > Datum Registry > > > IANA has created and now maintains the Datum registry following the > guidelines below. > > The registry consists of three values: Datum, Description, and > Reference. These are described below. > > Datum: An integer, refers to the value used in the DHCPv4 GeoConf and > the DHCPv4 and DHCPv6 GeoLoc options described in this document. > Value 0 is Reserved. Values 1 - 3 are assigned. Values 4 - 7 are > Unassigned [RFC5226]. > > Description: The description of the altitude described by this code. > > Reference: The reference to the document that describes the Datum > code. This reference MUST include specification of both the > horizontal and vertical datum, and MUST define the way that the > 34-bit values and the respective 6-bit uncertainties are > interpreted. > > Initial values are given below; new assignments are to be made > following the "Standards Action" policies [RFC5226]. > > +------+----------------------------------------+--------------+ > | # | Description | Reference | > +------+----------------------------------------+--------------+ > | 0 | Reserved | RFC 6225 | > +------+----------------------------------------+--------------+ > | 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 | > | | CRS Code 4327 | | > +------+----------------------------------------+--------------+ > | 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 | > | | CRS Code 4269 with North American | | > | | Vertical Datum of 1988 (NAVD88) | | > +------+----------------------------------------+--------------+ > | 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 | > | | CRS Code 4269 with Mean Lower Low Water| | > | | (MLLW) as associated vertical datum | | > +------+----------------------------------------+--------------+ > | 4-7 | Unassigned | | > +------+----------------------------------------+--------------+ > >> From https://tools.ietf.org/html/rfc6225#page-18 > > Cheers > > Carl > > -----Original Message----- From: Alexandru Petrescu > Sent: Thursday, November 13, 2014 1:35 PM > To: Rex Buddenberg > Cc: its@ietf.org > Subject: Re: [geonet/its] Presentation of draft about geolocation in > IPv6 headers - 6MAN Working Group > > Le 13/11/2014 21:10, Rex Buddenberg a écrit : >> Alex, >> >> The ID is a good first step -- it illustrates at least one way to encode >> Lat/Lon/Alt at layer 3. IPv6 certainly has the flexibility to do >> such. >> My misgiving, which I haven't thought out in detail, is that use of >> header extensions in IPv6 opens a bunch of security issues. The >> security part of the ID is pretty blithe. > > I agree. A colleague IETFer also told me the privacy risk may be there. > > I wonder whether the Destinations Options header of IPv6 could be > covered by the encryption part of an ESP (Encapsulating Security Payload > of IPsec), or if otherwise DO must always travel in clear. > >> The geo datum is not specified. At the ID stage that's hardly >> fatal but needs to get in eventually. > > I agree. This is a good remark. > >> The geo work should be followed by the header compression work in >> 6lowpan -- lots of bits means lots of spectrum use and lots of power >> (e.g. battery power) so you want to conserve. >> >> But do you want this content data at layer 3? Operational >> requirement... > > This is a good question. Many remarks in geonet/its were about the fact > that sending geo-position data should happen at app layer, not > elsewhere. An official report tells a country's vehicular comm > standards should not consider geo-position as strongly as another > country's similar standard - naming the wrong situation at network layer > as a reason. > > On another hand, many standards don't really feature application layers > distinct from network layers. If all applications run in the network > layer, is it still non-recommended to put geo-position in there? > >> RFC6953 (PAWS) has just been read out by IETF. PAWS uses layer 7 geo >> encoding (and specified WGS84). Also worth reading through altho the >> geo here is used for a different purpose. > > Ok, will look at this spectrum related document. > > The application seems to be different for PAWS (spectrum). > > HEre, if I understand correctly, IPv6 GEO may be useful for emergency > kinds of apps. In that sense, one would like _any_ packet out of a node > to tell its position, not necessarily the packets issues by one > particular application. > > I.e. one may wonder what happens if some application in the computer > crashes - will the control center loose computer's position? because > the kernel may still echo requests from the control center, piggybacked > with DO GEO IPv6. > > Alex > >> >> >> >> b >> >> >> On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote: >>> Hello, >>> >>> Friday morning there will be a presentation about using geolocation >>> information in IPv6 headers, in the 6man Working Group. >>> https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html >>> >>> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >>> >>> What do you think about this draft? >>> >>> Alex >>> >>> _______________________________________________ >>> 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 nobody Mon Nov 24 04:50:33 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D321E1A6F11 for ; Mon, 24 Nov 2014 04:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dZ2ncmrSolJ for ; Mon, 24 Nov 2014 04:50:29 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD5D1A6F07 for ; Mon, 24 Nov 2014 04:50:29 -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 sAOCoQPQ004042 for ; Mon, 24 Nov 2014 13:50:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DC83C20B0AC for ; Mon, 24 Nov 2014 13:51:02 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C9C95206C88 for ; Mon, 24 Nov 2014 13:51:02 +0100 (CET) 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 sAOCoBUB015312 for ; Mon, 24 Nov 2014 13:50:26 +0100 Message-ID: <54732983.504@gmail.com> Date: Mon, 24 Nov 2014 13:50:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/AVnbN2cFLDblvoBzCLGoUhn8CP4 Subject: [geonet/its] 802.11p driver availability X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 12:50:31 -0000 Hello, In recent months I continue receiving questions asking for an 802.11p driver for linux. It seems the original driver from GCDC is no longer available on the net. Could you please put it back online? Alex From nobody Mon Nov 24 06:45:26 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00A61A6FA9 for ; Mon, 24 Nov 2014 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb64lhXfDu0Z for ; Mon, 24 Nov 2014 06:45:21 -0800 (PST) Received: from radmz1.prettl-elektronik.de (radmz1.prettl-elektronik.de [212.185.50.242]) by ietfa.amsl.com (Postfix) with ESMTP id 499031A6FAC for ; Mon, 24 Nov 2014 06:45:21 -0800 (PST) Received: from rasrv02.prettl-elektronik.de ([10.76.0.20]:6173) by utm.prettl-electronics.com with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XsutB-0004XG-1R; Mon, 24 Nov 2014 15:45:17 +0100 Received: from RASRV50.prettl-elektronik.de ([10.76.0.50]) by RASRV02.prettl-elektronik.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2014 15:45:17 +0100 Received: from RASRV50.prettl-elektronik.de ([::1]) by RASRV50.prettl-elektronik.de ([::1]) with mapi id 14.02.0298.004; Mon, 24 Nov 2014 15:45:16 +0100 From: "Varadi , Andras (lesswire AG Ungarn)" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [geonet/its] 802.11p USB dongles? Thread-Index: AQHP+RF1za9YJSv2j0WIIdEjwpncfpxTxPdo///6BICAAWCe4IAAR/0AgBFjynCACNmjAIAAUvCw Date: Mon, 24 Nov 2014 14:45:16 +0000 Message-ID: References: <545BA571.5010502@gmail.com> <54730C9C.5070300@gmail.com> In-Reply-To: <54730C9C.5070300@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.100.61] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2014 14:45:17.0069 (UTC) FILETIME=[434483D0:01D007F5] Archived-At: http://mailarchive.ietf.org/arch/msg/its/jtTZClZcrVmy3HMtFrOf8Veur4s Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 14:45:24 -0000 Hi Alex >> Driving safety is indeed of paramount importance. However, it may be ha= rd to rely solely on 802.11p for safety, even if it is enhanced with DCC. = Because 5.9GHz is unlicensed spectrum - anyone can emit in this space witho= ut owning a license from authority - jammers are easy to do Why do You state that its unlicensed? " in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz)" - http://en.wikiped= ia.org/wiki/IEEE_802.11p =DCdv=F6zlettel / Best regards, =A0=A0 Andr=E1s V=E1radi =A0=A0=A0 =A0Project Manager - C2X/ITS Systems Customer Support Wireless Modules =A0=A0=A0=A0 Automotive & WLAN Group=20 =A0=A0=A0=A0 lesswire=A0=A0 Hungary | Office: +36 23521 667 | Email: Varadi= @lesswire.com=20 -----Original Message----- From: its [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Monday, November 24, 2014 11:47 AM To: its@ietf.org Subject: Re: [geonet/its] 802.11p USB dongles? Hello, Here are my thoughts. Le 18/11/2014 20:02, Varadi , Andras (lesswire AG Ungarn) a =E9crit : > Dear Arcot, Richard > > Sorry for the long delay, I will try to answer short, > >>> Will there be support from lesswire for Linux systems for these USB=20 >>> modules or will the users have to come up with the drivers themselves? There is one 802.11p driver used extensively on many platforms. It is base= d on a modified version of the Atheros' ath5k driver. I guess it may be u= sed on 802.11p USB dongles as well. The base ath5k driver is present in the linux kernel and is covered by a mi= xture of GPL/BSD-style licenses as well as a copyright notice. (see the licensing scheme in the top-level comments in this C file: http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath5k/base.c = ) By this licensing scheme, it is not sure the source code of this athk-based= 802.11p driver must or may be redistributed freely. It can "alternatively= ". Actually, I do think there is a strong need for an open-source GPL-style 80= 2.11p driver to be maintained on many platforms. It is relatively easy to = do one, starting from that ath5k. > AV: We provide products, not pure HW and thus I dont see a way for=20 > selling anything without a driver. I do not know who will supply the=20 > driver though, the distri, the module, the chip manufacturer or anyone=20 > else. This will be determined once we release the product. > > ---------- > > _please note that these are my personal opinions / feelings:_ > >>> In short, to answer your question about DCC, I don't know how to > handle that just yet. > >>> 1) DCC is not yet mandatory anywhere and hopefully that situation=20 >>> will > not change. > > AV: In the EU at least for G5A we are talking about a safety system=20 > which needs to be trustworthy, if my cars safety system fails in an=20 > urban intersection, because someone is allowed to transmit non-safety=20 > data on those channels, then the whole system is useless. > > (in this sense if You transmit safety data, then you apply DCC) DCC stands for Decentralized Congestion Control, as specified by document E= TSI TS 102 687. It is a high-level medium access facilitator:=20 power control (raise or lower emission power levels depending on noise), ba= ndwidth control (raise or lower). There are other MAC access mechanisms al= ready in place. Driving safety is indeed of paramount importance. However, it may be hard = to rely solely on 802.11p for safety, even if it is enhanced with DCC. Bec= ause 5.9GHz is unlicensed spectrum - anyone can emit in this space without = owning a license from authority - jammers are easy to do. Driving safety needs to rely on additional mechanisms such as 3D reconstruc= tion based on video recognition, radar waves bouncing off obstacles (laser,= lidar), and as a last resort - human sight, since ultimately it is a human= that is in charge of all this. [...] >>> The coupling that people seem to believe exists between 11p and IPv6=20 >>> is a fiction in their minds. There is NO coupling. 11p and IP are natural fits though. Both IPv6 _and_ IPv4 work ok very easi= ly on 802.11p. Additional layers between 11p and the IP networking layer may come at a cos= t. Enhanced IP layers (extension headers, IP control protocols) are another ma= tter, of course. > No coupling, but IPv6 is a (maybe the best) way to globally address=20 > future cars I agree. There is a real case manufacturers are confronted with when plann= ing production and assigning IP addresses to them. IPv4 addresses no longe= r available, NAT clumsy remote software updates, strong IPv6 migration in t= he Internet core - are all factors impacting the addressing architecture in= the long term for the future vehicles. > (check ITSSv6 for example), nevertheless, for safety messages (normal)=20 > IP has just to big overhead, a CAM or DENM V2V message is much more=20 > compact and IP can not fight that. (and we need short/quick=20 > transmission times!!) Sorry, I disagree. The shortest IP message is 40byte long, it is not overhead. What is the shortest CAM or DENM message? The latency is precisely the same for both IP and CAM or DENM messages. (I agree with you though if the functionality of a CAM message like "here I= am" is implemented in the form of an http/tcp/ip request-response "where a= re you/here I am" between a client and a server, with multiple 3-way handsh= akes). Alex > > =DCdv=F6zlettel / Best regards, > Andr=E1s V=E1radi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary***|***Office: +36 23521 667***|***Email: > Varadi@lesswire.com > > *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu] > *Sent:* Friday, November 07, 2014 7:04 PM > *To:* Varadi , Andras (lesswire AG Ungarn) > *Cc:* its@ietf.org > *Subject:* Re: [geonet/its] 802.11p USB dongles? > > Hi Andras, > > Thanks for the links. Will there be support from lesswire for Linux=20 > systems for these USB modules or will the users have to come up with=20 > the drivers themselves? Also, what do you think the price of USB=20 > module will be? Or is it better to ask one of the distributors that quest= ion? > > As for your DCC question, I have only now started looking in to the=20 > whole 802.11p shebang and haven't completely dug in to the=20 > requirements to comply with the standards yet. I have been asking=20 > questions of Alexandru Petrescu in another email chain and following=20 > his suggestions of first trying to find a hardware/driver combination=20 > that will allow me to transmit in the 802.11p frequency band with IP. > > In short, to answer your question about DCC, I don't know how to=20 > handle that just yet. > > Thanks, > > Kiran. > > On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn)=20 > > wrote: > > Hi Kiran > > I also have some serious concerns about outdoor usage of ETSI G5 in=20 > the EU... > Just for an example: how will You tolerate DCC (Decentralized=20 > Congestion > Control) in Your use case? (which will not let You transmit just any=20 > time - and You need DCC to transmit and comply the standards) > > USB 11p module (available next year) -=20 > http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its- > car2x/overview/ More info on availibility from the distributors: > http://www.lesswire.com/en/distributors/commercials-new/ > > =DCdv=F6zlettel / Best regards, > Andr=E1s V=E1radi > > Project Manager - C2X/ITS Systems > Customer Support Wireless Modules > > Automotive & WLAN Group > lesswire Hungary | Office: +36 23521 667 > | Email: Varadi@lesswire.com=20 > > > > -----Original Message----- > From: its [mailto:its-bounces@ietf.org ]=20 > On Behalf Of Alexandru Petrescu > Sent: Thursday, November 06, 2014 5:45 PM > To: Arcot, Kiran K; dickroy@alum.mit.edu > Cc: its@ietf.org > Subject: Re: [geonet/its] 802.11p USB dongles? > > Well - there may be ways to comply to the legislation of 5.9GHz and=20 > high power levels for ITS, if the flying experimentation happens=20 > indoors (hangar). > > But coming back to the original question: is there an USB dongle 802.11p? > > The manufacturer I am familiar with (UNEX, not to name it) only does=20 > mini-PCI 802.11p cards. > > An 802.11p USB dongle format may be useful to some of the most=20 > constrained linux platforms which feature USB rather than mini-PCI. > > If this is done, and given the easiness of running IP on 802.11p, I'd=20 > be thrilled to see IP between flying objects. > > Alex > > > Le 06/11/2014 17:04, Arcot, Kiran K a =E9crit : >> Hello RR, >> >> The idea indeed is to comply with the standards and regulation=20 >> already present. >> >> Thanks, >> Kiran. >> >> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy > >> wrote: >> >> __ __ __ >> >> I'd suggest you look for 802.11a compliant dongles that have >> mad-wifi or some other open source driver you can modify. I'd also >> recommend you NOT use the 5.850-5.925GHz band since that band is >> reserved for ITS, unless, of course, you plan on complying with the >> number of standards and regulations already in place for use of the >> band.____ >> >> __ __ >> >> Cheers,____ >> >> __ __ >> >> RR ____ >> >> __ __ >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu >> >] >> *Sent:* Tuesday, November 04, 2014 10:42 AM >> *To:*its@ietf.org > >> *Subject:* [geonet/its] 802.11p USB dongles?____ >> >> __ __ >> >> Hello All,____ >> >> __ __ >> >> I am a graduate student at the ____University__ of __Kentucky____ >> and I am looking at using 802.11p for communication between out >> quad-copters. To that end is anyone aware of any 802.11p USB dongles >> on the market? Are there any open source drivers (Linux >> specifically) that are in semi-usable state or in development? If >> so where can one find such a driver for 802.11p cards/USB=20 >> dongles?____ >> >> __ __ >> >> Thanks,____ >> >> Kiran Arcot.____ >> >> >> >> >> _______________________________________________ >> 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 From nobody Mon Nov 24 08:05:41 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43EE1A6FD5 for ; Mon, 24 Nov 2014 08:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JOqJoeKBKSo for ; Mon, 24 Nov 2014 08:05:34 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879C11A6FF8 for ; Mon, 24 Nov 2014 08:05:27 -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 sAOG5O6A015766; Mon, 24 Nov 2014 17:05:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9113120B3A9; Mon, 24 Nov 2014 17:06:00 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83E0E200B56; Mon, 24 Nov 2014 17:06:00 +0100 (CET) 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 sAOG4x80022832; Mon, 24 Nov 2014 17:05:23 +0100 Message-ID: <5473572B.9090109@gmail.com> Date: Mon, 24 Nov 2014 17:04:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Varadi , Andras (lesswire AG Ungarn)" References: <545BA571.5010502@gmail.com> <54730C9C.5070300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/wHOIc653sDPgA2qjRADfQXyyZmU Cc: "its@ietf.org" Subject: Re: [geonet/its] 802.11p USB dongles? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:05:39 -0000 Hi András, There may be a question of terminology here. Le 24/11/2014 15:45, Varadi , Andras (lesswire AG Ungarn) a écrit : > Hi Alex > >>> Driving safety is indeed of paramount importance. However, it >>> may be hard to rely solely on 802.11p for safety, even if it is >>> enhanced with DCC. Because 5.9GHz is unlicensed spectrum - >>> anyone can emit in this space without owning a license from >>> authority - jammers are easy to do > > Why do You state that its unlicensed? Because I do not need a license from any authority to emit radio in that frequency range. WiFi is unlicensed, whereas GPS or cellular are licensed. > " in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz)" - > http://en.wikipedia.org/wiki/IEEE_802.11p I guess that is wrong. No? Alex > > > Üdvözlettel / Best regards, András Váradi > > Project Manager - C2X/ITS Systems Customer Support Wireless Modules > > Automotive & WLAN Group lesswire Hungary | Office: +36 23521 667 | > Email: Varadi@lesswire.com > > > -----Original Message----- From: its [mailto:its-bounces@ietf.org] On > Behalf Of Alexandru Petrescu Sent: Monday, November 24, 2014 11:47 > AM To: its@ietf.org Subject: Re: [geonet/its] 802.11p USB dongles? > > Hello, > > Here are my thoughts. > > Le 18/11/2014 20:02, Varadi , Andras (lesswire AG Ungarn) a écrit : >> Dear Arcot, Richard >> >> Sorry for the long delay, I will try to answer short, >> >>>> Will there be support from lesswire for Linux systems for these >>>> USB modules or will the users have to come up with the drivers >>>> themselves? > > There is one 802.11p driver used extensively on many platforms. It > is based on a modified version of the Atheros' ath5k driver. I > guess it may be used on 802.11p USB dongles as well. > > The base ath5k driver is present in the linux kernel and is covered > by a mixture of GPL/BSD-style licenses as well as a copyright > notice. > > (see the licensing scheme in the top-level comments in this C file: > http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath5k/base.c > ) > > By this licensing scheme, it is not sure the source code of this > athk-based 802.11p driver must or may be redistributed freely. It > can "alternatively". > > Actually, I do think there is a strong need for an open-source > GPL-style 802.11p driver to be maintained on many platforms. It is > relatively easy to do one, starting from that ath5k. > >> AV: We provide products, not pure HW and thus I dont see a way for >> selling anything without a driver. I do not know who will supply >> the driver though, the distri, the module, the chip manufacturer or >> anyone else. This will be determined once we release the product. >> >> ---------- >> >> _please note that these are my personal opinions / feelings:_ >> >>>> In short, to answer your question about DCC, I don't know how >>>> to >> handle that just yet. >> >>>> 1) DCC is not yet mandatory anywhere and hopefully that >>>> situation will >> not change. >> >> AV: In the EU at least for G5A we are talking about a safety >> system which needs to be trustworthy, if my cars safety system >> fails in an urban intersection, because someone is allowed to >> transmit non-safety data on those channels, then the whole system >> is useless. >> >> (in this sense if You transmit safety data, then you apply DCC) > > DCC stands for Decentralized Congestion Control, as specified by > document ETSI TS 102 687. It is a high-level medium access > facilitator: power control (raise or lower emission power levels > depending on noise), bandwidth control (raise or lower). There are > other MAC access mechanisms already in place. > > Driving safety is indeed of paramount importance. However, it may be > hard to rely solely on 802.11p for safety, even if it is enhanced > with DCC. Because 5.9GHz is unlicensed spectrum - anyone can emit in > this space without owning a license from authority - jammers are easy > to do. > > Driving safety needs to rely on additional mechanisms such as 3D > reconstruction based on video recognition, radar waves bouncing off > obstacles (laser, lidar), and as a last resort - human sight, since > ultimately it is a human that is in charge of all this. > > [...] > > >>>> The coupling that people seem to believe exists between 11p and >>>> IPv6 is a fiction in their minds. There is NO coupling. > > 11p and IP are natural fits though. Both IPv6 _and_ IPv4 work ok > very easily on 802.11p. > > Additional layers between 11p and the IP networking layer may come at > a cost. > > Enhanced IP layers (extension headers, IP control protocols) are > another matter, of course. > >> No coupling, but IPv6 is a (maybe the best) way to globally >> address future cars > > I agree. There is a real case manufacturers are confronted with when > planning production and assigning IP addresses to them. IPv4 > addresses no longer available, NAT clumsy remote software updates, > strong IPv6 migration in the Internet core - are all factors > impacting the addressing architecture in the long term for the future > vehicles. > >> (check ITSSv6 for example), nevertheless, for safety messages >> (normal) IP has just to big overhead, a CAM or DENM V2V message is >> much more compact and IP can not fight that. (and we need >> short/quick transmission times!!) > > Sorry, I disagree. > > The shortest IP message is 40byte long, it is not overhead. > > What is the shortest CAM or DENM message? > > The latency is precisely the same for both IP and CAM or DENM > messages. > > (I agree with you though if the functionality of a CAM message like > "here I am" is implemented in the form of an http/tcp/ip > request-response "where are you/here I am" between a client and a > server, with multiple 3-way handshakes). > > Alex > >> >> Üdvözlettel / Best regards, András Váradi >> >> Project Manager - C2X/ITS Systems Customer Support Wireless >> Modules >> >> Automotive & WLAN Group lesswire Hungary***|***Office: +36 23521 >> 667***|***Email: Varadi@lesswire.com >> >> *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu] *Sent:* Friday, >> November 07, 2014 7:04 PM *To:* Varadi , Andras (lesswire AG >> Ungarn) *Cc:* its@ietf.org *Subject:* Re: [geonet/its] 802.11p USB >> dongles? >> >> Hi Andras, >> >> Thanks for the links. Will there be support from lesswire for >> Linux systems for these USB modules or will the users have to come >> up with the drivers themselves? Also, what do you think the price >> of USB module will be? Or is it better to ask one of the >> distributors that question? >> >> As for your DCC question, I have only now started looking in to >> the whole 802.11p shebang and haven't completely dug in to the >> requirements to comply with the standards yet. I have been asking >> questions of Alexandru Petrescu in another email chain and >> following his suggestions of first trying to find a hardware/driver >> combination that will allow me to transmit in the 802.11p frequency >> band with IP. >> >> In short, to answer your question about DCC, I don't know how to >> handle that just yet. >> >> Thanks, >> >> Kiran. >> >> On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG >> Ungarn) > wrote: >> >> Hi Kiran >> >> I also have some serious concerns about outdoor usage of ETSI G5 >> in the EU... Just for an example: how will You tolerate DCC >> (Decentralized Congestion Control) in Your use case? (which will >> not let You transmit just any time - and You need DCC to transmit >> and comply the standards) >> >> USB 11p module (available next year) - >> http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its- >> >> car2x/overview/ More info on availibility from the distributors: >> http://www.lesswire.com/en/distributors/commercials-new/ >> >> Üdvözlettel / Best regards, András Váradi >> >> Project Manager - C2X/ITS Systems Customer Support Wireless >> Modules >> >> Automotive & WLAN Group lesswire Hungary | Office: +36 23521 667 >> | Email: Varadi@lesswire.com >> >> >> >> -----Original Message----- From: its [mailto:its-bounces@ietf.org >> ] On Behalf Of Alexandru Petrescu >> Sent: Thursday, November 06, 2014 5:45 PM To: Arcot, Kiran K; >> dickroy@alum.mit.edu Cc: its@ietf.org >> Subject: Re: [geonet/its] 802.11p USB >> dongles? >> >> Well - there may be ways to comply to the legislation of 5.9GHz >> and high power levels for ITS, if the flying experimentation >> happens indoors (hangar). >> >> But coming back to the original question: is there an USB dongle >> 802.11p? >> >> The manufacturer I am familiar with (UNEX, not to name it) only >> does mini-PCI 802.11p cards. >> >> An 802.11p USB dongle format may be useful to some of the most >> constrained linux platforms which feature USB rather than >> mini-PCI. >> >> If this is done, and given the easiness of running IP on 802.11p, >> I'd be thrilled to see IP between flying objects. >> >> Alex >> >> >> Le 06/11/2014 17:04, Arcot, Kiran K a écrit : >>> Hello RR, >>> >>> The idea indeed is to comply with the standards and regulation >>> already present. >>> >>> Thanks, Kiran. >>> >>> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy >>> >>> >> >>> wrote: >>> >>> __ __ __ >>> >>> I'd suggest you look for 802.11a compliant dongles that have >>> mad-wifi or some other open source driver you can modify. I'd >>> also recommend you NOT use the 5.850-5.925GHz band since that >>> band is reserved for ITS, unless, of course, you plan on >>> complying with the number of standards and regulations already in >>> place for use of the band.____ >>> >>> __ __ >>> >>> Cheers,____ >>> >>> __ __ >>> >>> RR ____ >>> >>> __ __ >>> >>> >>> --------------------------------------------------------------------- >>> >>> - >>> -- >>> >>> *From:*Arcot, Kiran K [mailto:kiranarcot@uky.edu >>> >> >] *Sent:* Tuesday, November 04, 2014 >>> 10:42 AM *To:*its@ietf.org >>> > > >>> *Subject:* [geonet/its] 802.11p USB dongles?____ >>> >>> __ __ >>> >>> Hello All,____ >>> >>> __ __ >>> >>> I am a graduate student at the ____University__ of >>> __Kentucky____ and I am looking at using 802.11p for >>> communication between out quad-copters. To that end is anyone >>> aware of any 802.11p USB dongles on the market? Are there any >>> open source drivers (Linux specifically) that are in semi-usable >>> state or in development? If so where can one find such a driver >>> for 802.11p cards/USB dongles?____ >>> >>> __ __ >>> >>> Thanks,____ >>> >>> Kiran Arcot.____ >>> >>> >>> >>> >>> _______________________________________________ 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 > > From nobody Mon Nov 24 08:55:04 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DE21A7113 for ; Mon, 24 Nov 2014 08:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjO4IMa7KrzF for ; Mon, 24 Nov 2014 08:55:00 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6531A8703 for ; Mon, 24 Nov 2014 08:54:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 9E93B9418F; Mon, 24 Nov 2014 11:54:51 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (scale.ogcinc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT7ZIRBWxqW9; Mon, 24 Nov 2014 11:54:47 -0500 (EST) Received: from mail2.standardsmail.org (mail2.standardsmail.org [66.244.86.41]) by mail.opengeospatial.org (Postfix) with ESMTP id DC1B19405B; Mon, 24 Nov 2014 11:54:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id D3E89E5523F; Mon, 24 Nov 2014 11:54:47 -0500 (EST) Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id glfRVsS8SyDX; Mon, 24 Nov 2014 11:54:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail2.standardsmail.org (Postfix) with ESMTP id 2E1DFE551F7; Mon, 24 Nov 2014 11:54:44 -0500 (EST) X-Virus-Scanned: amavisd-new at mail2.standardsmail.org Received: from mail2.standardsmail.org ([127.0.0.1]) by localhost (mail2.standardsmail.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id diH_Otm2nZ6y; Mon, 24 Nov 2014 11:54:44 -0500 (EST) Received: from OfficeHP (c-75-71-122-141.hsd1.co.comcast.net [75.71.122.141]) by mail2.standardsmail.org (Postfix) with ESMTPSA id 71A49E523B8; Mon, 24 Nov 2014 11:54:43 -0500 (EST) Message-ID: From: "Carl Reed" To: "Alexandru Petrescu" , "Rex Buddenberg" , "Templin, Fred L" , "George Percivall" References: <54643126.7080806@gmail.com> <1415909416.13262.7.camel@localhost.localdomain> <54651605.2070708@gmail.com> <0345CC670596442CBB36396EE6728D96@OfficeHP> <547316D6.2020408@gmail.com> In-Reply-To: <547316D6.2020408@gmail.com> Date: Mon, 24 Nov 2014 09:47:06 -0700 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/its/HLo9juXBVZf8Bp4IPgmO8jQ0xQs Cc: its@ietf.org Subject: Re: [geonet/its] Results - presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:55:03 -0000 Thanks, Alex - I reviewed the slides. Very informative. In terms of the aviation community and their requirements, the OGC has be= en=20 working with the FAA, Eurocontrol, SESAR and a number of related=20 organizations on the geospatial elements in a number of standards that ar= e=20 part of the NextGen architecture. These include FIXM (Flight Information)= ,=20 WXXM (weather), and AIXM (aeronautical information). A good overview and = can=20 be found here: https://www.fbcinc.com/e/ATIEC/presentations/Tuesday/Percivall_-_08-26_12= 0_-_OGC_Testbed_10_Aviatio.pdf These geo-related standards activities are using the OGC/ISO Geography=20 Markup Language (GML). The geometry elements in in GML are based on the=20 abstract model defined in ISO 19107: Spatial Schema. As such, the aviatio= n=20 community use of GML is consistent with the IETF geodetic location object= as=20 defined by the GeoPriv WG activity as well as the geo extension for DHCP. My point is that consistency across the standards stack in how geo is=20 specified would enhance interoperability and ease of implementation. I need to check the internet drafts referenced in the presentation. Thanks! Carl -----Original Message-----=20 From: Alexandru Petrescu Sent: Monday, November 24, 2014 4:30 AM To: Carl Reed ; Rex Buddenberg ; Templin, Fred L Cc: its@ietf.org Subject: Re: [geonet/its] Results - presentation of draft about geolocati= on=20 in IPv6 headers - 6MAN Working Group Carl, colleagues, Thank you for the remarks on this draft. Much of the argumentation was on the privacy aspects and appropriatedness at the networking layer, with pros and cons. The conclusion is that there should be more discussion on this. The audiolog of the presentation in 6MAN WG on Nov. 14th, and the discussion are online at: http://www.ietf.org/audio/ietf91/ ietf91-coral3-20141114-0900-am1.mp3 in the zone from 1hour 24min 35sec until 1h 47m 34s. Slides at: http://www.ietf.org/proceedings/91/slides/slides-91-6man-8.pdf Video of entire session at: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF91_= 6MAN&chapter=3Dchapter_0 Alex Le 13/11/2014 22:39, Carl Reed a =C3=A9crit : > Alex - > > I would look at the DHCP Location extension to see how the datum is > specified. Also, if more than one datum (WGS 84) is required then I > would consider using the appropriate EPSG codes, which the DHCP Locatio= n > RFC also uses. To whit: > > Datum Registry > > > IANA has created and now maintains the Datum registry following the > guidelines below. > > The registry consists of three values: Datum, Description, and > Reference. These are described below. > > Datum: An integer, refers to the value used in the DHCPv4 GeoConf an= d > the DHCPv4 and DHCPv6 GeoLoc options described in this document. > Value 0 is Reserved. Values 1 - 3 are assigned. Values 4 - 7 ar= e > Unassigned [RFC5226]. > > Description: The description of the altitude described by this code. > > Reference: The reference to the document that describes the Datum > code. This reference MUST include specification of both the > horizontal and vertical datum, and MUST define the way that the > 34-bit values and the respective 6-bit uncertainties are > interpreted. > > Initial values are given below; new assignments are to be made > following the "Standards Action" policies [RFC5226]. > > +------+----------------------------------------+--------------+ > | # | Description | Reference | > +------+----------------------------------------+--------------+ > | 0 | Reserved | RFC 6225 | > +------+----------------------------------------+--------------+ > | 1 | Vertical datum WGS 84 defined by EPSG | RFC 6225 | > | | CRS Code 4327 | | > +------+----------------------------------------+--------------+ > | 2 | Vertical datum NAD83 defined by EPSG | RFC 6225 | > | | CRS Code 4269 with North American | | > | | Vertical Datum of 1988 (NAVD88) | | > +------+----------------------------------------+--------------+ > | 3 | Vertical datum NAD83 defined by EPSG | RFC 6225 | > | | CRS Code 4269 with Mean Lower Low Water| | > | | (MLLW) as associated vertical datum | | > +------+----------------------------------------+--------------+ > | 4-7 | Unassigned | | > +------+----------------------------------------+--------------+ > >> From https://tools.ietf.org/html/rfc6225#page-18 > > Cheers > > Carl > > -----Original Message----- From: Alexandru Petrescu > Sent: Thursday, November 13, 2014 1:35 PM > To: Rex Buddenberg > Cc: its@ietf.org > Subject: Re: [geonet/its] Presentation of draft about geolocation in > IPv6 headers - 6MAN Working Group > > Le 13/11/2014 21:10, Rex Buddenberg a =C3=A9crit : >> Alex, >> >> The ID is a good first step -- it illustrates at least one way to enco= de >> Lat/Lon/Alt at layer 3. IPv6 certainly has the flexibility to do >> such. >> My misgiving, which I haven't thought out in detail, is that use= of >> header extensions in IPv6 opens a bunch of security issues. The >> security part of the ID is pretty blithe. > > I agree. A colleague IETFer also told me the privacy risk may be there= . > > I wonder whether the Destinations Options header of IPv6 could be > covered by the encryption part of an ESP (Encapsulating Security Payloa= d > of IPsec), or if otherwise DO must always travel in clear. > >> The geo datum is not specified. At the ID stage that's hardly >> fatal but needs to get in eventually. > > I agree. This is a good remark. > >> The geo work should be followed by the header compression work i= n >> 6lowpan -- lots of bits means lots of spectrum use and lots of power >> (e.g. battery power) so you want to conserve. >> >> But do you want this content data at layer 3? Operational >> requirement... > > This is a good question. Many remarks in geonet/its were about the fac= t > that sending geo-position data should happen at app layer, not > elsewhere. An official report tells a country's vehicular comm > standards should not consider geo-position as strongly as another > country's similar standard - naming the wrong situation at network laye= r > as a reason. > > On another hand, many standards don't really feature application layers > distinct from network layers. If all applications run in the network > layer, is it still non-recommended to put geo-position in there? > >> RFC6953 (PAWS) has just been read out by IETF. PAWS uses layer 7 geo >> encoding (and specified WGS84). Also worth reading through altho the >> geo here is used for a different purpose. > > Ok, will look at this spectrum related document. > > The application seems to be different for PAWS (spectrum). > > HEre, if I understand correctly, IPv6 GEO may be useful for emergency > kinds of apps. In that sense, one would like _any_ packet out of a nod= e > to tell its position, not necessarily the packets issues by one > particular application. > > I.e. one may wonder what happens if some application in the computer > crashes - will the control center loose computer's position? because > the kernel may still echo requests from the control center, piggybacked > with DO GEO IPv6. > > Alex > >> >> >> >> b >> >> >> On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote: >>> Hello, >>> >>> Friday morning there will be a presentation about using geolocation >>> information in IPv6 headers, in the 6man Working Group. >>> https://tools.ietf.org/wg/6man/agenda?item=3Dagenda-91-6man.html >>> >>> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >>> >>> What do you think about this draft? >>> >>> Alex >>> >>> _______________________________________________ >>> 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 nobody Mon Nov 24 10:38:38 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A706A1A701E for ; Mon, 24 Nov 2014 10:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K3RXKzhdFo8 for ; Mon, 24 Nov 2014 10:38:11 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3391A8790 for ; Mon, 24 Nov 2014 10:36:39 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kq14so10018021pab.12 for ; Mon, 24 Nov 2014 10:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=zktK+OsZQFIVYzojgO+op3Po+fqT9azyRtPYA8Ia4Ro=; b=JMDH1bzISCu2MymlW2fLGll3dBQ1A7PwAucQp+F/ZGNbKlmWdURey0AqWA8nG8ypnq caX4nPrjqHe7idRdVGGxL2S/eW5+2ojV79woT/b+3zVL6oYo3XepK51MMm9a050Ef5zD fzFOmoQA9Qv+ZZRYKTwwN9mclyAW89eKAMyKM0FYzKaxcuZgM5NLFPv5Um+DQyir7+x0 ZA6KM2j2i1WaF3RKrBGhxXgv3NRL6d6ShMU+6x3XZNCCvc2DP3oayZbJPgSs8uy/SUw7 ILR1VfrRc1fHhU9NMf/p8yvT6S68CeXzxU1OX52l1cTE1oIYytFW/XxSTxFr4ErZ7B7U YbRg== X-Received: by 10.66.253.197 with SMTP id ac5mr17147592pad.152.1416854198192; Mon, 24 Nov 2014 10:36:38 -0800 (PST) Received: from [192.168.1.103] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id lm3sm13168743pab.34.2014.11.24.10.36.36 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Mon, 24 Nov 2014 10:36:37 -0800 (PST) Message-ID: <1416854195.1923.146.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandru Petrescu Date: Mon, 24 Nov 2014 10:36:35 -0800 In-Reply-To: <547312BA.70201@gmail.com> References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/IYVVzHXd1HvhWIivMHe6aRJ0yMQ Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 18:38:26 -0000 Alex and Roy, You've got most of the security issues here, but we can organize the thinking better. Reasoning through the security -- specifically the scope of security -- can clarify your requirements questions enormously. > >The ONLY reason to carry GEO information in a layer 3 header is that > > there are layer 3 processes/functions that require or will make use > > of that information. If the information is only useful at the > > destination, then the information belongs in a layer 4 header or > > higher up the stack. You're discussing layer 3 vs layer 7 security. This is right, but it may make more sense if we fill in the rest of the matrix: 2. Layer 1 and 2 security measures (e.g. anything sounding like 'wifi security') means security measures applied to ethernet headers and payloads. Because the layer 2 header is discarded before the first router, the scope of security is single segment. No farther. No matter how perfect your layer 2 security may be, it's scope is only one segment. 3. Layer 3 security is applied to datagrams. This is what the ID in 6MAN is doing. The scope of security is enclave as in VPN. (Enclaves do not include end systems). The chief payoff in layer 3 security is that you can mix multiple wide area networking needs into a single infrastructure -- each community can have an enclave to itself. 4-5. Layer 4 and 5 security secures connections. The primary example is SSL (aka TLS). Commonly used for e-commerce and commonly worked around by Bad Guys because they attack places outside of the security scope. Layer 4 security solutions are applied at the I/O outer layer of the operating system (at the network socket). Similarly, the security protection is removed at the network socket on arrival at destination, thereby leaving the data unprotected within the OS. 6-7. Protection applied at layer 6-7 is only removed by an application (or the library routines that an application calls). Layer 6-7 protection is generically different than lower layer protections in that it protects data, not infrastructure. Layer 6-7 protection is end-to-end -- from end system to end system, wholly agnostic about the networking infrastructure. Because it protects the data, layer 6-7 protection can protect data at rest (e.g. on a flash or disk drive) just as easily as over the internetwork. So it's not only end-system to end-system, but _through_ end systems as well, partially protecting the data against possible malware in an end system. E-mail, with S/MIME protections, is the most ubiquitous example of layer 6-7 protections. This exchange is correct; it makes, IMHO, even better sense when you apply the scope of security reasoning: > I agree with this draft's point. The location information is a good > hint for routing convergence. When most core links have similar speeds, > better connect to the closer router. Router location is also good for a > tie breaker when two destination have equal costs. > > > All the others involved sending source location to destination(s) and > > that's NOT a layer 3 problem. Geographic information is exchanged in organized form by several internet applications: > Third, other agreed non-IP networking layers already exchange > geo-location information - are these net layers or app layers? > SNMP, for example, contains a location variable in the MIB. It's only defined as a string right now but it's a space where an administrator can say 'this gadget is installed in the 4th floor wiring closet'. You could certainly encode a Lat/Lon/Alt chunk of data in the space. SNMP is an application -- layer 7. So the scope of the SNNP (v3) security measures is indeed end-to-end. PAWS, which I've mentioned before on [its] also is an application. Layer 6-7. It's Lat/Lon/Alt information is therefore at app layer. The security considerations in PAWS are exclusively targeted at protecting the data. You've commented that wiretapping layer 3 geo information for layer 7 application purposes would be a layer violation. That is most certainly correct. But what are the consequences of a layer violation? 1. The longer term consequence is that this disrupts the organization of the internet with downstream negatives regarding interoperability and flexibility. While true, this is a hard argument to sell to a guy with a screwdriver in his hand. 2. The more telling argument is the security scope one. Layer violations provide vectors for penetrating security. Because the layer violation always increases the scope of vulnerability. Help?? On Mon, 2014-11-24 at 12:12 +0100, Alexandru Petrescu wrote: > Richard, > > Le 15/11/2014 01:33, Richard Roy a écrit : > > My initial comment on the draft is that the concept of a destination > > options field is inappropriate and opens security holes and creates a > > possible attack vector needlessly. > > But (1) a DO header must not be examined by intermediary routers, by > definition, and (2) if the end node feels at risk, the Destinations > Options (DO) header may be put after an Encapsulation Security Payload > (ESP) header, and as such be hidden from unwanted scrutiny. > > > The destination of a packet is by definition a place where the ADU is > > parsed/consumed. Any information intended only for the destination > > should be carried ONLY in the ADU, not in any lower layer PDU. > > Hence, the concept of "destination options" at a lower layer (i.e. > > the network layer) amounts to a layer violation. > > YEs, layer violation may be what can happen. > > But in more detail, there are already many details in the networking > layer that may differentiate it from layer violation - most extension > headers carry info which may qualify as app by some, but are qualified > as networking by others. > > Another indication that Geo-information may be fit in the networking > layer is in the popular net analyzer Wireshark showing Source GeoIP and > Destination GeoIP in all packets displayed, even if unknown. > > > The ONLY reason to carry GEO information in a layer 3 header is that > > there are layer 3 processes/functions that require or will make use > > of that information. If the information is only useful at the > > destination, then the information belongs in a layer 4 header or > > higher up the stack. > > I agree. > > But the location information itselfy can qualify as more app-layer or > more 'net'-layer. I live on the 4th floor - that is the app-layer of > saying location; I live at 2/49/WGS48 is more of a 'net'-layer. > > Second, the app layers are less reliable than the 'net'-layer. An UDP > userspace application sending the GPS coordinates can crash at any time > and as such track is lost of some object. On another hand, same data > sent by the IP stack in the kernel as much less chances to crash - the > kernel is much more reliable and less latency than the userspace space > apps. It can be made even real time (rely on tangible hw features), > whereas apps are hard to make real time. > > Since the document claims that "This document seeks to specify a > > method for including the geolocation data in the IPv6 Destination > > Options header", it clearly seems to be focused on peer-to-peer > > exchange of GEO information. This is more safely accomplished at > > layers above the network layer. Note that the ONLY example given of > > an application involving layer 3 functionality was > > > > "Convergence of dynamic routing protocols in a wide variety of mobile > > networks can benefit greatly from knowledge of the geographical > > locations of prospective neighbors. This information is best > > conveyed in the headers of IPv6 packets used for routing protocol > > control message exchanges." > > I agree with this draft's point. The location information is a good > hint for routing convergence. When most core links have similar speeds, > better connect to the closer router. Router location is also good for a > tie breaker when two destination have equal costs. > > > All the others involved sending source location to destination(s) and > > that's NOT a layer 3 problem. > > > > Finally, the issue of coordinate systems was not addressed properly. > > It's implied by the description in the text that WGS84 is used, > > however, this system is subject to update and change. IF the IETF is > > going to include GEO info in it's headers, there must be a field with > > sufficient size to encode the coordinate system that is being used > > and which version thereof. > > I agree. > > > Furthermore, the issue of uncertainly (estimate error covariance > > really) was not addressed. All GEO locations are "estimates" and are > > realizations of a vector random process that has an associated MD > > PDF. The ability to also communicate other than jus the zeroth order > > moment (i.e., the mean) is often important! > > I agree. > > Alex > > > > > RR > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, November 12, > >> 2014 8:19 PM To: its@ietf.org Subject: [geonet/its] Presentation of > >> draft about geolocation in IPv6 headers - 6MAN Working Group > >> > >> Hello, > >> > >> Friday morning there will be a presentation about using > >> geolocation information in IPv6 headers, in the 6man Working > >> Group. > >> https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html > >> > >> The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo > >> > >> What do you think about this draft? > >> > >> Alex > >> > > > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From nobody Tue Nov 25 01:58:39 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEEE1A871B for ; Mon, 24 Nov 2014 09:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUlw_-MgSb9u for ; Mon, 24 Nov 2014 09:07:19 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C161E1A8741 for ; Mon, 24 Nov 2014 09:07:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id sAOH7DY7024402; Mon, 24 Nov 2014 09:07:13 -0800 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id sAOH7BSb024344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 24 Nov 2014 09:07:11 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.76]) by XCH-PHX-111.sw.nos.boeing.com ([169.254.11.32]) with mapi id 14.03.0210.002; Mon, 24 Nov 2014 09:07:10 -0800 From: "Templin, Fred L" To: Carl Reed , Alexandru Petrescu , Rex Buddenberg , George Percivall Thread-Topic: [geonet/its] Results - presentation of draft about geolocation in IPv6 headers - 6MAN Working Group Thread-Index: AQHQB9onDu+upnn2Jk2y12vZVhJBP5xwgvcA//9+JbA= Date: Mon, 24 Nov 2014 17:07:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832DA08A5@XCH-BLV-504.nw.nos.boeing.com> References: <54643126.7080806@gmail.com> <1415909416.13262.7.camel@localhost.localdomain> <54651605.2070708@gmail.com> <0345CC670596442CBB36396EE6728D96@OfficeHP> <547316D6.2020408@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/its/1FVoBQADkyXGLulQ8qwodjvuhu8 X-Mailman-Approved-At: Tue, 25 Nov 2014 01:58:39 -0800 Cc: "Skeen, Brian L" , "its@ietf.org" , "King, Edwin E" Subject: Re: [geonet/its] Results - presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 17:07:22 -0000 SGksIHRoYW5rIHlvdSBmb3IgdGhlIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4gSSB3aWxsIGpv aW4gdGhlICdpdHMnIGxpc3QgdG8gYmUgc3VyZSB3ZQ0KY2FuIHRyYWNrIHRoZSByZXN0IG9mIHRo ZSBhY3Rpdml0eS4NCg0KV2UgYXJlIG9wZW4gdG8gc3BlY2lmaWMgY29tbWVudHMgb24gZHJhZnQt c2tlZW4tNm1hbi1pcHY2Z2VvLiBXZSB3b3VsZA0KbGlrZSB0byBiZSBzdXJlIHRoYXQgYW55dGhp bmcgd2Ugc3BlY2lmeSBpcyBjb25zaXN0ZW50IHdpdGggaW5kdXN0cnkgc3RhbmRhcmRzLg0KDQpU aGUgZG9jdW1lbnQgcG9pbnRlcnMgYXJlIGFwcHJlY2lhdGVkLCBhbmQgd2Ugd2lsbCB0YWtlIGEg bG9vay4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmwgUmVlZCBbbWFpbHRvOmNyZWVk QG9wZW5nZW9zcGF0aWFsLm9yZ10NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyNCwgMjAxNCA4 OjQ3IEFNDQo+IFRvOiBBbGV4YW5kcnUgUGV0cmVzY3U7IFJleCBCdWRkZW5iZXJnOyBUZW1wbGlu LCBGcmVkIEw7IEdlb3JnZSBQZXJjaXZhbGwNCj4gQ2M6IGl0c0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW2dlb25ldC9pdHNdIFJlc3VsdHMgLSBwcmVzZW50YXRpb24gb2YgZHJhZnQgYWJvdXQg Z2VvbG9jYXRpb24gaW4gSVB2NiBoZWFkZXJzIC0gNk1BTiBXb3JraW5nIEdyb3VwDQo+IA0KPiBU aGFua3MsIEFsZXggLQ0KPiANCj4gSSByZXZpZXdlZCB0aGUgc2xpZGVzLiBWZXJ5IGluZm9ybWF0 aXZlLg0KPiANCj4gSW4gdGVybXMgb2YgdGhlIGF2aWF0aW9uIGNvbW11bml0eSBhbmQgdGhlaXIg cmVxdWlyZW1lbnRzLCB0aGUgT0dDIGhhcyBiZWVuDQo+IHdvcmtpbmcgd2l0aCB0aGUgRkFBLCBF dXJvY29udHJvbCwgU0VTQVIgYW5kIGEgbnVtYmVyIG9mIHJlbGF0ZWQNCj4gb3JnYW5pemF0aW9u cyBvbiB0aGUgZ2Vvc3BhdGlhbCBlbGVtZW50cyBpbiBhIG51bWJlciBvZiBzdGFuZGFyZHMgdGhh dCBhcmUNCj4gcGFydCBvZiB0aGUgTmV4dEdlbiBhcmNoaXRlY3R1cmUuIFRoZXNlIGluY2x1ZGUg RklYTSAoRmxpZ2h0IEluZm9ybWF0aW9uKSwNCj4gV1hYTSAod2VhdGhlciksIGFuZCBBSVhNIChh ZXJvbmF1dGljYWwgaW5mb3JtYXRpb24pLiBBIGdvb2Qgb3ZlcnZpZXcgYW5kIGNhbg0KPiBiZSBm b3VuZCBoZXJlOg0KPiANCj4gaHR0cHM6Ly93d3cuZmJjaW5jLmNvbS9lL0FUSUVDL3ByZXNlbnRh dGlvbnMvVHVlc2RheS9QZXJjaXZhbGxfLV8wOC0yNl8xMjBfLV9PR0NfVGVzdGJlZF8xMF9Bdmlh dGlvLnBkZg0KPiANCj4gVGhlc2UgZ2VvLXJlbGF0ZWQgc3RhbmRhcmRzIGFjdGl2aXRpZXMgYXJl IHVzaW5nIHRoZSBPR0MvSVNPIEdlb2dyYXBoeQ0KPiBNYXJrdXAgTGFuZ3VhZ2UgKEdNTCkuIFRo ZSBnZW9tZXRyeSBlbGVtZW50cyBpbiBpbiBHTUwgYXJlIGJhc2VkIG9uIHRoZQ0KPiBhYnN0cmFj dCBtb2RlbCBkZWZpbmVkIGluIElTTyAxOTEwNzogU3BhdGlhbCBTY2hlbWEuIEFzIHN1Y2gsIHRo ZSBhdmlhdGlvbg0KPiBjb21tdW5pdHkgdXNlIG9mIEdNTCBpcyBjb25zaXN0ZW50IHdpdGggdGhl IElFVEYgZ2VvZGV0aWMgbG9jYXRpb24gb2JqZWN0IGFzDQo+IGRlZmluZWQgYnkgdGhlIEdlb1By aXYgV0cgYWN0aXZpdHkgYXMgd2VsbCBhcyB0aGUgZ2VvIGV4dGVuc2lvbiBmb3IgREhDUC4NCj4g DQo+IE15IHBvaW50IGlzIHRoYXQgY29uc2lzdGVuY3kgYWNyb3NzIHRoZSBzdGFuZGFyZHMgc3Rh Y2sgaW4gaG93IGdlbyBpcw0KPiBzcGVjaWZpZWQgd291bGQgZW5oYW5jZSBpbnRlcm9wZXJhYmls aXR5IGFuZCBlYXNlIG9mIGltcGxlbWVudGF0aW9uLg0KPiANCj4gSSBuZWVkIHRvIGNoZWNrIHRo ZSBpbnRlcm5ldCBkcmFmdHMgcmVmZXJlbmNlZCBpbiB0aGUgcHJlc2VudGF0aW9uLg0KPiANCj4g VGhhbmtzIQ0KPiANCj4gQ2FybA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQWxleGFuZHJ1IFBldHJlc2N1DQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjQsIDIw MTQgNDozMCBBTQ0KPiBUbzogQ2FybCBSZWVkIDsgUmV4IEJ1ZGRlbmJlcmcgOyBUZW1wbGluLCBG cmVkIEwNCj4gQ2M6IGl0c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2dlb25ldC9pdHNdIFJl c3VsdHMgLSBwcmVzZW50YXRpb24gb2YgZHJhZnQgYWJvdXQgZ2VvbG9jYXRpb24NCj4gaW4gSVB2 NiBoZWFkZXJzIC0gNk1BTiBXb3JraW5nIEdyb3VwDQo+IA0KPiBDYXJsLCBjb2xsZWFndWVzLA0K PiANCj4gVGhhbmsgeW91IGZvciB0aGUgcmVtYXJrcyBvbiB0aGlzIGRyYWZ0Lg0KPiANCj4gTXVj aCBvZiB0aGUgYXJndW1lbnRhdGlvbiB3YXMgb24gdGhlIHByaXZhY3kgYXNwZWN0cyBhbmQNCj4g YXBwcm9wcmlhdGVkbmVzcyBhdCB0aGUgbmV0d29ya2luZyBsYXllciwgd2l0aCBwcm9zIGFuZCBj b25zLg0KPiANCj4gVGhlIGNvbmNsdXNpb24gaXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgbW9yZSBk aXNjdXNzaW9uIG9uIHRoaXMuDQo+IA0KPiBUaGUgYXVkaW9sb2cgb2YgdGhlIHByZXNlbnRhdGlv biBpbiA2TUFOIFdHIG9uIE5vdi4gMTR0aCwgYW5kIHRoZQ0KPiBkaXNjdXNzaW9uIGFyZSBvbmxp bmUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvYXVkaW8vaWV0ZjkxLw0KPiBpZXRmOTEtY29y YWwzLTIwMTQxMTE0LTA5MDAtYW0xLm1wMw0KPiBpbiB0aGUgem9uZSBmcm9tIDFob3VyIDI0bWlu IDM1c2VjIHVudGlsIDFoIDQ3bSAzNHMuDQo+IA0KPiBTbGlkZXMgYXQ6DQo+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS02bWFuLTgucGRmDQo+IA0K PiBWaWRlbyBvZiBlbnRpcmUgc2Vzc2lvbiBhdDoNCj4gaHR0cDovL3JlY29yZGluZ3MuY29uZi5t ZWV0ZWNoby5jb20vUGxheW91dC93YXRjaC5qc3A/cmVjb3JkaW5nPUlFVEY5MV82TUFOJmNoYXB0 ZXI9Y2hhcHRlcl8wDQo+IA0KPiANCj4gQWxleA0KPiANCj4gTGUgMTMvMTEvMjAxNCAyMjozOSwg Q2FybCBSZWVkIGEgw6ljcml0IDoNCj4gPiBBbGV4IC0NCj4gPg0KPiA+IEkgd291bGQgbG9vayBh dCB0aGUgREhDUCBMb2NhdGlvbiBleHRlbnNpb24gdG8gc2VlIGhvdyB0aGUgZGF0dW0gaXMNCj4g PiBzcGVjaWZpZWQuIEFsc28sIGlmIG1vcmUgdGhhbiBvbmUgZGF0dW0gKFdHUyA4NCkgaXMgcmVx dWlyZWQgdGhlbiBJDQo+ID4gd291bGQgY29uc2lkZXIgdXNpbmcgdGhlIGFwcHJvcHJpYXRlIEVQ U0cgY29kZXMsIHdoaWNoIHRoZSBESENQIExvY2F0aW9uDQo+ID4gUkZDIGFsc28gdXNlcy4gVG8g d2hpdDoNCj4gPg0KPiA+IERhdHVtIFJlZ2lzdHJ5DQo+ID4NCj4gPg0KPiA+ICAgIElBTkEgaGFz IGNyZWF0ZWQgYW5kIG5vdyBtYWludGFpbnMgdGhlIERhdHVtIHJlZ2lzdHJ5IGZvbGxvd2luZyB0 aGUNCj4gPiAgICBndWlkZWxpbmVzIGJlbG93Lg0KPiA+DQo+ID4gICAgVGhlIHJlZ2lzdHJ5IGNv bnNpc3RzIG9mIHRocmVlIHZhbHVlczogRGF0dW0sIERlc2NyaXB0aW9uLCBhbmQNCj4gPiAgICBS ZWZlcmVuY2UuICBUaGVzZSBhcmUgZGVzY3JpYmVkIGJlbG93Lg0KPiA+DQo+ID4gICAgRGF0dW06 IEFuIGludGVnZXIsIHJlZmVycyB0byB0aGUgdmFsdWUgdXNlZCBpbiB0aGUgREhDUHY0IEdlb0Nv bmYgYW5kDQo+ID4gICAgICAgdGhlIERIQ1B2NCBhbmQgREhDUHY2IEdlb0xvYyBvcHRpb25zIGRl c2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+ICAgICAgIFZhbHVlIDAgaXMgUmVzZXJ2ZWQu ICBWYWx1ZXMgMSAtIDMgYXJlIGFzc2lnbmVkLiAgVmFsdWVzIDQgLSA3IGFyZQ0KPiA+ICAgICAg IFVuYXNzaWduZWQgW1JGQzUyMjZdLg0KPiA+DQo+ID4gICAgRGVzY3JpcHRpb246IFRoZSBkZXNj cmlwdGlvbiBvZiB0aGUgYWx0aXR1ZGUgZGVzY3JpYmVkIGJ5IHRoaXMgY29kZS4NCj4gPg0KPiA+ ICAgIFJlZmVyZW5jZTogVGhlIHJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBkZXNjcmli ZXMgdGhlIERhdHVtDQo+ID4gICAgICAgY29kZS4gIFRoaXMgcmVmZXJlbmNlIE1VU1QgaW5jbHVk ZSBzcGVjaWZpY2F0aW9uIG9mIGJvdGggdGhlDQo+ID4gICAgICAgaG9yaXpvbnRhbCBhbmQgdmVy dGljYWwgZGF0dW0sIGFuZCBNVVNUIGRlZmluZSB0aGUgd2F5IHRoYXQgdGhlDQo+ID4gICAgICAg MzQtYml0IHZhbHVlcyBhbmQgdGhlIHJlc3BlY3RpdmUgNi1iaXQgdW5jZXJ0YWludGllcyBhcmUN Cj4gPiAgICAgICBpbnRlcnByZXRlZC4NCj4gPg0KPiA+ICAgIEluaXRpYWwgdmFsdWVzIGFyZSBn aXZlbiBiZWxvdzsgbmV3IGFzc2lnbm1lbnRzIGFyZSB0byBiZSBtYWRlDQo+ID4gICAgZm9sbG93 aW5nIHRoZSAiU3RhbmRhcmRzIEFjdGlvbiIgcG9saWNpZXMgW1JGQzUyMjZdLg0KPiA+DQo+ID4g ICAgICAgKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tKw0KPiA+ICAgICAgIHwgICMgICB8ICBEZXNjcmlwdGlvbiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIFJlZmVyZW5jZSAgIHwNCj4gPiAgICAgICArLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rDQo+ID4g ICAgICAgfCAgMCAgIHwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg UkZDIDYyMjUgICAgfA0KPiA+ICAgICAgICstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICB8ICAxICAgfCBWZXJ0 aWNhbCBkYXR1bSBXR1MgODQgZGVmaW5lZCBieSBFUFNHICB8ICBSRkMgNjIyNSAgICB8DQo+ID4g ICAgICAgfCAgICAgIHwgQ1JTIENvZGUgNDMyNyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgfA0KPiA+ICAgICAgICstLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSsNCj4gPiAgICAgICB8ICAyICAgfCBWZXJ0 aWNhbCBkYXR1bSBOQUQ4MyBkZWZpbmVkIGJ5IEVQU0cgICB8ICBSRkMgNjIyNSAgICB8DQo+ID4g ICAgICAgfCAgICAgIHwgQ1JTIENvZGUgNDI2OSB3aXRoIE5vcnRoIEFtZXJpY2FuICAgICAgfCAg ICAgICAgICAgICAgfA0KPiA+ICAgICAgIHwgICAgICB8IFZlcnRpY2FsIERhdHVtIG9mIDE5ODgg KE5BVkQ4OCkgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4gPiAgICAgICArLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rDQo+ID4g ICAgICAgfCAgMyAgIHwgVmVydGljYWwgZGF0dW0gTkFEODMgZGVmaW5lZCBieSBFUFNHICAgfCAg UkZDIDYyMjUgICAgfA0KPiA+ICAgICAgIHwgICAgICB8IENSUyBDb2RlIDQyNjkgd2l0aCBNZWFu IExvd2VyIExvdyBXYXRlcnwgICAgICAgICAgICAgIHwNCj4gPiAgICAgICB8ICAgICAgfCAoTUxM VykgYXMgYXNzb2NpYXRlZCB2ZXJ0aWNhbCBkYXR1bSAgICB8ICAgICAgICAgICAgICB8DQo+ID4g ICAgICAgKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tKw0KPiA+ICAgICAgIHwgNC03ICB8IFVuYXNzaWduZWQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwNCj4gPiAgICAgICArLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rDQo+ID4N Cj4gPj4gRnJvbSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjIyNSNwYWdlLTE4DQo+ ID4NCj4gPiBDaGVlcnMNCj4gPg0KPiA+IENhcmwNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tIEZyb206IEFsZXhhbmRydSBQZXRyZXNjdQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBO b3ZlbWJlciAxMywgMjAxNCAxOjM1IFBNDQo+ID4gVG86IFJleCBCdWRkZW5iZXJnDQo+ID4gQ2M6 IGl0c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbZ2VvbmV0L2l0c10gUHJlc2VudGF0aW9u IG9mIGRyYWZ0IGFib3V0IGdlb2xvY2F0aW9uIGluDQo+ID4gSVB2NiBoZWFkZXJzIC0gNk1BTiBX b3JraW5nIEdyb3VwDQo+ID4NCj4gPiBMZSAxMy8xMS8yMDE0IDIxOjEwLCBSZXggQnVkZGVuYmVy ZyBhIMOpY3JpdCA6DQo+ID4+IEFsZXgsDQo+ID4+DQo+ID4+IFRoZSBJRCBpcyBhIGdvb2QgZmly c3Qgc3RlcCAtLSBpdCBpbGx1c3RyYXRlcyBhdCBsZWFzdCBvbmUgd2F5IHRvIGVuY29kZQ0KPiA+ PiBMYXQvTG9uL0FsdCBhdCBsYXllciAzLiAgSVB2NiBjZXJ0YWlubHkgaGFzIHRoZSBmbGV4aWJp bGl0eSB0byBkbw0KPiA+PiBzdWNoLg0KPiA+PiAgICAgICBNeSBtaXNnaXZpbmcsIHdoaWNoIEkg aGF2ZW4ndCB0aG91Z2h0IG91dCBpbiBkZXRhaWwsIGlzIHRoYXQgdXNlIG9mDQo+ID4+IGhlYWRl ciBleHRlbnNpb25zIGluIElQdjYgb3BlbnMgYSBidW5jaCBvZiBzZWN1cml0eSBpc3N1ZXMuICBU aGUNCj4gPj4gc2VjdXJpdHkgcGFydCBvZiB0aGUgSUQgaXMgcHJldHR5IGJsaXRoZS4NCj4gPg0K PiA+IEkgYWdyZWUuICBBIGNvbGxlYWd1ZSBJRVRGZXIgYWxzbyB0b2xkIG1lIHRoZSBwcml2YWN5 IHJpc2sgbWF5IGJlIHRoZXJlLg0KPiA+DQo+ID4gSSB3b25kZXIgd2hldGhlciB0aGUgRGVzdGlu YXRpb25zIE9wdGlvbnMgaGVhZGVyIG9mIElQdjYgY291bGQgYmUNCj4gPiBjb3ZlcmVkIGJ5IHRo ZSBlbmNyeXB0aW9uIHBhcnQgb2YgYW4gRVNQIChFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBheWxv YWQNCj4gPiBvZiBJUHNlYyksIG9yIGlmIG90aGVyd2lzZSBETyBtdXN0IGFsd2F5cyB0cmF2ZWwg aW4gY2xlYXIuDQo+ID4NCj4gPj4gICAgICAgVGhlIGdlbyBkYXR1bSBpcyBub3Qgc3BlY2lmaWVk LiAgQXQgdGhlIElEIHN0YWdlIHRoYXQncyBoYXJkbHkNCj4gPj4gZmF0YWwgYnV0IG5lZWRzIHRv IGdldCBpbiBldmVudHVhbGx5Lg0KPiA+DQo+ID4gSSBhZ3JlZS4gIFRoaXMgaXMgYSBnb29kIHJl bWFyay4NCj4gPg0KPiA+PiAgICAgICBUaGUgZ2VvIHdvcmsgc2hvdWxkIGJlIGZvbGxvd2VkIGJ5 IHRoZSBoZWFkZXIgY29tcHJlc3Npb24gd29yayBpbg0KPiA+PiA2bG93cGFuIC0tIGxvdHMgb2Yg Yml0cyBtZWFucyBsb3RzIG9mIHNwZWN0cnVtIHVzZSBhbmQgbG90cyBvZiBwb3dlcg0KPiA+PiAo ZS5nLiBiYXR0ZXJ5IHBvd2VyKSBzbyB5b3Ugd2FudCB0byBjb25zZXJ2ZS4NCj4gPj4NCj4gPj4g QnV0IGRvIHlvdSB3YW50IHRoaXMgY29udGVudCBkYXRhIGF0IGxheWVyIDM/ICBPcGVyYXRpb25h bA0KPiA+PiByZXF1aXJlbWVudC4uLg0KPiA+DQo+ID4gVGhpcyBpcyBhIGdvb2QgcXVlc3Rpb24u ICBNYW55IHJlbWFya3MgaW4gZ2VvbmV0L2l0cyB3ZXJlIGFib3V0IHRoZSBmYWN0DQo+ID4gdGhh dCBzZW5kaW5nIGdlby1wb3NpdGlvbiBkYXRhIHNob3VsZCBoYXBwZW4gYXQgYXBwIGxheWVyLCBu b3QNCj4gPiBlbHNld2hlcmUuICBBbiBvZmZpY2lhbCByZXBvcnQgdGVsbHMgYSBjb3VudHJ5J3Mg dmVoaWN1bGFyIGNvbW0NCj4gPiBzdGFuZGFyZHMgc2hvdWxkIG5vdCBjb25zaWRlciBnZW8tcG9z aXRpb24gYXMgc3Ryb25nbHkgYXMgYW5vdGhlcg0KPiA+IGNvdW50cnkncyBzaW1pbGFyIHN0YW5k YXJkIC0gbmFtaW5nIHRoZSB3cm9uZyBzaXR1YXRpb24gYXQgbmV0d29yayBsYXllcg0KPiA+IGFz IGEgcmVhc29uLg0KPiA+DQo+ID4gT24gYW5vdGhlciBoYW5kLCBtYW55IHN0YW5kYXJkcyBkb24n dCByZWFsbHkgZmVhdHVyZSBhcHBsaWNhdGlvbiBsYXllcnMNCj4gPiBkaXN0aW5jdCBmcm9tIG5l dHdvcmsgbGF5ZXJzLiAgSWYgYWxsIGFwcGxpY2F0aW9ucyBydW4gaW4gdGhlIG5ldHdvcmsNCj4g PiBsYXllciwgaXMgaXQgc3RpbGwgbm9uLXJlY29tbWVuZGVkIHRvIHB1dCBnZW8tcG9zaXRpb24g aW4gdGhlcmU/DQo+ID4NCj4gPj4gUkZDNjk1MyAoUEFXUykgaGFzIGp1c3QgYmVlbiByZWFkIG91 dCBieSBJRVRGLiAgUEFXUyB1c2VzIGxheWVyIDcgZ2VvDQo+ID4+IGVuY29kaW5nIChhbmQgc3Bl Y2lmaWVkIFdHUzg0KS4gIEFsc28gd29ydGggcmVhZGluZyB0aHJvdWdoIGFsdGhvIHRoZQ0KPiA+ PiBnZW8gaGVyZSBpcyB1c2VkIGZvciBhIGRpZmZlcmVudCBwdXJwb3NlLg0KPiA+DQo+ID4gT2ss IHdpbGwgbG9vayBhdCB0aGlzIHNwZWN0cnVtIHJlbGF0ZWQgZG9jdW1lbnQuDQo+ID4NCj4gPiBU aGUgYXBwbGljYXRpb24gc2VlbXMgdG8gYmUgZGlmZmVyZW50IGZvciBQQVdTIChzcGVjdHJ1bSku DQo+ID4NCj4gPiBIRXJlLCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBJUHY2IEdFTyBtYXkg YmUgdXNlZnVsIGZvciBlbWVyZ2VuY3kNCj4gPiBraW5kcyBvZiBhcHBzLiAgSW4gdGhhdCBzZW5z ZSwgb25lIHdvdWxkIGxpa2UgX2FueV8gcGFja2V0IG91dCBvZiBhIG5vZGUNCj4gPiB0byB0ZWxs IGl0cyBwb3NpdGlvbiwgbm90IG5lY2Vzc2FyaWx5IHRoZSBwYWNrZXRzIGlzc3VlcyBieSBvbmUN Cj4gPiBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uLg0KPiA+DQo+ID4gSS5lLiBvbmUgbWF5IHdvbmRl ciB3aGF0IGhhcHBlbnMgaWYgc29tZSBhcHBsaWNhdGlvbiBpbiB0aGUgY29tcHV0ZXINCj4gPiBj cmFzaGVzIC0gd2lsbCB0aGUgY29udHJvbCBjZW50ZXIgbG9vc2UgY29tcHV0ZXIncyBwb3NpdGlv bj8gIGJlY2F1c2UNCj4gPiB0aGUga2VybmVsIG1heSBzdGlsbCBlY2hvIHJlcXVlc3RzIGZyb20g dGhlIGNvbnRyb2wgY2VudGVyLCBwaWdneWJhY2tlZA0KPiA+IHdpdGggRE8gR0VPIElQdjYuDQo+ ID4NCj4gPiBBbGV4DQo+ID4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gYg0KPiA+Pg0KPiA+Pg0K PiA+PiBPbiBUaHUsIDIwMTQtMTEtMTMgYXQgMDU6MTggKzAxMDAsIEFsZXhhbmRydSBQZXRyZXNj dSB3cm90ZToNCj4gPj4+IEhlbGxvLA0KPiA+Pj4NCj4gPj4+IEZyaWRheSBtb3JuaW5nIHRoZXJl IHdpbGwgYmUgYSBwcmVzZW50YXRpb24gYWJvdXQgdXNpbmcgZ2VvbG9jYXRpb24NCj4gPj4+IGlu Zm9ybWF0aW9uIGluIElQdjYgaGVhZGVycywgaW4gdGhlIDZtYW4gV29ya2luZyBHcm91cC4NCj4g Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvNm1hbi9hZ2VuZGE/aXRlbT1hZ2VuZGEtOTEt Nm1hbi5odG1sDQo+ID4+Pg0KPiA+Pj4gVGhlIGRyYWZ0IGlzIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNrZWVuLTZtYW4taXB2Nmdlbw0KPiA+Pj4NCj4gPj4+IFdoYXQgZG8geW91 IHRoaW5rIGFib3V0IHRoaXMgZHJhZnQ/DQo+ID4+Pg0KPiA+Pj4gQWxleA0KPiA+Pj4NCj4gPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBp dHMgbWFpbGluZyBsaXN0DQo+ID4+PiBpdHNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gaXRzIG1haWxpbmcgbGlzdA0KPiA+IGl0c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXRzDQo+ID4NCj4gPg0KPiANCg0K From nobody Wed Nov 26 10:04:37 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20C01A0366 for ; Wed, 26 Nov 2014 10:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KAlyoRHE2bw for ; Wed, 26 Nov 2014 10:04:32 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCF31A017C for ; Wed, 26 Nov 2014 10:04:31 -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 sAQI4QVl013835; Wed, 26 Nov 2014 19:04:26 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 190E220C649; Wed, 26 Nov 2014 19:05:06 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0ACB820C596; Wed, 26 Nov 2014 19:05:06 +0100 (CET) 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 sAQI40Lc002234; Wed, 26 Nov 2014 19:04:26 +0100 Message-ID: <54761610.50304@gmail.com> Date: Wed, 26 Nov 2014 19:04:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rex Buddenberg References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> In-Reply-To: <1416854195.1923.146.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/dSD-sa5JO864HlsTR8CEK1832HA Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:04:35 -0000 Le 24/11/2014 19:36, Rex Buddenberg a écrit : [...] > 3. Layer 3 security is applied to datagrams. This is what the ID in > 6MAN is doing. The scope of security is enclave as in VPN. (Enclaves > do not include end systems). The chief payoff in layer 3 security is > that you can mix multiple wide area networking needs into a single > infrastructure -- each community can have an enclave to itself. Right. The protection afforded by ESP and AH headers to the DO header (containing geo coordinates) is as high, flexible and measured as any protection at layers 4 and 5 (SSL). Whereas one _may_ worry about the privacy risks induced by the IP source address being always in-clear in the base header, the same worry does not apply to something that is in the DO header. This is why I do not understand the security worries for comments of this draft. [...] > Layer 6-7 protection is end-to-end -- from end system to end system, And Layer 3 security is also end-system to end-system. > wholly agnostic about the networking infrastructure. Because it > protects the data, layer 6-7 protection can protect data at rest > (e.g. on a flash or disk drive) just as easily as over the > internetwork. So it's not only end-system to end-system, but > _through_ end systems as well, partially protecting the data against > possible malware in an end system. E-mail, with S/MIME protections, > is the most ubiquitous example of layer 6-7 protections. > > > This exchange is correct; it makes, IMHO, even better sense when you > apply the scope of security reasoning: >> I agree with this draft's point. The location information is a >> good hint for routing convergence. When most core links have >> similar speeds, better connect to the closer router. Router >> location is also good for a tie breaker when two destination have >> equal costs. >> >>> All the others involved sending source location to >>> destination(s) > and >>> that's NOT a layer 3 problem. > > > Geographic information is exchanged in organized form by several > internet applications: >> Third, other agreed non-IP networking layers already exchange >> geo-location information - are these net layers or app layers? >> > > SNMP, for example, contains a location variable in the MIB. It's > only defined as a string right now but it's a space where an > administrator can say 'this gadget is installed in the 4th floor > wiring closet'. You could certainly encode a Lat/Lon/Alt chunk of > data in the space. SNMP is an application -- layer 7. So the scope > of the SNNP (v3) security measures is indeed end-to-end. PAWS, which > I've mentioned before on [its] also is an application. Layer 6-7. > It's Lat/Lon/Alt information is therefore at app layer. I think there are different uses of Lat/Lon/Alt information that need different placement in layers. Browsing webpage to see an object location is typical example of putting coordinates in app layer. It is good for certain uses like fleet management. But, there are some cases where this app-layer geo-localisation is not enough, or sometimes plain wrong - 'inaccurate' would say some. It is especially wrong when associations between the IP address and any form of 'localization'. This is immediately obvious when trying any of the following: - type 'where am I' in a browser to be told the other side of the Earth. - VPN into a gateway to escape local rules to get access to content (youtube content not available in your country). - take a long-distance train or plane and be told you're still in the country of origin. [...] > You've commented that wiretapping layer 3 geo information for layer 7 > application purposes would be a layer violation. That is most > certainly correct. But what are the consequences of a layer > violation? 1. The longer term consequence is that this disrupts the > organization of the internet with downstream negatives regarding > interoperability and flexibility. While true, this is a hard > argument to sell to a guy with a screwdriver in his hand. 2. The > more telling argument is the security scope one. Layer violations > provide vectors for penetrating security. Because the layer > violation always increases the scope of vulnerability. But we have IP layer security which works fine. I dont understand where would be the risks? Geo-coordinates in the IP layer would be protected by IP layer security, no violation, no new risk. Alex > > > > Help?? > > > > > On Mon, 2014-11-24 at 12:12 +0100, Alexandru Petrescu wrote: >> Richard, >> >> Le 15/11/2014 01:33, Richard Roy a écrit : >>> My initial comment on the draft is that the concept of a >>> destination options field is inappropriate and opens security >>> holes and creates a possible attack vector needlessly. >> >> But (1) a DO header must not be examined by intermediary routers, >> by definition, and (2) if the end node feels at risk, the >> Destinations Options (DO) header may be put after an Encapsulation >> Security Payload (ESP) header, and as such be hidden from unwanted >> scrutiny. >> >>> The destination of a packet is by definition a place where the >>> ADU is parsed/consumed. Any information intended only for the >>> destination should be carried ONLY in the ADU, not in any lower >>> layer PDU. Hence, the concept of "destination options" at a >>> lower layer (i.e. the network layer) amounts to a layer >>> violation. >> >> YEs, layer violation may be what can happen. >> >> But in more detail, there are already many details in the >> networking layer that may differentiate it from layer violation - >> most extension headers carry info which may qualify as app by >> some, but are qualified as networking by others. >> >> Another indication that Geo-information may be fit in the >> networking layer is in the popular net analyzer Wireshark showing >> Source GeoIP and Destination GeoIP in all packets displayed, even >> if unknown. >> >>> The ONLY reason to carry GEO information in a layer 3 header is >>> that there are layer 3 processes/functions that require or will >>> make use of that information. If the information is only useful >>> at the destination, then the information belongs in a layer 4 >>> header or higher up the stack. >> >> I agree. >> >> But the location information itselfy can qualify as more app-layer >> or more 'net'-layer. I live on the 4th floor - that is the >> app-layer of saying location; I live at 2/49/WGS48 is more of a >> 'net'-layer. >> >> Second, the app layers are less reliable than the 'net'-layer. An >> UDP userspace application sending the GPS coordinates can crash at >> any time and as such track is lost of some object. On another >> hand, same data sent by the IP stack in the kernel as much less >> chances to crash - the kernel is much more reliable and less >> latency than the userspace space apps. It can be made even real >> time (rely on tangible hw features), whereas apps are hard to make >> real time. > >>> Since the document claims that "This document seeks to specify a >>> method for including the geolocation data in the IPv6 >>> Destination Options header", it clearly seems to be focused on >>> peer-to-peer exchange of GEO information. This is more safely >>> accomplished at layers above the network layer. Note that the >>> ONLY example given of an application involving layer 3 >>> functionality was >>> >>> "Convergence of dynamic routing protocols in a wide variety of >>> mobile networks can benefit greatly from knowledge of the >>> geographical locations of prospective neighbors. This >>> information is best conveyed in the headers of IPv6 packets used >>> for routing protocol control message exchanges." >> >> I agree with this draft's point. The location information is a >> good hint for routing convergence. When most core links have >> similar speeds, better connect to the closer router. Router >> location is also good for a tie breaker when two destination have >> equal costs. >> >>> All the others involved sending source location to >>> destination(s) and that's NOT a layer 3 problem. >>> >>> Finally, the issue of coordinate systems was not addressed >>> properly. It's implied by the description in the text that WGS84 >>> is used, however, this system is subject to update and change. IF >>> the IETF is going to include GEO info in it's headers, there must >>> be a field with sufficient size to encode the coordinate system >>> that is being used and which version thereof. >> >> I agree. >> >>> Furthermore, the issue of uncertainly (estimate error covariance >>> really) was not addressed. All GEO locations are "estimates" >>> and are realizations of a vector random process that has an >>> associated MD PDF. The ability to also communicate other than >>> jus the zeroth order moment (i.e., the mean) is often important! >> >> I agree. >> >> Alex >> >>> >>> RR >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>> November 12, 2014 8:19 PM To: its@ietf.org Subject: >>>> [geonet/its] Presentation of draft about geolocation in IPv6 >>>> headers - 6MAN Working Group >>>> >>>> Hello, >>>> >>>> Friday morning there will be a presentation about using >>>> geolocation information in IPv6 headers, in the 6man Working >>>> Group. >>>> https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html >>>> >>>> The draft is >>>> http://tools.ietf.org/html/draft-skeen-6man-ipv6geo >>>> >>>> What do you think about this draft? >>>> >>>> Alex >>>> >>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > From nobody Wed Nov 26 10:30:48 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1231A1B34 for ; Wed, 26 Nov 2014 10:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svQgHmM7ydjJ for ; Wed, 26 Nov 2014 10:30:40 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07F01A1B3E for ; Wed, 26 Nov 2014 10:30:40 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id eu11so3317704pac.8 for ; Wed, 26 Nov 2014 10:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=8qjyVWrLYQF7m0vHCzFfyoIf81C7AfiWAwbwXthIS0c=; b=p7W7EkWUal7KyE5T3A/Prg2c5cVaGtUqAeVyub8IB89Nj9WLXKhTfaLSstLvaTmPRT Ac4mp6cOJtsxooJV2RTB8JW6/AN8UykhSOhYvIU1CJDbRaLITkDbxsCqGM16R9ijjwVW TX2DgJerLHTSRWZwKdCIJcnt4IzxlFPI5vY2MW5BxDQD4iYzjYjIjCvBrtU71wmBDsJu bMbxMu23hzCdwPEqKsg80oW6J14yioitDAjHWY83Z7+ZyEuLcrjZVDk9QUwwZI8KDx4T D3QS5L2dwH/PlxtJvqaNeLn3j0i0EfZZb80FnAJfDnHWXwU3wrA6UXLPwcZuCXmhdIHG m8Og== X-Received: by 10.70.100.199 with SMTP id fa7mr56287310pdb.114.1417026639676; Wed, 26 Nov 2014 10:30:39 -0800 (PST) Received: from [192.168.1.103] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id oq6sm4956774pdb.45.2014.11.26.10.30.38 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 26 Nov 2014 10:30:39 -0800 (PST) Message-ID: <1417026637.1923.198.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandru Petrescu Date: Wed, 26 Nov 2014 10:30:37 -0800 In-Reply-To: <54761610.50304@gmail.com> References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> <54761610.50304@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/JFWlr1vlrZCPBGmaUO0aFjagf28 Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:30:44 -0000 On Wed, 2014-11-26 at 19:04 +0100, Alexandru Petrescu wrote: > > > Layer 6-7 protection is end-to-end -- from end system to end system, > > And Layer 3 security is also end-system to end-system. No no no, not true. Layer 3 security covers a network enclave. From the point where the IP datagram is encrypted and inserted into a wrapper datagram. In classical VPNs, this was done by a specialized box. So you had a red LAN outboard of the box. DoD boxes that do this were called TACLANEs. You can push the enclave toward the end system by putting the VPN encapsulation function in the I/O services of the end system operating system but that's not a topological shift -- the data is still en claire outboard of the VPN function (including all of the end system). To expand the scope of security, you have to move to higher layers. From nobody Thu Nov 27 02:26:07 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860FA1A88C7 for ; Thu, 27 Nov 2014 02:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA-88lW2-ad8 for ; Thu, 27 Nov 2014 02:26:02 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB4A1A88BD for ; Thu, 27 Nov 2014 02:26:02 -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 sARAPvvK023853; Thu, 27 Nov 2014 11:25:57 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E0122201735; Thu, 27 Nov 2014 11:26:37 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D20ED203C08; Thu, 27 Nov 2014 11:26:37 +0100 (CET) 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 sARAOgjk013546; Thu, 27 Nov 2014 11:25:57 +0100 Message-ID: <5476FBE9.7050101@gmail.com> Date: Thu, 27 Nov 2014 11:24:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rex Buddenberg References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> <54761610.50304@gmail.com> <1417026637.1923.198.camel@localhost.localdomain> In-Reply-To: <1417026637.1923.198.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/MQXN_5zG3Qkqr6fS4i_T2bKFEmU Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 10:26:04 -0000 Le 26/11/2014 19:30, Rex Buddenberg a écrit : > On Wed, 2014-11-26 at 19:04 +0100, Alexandru Petrescu wrote: >> >>> Layer 6-7 protection is end-to-end -- from end system to end system, >> >> And Layer 3 security is also end-system to end-system. > > No no no, not true. > > Layer 3 security covers a network enclave. From the point where the IP > datagram is encrypted and inserted into a wrapper datagram. > In classical VPNs, this was done by a specialized box. So you had a > red LAN outboard of the box. DoD boxes that do this were called > TACLANEs. You can push the enclave toward the end system by putting the > VPN encapsulation function in the I/O services of the end system > operating system but that's not a topological shift -- the data is still > en claire outboard of the VPN function (including all of the end > system). > To expand the scope of security, you have to move to higher layers. I agree considering VPN-on-gateway-and-client to not be end-to-end security. Because the Gateway encaps/decaps and forwards out of it -- a box in the middle. As when accessing an enterprise network from a remote location. On another hand IPsec is not necessarily VPN. IPsec can be executed on a client and a server, in the same manner as when using https for e-commerce or banking. In that sense, it happens on each end, no intermediary boxes. There is end-to-end IPsec, for example, between a Mobile Host and its Home Agent. A ping can be protected by IPsec as well. Another difference is that 'VPN' includes a set of message exchanges to establish keys in a dynamic manner and then use IPsec. IPsec is just message formats, and a bit of local crypto. Alex From nobody Thu Nov 27 11:03:49 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098DC1A013B for ; Thu, 27 Nov 2014 11:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh06WDVaMfVW for ; Thu, 27 Nov 2014 11:03:46 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19FB1A00E9 for ; Thu, 27 Nov 2014 11:03:45 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id y13so5370279pdi.3 for ; Thu, 27 Nov 2014 11:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=63FEnKVthC6Y+8Nm0BdjOxRJeTdv92MhMiyk6ODkblY=; b=NWWDm9MerSvwb0OTfZ3rEesuLW5J841oZVMoHzNzyo6tz0TOLvYH32a0I9r1oMajct w1mgJK5+YMsXy9UUOeIj8ODPVp8g2zFQv5rq8HibbI5aTCYp0Iw8oFd0tAD000xpuH1b TEc97tWYV41poAcqXQ8s2d2RjJ2JesHNrerGZCZgk/ebOKdfzTMDBSXKcuT+2frwqx2c QNfM8MnJeDabOfvPbPbiLMLLX6l9wNtvy5gnOyrKc97kK7IXORNQDmGOxUpOYKmMy6nP q8FJR5ed/g/zhv/4fiCsPjA1xD/SR3Rx5idktWE/258Y2jtYbklA43Gkfvru1cI1ni8N J/DQ== X-Received: by 10.66.253.230 with SMTP id ad6mr66139540pad.85.1417115025176; Thu, 27 Nov 2014 11:03:45 -0800 (PST) Received: from [192.168.1.105] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id d8sm7810528pdm.27.2014.11.27.11.03.43 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 11:03:44 -0800 (PST) Message-ID: <1417115022.1923.212.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandru Petrescu Date: Thu, 27 Nov 2014 11:03:42 -0800 In-Reply-To: <5476FBE9.7050101@gmail.com> References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> <54761610.50304@gmail.com> <1417026637.1923.198.camel@localhost.localdomain> <5476FBE9.7050101@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/qx78eFcx2RF8tYRfO9GMDViDKDQ Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:03:48 -0000 Still not getting it, Alex. On Thu, 2014-11-27 at 11:24 +0100, Alexandru Petrescu wrote: > Le 26/11/2014 19:30, Rex Buddenberg a écrit : > > On Wed, 2014-11-26 at 19:04 +0100, Alexandru Petrescu wrote: > >> > >>> Layer 6-7 protection is end-to-end -- from end system to end system, > >> > >> And Layer 3 security is also end-system to end-system. > > > > No no no, not true. > > > > Layer 3 security covers a network enclave. From the point where the IP > > datagram is encrypted and inserted into a wrapper datagram. > > In classical VPNs, this was done by a specialized box. So you had a > > red LAN outboard of the box. DoD boxes that do this were called > > TACLANEs. You can push the enclave toward the end system by putting the > > VPN encapsulation function in the I/O services of the end system > > operating system but that's not a topological shift -- the data is still > > en claire outboard of the VPN function (including all of the end > > system). > > To expand the scope of security, you have to move to higher layers. > > I agree considering VPN-on-gateway-and-client to not be end-to-end > security. Because the Gateway encaps/decaps and forwards out of it -- a > box in the middle. As when accessing an enterprise network from a > remote location. > > On another hand IPsec is not necessarily VPN. Yes it is. The term IPsec is associated with IPv6 and the mechanism is slightly different than in IPv4. But the terms tunneling, encapsulation, VPN and IPSec mean more or less the same thing. > IPsec can be executed on > a client and a server, in the same manner as when using https for > e-commerce or banking. This is correct. (https is the implementation of Secure Sockets Layer or, renamed, Transport Layer Security. The difference between TLS and VPN is that a VPN protects and enclave and TLS protects a connection. Both, of course, can be used. But neither are end to end as both can terminate no later than at the I/O socket of each end system. > In that sense, it happens on each end, no > intermediary boxes. There is end-to-end IPsec, for example, between a > Mobile Host and its Home Agent. No there is not. The scope of security is from the IPSec encypher to the IPSec decypher which is always in the networking socket of the operating system. So the data has no protection from IPSec (or IPv4 VPN) within the OSs. > A ping can be protected by IPsec as well. True. A ping is simply an ICMP echo request which fits inside a datagram. Datagrams are what VPNs protect. (The diff is that in IPv4, a separate RFC defines Internet Control Message Protocol; in IPv6 this stuff is rolled into the IPv6 documentation rather than as a separate RFC.) > > Another difference is that 'VPN' includes a set of message exchanges to > establish keys in a dynamic manner and then use IPsec. Whatever the layer that protection is implemented, there has to be some peer-peer agreement on keys. There are, of course, multiple ways to exchange keys, both in and out of band. But this is not relevant to understanding the scope of security. > IPsec is just > message formats, and a bit of local crypto. Well, no. IPv4 tunneling grew up outside of the standardization process. Which meant that there were (and are) a variety of different VPN systems (usually brand specific). These are all _compatible_ (datagrams are datagrams and they all get handled by routers the same way) meaning you can accommodate an indefinite number of VPNs over a routed communications infrastructure. But they are not _interoperable_ without some agreement on elements (especially key control and distribution). When the IPng working group reworked the system, they absorbed the lessons of IPv4 VPNs and included IPSec (IP security -- it tells you the scope right in the title) in he IPv6 RFCs. The point to remember is that neither IPsec (layer 3) or TLS (layer 4-5) provide any protection within the operating systems of end systems. (Gateways included). > > Alex > > > From nobody Fri Nov 28 06:00:04 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799011A1B0A for ; Fri, 28 Nov 2014 06:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4oCdRO32-O6 for ; Fri, 28 Nov 2014 05:59:57 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198EB1A1B26 for ; Fri, 28 Nov 2014 05:59: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 sASDxqJm004422; Fri, 28 Nov 2014 14:59:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 88E6C2042D6; Fri, 28 Nov 2014 15:00:34 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B2352042C4; Fri, 28 Nov 2014 15:00:34 +0100 (CET) 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 sASDxSuj021553; Fri, 28 Nov 2014 14:59:52 +0100 Message-ID: <54787FC0.5000202@gmail.com> Date: Fri, 28 Nov 2014 14:59:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rex Buddenberg References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> <54761610.50304@gmail.com> <1417026637.1923.198.camel@localhost.localdomain> <5476FBE9.7050101@gmail.com> <1417115022.1923.212.camel@localhost.localdomain> In-Reply-To: <1417115022.1923.212.camel@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/6_ly8uEK5xR9zU4tE1srjrJPPBA Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 14:00:02 -0000 Le 27/11/2014 20:03, Rex Buddenberg a écrit : > Still not getting it, Alex. > [...] >> Another difference is that 'VPN' includes a set of message exchanges to >> establish keys in a dynamic manner and then use IPsec. > > Whatever the layer that protection is implemented, there has to be some > peer-peer agreement on keys. There are, of course, multiple ways to > exchange keys, both in and out of band. But this is not relevant to > understanding the scope of security. Based on this argumentation, can we draw that wherever one's geo-position data is placed (at the IP layer in a Destination Options header, or at the app layer in a https payload), there are several means such as VPN or IPsec to protect it against undesirable inspection - to respect one's privacy. Am I correct? Alex > >> IPsec is just >> message formats, and a bit of local crypto. > > Well, no. IPv4 tunneling grew up outside of the standardization > process. Which meant that there were (and are) a variety of different > VPN systems (usually brand specific). These are all _compatible_ > (datagrams are datagrams and they all get handled by routers the same > way) meaning you can accommodate an indefinite number of VPNs over a > routed communications infrastructure. But they are not _interoperable_ > without some agreement on elements (especially key control and > distribution). When the IPng working group reworked the system, they > absorbed the lessons of IPv4 VPNs and included IPSec (IP security -- it > tells you the scope right in the title) in he IPv6 RFCs. > > The point to remember is that neither IPsec (layer 3) or TLS (layer 4-5) > provide any protection within the operating systems of end systems. > (Gateways included). > > >> >> Alex >> >> >> > > > > From nobody Fri Nov 28 09:45:43 2014 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000761A0099 for ; Fri, 28 Nov 2014 09:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3aYQSi1vcqd for ; Fri, 28 Nov 2014 09:45:40 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B7EF1A002F for ; Fri, 28 Nov 2014 09:45:40 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id kq14so7152075pab.12 for ; Fri, 28 Nov 2014 09:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=EIpDd9agyeijKNVMh8xMFZNDigL5GE5UHmvAT0iA6Lw=; b=HFyX7Yv5YMJg3i9KjfnqdFqTYlah1jOCrVHsIgqrOY52M9TRWj30tNfOEinQIxc0cS SoMNaPUJgiWHGqeak1Vkr2C2E0RVcIkkDEv76unz/5J1R3fu/LzfMqJta4K3JLv2xC42 kV73G/Gbq3uFgiC1iXIjkw2YnZ9QGvDtJN+oVIxJMIG0gkhbX0fa4SOp/9QnsqtxAAek Fc2tP4OWtLMlVr0QnHDsSbhvz7xAtExCiHzLU7OY7tbWJbpc2VhkXNVadwtv0xdi+mK9 e/G/Z2BYRqOU4r+sPvn1FGanrkVkirFb2XAglSCMSH95e69hKgbq/ixzDwEo/QtyWvox YERg== X-Received: by 10.68.102.5 with SMTP id fk5mr73929164pbb.136.1417196739750; Fri, 28 Nov 2014 09:45:39 -0800 (PST) Received: from [192.168.1.105] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id k4sm10424818pbq.74.2014.11.28.09.45.38 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Fri, 28 Nov 2014 09:45:39 -0800 (PST) Message-ID: <1417196737.1923.218.camel@localhost.localdomain> From: Rex Buddenberg To: Alexandru Petrescu Date: Fri, 28 Nov 2014 09:45:37 -0800 In-Reply-To: <54787FC0.5000202@gmail.com> References: <54643126.7080806@gmail.com> <547312BA.70201@gmail.com> <1416854195.1923.146.camel@localhost.localdomain> <54761610.50304@gmail.com> <1417026637.1923.198.camel@localhost.localdomain> <5476FBE9.7050101@gmail.com> <1417115022.1923.212.camel@localhost.localdomain> <54787FC0.5000202@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/its/vW0Zl_PEWgFtnYTZS4H_i2T6P1Q Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "GeoNet BoF discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 17:45:42 -0000 On Fri, 2014-11-28 at 14:59 +0100, Alexandru Petrescu wrote: > Le 27/11/2014 20:03, Rex Buddenberg a écrit : > > Still not getting it, Alex. > > > [...] > >> Another difference is that 'VPN' includes a set of message exchanges to > >> establish keys in a dynamic manner and then use IPsec. > > > > Whatever the layer that protection is implemented, there has to be some > > peer-peer agreement on keys. There are, of course, multiple ways to > > exchange keys, both in and out of band. But this is not relevant to > > understanding the scope of security. > > Based on this argumentation, can we draw that wherever one's > geo-position data is placed (at the IP layer in a Destination Options > header, or at the app layer in a https payload), there are several means > such as VPN or IPsec to protect it against undesirable inspection - to > respect one's privacy. > > Am I correct? You could put a chunk of metadata in a header at layers 2,3,4 and 7. (Implementation is harder in some than others, but you could). The problem, as I've tried to illustrate, is that you need to match the availability of the data to the scope of the security. If you embed the geo data at layers 2, 3, or 4 then you commit a layer violation (which equals a security compromise vector) if you want the data to be visible at layer 7. If you want the data to be (securely) visible at layer 7 then you need to put it in a layer 7 vehicle, not a layer 3 one. If, on the other hand, you want the geo data to be visible at layer 3 (for routing decisions, presumably) then the approach of using IP datagram header extensions is a feasible one. This is why I was asking what application you're after. > > Alex > > > > >> IPsec is just > >> message formats, and a bit of local crypto. > > > > Well, no. IPv4 tunneling grew up outside of the standardization > > process. Which meant that there were (and are) a variety of different > > VPN systems (usually brand specific). These are all _compatible_ > > (datagrams are datagrams and they all get handled by routers the same > > way) meaning you can accommodate an indefinite number of VPNs over a > > routed communications infrastructure. But they are not _interoperable_ > > without some agreement on elements (especially key control and > > distribution). When the IPng working group reworked the system, they > > absorbed the lessons of IPv4 VPNs and included IPSec (IP security -- it > > tells you the scope right in the title) in he IPv6 RFCs. > > > > The point to remember is that neither IPsec (layer 3) or TLS (layer 4-5) > > provide any protection within the operating systems of end systems. > > (Gateways included). > > > > > >> > >> Alex > >> > >> > >> > > > > > > > > > >