From alexandru.petrescu@gmail.com Mon Jul 1 10:09:47 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8F11E823A for ; Mon, 1 Jul 2013 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuAais7Rx2UL for ; Mon, 1 Jul 2013 10:09:40 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id A74A911E81FD for ; Mon, 1 Jul 2013 10:09:36 -0700 (PDT) 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 r61H9Zki013388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Jul 2013 19:09:35 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r61H9Y9B010339 for ; Mon, 1 Jul 2013 19:09:35 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.16]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r61H9QWt004556 for ; Mon, 1 Jul 2013 19:09:30 +0200 Message-ID: <51D1B7C5.805@gmail.com> Date: Mon, 01 Jul 2013 19:09:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:09:47 -0000 Hi, I would like to plan for a bar BoF ITS in Berlin. What do you think about Monday evening after the Technical Plenary? Alex From lear@cisco.com Mon Jul 1 10:14:06 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBB821F9E39 for ; Mon, 1 Jul 2013 10:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.3 X-Spam-Level: X-Spam-Status: No, score=-110.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWom6DhMT77M for ; Mon, 1 Jul 2013 10:14:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 289D821F9A00 for ; Mon, 1 Jul 2013 10:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=383; q=dns/txt; s=iport; t=1372698837; x=1373908437; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SEPwVOaro4qExVdZVfiYvcndGv4ZFhMJnAbWIMvVGrc=; b=GiDqsct/b2y8I6OBPzE0QsSYIZKzFLiIWdnSlpXFNSIl6K7jHnupfzEZ B1O+7HjjUwkAWmBdz43DpGmO1xoUqN+5XuSSmAwK7+sbbjEgdXcDXrBKX osYP/MflJARTQpgFg8D0z9yUUqRRe24XFSIs7FM/d5urVpZ1WXAlXbR6u o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugKABa30VGQ/khL/2dsb2JhbABagwmEArwKAQMBAwF/FnSCIwEBAQQjVhALGAICBSECAg8CLBoGDQEHAQGIC6sjkQiBJo44B4JRgRYDl0iRRYMTOg X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="83835982" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Jul 2013 17:13:52 +0000 Received: from mctiny.local ([10.61.211.26]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r61HDoVU022475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 17:13:51 GMT Message-ID: <51D1B8CE.10808@cisco.com> Date: Mon, 01 Jul 2013 19:13:50 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexandru Petrescu References: <51D1B7C5.805@gmail.com> In-Reply-To: <51D1B7C5.805@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "its@ietf.org" Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:14:06 -0000 Hi Alex, On 7/1/13 7:09 PM, Alexandru Petrescu wrote: > Hi, > > I would like to plan for a bar BoF ITS in Berlin. > > What do you think about Monday evening after the Technical Plenary? Thank you for moving forward on this. I've said I would participate in such a discussion. That time works for me as would others, as long as we can settle on them quickly. Eliot From garmitage@swin.edu.au Mon Jul 1 20:57:53 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF73011E83B2 for ; Mon, 1 Jul 2013 20:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS0MODLKP55b for ; Mon, 1 Jul 2013 20:57:49 -0700 (PDT) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by ietfa.amsl.com (Postfix) with ESMTP id CA91A11E83A3 for ; Mon, 1 Jul 2013 20:57:48 -0700 (PDT) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r623vW0d028502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 13:57:43 +1000 Message-ID: <51D24FAC.6070608@swin.edu.au> Date: Tue, 02 Jul 2013 13:57:32 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 03:57:54 -0000 On 7/1/13 7:09 PM, Alexandru Petrescu wrote: > Hi, > > I would like to plan for a bar BoF ITS in Berlin. > > What do you think about Monday evening after the Technical Plenary? Just joined the list to say my colleague (Nigel Williams) and I will try to join you at the bar BoF. We're exploring the possible use of multipath TCP in V2I contexts, so it isn't clear what we can contribute (given that MPTCP isn't mentioned in the BoF proposal document). But we're interested nevertheless. cheers, gja -- Professor Grenville Armitage Director, Centre for Advanced Internet Architectures Faculty of Information and Communication Technologies Swinburne University of Technology, Australia http://caia.swin.edu.au From alexandru.petrescu@gmail.com Wed Jul 3 09:44:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDAD11E81B2 for ; Wed, 3 Jul 2013 09:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leo+bCB2av01 for ; Wed, 3 Jul 2013 09:44:48 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 10C8611E80F2 for ; Wed, 3 Jul 2013 09:44:47 -0700 (PDT) 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 r63Gij16028227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 18:44:45 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r63GiiNQ002385; Wed, 3 Jul 2013 18:44:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r63GifHu006911; Wed, 3 Jul 2013 18:44:44 +0200 Message-ID: <51D454F9.1030509@gmail.com> Date: Wed, 03 Jul 2013 18:44:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Ivancic, William D. (GRC-RHN0)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Michael Richardson , Jong-Hyouk Lee , Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:44:54 -0000 I agree with this genericity aspect. The V2V scenario (IP webcam out a truck's windshield streams to all vehicles IP laptops nearby) could be written according to these 2 other situations: - communication between an IP device in a vehicle's network, and the IP device situated in a Station along the road. A speedcam Station contains among several IP devices one which requests speed data from the device in the vehicle passing by. - communication between the IP device in a WPAN and an IP device in a vehicles' network, according to a spacesuit scenario. This is one direction of scoping the work of a group. If we go this direction, we dont go the 2 other directions (IPv6-over-80211p, 'geo-' aspects). Alex Le 28/06/2013 15:07, Ivancic, William D. (GRC-RHN0) a écrit : > Agree. One bit of advices / history lesson. After the tcpsat > working group, I believe there was a lot of reluctance to establish > working groups at IETF to solve particular industry specific > problems. I certainly agree as generally problems that initially may > appear to be industry specific actually occur in many places. For > example in tcpsat the initial problem was how to get TCP to work > better over long delays. But, in reality, the problem is (delay x > bandwidth) and is certainly not unique to satellite communications. > > I guess the point I am trying to make is to think beyond ITS when > looking at the problem space so that any solutions are more general. > > -- Will > > > > > ------------------------------------------------------------------------ > > *From: *Jong-Hyouk Lee > *Date: *Thu, 27 Jun 2013 21:05:22 -0500 *To: *Alexandru Petrescu > *Cc: *Michael Richardson > , Jong-Hyouk Lee , > "its@ietf.org" *Subject: *Re: [its] Please select area > scoping the Charter > > Hi all, > > I support to have the topic "establishment of IP networking between > neighboring vehicles" that is one of essential requirements. But, I'm > willing to extend it. In other words, we should not limit it only to > vehicles. So, I suggest to revise the text as: > > "establishment of IP networking between neighboring nodes including > vehicles and infrastrcutures" > > > From alexandru.petrescu@gmail.com Wed Jul 3 09:47:12 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E75621F9D05 for ; Wed, 3 Jul 2013 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vwZ9P6HyVqH for ; Wed, 3 Jul 2013 09:47:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA111E81B2 for ; Wed, 3 Jul 2013 09:47:02 -0700 (PDT) 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 r63GkxmL012507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 18:46:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r63Gkwdg003765; Wed, 3 Jul 2013 18:46:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r63Gkw0W008473; Wed, 3 Jul 2013 18:46:58 +0200 Message-ID: <51D45582.4020405@gmail.com> Date: Wed, 03 Jul 2013 18:46:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Romain KUNTZ References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> <51CC604F.4030509@gmail.com> <526FF3FE-751D-4082-B069-768EF7CB5EAE@gmail.com> In-Reply-To: <526FF3FE-751D-4082-B069-768EF7CB5EAE@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Michael Richardson , "Romascanu, Dan \(Dan\)" , "its@ietf.org" , =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:47:12 -0000 Romain, thank you for the email. In this sense, do you think we should rather work on Mobile IPv6/80211p handover aspects, rather than on IPv6-over-80211p (and rather than working on V2V and 'geo-' aspects)? Alex Le 28/06/2013 09:51, Romain KUNTZ a écrit : > Hello, > > On Jun 27, 2013, at 17:54 , Alexandru Petrescu > wrote: >> Hi Francisco, >> >> Le 27/06/2013 17:20, Francisco Javier Ros Muñoz a écrit : >>> Hi Alex, >>> >>> El 27/06/2013, a las 16:55, Alexandru Petrescu escribió: >>>> There may be modifications to ICMP needed such that the >>>> movement detection procedure of Mobile IPv6 works ok on a >>>> non-BSSID channel (the 802.11p has no BSSID, hence no subnet >>>> structure). Currently this doesnt work because the UMIP >>>> software gets random behaviour when hearing two different >>>> prefixes on the same link (they are supposed to be 2 different >>>> links). >>> >>> This seems to be an implementation issue in uMIP, >> >> Has one seen this issue solved somehow? How can I get Mobile IPv6 >> handovers between two different 802.11p Access Points? > > This problem can be solved using the "MnRouterProbes" and > "MnRouterProbeTimeout" options of UMIP, which makes UMIP avoiding > switching to another router if the current one is still reachable. > This behaviour is disabled by default. More below (from the UMIP > manpage): > > > MnRouterProbes " "number" ";" > > Indicates how many times the MN should send Neighbor Unreachability > Detection (NUD) probes to its old router after receiving a Router > Advertisement (RA) from a new one. If the option is set to zero or > the new router advertises a strictly higher default preference value > than the old one (as defined in RFC 4191), the MN will move to the > new router straight away. > > Default: 0 > > > "MnRouterProbeTimeout " "decimal" ";" > > Indicates how long (in seconds) the MN should wait for a reply > during a access router Neighbor Unreachability Detection probe. If > set, it overrides any default Neighbor Solicitation Retransmit Timer > value greater than MnRouterProbeTimeout. For example, if the > interface Retransmit Timer is 1 second, but MnRouterProbeTimeout is > just 0.2 seconds, the MN will only wait 0.2 seconds for a Neighbor > Advertisement before proceeding with the handoff. > > Default: 0.0 > > >> What do you think? >> >> This may only be an implementation issue. Maybe largely >> identified within uMIP code. But it may be that this gets >> redirected to one other kind of issue: source-selection, multiple >> source address, multiple Care-of Address. It may be that uMIP >> people say that's a much larger issue than just Mobile IP, which >> uMIP excells at. >> >>> and not an 802.11p-specific problem. >> >> I tend to agree, it is largely a problem with multiple prefixes on >> the same link, not necessarily 802.11p. >> >> However, one may note that among all 802 wireless links the .11p is >> the only one which has no structure naturally leading to a subnet >> (no 'broadcast domain', no ESSID, no messages to create/delete such >> link, or to associate to one). This is so in purpose, of course, >> to realize very fast exchanges - avoid the need to first Associate >> to a network, and all 3 subsequent messages. >> >>> RFC 3775 warns us about such situation: >>> >>> o There might be multiple routers on the same link, thus hearing >>> a new router does not necessarily constitute an L3 handover. >> >> Right, and in that case there should exist a logic for a Host to >> choose between these links, and to determine whether a handover is >> really present or not. >> >> This logic has been implemented under various forms by various >> people. None is standard. > > I think this can be solved by performing NUD (which is standard) as > UMIP does. > > Best, Romain Kuntz (UMIP maintainer) > > >> There is also DNA. >> >>> o When there are multiple routers on the same link they might >>> advertise different prefixes. Thus even hearing a new router >>> with a new prefix might not be a reliable indication of an L3 >>> handover. >> >> That is right. RFC3775 warns about that situation. >> >> However, in a 802.11p deployment of RSUs (Road Side Unit), there >> are few constants: - there are no multiple prefixes on the same >> link. - each prefix is actually belonging to one particular RSU, >> and that particular RSU is in a different subnet. - hearing a >> different prefix means a different subnet. - there are no two same >> prefixes on the same subnet. >> >> The link-layer problem is that there is no link, one can't >> distinguish it. >> >> I suppose that this is also a reason why ETSI and earlier came up >> with GeoNetworking, because GPS data can help disambiguate >> (although it does not work when there is no GPS data). >> >> Alex >> >>> >>> Best, fran -- Francisco J. Ros, PhD Dept. of Information and >>> Communications Engineering University of Murcia, Murcia (Spain) >>> http://masimum.inf.um.es/fjrm/ >>> >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > From alexandru.petrescu@gmail.com Wed Jul 3 09:51:53 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AA911E81F6 for ; Wed, 3 Jul 2013 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0HVs55aC0Jv for ; Wed, 3 Jul 2013 09:51:43 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66B21F9D7D for ; Wed, 3 Jul 2013 09:51:32 -0700 (PDT) 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 r63GpQc9030865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jul 2013 18:51:26 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r63GpQHH006251; Wed, 3 Jul 2013 18:51:26 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r63GpPT4011068; Wed, 3 Jul 2013 18:51:26 +0200 Message-ID: <51D4568D.3080502@gmail.com> Date: Wed, 03 Jul 2013 18:51:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rex Buddenberg References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1372352848.1665.88.camel@localhost> In-Reply-To: <1372352848.1665.88.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:51:53 -0000 Le 27/06/2013 19:07, Rex Buddenberg a écrit : > On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote: >> and both consider IP is not about safety but rather entertainment. > > ??? This makes no sense. IP is about a set of communications > protocols. > > 'safety' usually implies some high availability requirements. There > are three principles of high availability engineering: > > - elimination of single points of failure. In comms systems this > usually boils down to altroutes and backup power. Provisioning > issue, has nothing to do with choices of technology ('IP' or > non-IP). > > - reliable crossover. In redundant systems the crossover switch > itself can become a single point of failure. And this is where IP > shines: routers do reliable crossover all day every day. I don't > know of any other comms technology that solves this problem by > protocol design or solves it as elegantly. > > - detection of failures as they occur. The function of a management > system, particularly fault management. SNMP is designed to do > exactly this (and a lot more). > > > Meet these principles for the most demanding applications (remember > that 'IP' is application-agnostic) and you have a super-solution for > everything else. Right, not to mention that IPv6 wouldn't need to run directly on a communication channel PHY, but rather over a MAC. The question then is whether that MAC is 802.11p, or 802.11p plus something else. Another question one is asked is whether it is reasonable to send 40bytes of IPv6 header, when that data is something short (4bytes) but important (heading of the vehicle approaching). Alex From william.d.ivancic@nasa.gov Wed Jul 3 09:57:27 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F70A11E8200 for ; Wed, 3 Jul 2013 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mb5tyUp3lJ6 for ; Wed, 3 Jul 2013 09:57:21 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::103]) by ietfa.amsl.com (Postfix) with ESMTP id 2C01911E81F9 for ; Wed, 3 Jul 2013 09:57:21 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (NDJSPPT104.ndc.nasa.gov [198.117.1.198]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 2910D2D8075; Wed, 3 Jul 2013 11:57:20 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r63GvJPT020576; Wed, 3 Jul 2013 11:57:19 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Wed, 3 Jul 2013 11:57:20 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Alexandru Petrescu , Rex Buddenberg Date: Wed, 3 Jul 2013 11:57:19 -0500 Thread-Topic: [its] Please select area scoping the Charter Thread-Index: Ac54DaF2Sb7VFHUpSIKTtivauS7qggAAL9je Message-ID: In-Reply-To: <51D4568D.3080502@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.11.0.110726 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-03_09:2013-07-03, 2013-07-03, 1970-01-01 signatures=0 Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:57:27 -0000 The question then is whether that MAC is 802.11p, or 802.11p plus > something else. Another question one is asked is whether it is reasonable to > send 40bytes of IPv6 header, when that data is something short (4bytes) > but important (heading of the vehicle The Aeronautical Telecommunication Network (ATN) protocols had similar questions. However, they were trying hard to save bits because the links were extremely bandwidth limited (8 kbps shared). But, there is a tendency to forget about security. I need to authenticate the message or it is wors= e than worthless, it can cause harm and make systems react to none-existent situations. - Will From alexandru.petrescu@gmail.com Wed Jul 3 10:02:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C73911E8214 for ; Wed, 3 Jul 2013 10:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQdWnDm8XRl2 for ; Wed, 3 Jul 2013 10:02:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id A54F311E8204 for ; Wed, 3 Jul 2013 10:02:44 -0700 (PDT) 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 r63H2hT9000323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Jul 2013 19:02:43 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r63H2hB7012732 for ; Wed, 3 Jul 2013 19:02:43 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r63H2e69027628 for ; Wed, 3 Jul 2013 19:02:43 +0200 Message-ID: <51D45930.7070504@gmail.com> Date: Wed, 03 Jul 2013 19:02:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Geo-networking and WiFi positioning X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:02:54 -0000 I agree, There several ways in which a vehicle may obtain its position in a cheap ways, one of them being GPS. There are others, as you relate to: - prebuilt maps of WiFi access points - maps of Cellular towers (once attached to one of them you'd know your position with a certain precision). - glonass - chinese, japanese satellite systems - small inertial central - visual light sensors detecting speed and direction, in the wheel or in the bottom of vehicle. To me, the issue here is to represent a position in an as generic as possible way. I doubt it would not possible to the extent that IP reachability requires. For example, IP needs to reach in corners of space which are not represented ('projected'?) in same ways. E.g. IP reaches at ocean depth but GPS doesnt reach it. And vice-versa: you have a GPS coordinate for each square millimeter of the Earth surface but you wouldn't have an IP-addressable device for each. That is a conceptual difficulty I have with geo- aspects. But warned: I am not a geo- expert. Alex Le 29/06/2013 21:55, Alison Chaiken a écrit : > Regarding loss of GPS signal in tunnels and cities, why not use WiFi > Positioning? Couldn't a vehicle know its position by triangulating > among different RSUs? Couldn't the last 32 or 64 positions be > cached? What problem is temporary loss of GPS connectivity going to > cause that we are trying to solve, anyway? > > Consider my car parked inside my garage overnight. Assuredly I > should be able to communicate with a router in my house securely. > Does geo-networking apply here? Should I have a second radio in > the car that talks in the 2.4 GHz band with a different 802.11 > protocol for this purpose? > > The other fascinating topic is over-the-air updates of vehicle > software. These have security concerns more akin to emergency > vehicles than to (gag) infotainment. I assume current vendors (Red > bend) and OEMs (Tesla) are using 3G right now for this purpose. > > On Thursday night I attended a panel discussion with Mercedes, QNX > (leading car software vendor), Pandora music service, and Gartner. > They talked about LTE and satellite communications, not 802.11p. > XM and Sirius are planning to expand their business models to include > non-broadcast data streams, apparently. GM has announced that it > plans to offer LTE across its whole fleet. Does 802.11p stand a > chance? Are we certain it will extend beyond simTD and SafetyPilot > trials? > > Happy weekend, Alison > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From mcr@sandelman.ca Wed Jul 3 10:07:36 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7F421F9C25 for ; Wed, 3 Jul 2013 10:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUQy7cM1yB2H for ; Wed, 3 Jul 2013 10:07:32 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 4C29521F9D4B for ; Wed, 3 Jul 2013 10:07:29 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B9F62017B; Wed, 3 Jul 2013 14:11:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CE3D763A88; Wed, 3 Jul 2013 13:06:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BFC9063A5E; Wed, 3 Jul 2013 13:06:12 -0400 (EDT) From: Michael Richardson To: "Ivancic, William D. (GRC-RHN0)" In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Rex Buddenberg , "Romascanu, Dan \(Dan\)" , Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:07:36 -0000 Ivancic, William D. (GRC-RHN0) wrote: > Another question one is asked is whether it is reasonable to > send > 40bytes of IPv6 header, when that data is something short (4bytes) > but > important (heading of the vehicle > The Aeronautical Telecommunication Network (ATN) protocols had similar > questions. However, they were trying hard to save bits because the > links were extremely bandwidth limited (8 kbps shared). But, there is > a tendency to forget about security. I need to authenticate the > message or it is worse than worthless, it can cause harm and make > systems react to none-existent situations. Once you include security and the need to identify senders and receivers, suddendly the 40 bytes doesn't seem like such a big deal. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From alexandru.petrescu@gmail.com Wed Jul 3 12:29:04 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9768D11E8202 for ; Wed, 3 Jul 2013 12:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id finIMaebzcjq for ; Wed, 3 Jul 2013 12:28:56 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3A11E81F9 for ; Wed, 3 Jul 2013 12:28:56 -0700 (PDT) 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 r63JStW8007274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Jul 2013 21:28:55 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r63JSsLP022390 for ; Wed, 3 Jul 2013 21:28:54 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.1]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r63JSsfU016941 for ; Wed, 3 Jul 2013 21:28:54 +0200 Message-ID: <51D47B75.9060000@gmail.com> Date: Wed, 03 Jul 2013 21:28:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "its@ietf.org" References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] Fwd: Draft submission deadlines change X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 19:29:04 -0000 Please submit drafts about ITS: Intelligent Transportation Systems, at IETF. The deadline is now July 15th, a change from the past. Alex -------- Message original -------- Sujet: Draft submission deadlines change Date : Tue, 2 Jul 2013 22:17:01 -0700 De : IETF Chair Répondre à : Pour : IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From r.kuntz@gmail.com Thu Jul 4 00:13:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120D521F9F07 for ; Thu, 4 Jul 2013 00:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIJT87m2enwr for ; Thu, 4 Jul 2013 00:13:53 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4821F9F02 for ; Thu, 4 Jul 2013 00:13:49 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so819582wes.3 for ; Thu, 04 Jul 2013 00:13:48 -0700 (PDT) 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:x-mailer; bh=C8my/O6qAlC3RuojVjeBOWnRfTIgN6NU4he02Hz/5PY=; b=BaPBOmJdiLtu3+VkFGszQ2c/d/UeJk+FxhUDd25lbkpQ1ksBzU9mBTw+zKKhyzSz8P vC6N/kv8OO/q2fI/0sYHL48aK1Qz41UBLWu7ERTi/1h/IwNUvi/cp3TWHLGxXpXp5B+l h2eSeUb9BNSWKvgPjXNGQ42scSElNxW3Q0taCkjty7GRrkvGxPcgO6qe+73jgAZsbIy6 DMZcdbvtSdTwq0Sb8ojNi1DFhP7r1UOR2bicuoUpFI6FXSmqQU7zv2gPwrvzxqIpzByo dmUFEkmEgnmTO/NmYFrAZivUZlHzjMLpVqEyx8IMXswT1ZgMtHYKYdcguAxhJ9gewgz6 TjpQ== X-Received: by 10.180.102.36 with SMTP id fl4mr2482487wib.45.1372922027412; Thu, 04 Jul 2013 00:13:47 -0700 (PDT) Received: from guest-rocq-134209.inria.fr (guest-rocq-134209.inria.fr. [128.93.134.209]) by mx.google.com with ESMTPSA id eu1sm32633707wib.8.2013.07.04.00.13.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 00:13:46 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Romain KUNTZ In-Reply-To: <51D45582.4020405@gmail.com> Date: Thu, 4 Jul 2013 09:13:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <487B3E50-75D5-462E-85F6-F80AE511CBC1@gmail.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1E2E8F27-5524-4B63-9DBB-DC265DF4C6BE@um.es> <51CC604F.4030509@gmail.com> <526FF3FE-751D-4082-B069-768EF7CB5EAE@gmail.com> <51D45582.4020405@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1508) Cc: its@ietf.org Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:13:54 -0000 Hello Alex, On Jul 3, 2013, at 18:46 , Alexandru Petrescu = wrote: > Romain, thank you for the email. >=20 > In this sense, do you think we should rather work on Mobile = IPv6/80211p > handover aspects, I don't think so, unless someone can point clear issues that arise when = MIPv6 is running over 802.11p. So far I do not see any, but I would be = happy to hear other's opinions. Best, Romain > rather than on IPv6-over-80211p (and rather than > working on V2V and 'geo-' aspects)? >=20 > Alex >=20 > Le 28/06/2013 09:51, Romain KUNTZ a =E9crit : >> Hello, >>=20 >> On Jun 27, 2013, at 17:54 , Alexandru Petrescu >> wrote: >>> Hi Francisco, >>>=20 >>> Le 27/06/2013 17:20, Francisco Javier Ros Mu=F1oz a =E9crit : >>>> Hi Alex, >>>>=20 >>>> El 27/06/2013, a las 16:55, Alexandru Petrescu escribi=F3: >>>>> There may be modifications to ICMP needed such that the >>>>> movement detection procedure of Mobile IPv6 works ok on a >>>>> non-BSSID channel (the 802.11p has no BSSID, hence no subnet >>>>> structure). Currently this doesnt work because the UMIP >>>>> software gets random behaviour when hearing two different >>>>> prefixes on the same link (they are supposed to be 2 different >>>>> links). >>>>=20 >>>> This seems to be an implementation issue in uMIP, >>>=20 >>> Has one seen this issue solved somehow? How can I get Mobile IPv6 >>> handovers between two different 802.11p Access Points? >>=20 >> This problem can be solved using the "MnRouterProbes" and >> "MnRouterProbeTimeout" options of UMIP, which makes UMIP avoiding >> switching to another router if the current one is still reachable. >> This behaviour is disabled by default. More below (from the UMIP >> manpage): >>=20 >>=20 >> MnRouterProbes " "number" ";" >>=20 >> Indicates how many times the MN should send Neighbor Unreachability >> Detection (NUD) probes to its old router after receiving a Router >> Advertisement (RA) from a new one. If the option is set to zero or >> the new router advertises a strictly higher default preference value >> than the old one (as defined in RFC 4191), the MN will move to the >> new router straight away. >>=20 >> Default: 0 >>=20 >>=20 >> "MnRouterProbeTimeout " "decimal" ";" >>=20 >> Indicates how long (in seconds) the MN should wait for a reply >> during a access router Neighbor Unreachability Detection probe. If >> set, it overrides any default Neighbor Solicitation Retransmit Timer >> value greater than MnRouterProbeTimeout. For example, if the >> interface Retransmit Timer is 1 second, but MnRouterProbeTimeout is >> just 0.2 seconds, the MN will only wait 0.2 seconds for a Neighbor >> Advertisement before proceeding with the handoff. >>=20 >> Default: 0.0 >>=20 >>=20 >>> What do you think? >>>=20 >>> This may only be an implementation issue. Maybe largely >>> identified within uMIP code. But it may be that this gets >>> redirected to one other kind of issue: source-selection, multiple >>> source address, multiple Care-of Address. It may be that uMIP >>> people say that's a much larger issue than just Mobile IP, which >>> uMIP excells at. >>>=20 >>>> and not an 802.11p-specific problem. >>>=20 >>> I tend to agree, it is largely a problem with multiple prefixes on >>> the same link, not necessarily 802.11p. >>>=20 >>> However, one may note that among all 802 wireless links the .11p is >>> the only one which has no structure naturally leading to a subnet >>> (no 'broadcast domain', no ESSID, no messages to create/delete such >>> link, or to associate to one). This is so in purpose, of course, >>> to realize very fast exchanges - avoid the need to first Associate >>> to a network, and all 3 subsequent messages. >>>=20 >>>> RFC 3775 warns us about such situation: >>>>=20 >>>> o There might be multiple routers on the same link, thus hearing >>>> a new router does not necessarily constitute an L3 handover. >>>=20 >>> Right, and in that case there should exist a logic for a Host to >>> choose between these links, and to determine whether a handover is >>> really present or not. >>>=20 >>> This logic has been implemented under various forms by various >>> people. None is standard. >>=20 >> I think this can be solved by performing NUD (which is standard) as >> UMIP does. >>=20 >> Best, Romain Kuntz (UMIP maintainer) >>=20 >>=20 >>> There is also DNA. >>>=20 >>>> o When there are multiple routers on the same link they might >>>> advertise different prefixes. Thus even hearing a new router >>>> with a new prefix might not be a reliable indication of an L3 >>>> handover. >>>=20 >>> That is right. RFC3775 warns about that situation. >>>=20 >>> However, in a 802.11p deployment of RSUs (Road Side Unit), there >>> are few constants: - there are no multiple prefixes on the same >>> link. - each prefix is actually belonging to one particular RSU, >>> and that particular RSU is in a different subnet. - hearing a >>> different prefix means a different subnet. - there are no two same >>> prefixes on the same subnet. >>>=20 >>> The link-layer problem is that there is no link, one can't >>> distinguish it. >>>=20 >>> I suppose that this is also a reason why ETSI and earlier came up >>> with GeoNetworking, because GPS data can help disambiguate >>> (although it does not work when there is no GPS data). >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Best, fran -- Francisco J. Ros, PhD Dept. of Information and >>>> Communications Engineering University of Murcia, Murcia (Spain) >>>> http://masimum.inf.um.es/fjrm/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >=20 >=20 From john.dowdell@cassidian.com Fri Jul 5 04:17:51 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9150C11E82A0 for ; Fri, 5 Jul 2013 04:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC4kpPv9JCfY for ; Fri, 5 Jul 2013 04:17:47 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF611E82A9 for ; Fri, 5 Jul 2013 04:17:44 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 05 Jul 2013 13:17:34 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 5 Jul 2013 13:17:33 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 13:17:33 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 13:17:33 +0200 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 12:17:32 +0100 From: "Dowdell, John" To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [its] Plan for bar BoF Monday after Technical Plenary? Thread-Index: AQHOdn3y+OqPonR9TkmXr2F5K9vPf5lV9NpA Date: Fri, 5 Jul 2013 11:17:32 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB09FF7C34@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.216.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jul 2013 11:17:33.0426 (UTC) FILETIME=[3EEC4520:01CE7971] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19994.005 X-TM-AS-Result: No--12.490900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 11:17:51 -0000 Alex I hope to be in town for the manet meeting, but will not arrive until Tuesd= ay. I wonder if given the overlap between its and manet, it would be worth = moving your BOF closer to the manet slot on Thursday. Regards John -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan for bar BoF Monday after Technical Plenary? Hi, I would like to plan for a bar BoF ITS in Berlin. What do you think about Monday evening after the Technical Plenary? Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From lear@cisco.com Fri Jul 5 04:24:17 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221A21F9476 for ; Fri, 5 Jul 2013 04:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNEHvhbj2uT5 for ; Fri, 5 Jul 2013 04:24:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 816F511E82AA for ; Fri, 5 Jul 2013 04:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1740; q=dns/txt; s=iport; t=1373023448; x=1374233048; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DpSjPtzfqoLvcLAgL90FufuXpNSNPlXtLFO9Wzg9Shw=; b=flCS8pf9OU5Hknbdn7IDXC+HF3Mq4cz3Gq0olc7SKryDYn9p90/bOQdM RJJY19br/I72bV+k4M18aXrAV6hR7Z3T2jBrIGOEsTHSrZv3VCzjfqHX9 5/ToLDq/+QA7KnZf8FFrdG0w8WybLhZr0muRJgZmtcDxSAiYS79pD4m5N M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAIKr1lGQ/khN/2dsb2JhbABagwkyg1G9KH8WdIIjAQEBBAEBASAyGQoBDAQLEQQBAQECAgUWCAMCAgkDAgECARUWCQkIBg0BBQIBAYgLDKdkkQeBJo0NBoEyBwaCS4EcA5dJkUWDEzqBLAkX X-IronPort-AV: E=Sophos;i="4.87,1001,1363132800"; d="scan'208";a="156216478" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Jul 2013 11:24:06 +0000 Received: from mctiny.local ([10.61.207.23]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r65BO4oA020540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 11:24:05 GMT Message-ID: <51D6ACD4.8020005@cisco.com> Date: Fri, 05 Jul 2013 13:24:04 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Dowdell, John" References: <603F5FD847B5174CBDA37A9DC00532FB09FF7C34@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB09FF7C34@SUCNPTEXM02.com.ad.uk.ds.corp> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 11:24:17 -0000 This woudn't kill me either. Eliot On 7/5/13 1:17 PM, Dowdell, John wrote: > Alex > > I hope to be in town for the manet meeting, but will not arrive until Tuesday. I wonder if given the overlap between its and manet, it would be worth moving your BOF closer to the manet slot on Thursday. > > Regards > John > > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: 01 July 2013 18:09 > To: its@ietf.org > Subject: [its] Plan for bar BoF Monday after Technical Plenary? > > Hi, > > I would like to plan for a bar BoF ITS in Berlin. > > What do you think about Monday evening after the Technical Plenary? > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Fri Jul 5 08:26:51 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CE811E812F for ; Fri, 5 Jul 2013 08:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq+xae6vnwu2 for ; Fri, 5 Jul 2013 08:26:46 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9F94711E8132 for ; Fri, 5 Jul 2013 08:26:43 -0700 (PDT) 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 r65FQdI9000831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Jul 2013 17:26:39 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r65FQdvJ030152; Fri, 5 Jul 2013 17:26:39 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.19]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r65FQVgD003955; Fri, 5 Jul 2013 17:26:39 +0200 Message-ID: <51D6E5A7.4070802@gmail.com> Date: Fri, 05 Jul 2013 17:26:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eliot Lear References: <603F5FD847B5174CBDA37A9DC00532FB09FF7C34@SUCNPTEXM02.com.ad.uk.ds.corp> <51D6ACD4.8020005@cisco.com> In-Reply-To: <51D6ACD4.8020005@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Dowdell, John" Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:26:51 -0000 manet is followed by 6lo meeting and then bits'n'bytes (demos, food) until 21h. Would 21h-22h bar BoF ITS work? Alex Le 05/07/2013 13:24, Eliot Lear a écrit : > This woudn't kill me either. > > Eliot > > On 7/5/13 1:17 PM, Dowdell, John wrote: >> Alex >> >> I hope to be in town for the manet meeting, but will not arrive >> until Tuesday. I wonder if given the overlap between its and manet, >> it would be worth moving your BOF closer to the manet slot on >> Thursday. >> >> Regards John >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan for bar BoF >> Monday after Technical Plenary? >> >> Hi, >> >> I would like to plan for a bar BoF ITS in Berlin. >> >> What do you think about Monday evening after the Technical >> Plenary? >> >> Alex >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its The >> information contained within this e-mail and any files attached to >> this e-mail is private and in addition may include commercially >> sensitive information. The contents of this e-mail are for the >> intended recipient only and therefore if you wish to disclose the >> information contained within this e-mail or attached files, please >> contact the sender prior to any such disclosure. If you are not the >> intended recipient, any disclosure, copying or distribution is >> prohibited. Please also contact the sender and inform them of the >> error and delete the e-mail, including any attached files from your >> system. Cassidian Limited, Registered Office : Quadrant House, >> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >> http://www.cassidian.com >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > From john.dowdell@cassidian.com Fri Jul 5 08:39:55 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9328111E8314 for ; Fri, 5 Jul 2013 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WylZx2WwybCe for ; Fri, 5 Jul 2013 08:39:51 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0562121F9FD9 for ; Fri, 5 Jul 2013 08:39:49 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet4.eads.net with ESMTP; 05 Jul 2013 17:39:47 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 5 Jul 2013 17:39:46 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 17:39:46 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 17:39:46 +0200 Received: from SUCNPTEXM02.COM.AD.UK.DS.CORP ([fe80::c1e:1167:8c94:a12e]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Fri, 5 Jul 2013 16:39:46 +0100 From: "Dowdell, John" To: "'alexandru.petrescu@gmail.com'" , "'lear@cisco.com'" Thread-Topic: [its] Plan for bar BoF Monday after Technical Plenary? Thread-Index: AQHOeZQG+OqPonR9TkmXr2F5K9vPf5lWOJZq Date: Fri, 5 Jul 2013 15:39:44 +0000 Message-ID: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.80.73.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jul 2013 15:39:46.0371 (UTC) FILETIME=[E07D2930:01CE7995] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19994.006 X-TM-AS-Result: No--25.029600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "'its@ietf.org'" Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:39:55 -0000 Alex Sounds good to me John John Dowdell Solution Architect, COEIC1 Cassidian Newport, UK Mobile +44 7710 875008 UAE desk +971 2 503 9017 ----- Original Message ----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, 2013 04:26 PM GMT Standard Time To: Eliot Lear Cc: Dowdell, John; its@ietf.org Subject: Re: [its] Plan for bar BoF Monday after Technical Plenary? manet is followed by 6lo meeting and then bits'n'bytes (demos, food) until 21h. Would 21h-22h bar BoF ITS work? Alex Le 05/07/2013 13:24, Eliot Lear a =E9crit : > This woudn't kill me either. > > Eliot > > On 7/5/13 1:17 PM, Dowdell, John wrote: >> Alex >> >> I hope to be in town for the manet meeting, but will not arrive >> until Tuesday. I wonder if given the overlap between its and manet, >> it would be worth moving your BOF closer to the manet slot on >> Thursday. >> >> Regards John >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan for bar BoF >> Monday after Technical Plenary? >> >> Hi, >> >> I would like to plan for a bar BoF ITS in Berlin. >> >> What do you think about Monday evening after the Technical >> Plenary? >> >> Alex >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its The >> information contained within this e-mail and any files attached to >> this e-mail is private and in addition may include commercially >> sensitive information. The contents of this e-mail are for the >> intended recipient only and therefore if you wish to disclose the >> information contained within this e-mail or attached files, please >> contact the sender prior to any such disclosure. If you are not the >> intended recipient, any disclosure, copying or distribution is >> prohibited. Please also contact the sender and inform them of the >> error and delete the e-mail, including any attached files from your >> system. Cassidian Limited, Registered Office : Quadrant House, >> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >> http://www.cassidian.com >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, = Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com From alexandru.petrescu@gmail.com Sat Jul 6 03:08:52 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC97121F9C0B for ; Sat, 6 Jul 2013 03:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGPd+JqTg0pp for ; Sat, 6 Jul 2013 03:08:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC821F9C08 for ; Sat, 6 Jul 2013 03:08:46 -0700 (PDT) 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 r66A8grW011432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Jul 2013 12:08:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r66A8gFV032552; Sat, 6 Jul 2013 12:08:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r66A8bEb030862; Sat, 6 Jul 2013 12:08:41 +0200 Message-ID: <51D7ECA4.8090104@gmail.com> Date: Sat, 06 Jul 2013 12:08:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Dowdell, John" References: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> In-Reply-To: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "'its@ietf.org'" , "'lear@cisco.com'" Subject: Re: [its] Plan for bar BoF? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 10:08:52 -0000 The date for ITS bar BoF is now: Thursday, August 1st 21h-22h I hope this fits, otherwise do not hesitate to object. Alex Le 05/07/2013 17:39, Dowdell, John a écrit : > Alex > > Sounds good to me > > John John Dowdell Solution Architect, COEIC1 Cassidian Newport, UK > Mobile +44 7710 875008 UAE desk +971 2 503 9017 > > ----- Original Message ----- From: Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, 2013 > 04:26 PM GMT Standard Time To: Eliot Lear Cc: > Dowdell, John; its@ietf.org Subject: Re: [its] Plan > for bar BoF Monday after Technical Plenary? > > manet is followed by 6lo meeting and then bits'n'bytes (demos, food) > until 21h. > > Would 21h-22h bar BoF ITS work? > > Alex > > Le 05/07/2013 13:24, Eliot Lear a écrit : >> This woudn't kill me either. >> >> Eliot >> >> On 7/5/13 1:17 PM, Dowdell, John wrote: >>> Alex >>> >>> I hope to be in town for the manet meeting, but will not arrive >>> until Tuesday. I wonder if given the overlap between its and >>> manet, it would be worth moving your BOF closer to the manet slot >>> on Thursday. >>> >>> Regards John >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>> Sent: 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan for >>> bar BoF Monday after Technical Plenary? >>> >>> Hi, >>> >>> I would like to plan for a bar BoF ITS in Berlin. >>> >>> What do you think about Monday evening after the Technical >>> Plenary? >>> >>> Alex >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its The >>> information contained within this e-mail and any files attached >>> to this e-mail is private and in addition may include >>> commercially sensitive information. The contents of this e-mail >>> are for the intended recipient only and therefore if you wish to >>> disclose the information contained within this e-mail or attached >>> files, please contact the sender prior to any such disclosure. If >>> you are not the intended recipient, any disclosure, copying or >>> distribution is prohibited. Please also contact the sender and >>> inform them of the error and delete the e-mail, including any >>> attached files from your system. Cassidian Limited, Registered >>> Office : Quadrant House, Celtic Springs, Coedkernew, Newport, >>> NP10 8FZ Company No: 04191036 http://www.cassidian.com >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> > > > The information contained within this e-mail and any files attached > to this e-mail is private and in addition may include commercially > sensitive information. The contents of this e-mail are for the > intended recipient only and therefore if you wish to disclose the > information contained within this e-mail or attached files, please > contact the sender prior to any such disclosure. If you are not the > intended recipient, any disclosure, copying or distribution is > prohibited. Please also contact the sender and inform them of the > error and delete the e-mail, including any attached files from your > system. Cassidian Limited, Registered Office : Quadrant House, Celtic > Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 > http://www.cassidian.com > > From Andreas.Festag@neclab.eu Thu Jul 11 01:04:35 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346E621F9E1E for ; Thu, 11 Jul 2013 01:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS5VF78lQJuu for ; Thu, 11 Jul 2013 01:04:31 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2F21F9E50 for ; Thu, 11 Jul 2013 01:04:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 84235104A4F; Thu, 11 Jul 2013 10:03:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXBicWgtBt16; Thu, 11 Jul 2013 10:03:46 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6904B104A43; Thu, 11 Jul 2013 10:03:36 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 11 Jul 2013 10:04:09 +0200 From: Andreas Festag To: Alexandru Petrescu , "its@ietf.org" Thread-Topic: [its] Please select area scoping the Charter Thread-Index: AQHOcbuFnDcZm+3/3UCAKto6qU9tp5lfNPJw Date: Thu, 11 Jul 2013 08:02:22 +0000 Message-ID: <21E46EE9B979354990401539FD0A63E517747F@DAPHNIS.office.hd> References: <51C9BBCC.1090304@gmail.com> In-Reply-To: <51C9BBCC.1090304@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:04:35 -0000 Dear Alex, Re the area scoping: - I think the 1st option is relevant and to be done, e.g. enabling cars to = discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over= GeoNetworking. - Option 3 sounds interesting, but I am not aware of a solution that can be= standardized right away. So, this would require some research and analysis= . Kind regards, Andreas -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Tuesday, June 25, 2013 5:48 PM To: its@ietf.org Subject: [its] Please select area scoping the Charter Hello participants to ITS email list, During recent discussions we mentioned 3 different areas to work on. They are too many for a meaningful detail work. Please select area scoping the Charter, prioritizing according to the envir= onment you work on. 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Yours, Alex _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From alison@she-devel.com Thu Jul 11 23:53:38 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0AA21F9F95 for ; Thu, 11 Jul 2013 23:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WPem0UKXSNi for ; Thu, 11 Jul 2013 23:53:34 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2F221F9E72 for ; Thu, 11 Jul 2013 23:53:34 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so7498964lab.0 for ; Thu, 11 Jul 2013 23:53:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=Y69xiC8FIt65hdGMpR6ELWlDcegLI5BJKLabC7hvigM=; b=CSTvH5R73sNHGd4BhovqbJmIWT808RSI+HdmGBbvFM/x0Qtey9zQWA1LBrTzK5OLmn GzHjsza9la5twqjVynQ4vqzMHwttFWsZe684ZkZm9lbdV7TRwc8qYzKWI/t+S+1BxyzY xMPPaAxLf0/aF8C6pSejrW1PxH86E8ah1zFuLzz8RNitMDbh9mBtqIRFli+oar6JinXo 0BTHQ3T9Xb1vh5cNaGYS5pLumkU88HRihmez8iB2hCbw8t7KkWujJ5leVTl4TGbDdUNK ryVdoTz4xIM0Hcf/wZGE97EaCZ8rDxyN5lFgP4wo6ENAxfspXLq3+gRwuLVkGwsFifsi suPQ== MIME-Version: 1.0 X-Received: by 10.112.130.37 with SMTP id ob5mr18706171lbb.77.1373612013105; Thu, 11 Jul 2013 23:53:33 -0700 (PDT) Received: by 10.112.201.194 with HTTP; Thu, 11 Jul 2013 23:53:32 -0700 (PDT) Date: Thu, 11 Jul 2013 23:53:32 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmdChF+NBHmCwhEe6Iryss02H7eVPoJBoffg0cgKQX7VNK1JHvKrtwE7E5aK3YZd5CD+cck Subject: [its] I.T.U. and United Nations Transport Division meet X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:53:39 -0000 http://qnxauto.blogspot.com/2013/07/un-agencies-take-major-step-towards.html -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From alexandru.petrescu@gmail.com Mon Jul 15 07:28:35 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4534121F9E97 for ; Mon, 15 Jul 2013 07:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k0RcDv55oMN for ; Mon, 15 Jul 2013 07:28:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9253411E8125 for ; Mon, 15 Jul 2013 07:28:12 -0700 (PDT) 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 r6FESAgI022101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Jul 2013 16:28:11 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6FESAOk010500 for ; Mon, 15 Jul 2013 16:28:10 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6FES9An008816 for ; Mon, 15 Jul 2013 16:28:10 +0200 Message-ID: <51E406F8.1050508@gmail.com> Date: Mon, 15 Jul 2013 16:28:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:28:35 -0000 Dirk, Any idea whether the results of this project use: - dynamic IPv6 prefix exchanges between vehicles, or between vehicle and infrastructure? - IPv6-straight-over-80211p? - any form of geonetworking? Thanks, Alex Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a écrit : > Hi all, > Speaking of actual use cases it may be of interest that the German project SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" has completed to test the functionality, efficacy and feasibility for everyday use of car-to-x communication under real-life driving conditions. Some detailed information can be found here: http://simtd.de/index.dhtml/0251caae465f8345005d/-/enEN/-/CS/-/ and > http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/8033/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf > > Best regards > Dirk > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg > Sent: Dienstag, 25. Juni 2013 05:19 > To: Michael Richardson > Cc: Alison Chaiken; its@ietf.org > Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration > > Michael, > > We might want to consider this the snowplow case; gets past some of your human factors issues. Try this as a variant to the ambulance/siren illustration. > > One of my friends and sounding board for such stuff works for Wyoming DoT. He observes that the casualty rate among snowplow operators in Wy is higher than among cops. The typical accident scenario is when the plow is working on I-80 and is overtaken by other traffic, the villain usually a semi. If the semi driver doesn't figure out that it is a snowplow ahead of him until too late, he's exceeded the intertia/road slickness limits, and rear-ends the plow. (Trucks as a class are more prone to push the weather limits than the family sedan. If the family sedan is out in this weather, and is smart, he's tucked in behind the semi). > In this case, visibility is routinely awful (it's snowing, and often blowing). And even if the plow had a siren, the semi driver probably wouldn't hear it until too late. The sedan behind the semi is in an even worse situation. > So this is a good use case for alerting message. > > > > On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >> Alison Chaiken wrote: >> alison> If passenger vehicles expect WSM on 802.11p, don't emergency >> alison>vehicles then need 802.11p to communicate with them, irrespective >> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >> alison>Connected Future we don't expect that emergency vehicles will >> alison>communicate with individual drivers via audible alarms and >> alison>flashing lights only? And assuredly having emergency vehicles >> alison>call out siren messages over LTE to infrastructure which sends >> alison>802.11p would be ridiculous? >> >> I don't know that it would be ridiculous to assume this. >> I agree that the latency might suck. I presume, however two things: >> >> 1) the route the *ambulance* or *fire* truck might take is well known >> in advance to the traffic control system ("in advance" is a relative >> term, in this I'm saying that 5s >> 0.1s maximum latency). >> So it need not be the vehicle *itself* that is calling out it's route, >> the vehicle may well be following the route that the traffic control >> system has established. >> >> 2) my observation is that flashing lights and sirens have two undesireable >> affects. On overly consentious drivers (my mom-in-law, former er nurse), >> they yank the wheel, to get out the way, often so fast they nearly >> cause a collision themselves, even when the vehicle won't even be >> coming near them. >> On drivers who day-dream (my mom! "oh, was there a stop sign back there?") >> they don't notice a thing until the vehicle is stuck behind them. >> >> It would be very useful to both of them to be told that the vehicle is >> coming, and that it will in fact affect them. >> >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | network architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> > > > _______________________________________________ > 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 mcr@sandelman.ca Mon Jul 15 09:31:49 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC35D21F9ABD for ; Mon, 15 Jul 2013 09:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzWcqQ+5XswX for ; Mon, 15 Jul 2013 09:31:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8221E80E2 for ; Mon, 15 Jul 2013 09:31:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B3A020192 for ; Mon, 15 Jul 2013 13:36:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 21A7463A88; Mon, 15 Jul 2013 12:30:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0F15B63732 for ; Mon, 15 Jul 2013 12:30:30 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-Reply-To: <51E406F8.1050508@gmail.com> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:31:49 -0000 Rex Buddenberg wrote: > Michael, > > We might want to consider this the snowplow case; gets past some of your > human factors issues. Try this as a variant to the ambulance/siren > illustration. > > One of my friends and sounding board for such stuff works for Wyoming DoT. > He observes that the casualty rate among snowplow operators in Wy is > higher than among cops. The typical accident scenario is when the > plow is working on I-80 and is overtaken by other traffic, the villain > usually a semi. If the semi driver doesn't figure out that it is a > snowplow ahead of him until too late, he's exceeded the intertia/road > slickness limits, and rear-ends the plow. (Trucks as a class are more > prone to push the weather limits than the family sedan. If the family > sedan is out in this weather, and is smart, he's tucked in behind the > semi). > In this case, visibility is routinely awful (it's snowing, and often > blowing). And even if the plow had a siren, the semi driver probably > wouldn't hear it until too late. The sedan behind the semi is in an > even worse situation. > So this is a good use case for alerting message. That's an interesting situation, and I observe (anecdotaly) the same thing in Ontario. Way out on the highways, and the side roads, and the like, LTE isn't too great, and I'm not convinced it will really get better. I am really un-happy about having to backhaul that stuff: I'd rather have a protocol that worked vehicle to vehicle. This is one reason I'd like a layer-3 (mesh) approach: we can use whatever LTE there is, and whatever 11p there is, but the GeoNet stuff seems very much layer-2 stuck. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From maxpassion@gmail.com Mon Jul 15 20:23:15 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3121E8197 for ; Mon, 15 Jul 2013 20:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opm0z1MLzJ7F for ; Mon, 15 Jul 2013 20:23:14 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 683A421E8195 for ; Mon, 15 Jul 2013 20:23:14 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz10so122561veb.36 for ; Mon, 15 Jul 2013 20:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eem7M5HRsWtlBbGTI89uhUjNyfoT/h8SyseyHinTGwg=; b=cOe63PPszd1BDkIvYa1UkPFWJcTstsgzlUgF6sYRlOW06ENzMgfURlRwJAenC4Gn7V 3ptUhQOQTGM/wViNMvJ5ylicF2chJvcIMtNEgvoNfLuPcXFUy9hogji6Dbs9w6qJqMbx lM/7q9380N1FxFw8HMs19sMYp1YtDWKGXFZlEjUWIGO9pRQwmm4CVsc1y/DbWOklb7fA rZ8n3A9ExnnibzKHN4QD9fy2xpKuB8U+7azwRFpjZx12ml3edZWto6G8UEvDyk8knesf Ezw9y0mYrimayJO7ctQhNfda43bOq0RewHAZhImiebbxY7NBoMYxDPxnk4XtmOvLDrX6 rWsw== MIME-Version: 1.0 X-Received: by 10.58.128.71 with SMTP id nm7mr13748482veb.51.1373944993805; Mon, 15 Jul 2013 20:23:13 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Mon, 15 Jul 2013 20:23:13 -0700 (PDT) In-Reply-To: <003201ce81d2$9e8a1d90$db9e58b0$@com> References: <003201ce81d2$9e8a1d90$db9e58b0$@com> Date: Tue, 16 Jul 2013 11:23:13 +0800 Message-ID: From: Liu Dapeng To: "its@ietf.org" Content-Type: multipart/alternative; boundary=047d7b60518c4bfd2204e1987f77 Subject: [its] Fwd: FW: New Version Notification for draft-liu-its-mobility-00.txt X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 03:23:15 -0000 --047d7b60518c4bfd2204e1987f77 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We submit a ITS mobility draft. Your comment and review is appreciated. Thanks, Regards, Dapeng Liu ---------- Forwarded message ---------- From: Dapeng Liu Date: 2013/7/16 Subject: FW: New Version Notification for draft-liu-its-mobility-00.txt To: maxpassion@gmail.com -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, July 16, 2013 2:21 AM To: Dapeng Liu; Hui Deng Subject: New Version Notification for draft-liu-its-mobility-00.txt A new version of I-D, draft-liu-its-mobility-00.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Filename: draft-liu-its-mobility Revision: 00 Title: Mobility Support for Mobile Router Creation date: 2013-07-15 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-liu-its-mobility-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-its-mobility Htmlized: http://tools.ietf.org/html/draft-liu-its-mobility-00 Abstract: This document proposes a ITS mobility solution. The solution is based on extensions to current IP mobility protocol. The IETF Secretariat -- ------ Best Regards, Dapeng Liu --047d7b60518c4bfd2204e1987f77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

We=A0submit a ITS mobility draf= t. Your comment and review is appreciated.

Thanks,=
Regards,
Dapeng Liu
----= ------ Forwarded message ----------
From: Dapeng Liu <liudapeng@chinamobile.com>= ;
Date: 2013/7/16
Subject: FW: New Version Notification for dr= aft-liu-its-mobility-00.txt
To: maxpassion@gmail.com


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, July 16, 2013 2:21 AM
To: Dapeng Liu; Hui Deng
Subject: New Version Notification for draft-liu-its-mobility-00.txt


A new version of I-D, draft-liu-its-mobility-00.txt has been successfully s= ubmitted by Dapeng Liu and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-liu-its-mobility
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Mobility Support for Mobile Router
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/inter= net-drafts/draft-liu-its-mobility-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-= liu-its-mobility
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu-its-m= obility-00


Abstract:
=A0 =A0This document proposes a ITS mobility solution. =A0The solution is =A0 =A0based on extensions to current IP mobility protocol.




The IETF Secretariat







--

------
Best Regard= s,
Dapeng Liu
--047d7b60518c4bfd2204e1987f77-- From Andreas.Festag@neclab.eu Tue Jul 16 00:59:40 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2A711E8245 for ; Tue, 16 Jul 2013 00:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ5Jjsykz0jx for ; Tue, 16 Jul 2013 00:59:36 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4011E8233 for ; Tue, 16 Jul 2013 00:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B457E104B50 for ; Tue, 16 Jul 2013 09:58:58 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeOVOzXZ1U3h for ; Tue, 16 Jul 2013 09:58:58 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 90CDF104B4E for ; Tue, 16 Jul 2013 09:58:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 16 Jul 2013 09:59:29 +0200 From: Andreas Festag To: "its@ietf.org" Thread-Topic: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) Thread-Index: AQHOgWfNOWl5bqyDdUyFVlayzMzGwpll6cMg Date: Tue, 16 Jul 2013 07:58:20 +0000 Message-ID: <21E46EE9B979354990401539FD0A63E5183C1D@DAPHNIS.office.hd> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> In-Reply-To: <51E406F8.1050508@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 07:59:40 -0000 simTD has used the ETSI TC ITS protocol stack for communication over 11.p/I= TS-G5 and a proprietary solution for communication over cellular. Kind regards, Andreas -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Monday, July 15, 2013 4:28 PM To: its@ietf.org Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 Addr= essAuto-Configuration) Dirk, Any idea whether the results of this project use: - dynamic IPv6 prefix exchanges between vehicles, or between vehicle and infrastructure? - IPv6-straight-over-80211p? - any form of geonetworking? Thanks, Alex Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a =E9crit : > Hi all, > Speaking of actual use cases it may be of interest that the German projec= t SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" h= as completed to test the functionality, efficacy and feasibility for everyd= ay use of car-to-x communication under real-life driving conditions. Some = detailed information can be found here: http://simtd.de/index.dhtml/0251caa= e465f8345005d/-/enEN/-/CS/-/ and=09 > http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/803 > 3/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf > > Best regards > Dirk > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of=20 > Rex Buddenberg > Sent: Dienstag, 25. Juni 2013 05:19 > To: Michael Richardson > Cc: Alison Chaiken; its@ietf.org > Subject: Re: [its] P1609.3 Networking Services and IPv6=20 > AddressAuto-Configuration > > Michael, > > We might want to consider this the snowplow case; gets past some of your = human factors issues. Try this as a variant to the ambulance/siren illustr= ation. > > One of my friends and sounding board for such stuff works for Wyoming DoT= . He observes that the casualty rate among snowplow operators in Wy is hig= her than among cops. The typical accident scenario is when the plow is wor= king on I-80 and is overtaken by other traffic, the villain usually a semi.= If the semi driver doesn't figure out that it is a snowplow ahead of him = until too late, he's exceeded the intertia/road slickness limits, and rear-= ends the plow. (Trucks as a class are more prone to push the weather limit= s than the family sedan. If the family sedan is out in this weather, and i= s smart, he's tucked in behind the semi). > In this case, visibility is routinely awful (it's snowing, and often= blowing). And even if the plow had a siren, the semi driver probably woul= dn't hear it until too late. The sedan behind the semi is in an even worse= situation. > So this is a good use case for alerting message. > > > > On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >> Alison Chaiken wrote: >> alison> If passenger vehicles expect WSM on 802.11p, don't emergenc= y >> alison>vehicles then need 802.11p to communicate with them, irrespe= ctive >> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >> alison>Connected Future we don't expect that emergency vehicles wil= l >> alison>communicate with individual drivers via audible alarms and >> alison>flashing lights only? And assuredly having emergency vehicl= es >> alison>call out siren messages over LTE to infrastructure which sen= ds >> alison>802.11p would be ridiculous? >> >> I don't know that it would be ridiculous to assume this. >> I agree that the latency might suck. I presume, however two things: >> >> 1) the route the *ambulance* or *fire* truck might take is well known >> in advance to the traffic control system ("in advance" is a relative >> term, in this I'm saying that 5s >> 0.1s maximum latency). >> So it need not be the vehicle *itself* that is calling out it's rout= e, >> the vehicle may well be following the route that the traffic control >> system has established. >> >> 2) my observation is that flashing lights and sirens have two undesireab= le >> affects. On overly consentious drivers (my mom-in-law, former er nu= rse), >> they yank the wheel, to get out the way, often so fast they nearly >> cause a collision themselves, even when the vehicle won't even be >> coming near them. >> On drivers who day-dream (my mom! "oh, was there a stop sign back t= here?") >> they don't notice a thing until the vehicle is stuck behind them. >> >> It would be very useful to both of them to be told that the vehicle=20 >> is coming, and that it will in fact affect them. >> >> >> -- >> ] Never tell me the odds! | ipv6 mesh netw= orks [ >> ] Michael Richardson, Sandelman Software Works | network archit= ect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s [ >> > > > _______________________________________________ > 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 HJFischer@fischer-tech.eu Tue Jul 16 03:58:11 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2696D11E818D for ; Tue, 16 Jul 2013 03:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG0x-JqwUb+H for ; Tue, 16 Jul 2013 03:58:09 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E96111E81C6 for ; Tue, 16 Jul 2013 03:58:08 -0700 (PDT) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVlwGJAbGYmQV2qAhj2Yk5fa+k37V6G Received: from [192.168.222.102] (p549D2673.dip0.t-ipconnect.de [84.157.38.115]) by smtp.strato.de (josoe mo46) (RZmta 31.29 DYNA|AUTH) with ESMTPA id D03e17p6GAZHnE for ; Tue, 16 Jul 2013 12:57:57 +0200 (CEST) Message-ID: <51E527C0.1020201@fischer-tech.eu> Date: Tue, 16 Jul 2013 13:00:16 +0200 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> <21E46EE9B979354990401539FD0A63E5183C1D@DAPHNIS.office.hd> In-Reply-To: <21E46EE9B979354990401539FD0A63E5183C1D@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] projects X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:58:11 -0000 Dear Andreas, could you please be so kind to tell us which versions of which ETSI standard were implemented by which manufacturer for usage in simTD? Sincerely Hans-Joachim Am 16.07.2013 09:58, schrieb Andreas Festag: > simTD has used the ETSI TC ITS protocol stack for communication over 11.p/ITS-G5 and a proprietary solution for communication over cellular. > > Kind regards, > > Andreas > > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Monday, July 15, 2013 4:28 PM > To: its@ietf.org > Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) > > Dirk, > > Any idea whether the results of this project use: > > - dynamic IPv6 prefix exchanges between vehicles, or between vehicle > and infrastructure? > - IPv6-straight-over-80211p? > - any form of geonetworking? > > Thanks, > > Alex > > Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a écrit : >> Hi all, >> Speaking of actual use cases it may be of interest that the German project SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" has completed to test the functionality, efficacy and feasibility for everyday use of car-to-x communication under real-life driving conditions. Some detailed information can be found here: http://simtd.de/index.dhtml/0251caae465f8345005d/-/enEN/-/CS/-/ and >> http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/803 >> 3/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf >> >> Best regards >> Dirk >> -----Original Message----- >> From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of >> Rex Buddenberg >> Sent: Dienstag, 25. Juni 2013 05:19 >> To: Michael Richardson >> Cc: Alison Chaiken; its@ietf.org >> Subject: Re: [its] P1609.3 Networking Services and IPv6 >> AddressAuto-Configuration >> >> Michael, >> >> We might want to consider this the snowplow case; gets past some of your human factors issues. Try this as a variant to the ambulance/siren illustration. >> >> One of my friends and sounding board for such stuff works for Wyoming DoT. He observes that the casualty rate among snowplow operators in Wy is higher than among cops. The typical accident scenario is when the plow is working on I-80 and is overtaken by other traffic, the villain usually a semi. If the semi driver doesn't figure out that it is a snowplow ahead of him until too late, he's exceeded the intertia/road slickness limits, and rear-ends the plow. (Trucks as a class are more prone to push the weather limits than the family sedan. If the family sedan is out in this weather, and is smart, he's tucked in behind the semi). >> In this case, visibility is routinely awful (it's snowing, and often blowing). And even if the plow had a siren, the semi driver probably wouldn't hear it until too late. The sedan behind the semi is in an even worse situation. >> So this is a good use case for alerting message. >> >> >> >> On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >>> Alison Chaiken wrote: >>> alison> If passenger vehicles expect WSM on 802.11p, don't emergency >>> alison>vehicles then need 802.11p to communicate with them, irrespective >>> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >>> alison>Connected Future we don't expect that emergency vehicles will >>> alison>communicate with individual drivers via audible alarms and >>> alison>flashing lights only? And assuredly having emergency vehicles >>> alison>call out siren messages over LTE to infrastructure which sends >>> alison>802.11p would be ridiculous? >>> >>> I don't know that it would be ridiculous to assume this. >>> I agree that the latency might suck. I presume, however two things: >>> >>> 1) the route the *ambulance* or *fire* truck might take is well known >>> in advance to the traffic control system ("in advance" is a relative >>> term, in this I'm saying that 5s >> 0.1s maximum latency). >>> So it need not be the vehicle *itself* that is calling out it's route, >>> the vehicle may well be following the route that the traffic control >>> system has established. >>> >>> 2) my observation is that flashing lights and sirens have two undesireable >>> affects. On overly consentious drivers (my mom-in-law, former er nurse), >>> they yank the wheel, to get out the way, often so fast they nearly >>> cause a collision themselves, even when the vehicle won't even be >>> coming near them. >>> On drivers who day-dream (my mom! "oh, was there a stop sign back there?") >>> they don't notice a thing until the vehicle is stuck behind them. >>> >>> It would be very useful to both of them to be told that the vehicle >>> is coming, and that it will in fact affect them. >>> >>> >>> -- >>> ] Never tell me the odds! | ipv6 mesh networks [ >>> ] Michael Richardson, Sandelman Software Works | network architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>> >> >> _______________________________________________ >> 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 > -- ------------------------------------------------------------------------------ ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ------------------------------------------------------------------------------ The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------------------------------------------------------------------------------ Dr. Hans-Joachim Fischer ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344) 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS ------------------------------------------------------------------------------ From alexandru.petrescu@gmail.com Tue Jul 16 06:16:03 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617A221E8087 for ; Tue, 16 Jul 2013 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OAxnF2CiIuv for ; Tue, 16 Jul 2013 06:15:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id DE8F721E808E for ; Tue, 16 Jul 2013 06:15:57 -0700 (PDT) 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 r6GDFuQ3010985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Jul 2013 15:15:56 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6GDFuS7017466 for ; Tue, 16 Jul 2013 15:15:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6GDFjHm018709 for ; Tue, 16 Jul 2013 15:15:56 +0200 Message-ID: <51E54781.9000605@gmail.com> Date: Tue, 16 Jul 2013 15:15:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "its@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:16:03 -0000 Hi ITSers, For your information, ETSI ITS announces it just published this document. ETSI EN 302 663 V1.2.1 http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_302663v010201p.pdf One interesting aspect is that, in my humble reading, it does not seem to prohibit the use of IP over an access layer operating at 5880 MHz at 33dBm EIRP (which is relatively high power, approx. 1km in line of sight). It and its references insist this particular channel G5-SCH1 is 'dedicated basically for ITS road safety' and that is 'the default channel for announcing and offering ITS services for safety & road efficiency under the DCC state ACTIVE and RESTRITIVE of the CCH. The transmissions of other message-types on the SCH1 are allowed if channel conditions according to the restrictions in the present document permit.' This would mean, IMHO, that it still possible to exchange IP packets, directly between vehicles, over a MAC over a particular PHY at 5880MHz G5-SCH1, provided some conditions are met. One other interesting aspect is the changes from an earlier version in 2009: - the 10Mhz bands around 5910MHz and 5920MHz are now new bands allocated for 'ITS road traffic efficiency'. (previously they were not dedicated to anything). - renaming of another channel typically used for Radio LANs. Alex -------- Message original -------- Sujet: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published Date : Wed, 10 Jul 2013 11:05:16 +0200 De : Martin Arndt Répondre à : Martin Arndt Pour : Dear all, Please note that the following European Standard has been published recently. You can download it for free via the link given below. *ETSI EN 302 663 V1.2.1 * Intelligent Transport Systems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band This European Standard addresses the European Commission Standardization Mandate M/453. Kind regards, Martin ############################## Martin ARNDT Technical Officer ETSI Operations (OPS) Committee Support Centre (CSC) Telephone: +33 4 92 94 42 49 Skype: Mr Wavelength Email: martin.arndt@etsi.org Web: http://www.etsi.org ############################## From HJFischer@fischer-tech.eu Tue Jul 16 07:22:32 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63CC21F909A for ; Tue, 16 Jul 2013 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejth57FG4TzV for ; Tue, 16 Jul 2013 07:22:31 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59B21F84D1 for ; Tue, 16 Jul 2013 07:22:30 -0700 (PDT) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVlwGJAbGYmQV2qAhj2Yk5fa+k37V6G Received: from [192.168.222.102] (p549D2673.dip0.t-ipconnect.de [84.157.38.115]) by smtp.strato.de (jored mo23) (RZmta 31.29 DYNA|AUTH) with ESMTPA id I07d36p6GE9D2T ; Tue, 16 Jul 2013 16:22:18 +0200 (CEST) Message-ID: <51E557CF.5070406@fischer-tech.eu> Date: Tue, 16 Jul 2013 16:25:19 +0200 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <51E54781.9000605@gmail.com> In-Reply-To: <51E54781.9000605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:22:33 -0000 There seems to be also a further significant change in this EN compared to earlier versions (as it was discussed recently at ETSI). The usage of the BRAN band is no more supported. This is a severe drawback for road operators who need to use RSUs to connect to passing cars. Allowing the BRAN band (which is allowed by the base standard IEEE 802.11 (p-mode) and by the ISO 21215 standard (which was published before the EN from ETSI covering the same issue)) a RSU could use the CCH to send out service advertisement messages (FSAP, ISO 24102-5) which include a request to change channel (select a channel in the BRAN band to run the session). There we have enough bandwidth to allow for a system where the RSU implemented as a multi-channel device which can simultaneously operate several orthogonal channels, serving several cars simultaneously. ISO 21215 does not restrict its usage to any kind of networking protocol. My two cents on what the end user really needs. We should be aware that the set of standards from ETSI is designed in a way to specify a system around the GeoNetworking / Congestion Control Protocols which are covered by IPRs. Luckily nobody needs to implement a specific standard as long as there is no related regulation. Hans-Joachim Am 16.07.2013 15:15, schrieb Alexandru Petrescu: > Hi ITSers, > > For your information, ETSI ITS announces it just published this document. > > ETSI EN 302 663 V1.2.1 > http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_302663v010201p.pdf > > > One interesting aspect is that, in my humble reading, it does not seem > to prohibit the use of IP over an access layer operating at 5880 MHz at > 33dBm EIRP (which is relatively high power, approx. 1km in line of > sight). > > It and its references insist this particular channel G5-SCH1 is > 'dedicated basically for ITS road safety' and that is 'the default > channel for announcing and offering ITS services for safety & road > efficiency under the DCC state ACTIVE and RESTRITIVE of the CCH. The > transmissions of other message-types on the SCH1 are allowed if channel > conditions according to the restrictions in the present document permit.' > > This would mean, IMHO, that it still possible to exchange IP packets, > directly between vehicles, over a MAC over a particular PHY at 5880MHz > G5-SCH1, provided some conditions are met. > > One other interesting aspect is the changes from an earlier version in > 2009: > - the 10Mhz bands around 5910MHz and 5920MHz are now new bands > allocated for 'ITS road traffic efficiency'. (previously they were > not dedicated to anything). > - renaming of another channel typically used for Radio LANs. > > Alex > > -------- Message original -------- > Sujet: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in > the 5 GHz frequency band published > Date : Wed, 10 Jul 2013 11:05:16 +0200 > De : Martin Arndt > Répondre à : Martin Arndt > Pour : > > > > Dear all, > > Please note that the following European Standard has been published > recently. You can download it for free via the link given below. > > *ETSI EN 302 663 V1.2.1 > * > > > Intelligent Transport Systems (ITS); > > Access layer specification for Intelligent Transport Systems operating > in the 5 GHz frequency band > > This European Standard addresses the European Commission Standardization > Mandate M/453. > > Kind regards, > > Martin > > ############################## > > Martin ARNDT > > Technical Officer > > ETSI Operations (OPS) > > Committee Support Centre (CSC) > > Telephone: +33 4 92 94 42 49 > > Skype: Mr Wavelength > > Email: martin.arndt@etsi.org > > Web: http://www.etsi.org > > ############################## > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- ------------------------------------------------------------------------------ ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ------------------------------------------------------------------------------ The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------------------------------------------------------------------------------ Dr. Hans-Joachim Fischer ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344) 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS ------------------------------------------------------------------------------ From Dirk.von-Hugo@telekom.de Tue Jul 16 08:34:19 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF3911E80D5 for ; Tue, 16 Jul 2013 08:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjcmTfy2TjFJ for ; Tue, 16 Jul 2013 08:34:16 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 570E021F9C41 for ; Tue, 16 Jul 2013 08:34:15 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Jul 2013 17:34:13 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 16 Jul 2013 17:34:12 +0200 From: To: , Date: Tue, 16 Jul 2013 17:34:11 +0200 Thread-Topic: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) Thread-Index: Ac6BZ8KnIjFdTqCuQiKgJ+HLtIaUZgA0Pydg Message-ID: <05C81A773E48DD49B181B04BA21A342A2C52A59D36@HE113484.emea1.cds.t-internal.com> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> In-Reply-To: <51E406F8.1050508@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:34:19 -0000 Hello Alex, Concerning your questions my impression is (if I understood it correctly fo= rm available documents) that SimTD did not specify IPv6 Prefix Exchange sin= ce the protocol stack shows IPv6 over IPv4 over 802.11p and other wireless = and cellular technologies - so I would guess that also no IPv6 straight ove= r 802.11p. There are Geoservers with polling Lat/Lon from the vehicles (and distributi= ng Geo data for warnings etc.) =20 I anyone is more involved and can help with details, I would be glad! Best regards Dirk -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Montag, 15. Juli 2013 16:28 To: its@ietf.org Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 Addr= essAuto-Configuration) Dirk, Any idea whether the results of this project use: - dynamic IPv6 prefix exchanges between vehicles, or between vehicle and infrastructure? - IPv6-straight-over-80211p? - any form of geonetworking? Thanks, Alex Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a =E9crit : > Hi all, > Speaking of actual use cases it may be of interest that the German projec= t SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" h= as completed to test the functionality, efficacy and feasibility for everyd= ay use of car-to-x communication under real-life driving conditions. Some = detailed information can be found here: http://simtd.de/index.dhtml/0251caa= e465f8345005d/-/enEN/-/CS/-/ and=09 > http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/8033/C= S/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf > > Best regards > Dirk > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Rex= Buddenberg > Sent: Dienstag, 25. Juni 2013 05:19 > To: Michael Richardson > Cc: Alison Chaiken; its@ietf.org > Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Confi= guration > > Michael, > > We might want to consider this the snowplow case; gets past some of your = human factors issues. Try this as a variant to the ambulance/siren illustr= ation. > > One of my friends and sounding board for such stuff works for Wyoming DoT= . He observes that the casualty rate among snowplow operators in Wy is hig= her than among cops. The typical accident scenario is when the plow is wor= king on I-80 and is overtaken by other traffic, the villain usually a semi.= If the semi driver doesn't figure out that it is a snowplow ahead of him = until too late, he's exceeded the intertia/road slickness limits, and rear-= ends the plow. (Trucks as a class are more prone to push the weather limit= s than the family sedan. If the family sedan is out in this weather, and i= s smart, he's tucked in behind the semi). > In this case, visibility is routinely awful (it's snowing, and often= blowing). And even if the plow had a siren, the semi driver probably woul= dn't hear it until too late. The sedan behind the semi is in an even worse= situation. > So this is a good use case for alerting message. > > > > On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >> Alison Chaiken wrote: >> alison> If passenger vehicles expect WSM on 802.11p, don't emergenc= y >> alison>vehicles then need 802.11p to communicate with them, irrespe= ctive >> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >> alison>Connected Future we don't expect that emergency vehicles wil= l >> alison>communicate with individual drivers via audible alarms and >> alison>flashing lights only? And assuredly having emergency vehicl= es >> alison>call out siren messages over LTE to infrastructure which sen= ds >> alison>802.11p would be ridiculous? >> >> I don't know that it would be ridiculous to assume this. >> I agree that the latency might suck. I presume, however two things: >> >> 1) the route the *ambulance* or *fire* truck might take is well known >> in advance to the traffic control system ("in advance" is a relative >> term, in this I'm saying that 5s >> 0.1s maximum latency). >> So it need not be the vehicle *itself* that is calling out it's rout= e, >> the vehicle may well be following the route that the traffic control >> system has established. >> >> 2) my observation is that flashing lights and sirens have two undesireab= le >> affects. On overly consentious drivers (my mom-in-law, former er nu= rse), >> they yank the wheel, to get out the way, often so fast they nearly >> cause a collision themselves, even when the vehicle won't even be >> coming near them. >> On drivers who day-dream (my mom! "oh, was there a stop sign back t= here?") >> they don't notice a thing until the vehicle is stuck behind them. >> >> It would be very useful to both of them to be told that the vehicle is >> coming, and that it will in fact affect them. >> >> >> -- >> ] Never tell me the odds! | ipv6 mesh netw= orks [ >> ] Michael Richardson, Sandelman Software Works | network archit= ect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s [ >> > > > _______________________________________________ > 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 HJFischer@fischer-tech.eu Tue Jul 16 08:43:47 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1BE21F9AE7 for ; Tue, 16 Jul 2013 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mABQGcedPsKO for ; Tue, 16 Jul 2013 08:43:46 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 709CB21F85BB for ; Tue, 16 Jul 2013 08:43:46 -0700 (PDT) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVlwGJAbGYmQV2qAhj2Yk5fa+k37V6G Received: from [192.168.222.102] (p549D2673.dip0.t-ipconnect.de [84.157.38.115]) by smtp.strato.de (josoe mo23) (RZmta 31.29 DYNA|AUTH) with ESMTPA id I037aep6GF8u6e for ; Tue, 16 Jul 2013 17:43:36 +0200 (CEST) Message-ID: <51E56AEF.2080400@fischer-tech.eu> Date: Tue, 16 Jul 2013 17:46:55 +0200 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> <05C81A773E48DD49B181B04BA21A342A2C52A59D36@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C52A59D36@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] projects - Deo-dissemination of information - Usage of IPv6 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:43:47 -0000 IPv6 over 802.11p: Yes, this is in our scope. We, at ISO TC204 WG16, are developing a suite of standards on how to use IPv6 in the context of an ITS station. There is no restriction at all on how to use IPv6. At ETSI they only want to have IP over GeoNetworking, which bears significant technical risks. Whether to use IPv6 over 802.11p narrow band channels with quickly moving stations depends on the road scenario (potentially this is reasonable for roadside to car communications), the traffic scenario (how many stations are trying to use the same channel). Dissemination of Geo Data, i.e. geo-dissemination of information (the term we are using at ISO) can be done with different protocols. GeoNetworking is, in my opinion, the uppermost useless tool to do it in 5,9 GHz channels. There is an excellent idea to use IPv6. And this will go over any kind of access technology (802.11p, CNs, Internet). Sincerely Hans-Joachim Am 16.07.2013 17:34, schrieb Dirk.von-Hugo@telekom.de: > Hello Alex, > Concerning your questions my impression is (if I understood it correctly form available documents) that SimTD did not specify IPv6 Prefix Exchange since the protocol stack shows IPv6 over IPv4 over 802.11p and other wireless and cellular technologies - so I would guess that also no IPv6 straight over 802.11p. > There are Geoservers with polling Lat/Lon from the vehicles (and distributing Geo data for warnings etc.) > I anyone is more involved and can help with details, I would be glad! > > Best regards > Dirk > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Montag, 15. Juli 2013 16:28 > To: its@ietf.org > Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) > > Dirk, > > Any idea whether the results of this project use: > > - dynamic IPv6 prefix exchanges between vehicles, or between vehicle > and infrastructure? > - IPv6-straight-over-80211p? > - any form of geonetworking? > > Thanks, > > Alex > > Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a écrit : >> Hi all, >> Speaking of actual use cases it may be of interest that the German project SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" has completed to test the functionality, efficacy and feasibility for everyday use of car-to-x communication under real-life driving conditions. Some detailed information can be found here: http://simtd.de/index.dhtml/0251caae465f8345005d/-/enEN/-/CS/-/ and >> http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/8033/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf >> >> Best regards >> Dirk >> -----Original Message----- >> From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Rex Buddenberg >> Sent: Dienstag, 25. Juni 2013 05:19 >> To: Michael Richardson >> Cc: Alison Chaiken; its@ietf.org >> Subject: Re: [its] P1609.3 Networking Services and IPv6 AddressAuto-Configuration >> >> Michael, >> >> We might want to consider this the snowplow case; gets past some of your human factors issues. Try this as a variant to the ambulance/siren illustration. >> >> One of my friends and sounding board for such stuff works for Wyoming DoT. He observes that the casualty rate among snowplow operators in Wy is higher than among cops. The typical accident scenario is when the plow is working on I-80 and is overtaken by other traffic, the villain usually a semi. If the semi driver doesn't figure out that it is a snowplow ahead of him until too late, he's exceeded the intertia/road slickness limits, and rear-ends the plow. (Trucks as a class are more prone to push the weather limits than the family sedan. If the family sedan is out in this weather, and is smart, he's tucked in behind the semi). >> In this case, visibility is routinely awful (it's snowing, and often blowing). And even if the plow had a siren, the semi driver probably wouldn't hear it until too late. The sedan behind the semi is in an even worse situation. >> So this is a good use case for alerting message. >> >> >> >> On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >>> Alison Chaiken wrote: >>> alison> If passenger vehicles expect WSM on 802.11p, don't emergency >>> alison>vehicles then need 802.11p to communicate with them, irrespective >>> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >>> alison>Connected Future we don't expect that emergency vehicles will >>> alison>communicate with individual drivers via audible alarms and >>> alison>flashing lights only? And assuredly having emergency vehicles >>> alison>call out siren messages over LTE to infrastructure which sends >>> alison>802.11p would be ridiculous? >>> >>> I don't know that it would be ridiculous to assume this. >>> I agree that the latency might suck. I presume, however two things: >>> >>> 1) the route the *ambulance* or *fire* truck might take is well known >>> in advance to the traffic control system ("in advance" is a relative >>> term, in this I'm saying that 5s >> 0.1s maximum latency). >>> So it need not be the vehicle *itself* that is calling out it's route, >>> the vehicle may well be following the route that the traffic control >>> system has established. >>> >>> 2) my observation is that flashing lights and sirens have two undesireable >>> affects. On overly consentious drivers (my mom-in-law, former er nurse), >>> they yank the wheel, to get out the way, often so fast they nearly >>> cause a collision themselves, even when the vehicle won't even be >>> coming near them. >>> On drivers who day-dream (my mom! "oh, was there a stop sign back there?") >>> they don't notice a thing until the vehicle is stuck behind them. >>> >>> It would be very useful to both of them to be told that the vehicle is >>> coming, and that it will in fact affect them. >>> >>> >>> -- >>> ] Never tell me the odds! | ipv6 mesh networks [ >>> ] Michael Richardson, Sandelman Software Works | network architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>> >> >> _______________________________________________ >> 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 > -- ------------------------------------------------------------------------------ ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ------------------------------------------------------------------------------ The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------------------------------------------------------------------------------ Dr. Hans-Joachim Fischer ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344) 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS ------------------------------------------------------------------------------ From HJFischer@fischer-tech.eu Tue Jul 16 22:18:59 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E5B21F9AE6 for ; Tue, 16 Jul 2013 22:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ+JMGEc22MK for ; Tue, 16 Jul 2013 22:18:57 -0700 (PDT) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4421F9A05 for ; Tue, 16 Jul 2013 22:18:56 -0700 (PDT) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :JGYCfFOrc/o0m7eTcArWz0wjmOawaLakL8gsnQVlwGJAbGYmQV2qAhj2Yk5YYukyZNE= Received: from [192.168.222.102] (p549D292B.dip0.t-ipconnect.de [84.157.41.43]) by smtp.strato.de (joses mo41) (RZmta 31.29 DYNA|AUTH) with ESMTPA id i019efp6H3CveM ; Wed, 17 Jul 2013 07:18:46 +0200 (CEST) Message-ID: <51E629C2.6030303@fischer-tech.eu> Date: Wed, 17 Jul 2013 07:21:06 +0200 From: "Dr. Hans-Joachim Fischer" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dickroy@alum.mit.edu References: <51E54781.9000605@gmail.com> <51E557CF.5070406@fischer-tech.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090305020806020606070702" Cc: its@ietf.org Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:18:59 -0000 This is a multi-part message in MIME format. --------------090305020806020606070702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is all true, but only half of the story. You can set MIB parameter dot11OCBActivated to true and consequently dot11SpectrumManagementRequired to false and nevertheless a station can implement spectrum management. It is not said that you need to use a functionality of a semiconductor device which implements 802.11. The requirement in the harmonized standard is simply that in the BRAN band you have to check whether a channel is used before you use it yourself. This is why car-to-car communication in the BRAN band is not very reasonable, as there are only real peers. For roadside-to-car communication you can design your system such that communications always is initiated by the roadside ITS station unit and thus the requirment for spectrum management in combination with p-mode can be fulfilled. By the way, car-to-car communications at 5 GHz in channels with 10 MHz channel spacing is a dream. In most road traffic scenarios we will face severe radio channel congestion problems. Further on, my private opinion, car-to-car communication in no way can significantly improve road traffic safety. We need autonomeous systems (in-car radar) and distribution of trustable traffic information (coming for a trusted source which can perform sensor fusion and plausibility checks). Distribution of such trusted information via 5 GHz from roadside ITS station units, or via LTE, is the solution for day 1 procurement. Hans-Joachim Am 17.07.2013 00:24, schrieb Richard Roy: > > See below regarding G5C (BRAN usage) ... > > > -----Original Message----- > > > From:Dr. Hans-Joachim Fischer [mailto:HJFischer@fischer-tech.eu] > > > Sent: Tuesday, July 16, 2013 4:25 PM > > > To: its@ietf.org > > > Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS > > > operating in the 5 GHz frequency band published > > > > > > > > > There seems to be also a further significant change in this EN compared > > > to earlier versions (as it was discussed recently at ETSI). The usage of > > > the BRAN band is no more supported. > > [RR>] From 302 663 v1.2.1: > > " The requirement of TPC and DFS is covered in IEEE 802.11-2012 [3] > through the MIB parameter > > dot11SpectrumManagementRequired set to true. When setting the MIB > parameter dot11OCBActivated to > > true, dot11SpectrumManagementRequired is false, thus the two modes of > operation are mutually exclusive. > > Hence, communication outside the context of a basic service set is not > possible in the ITS-G5C band. But short range > > communication with a fixed station in the context of a BSS in > combination with spectrum management is possible > > (e.g. in a garage) even though not specified for ITS-G5 stations at > time of preparation of the present document." > > Unfortunately the ETSI guys didn't get it right this time either. > There is nothing that states dot11OCBActivated has to be true in the > G5C band. You simply execute normal 802.11 operations in that band > using DFS and you are good to go. By writing the blanket statement > that for ITS-G5 (meaning ALL G5 channels including G5C) > dot11OCBActivated must be set to true, they shot themselves in the > foot unnecessarily. (They were warned on many occasions by the > way:^))) Again, there is NO REASON why a G5C radio needs to have > dot11OCBActivated set to true. Set it to false for that interface, > turn on the SpectrumManagement stuff and anything else you want, and > voila ... DFS! > > Point is, anyone can ignore the part of the spec that say > dot11OCBActivated has to be true in the G5C band and no one should > care or complain. > > RR > > > This is a severe drawback for road > > > operators who need to use RSUs to connect to passing cars. Allowing the > > > BRAN band (which is allowed by the base standard IEEE 802.11 (p-mode) > > > and by the ISO 21215 standard (which was published before the EN from > > > ETSI covering the same issue)) a RSU could use the CCH to send out > > > service advertisement messages (FSAP, ISO 24102-5) which include a > > > request to change channel (select a channel in the BRAN band to run the > > > session). There we have enough bandwidth to allow for a system where the > > > RSU implemented as a multi-channel device which can simultaneously > > > operate several orthogonal channels, serving several cars > > > simultaneously. ISO 21215 does not restrict its usage to any kind of > > > networking protocol. > > > > > > My two cents on what the end user really needs. > > > > > > We should be aware that the set of standards from ETSI is designed in a > > > way to specify a system around the GeoNetworking / Congestion Control > > > Protocols which are covered by IPRs. Luckily nobody needs to implement a > > > specific standard as long as there is no related regulation. > > > > > > > > > Hans-Joachim > > > > > > Am 16.07.2013 15:15, schrieb Alexandru Petrescu: > > > > Hi ITSers, > > > > > > > > For your information, ETSI ITS announces it just published this document. > > > > > > > > ETSI EN 302 663 V1.2.1 > > > > > > > http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_30 > > > 2663v010201p.pdf > > > > > > > > > > > > One interesting aspect is that, in my humble reading, it does not seem > > > > to prohibit the use of IP over an access layer operating at 5880 MHz at > > > > 33dBm EIRP (which is relatively high power, approx. 1km in line of > > > > sight). > > > > > > > > It and its references insist this particular channel G5-SCH1 is > > > > 'dedicated basically for ITS road safety' and that is 'the default > > > > channel for announcing and offering ITS services for safety & road > > > > efficiency under the DCC state ACTIVE and RESTRITIVE of the CCH. The > > > > transmissions of other message-types on the SCH1 are allowed if channel > > > > conditions according to the restrictions in the present document > > > permit.' > > > > > > > > This would mean, IMHO, that it still possible to exchange IP packets, > > > > directly between vehicles, over a MAC over a particular PHY at 5880MHz > > > > G5-SCH1, provided some conditions are met. > > > > > > > > One other interesting aspect is the changes from an earlier version in > > > > 2009: > > > > - the 10Mhz bands around 5910MHz and 5920MHz are now new bands > > > > allocated for 'ITS road traffic efficiency'. (previously they were > > > > not dedicated to anything). > > > > - renaming of another channel typically used for Radio LANs. > > > > > > > > Alex > > > > > > > > -------- Message original -------- > > > > Sujet: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating > > > in > > > > the 5 GHz frequency band published > > > > Date : Wed, 10 Jul 2013 11:05:16 +0200 > > > > De : Martin Arndt > > > > Répondre à : Martin Arndt > > > > Pour : > > > > > > > > > > > > > > > > Dear all, > > > > > > > > Please note that the following European Standard has been published > > > > recently. You can download it for free via the link given below. > > > > > > > > *ETSI EN 302 663 V1.2.1 > > > > > > > > > 02663v010201p.pdf>* > > > > > > > > > > > > Intelligent Transport Systems (ITS); > > > > > > > > Access layer specification for Intelligent Transport Systems operating > > > > in the 5 GHz frequency band > > > > > > > > This European Standard addresses the European Commission Standardization > > > > Mandate M/453. > > > > > > > > Kind regards, > > > > > > > > Martin > > > > > > > > ############################## > > > > > > > > Martin ARNDT > > > > > > > > Technical Officer > > > > > > > > ETSI Operations (OPS) > > > > > > > > Committee Support Centre (CSC) > > > > > > > > Telephone: +33 4 92 94 42 49 > > > > > > > > Skype: Mr Wavelength > > > > > > > > Email: martin.arndt@etsi.org > > > > > > > > Web: http://www.etsi.org > > > > > > > > ############################## > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > its mailing list > > > > its@ietf.org > > > > https://www.ietf.org/mailman/listinfo/its > > > > > > > > > > -- > > > -------------------------------------------------------------------------- > > > ---- > > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > > > C-ITS online news:http://its-standards.info/Feeds/cits.rss > > > -------------------------------------------------------------------------- > > > ---- > > > The information contained in this message is confidential and may be > > > legally privileged. The message is intended solely for the addressee(s). > > > If you are not the intended recipient, you are hereby notified that any > > > use, dissemination, or reproduction is strictly prohibited and may be > > > unlawful. If you are not the intended recipient, please contact the sender > > > by return e-mail and destroy all copies of the original message. > > > -------------------------------------------------------------------------- > > > ---- > > >Dr. Hans-Joachim Fischer > > > ESF GmbH > > > Fichtenweg 9 > > > 89143 Blaubeuren > > > +49 (7344) 175340 > > > +49 (7344) 919123 (Fax) > > > http://fischer-tech.eu : Main web of ESF GmbH > > > http://its-standards.eu : News on cooperative ITS standardization > > > http://its-testing.org : International consultancy for cooperative ITS > > > -------------------------------------------------------------------------- > > > ---- > -- ------------------------------------------------------------------------------ ESF online-news: http://fischer-tech.eu/Feeds/esf.rss C-ITS online news: http://its-standards.info/Feeds/cits.rss ------------------------------------------------------------------------------ The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. ------------------------------------------------------------------------------ Dr. Hans-Joachim Fischer ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344) 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH http://its-standards.eu : News on cooperative ITS standardization http://its-testing.org : International consultancy for cooperative ITS ------------------------------------------------------------------------------ --------------090305020806020606070702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This is all true, but only half of the story. You can set MIB parameter dot11OCBActivated to true and consequently dot11SpectrumManagementRequired to false and nevertheless a station can implement spectrum management. It is not said that you need to use a functionality of a semiconductor device which implements 802.11. The requirement in the harmonized standard is simply that in the BRAN band you have to check whether a channel is used before you use it yourself. This is why car-to-car communication in the BRAN band is not very reasonable, as there are only real peers. For roadside-to-car communication you can design your system such that communications always is initiated by the roadside ITS station unit and thus the requirment for spectrum management in combination with p-mode can be fulfilled.

By the way, car-to-car communications at 5 GHz in channels with 10 MHz channel spacing is a dream. In most road traffic scenarios we will face severe radio channel congestion problems. Further on, my private opinion, car-to-car communication in no way can significantly improve road traffic safety. We need autonomeous systems (in-car radar) and distribution of trustable traffic information (coming for a trusted source which can perform sensor fusion and plausibility checks). Distribution of such trusted information via 5 GHz from roadside ITS station units, or via LTE, is the solution for day 1 procurement.


Hans-Joachim

Am 17.07.2013 00:24, schrieb Richard Roy:

See below regarding G5C (BRAN usage) ...

 

> -----Original Message-----

> From: Dr. Hans-Joachim Fischer [mailto:HJFischer@fischer-tech.eu]

> Sent: Tuesday, July 16, 2013 4:25 PM

> To: its@ietf.org

> Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS

> operating in the 5 GHz frequency band published

>

>

> There seems to be also a further significant change in this EN compared

> to earlier versions (as it was discussed recently at ETSI). The usage of

> the BRAN band is no more supported.

 

[RR>] From 302 663 v1.2.1:

" The requirement of TPC and DFS is covered in IEEE 802.11-2012 [3] through the MIB parameter

dot11SpectrumManagementRequired set to true. When setting the MIB parameter dot11OCBActivated to

true, dot11SpectrumManagementRequired is false, thus the two modes of operation are mutually exclusive.

Hence, communication outside the context of a basic service set is not possible in the ITS-G5C band. But short range

communication with a fixed station in the context of a BSS in combination with spectrum management is possible

(e.g. in a garage) even though not specified for ITS-G5 stations at time of preparation of the present document."

 

Unfortunately the ETSI guys didn't get it right this time either.  There is nothing that states dot11OCBActivated has to be true in the G5C band.  You simply execute normal 802.11 operations in that band using DFS and you are good to go.  By writing the blanket statement that for ITS-G5 (meaning ALL G5 channels including G5C) dot11OCBActivated must be set to true, they shot themselves in the foot unnecessarily.  (They were warned on many occasions by the way:^))) Again, there is NO REASON why a G5C radio needs to have dot11OCBActivated set to true.  Set it to false for that interface, turn on the SpectrumManagement stuff and anything else you want, and voila ... DFS!  

 

Point is, anyone can ignore the part of the spec that say dot11OCBActivated has to be true in the G5C band and no one should care or complain.

 

RR

 

 

> This is a severe drawback for road

> operators who need to use RSUs to connect to passing cars. Allowing the

> BRAN band (which is allowed by the base standard IEEE 802.11 (p-mode)

> and by the ISO 21215 standard (which was published before the EN from

> ETSI covering the same issue)) a RSU could use the CCH to send out

> service advertisement messages (FSAP, ISO 24102-5) which include a

> request to change channel (select a channel in the BRAN band to run the

> session). There we have enough bandwidth to allow for a system where the

> RSU implemented as a multi-channel device which can simultaneously

> operate several orthogonal channels, serving several cars

> simultaneously. ISO 21215 does not restrict its usage to any kind of

> networking protocol.

>

> My two cents on what the end user really needs.

>

> We should be aware that the set of standards from ETSI is designed in a

> way to specify a system around the GeoNetworking / Congestion Control

> Protocols which are covered by IPRs. Luckily nobody needs to implement a

> specific standard as long as there is no related regulation.

>

>

> Hans-Joachim

>

> Am 16.07.2013 15:15, schrieb Alexandru Petrescu:

> > Hi ITSers,

> >

> > For your information, ETSI ITS announces it just published this document.

> >

> > ETSI EN 302 663 V1.2.1

> >

> http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_30

> 2663v010201p.pdf

> >

> >

> > One interesting aspect is that, in my humble reading, it does not seem

> > to prohibit the use of IP over an access layer operating at 5880 MHz at

> > 33dBm EIRP (which is relatively high power, approx. 1km in line of

> > sight).

> >

> > It and its references insist this particular channel G5-SCH1 is

> > 'dedicated basically for ITS road safety' and that is 'the default

> > channel for announcing and offering ITS services for safety & road

> > efficiency under the DCC state ACTIVE and RESTRITIVE of the CCH. The

> > transmissions of other message-types on the SCH1 are allowed if channel

> > conditions according to the restrictions in the present document

> permit.'

> >

> > This would mean, IMHO, that it still possible to exchange IP packets,

> > directly between vehicles, over a MAC over a particular PHY at 5880MHz

> > G5-SCH1, provided some conditions are met.

> >

> > One other interesting aspect is the changes from an earlier version in

> > 2009:

> > - the 10Mhz bands around 5910MHz and 5920MHz are now new bands

> >   allocated for 'ITS road traffic efficiency'. (previously they were

> >   not dedicated to anything).

> > - renaming of another channel typically used for Radio LANs.

> >

> > Alex

> >

> > -------- Message original --------

> > Sujet:     [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating

> in

> > the 5 GHz frequency band published

> > Date :     Wed, 10 Jul 2013 11:05:16 +0200

> > De :     Martin Arndt <Martin.Arndt@ETSI.ORG>

> > Répondre à :     Martin Arndt <Martin.Arndt@ETSI.ORG>

> > Pour :     <ITS-NEWS@LIST.ETSI.ORG>

> >

> >

> >

> > Dear all,

> >

> > Please note that the following European Standard has been published

> > recently. You can download it for free via the link given below.

> >

> > *ETSI EN 302 663 V1.2.1

> >

> <http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_3

> 02663v010201p.pdf>*

> >

> >

> > Intelligent Transport Systems (ITS);

> >

> > Access layer specification for Intelligent Transport Systems operating

> > in the 5 GHz frequency band

> >

> > This European Standard addresses the European Commission Standardization

> > Mandate M/453.

> >

> > Kind regards,

> >

> > Martin

> >

> > ##############################

> >

> > Martin ARNDT

> >

> > Technical Officer

> >

> > ETSI Operations (OPS)

> >

> > Committee Support Centre (CSC)

> >

> > Telephone: +33 4 92 94 42 49

> >

> > Skype: Mr Wavelength

> >

> > Email: martin.arndt@etsi.org

> >

> > Web: http://www.etsi.org

> >

> > ##############################

> >

> >

> >

> >

> > _______________________________________________

> > its mailing list

> > its@ietf.org

> > https://www.ietf.org/mailman/listinfo/its

> >

>

> --

> --------------------------------------------------------------------------

> ----

> ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss

> C-ITS online news:  http://its-standards.info/Feeds/cits.rss

> --------------------------------------------------------------------------

> ----

> The information contained in this message is confidential and may be

> legally privileged. The message is intended solely for the addressee(s).

> If you are not the intended recipient, you are hereby notified that any

> use, dissemination, or reproduction is strictly prohibited and may be

> unlawful. If you are not the intended recipient, please contact the sender

> by return e-mail and destroy all copies of the original message.

> --------------------------------------------------------------------------

> ----

> Dr. Hans-Joachim Fischer

> ESF GmbH

> Fichtenweg 9

> 89143 Blaubeuren

> +49 (7344) 175340

> +49 (7344) 919123 (Fax)

> http://fischer-tech.eu : Main web of ESF GmbH

> http://its-standards.eu : News on cooperative ITS standardization

> http://its-testing.org : International consultancy for cooperative ITS

> --------------------------------------------------------------------------

> ----


-- 
------------------------------------------------------------------------------ 
ESF online-news:    http://fischer-tech.eu/Feeds/esf.rss
C-ITS online news:  http://its-standards.info/Feeds/cits.rss
------------------------------------------------------------------------------ 
The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
------------------------------------------------------------------------------ 
Dr. Hans-Joachim Fischer
ESF GmbH
Fichtenweg 9
89143 Blaubeuren
+49 (7344) 175340
+49 (7344) 919123 (Fax)
http://fischer-tech.eu : Main web of ESF GmbH
http://its-standards.eu : News on cooperative ITS standardization
http://its-testing.org : International consultancy for cooperative ITS
------------------------------------------------------------------------------
--------------090305020806020606070702-- From karagian@cs.utwente.nl Tue Jul 16 22:20:59 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDFB21F9AEE for ; Tue, 16 Jul 2013 22:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUb8F74gJk6D for ; Tue, 16 Jul 2013 22:20:53 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id D51BD21F9A8F for ; Tue, 16 Jul 2013 22:20:52 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 17 Jul 2013 07:20:48 +0200 Received: from EXMBX21.ad.utwente.nl ([169.254.1.232]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 07:20:42 +0200 From: To: , Thread-Topic: [its] Please select area scoping the Charter Thread-Index: AQHOcbt5Gaa0t9xhE02lWAmiklk/CZlfFPMAgAlhY1iAAAD5sw== Date: Wed, 17 Jul 2013 05:20:41 +0000 Message-ID: References: <51C9BBCC.1090304@gmail.com>, <21E46EE9B979354990401539FD0A63E517747F@DAPHNIS.office.hd> In-Reply-To: <21E46EE9B979354990401539FD0A63E517747F@DAPHNIS.office.hd> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3B0F58EXMBX21adutwent_" MIME-Version: 1.0 Cc: Andreas.Festag@neclab.eu Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:20:59 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3B0F58EXMBX21adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alex, Agree with Andreas that the 1st option is relevant, but I am also in favour= of working on option 3, see the presentations that I gave on this topic on= previous IETF ITS meetings. This in favour for option 1 and 3! Best regards, Georgios ________________________________ Van: its-bounces@ietf.org [its-bounces@ietf.org] namens Andreas Festag [And= reas.Festag@neclab.eu] Verzonden: donderdag 11 juli 2013 10:02 To: Alexandru Petrescu; its@ietf.org Onderwerp: Re: [its] Please select area scoping the Charter Dear Alex, Re the area scoping: - I think the 1st option is relevant and to be done, e.g. enabling cars to = discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over= GeoNetworking. - Option 3 sounds interesting, but I am not aware of a solution that can be= standardized right away. So, this would require some research and analysis= . Kind regards, Andreas -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Tuesday, June 25, 2013 5:48 PM To: its@ietf.org Subject: [its] Please select area scoping the Charter Hello participants to ITS email list, During recent discussions we mentioned 3 different areas to work on. They are too many for a meaningful detail work. Please select area scoping the Charter, prioritizing according to the envir= onment you work on. 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Yours, 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 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3B0F58EXMBX21adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Alex,

 

Agree with Andreas that the 1st option is relevant, but I am also in fav= our of working on option 3, see the presentations that I gave on this = topic on previous IETF ITS meetings.

 

This in favour for option 1 and 3!

 

Best regards,

Georgios

 

Van: its-bounces@ietf.org [its-bounces@ietf.org] namens Andreas = Festag [Andreas.Festag@neclab.eu]
Verzonden: donderdag 11 juli 2013 10:02
To: Alexandru Petrescu; its@ietf.org
Onderwerp: Re: [its] Please select area scoping the Charter

Dear Alex,

Re the area scoping:

- I think the 1st option is relevant and to be done, e.g. enabling cars to = discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over= GeoNetworking.

- Option 3 sounds interesting, but I am not aware of a solution that can be= standardized right away. So, this would require some research and analysis= .

Kind regards,

Andreas

-----Original Message-----
From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petresc= u
Sent: Tuesday, June 25, 2013 5:48 PM
To: its@ietf.org
Subject: [its] Please select area scoping the Charter

Hello participants to ITS email list,

During recent discussions we mentioned 3 different areas to work on.
They are too many for a meaningful detail work.

Please select area scoping the Charter, prioritizing according to the envir= onment you work on.

1. establishment of IP networking between neighboring vehicles using
     either MANET protocols or 1-hop ICMP protocol.

2. layering of IPv6 over IEEE 802.11p communication technology.

3. IPv6-based network-layer distribution of content in a geographic
    area.

Yours,

Alex


_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its
_______________________________________________
its mailing list
its@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/its
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3B0F58EXMBX21adutwent_-- From Andreas.Festag@neclab.eu Wed Jul 17 08:10:15 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA4221E805A for ; Wed, 17 Jul 2013 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0ZHt6JfofEn for ; Wed, 17 Jul 2013 08:10:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7721E8056 for ; Wed, 17 Jul 2013 08:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A4FCB104BAC for ; Wed, 17 Jul 2013 17:09:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSmixajb30II for ; Wed, 17 Jul 2013 17:09:32 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7C243104B7F for ; Wed, 17 Jul 2013 17:09:27 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 17 Jul 2013 17:10:04 +0200 From: Andreas Festag To: "its@ietf.org" Thread-Topic: [its] Please select area scoping the Charter Thread-Index: AQHOcbuFnDcZm+3/3UCAKto6qU9tp5lfNPJwgAkg0oCAAMTMUA== Date: Wed, 17 Jul 2013 15:09:04 +0000 Message-ID: <21E46EE9B979354990401539FD0A63E5184F65@DAPHNIS.office.hd> References: <51C9BBCC.1090304@gmail.com>, <21E46EE9B979354990401539FD0A63E517747F@DAPHNIS.office.hd> 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.7.0.201] Content-Type: multipart/alternative; boundary="_000_21E46EE9B979354990401539FD0A63E5184F65DAPHNISofficehd_" MIME-Version: 1.0 Subject: Re: [its] Please select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:10:15 -0000 --_000_21E46EE9B979354990401539FD0A63E5184F65DAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Georgios, Re option 3, I thought that this might be relevant not only for ITS use cas= es. Therefore it might be worth looking at existing requirements and soluti= ons beyond ITS and take this into account. In any case, I share your favori= tes. Kind regards, Andreas From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] Sent: Wednesday, July 17, 2013 7:21 AM To: alexandru.petrescu@gmail.com; its@ietf.org Cc: Andreas Festag Subject: RE: [its] Please select area scoping the Charter Hi Alex, Agree with Andreas that the 1st option is relevant, but I am also in favour= of working on option 3, see the presentations that I gave on this topic on= previous IETF ITS meetings. This in favour for option 1 and 3! Best regards, Georgios ________________________________ Van: its-bounces@ietf.org [its-bounces@ietf.or= g] namens Andreas Festag [Andreas.Festag@neclab.eu] Verzonden: donderdag 11 juli 2013 10:02 To: Alexandru Petrescu; its@ietf.org Onderwerp: Re: [its] Please select area scoping the Charter Dear Alex, Re the area scoping: - I think the 1st option is relevant and to be done, e.g. enabling cars to = discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over= GeoNetworking. - Option 3 sounds interesting, but I am not aware of a solution that can be= standardized right away. So, this would require some research and analysis= . Kind regards, Andreas -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces= @ietf.org] On Behalf Of Alexandru Petrescu Sent: Tuesday, June 25, 2013 5:48 PM To: its@ietf.org Subject: [its] Please select area scoping the Charter Hello participants to ITS email list, During recent discussions we mentioned 3 different areas to work on. They are too many for a meaningful detail work. Please select area scoping the Charter, prioritizing according to the envir= onment you work on. 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Yours, 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 --_000_21E46EE9B979354990401539FD0A63E5184F65DAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Georgios,

 <= /p>

Re option 3, I thought th= at this might be relevant not only for ITS use cases. Therefore it might be= worth looking at existing requirements and solutions beyond ITS and take this into account. In any case, I share your favorites.<= /o:p>

 <= /p>

Kind regards,<= /span>

 <= /p>

Andreas=

 <= /p>

From: karagian= @cs.utwente.nl [mailto:karagian@cs.utwente.nl]
Sent: Wednesday, July 17, 2013 7:21 AM
To: alexandru.petrescu@gmail.com; its@ietf.org
Cc: Andreas Festag
Subject: RE: [its] Please select area scoping the Charter=

 

Hi Alex,

 

Agree with Andreas that the 1st option is releva= nt, but I am also in favour of working on option 3, see the presentations t= hat I gave on this topic on previous IETF ITS meetings.

 

This in favour for option 1 and 3!

 

Best regards,

Georgios

 

Van: its-bounces@ietf.org [its-bounc= es@ietf.org] namens Andreas Festag [Andreas.Festag@neclab.eu]
Verzonden: donderdag 11 juli 2013 10:02
To: Alexandru Petrescu; its@ietf.org=
Onderwerp: Re: [its] Please select area scoping the Charter

Dear Alex,

Re the area scoping:

- I think the 1st option is relevant and to be done, e.g. enabling cars to = discover their in-vehicle networks. It could run over ETSI TC ITS IPv6 over= GeoNetworking.

- Option 3 sounds interesting, but I am not aware of a solution that can be= standardized right away. So, this would require some research and analysis= .

Kind regards,

Andreas

-----Original Message-----
From: its-bounces@ietf.org [mailto:its-bounces@i= etf.org] On Behalf Of Alexandru Petrescu
Sent: Tuesday, June 25, 2013 5:48 PM
To: its@ietf.org
Subject: [its] Please select area scoping the Charter

Hello participants to ITS email list,

During recent discussions we mentioned 3 different areas to work on.
They are too many for a meaningful detail work.

Please select area scoping the Charter, prioritizing according to the envir= onment you work on.

1. establishment of IP networking between neighboring vehicles using
     either MANET protocols or 1-hop ICMP protocol.

2. layering of IPv6 over IEEE 802.11p communication technology.

3. IPv6-based network-layer distribution of content in a geographic
    area.

Yours,

Alex


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

--_000_21E46EE9B979354990401539FD0A63E5184F65DAPHNISofficehd_-- From Andreas.Festag@neclab.eu Wed Jul 17 08:17:03 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC711E8113 for ; Wed, 17 Jul 2013 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvPbCSMCRKlS for ; Wed, 17 Jul 2013 08:16:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B486411E80E6 for ; Wed, 17 Jul 2013 08:16:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 21149104BA1; Wed, 17 Jul 2013 17:16:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKAoRyPdpkOl; Wed, 17 Jul 2013 17:16:10 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 04C0A104B7C; Wed, 17 Jul 2013 17:16:00 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 17 Jul 2013 17:15:16 +0200 From: Andreas Festag To: "Dirk.von-Hugo@telekom.de" Thread-Topic: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) Thread-Index: AQHOgjoFIPAYdOjTX0yVOw7bKevHaZlo+//A Date: Wed, 17 Jul 2013 15:15:16 +0000 Message-ID: <21E46EE9B979354990401539FD0A63E5184F9E@DAPHNIS.office.hd> References: <1372025267.7392.41.camel@localhost> <20951.1372079256@sandelman.ca> <1372130355.7392.160.camel@localhost> <05C81A773E48DD49B181B04BA21A342A2C33C70A07@HE113484.emea1.cds.t-internal.com> <51E406F8.1050508@gmail.com> <05C81A773E48DD49B181B04BA21A342A2C52A59D36@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C52A59D36@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "its@ietf.org" Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 AddressAuto-Configuration) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:17:03 -0000 Dear Dirk, AFAIK, simTD did not apply IP over 802.11p (neither IPv4 nor IPv6). Kind regards, Andreas -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Dirk.= von-Hugo@telekom.de Sent: Tuesday, July 16, 2013 5:34 PM To: alexandru.petrescu@gmail.com; its@ietf.org Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 Addr= essAuto-Configuration) Hello Alex, Concerning your questions my impression is (if I understood it correctly fo= rm available documents) that SimTD did not specify IPv6 Prefix Exchange sin= ce the protocol stack shows IPv6 over IPv4 over 802.11p and other wireless = and cellular technologies - so I would guess that also no IPv6 straight ove= r 802.11p. There are Geoservers with polling Lat/Lon from the vehicles (and distributi= ng Geo data for warnings etc.) I anyone is more involved and can help with = details, I would be glad! Best regards Dirk -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Montag, 15. Juli 2013 16:28 To: its@ietf.org Subject: Re: [its] projects (was: P1609.3 Networking Services and IPv6 Addr= essAuto-Configuration) Dirk, Any idea whether the results of this project use: - dynamic IPv6 prefix exchanges between vehicles, or between vehicle and infrastructure? - IPv6-straight-over-80211p? - any form of geonetworking? Thanks, Alex Le 26/06/2013 11:19, Dirk.von-Hugo@telekom.de a =E9crit : > Hi all, > Speaking of actual use cases it may be of interest that the German projec= t SIMTD - "Safe, Intelligent Mobility - Test field Deutschland (Germany)" h= as completed to test the functionality, efficacy and feasibility for everyd= ay use of car-to-x communication under real-life driving conditions. Some = detailed information can be found here: http://simtd.de/index.dhtml/0251caa= e465f8345005d/-/enEN/-/CS/-/ and=09 > http://simtd.de/index.dhtml/0251caae465f8345005d/object.media/enEN/803 > 3/CS/-/news/Presse/simTD-Pressemitteilung_2013_EN.pdf > > Best regards > Dirk > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of=20 > Rex Buddenberg > Sent: Dienstag, 25. Juni 2013 05:19 > To: Michael Richardson > Cc: Alison Chaiken; its@ietf.org > Subject: Re: [its] P1609.3 Networking Services and IPv6=20 > AddressAuto-Configuration > > Michael, > > We might want to consider this the snowplow case; gets past some of your = human factors issues. Try this as a variant to the ambulance/siren illustr= ation. > > One of my friends and sounding board for such stuff works for Wyoming DoT= . He observes that the casualty rate among snowplow operators in Wy is hig= her than among cops. The typical accident scenario is when the plow is wor= king on I-80 and is overtaken by other traffic, the villain usually a semi.= If the semi driver doesn't figure out that it is a snowplow ahead of him = until too late, he's exceeded the intertia/road slickness limits, and rear-= ends the plow. (Trucks as a class are more prone to push the weather limit= s than the family sedan. If the family sedan is out in this weather, and i= s smart, he's tucked in behind the semi). > In this case, visibility is routinely awful (it's snowing, and often= blowing). And even if the plow had a siren, the semi driver probably woul= dn't hear it until too late. The sedan behind the semi is in an even worse= situation. > So this is a good use case for alerting message. > > > > On Mon, 2013-06-24 at 09:07 -0400, Michael Richardson wrote: >> Alison Chaiken wrote: >> alison> If passenger vehicles expect WSM on 802.11p, don't emergenc= y >> alison>vehicles then need 802.11p to communicate with them, irrespe= ctive >> alison>of LTE plans for emergency vehicles? Assuredly in the Grand >> alison>Connected Future we don't expect that emergency vehicles wil= l >> alison>communicate with individual drivers via audible alarms and >> alison>flashing lights only? And assuredly having emergency vehicl= es >> alison>call out siren messages over LTE to infrastructure which sen= ds >> alison>802.11p would be ridiculous? >> >> I don't know that it would be ridiculous to assume this. >> I agree that the latency might suck. I presume, however two things: >> >> 1) the route the *ambulance* or *fire* truck might take is well known >> in advance to the traffic control system ("in advance" is a relative >> term, in this I'm saying that 5s >> 0.1s maximum latency). >> So it need not be the vehicle *itself* that is calling out it's rout= e, >> the vehicle may well be following the route that the traffic control >> system has established. >> >> 2) my observation is that flashing lights and sirens have two undesireab= le >> affects. On overly consentious drivers (my mom-in-law, former er nu= rse), >> they yank the wheel, to get out the way, often so fast they nearly >> cause a collision themselves, even when the vehicle won't even be >> coming near them. >> On drivers who day-dream (my mom! "oh, was there a stop sign back t= here?") >> they don't notice a thing until the vehicle is stuck behind them. >> >> It would be very useful to both of them to be told that the vehicle=20 >> is coming, and that it will in fact affect them. >> >> >> -- >> ] Never tell me the odds! | ipv6 mesh netw= orks [ >> ] Michael Richardson, Sandelman Software Works | network archit= ect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rail= s [ >> > > > _______________________________________________ > 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 alison@she-devel.com Wed Jul 17 22:36:45 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5490521F9DED for ; Wed, 17 Jul 2013 22:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G889P6Xesz8S for ; Wed, 17 Jul 2013 22:36:41 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id EABBB21F9DDE for ; Wed, 17 Jul 2013 22:36:40 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so5989780iet.23 for ; Wed, 17 Jul 2013 22:36:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=OxA4qn/cCoyY1JppLazOC2qOsezA4Y7P2Rn5A/DLJ5M=; b=aNT9Gg0IQ/eLSUdHakTWdQj1st15jgbNsDX50ylKvGAxFcH/x66IUxhJnlsXpIJqYa jgc3iYcI9z/gftNJmlPZCuNxhRM8Fd83XCFrLrJJRDly02Ld4sgx0AyeaOgMoh+v+lZj 2b6/Zwgyj9JOnlypO1ntcNQQjLMiXjlHyuIjW98NYHfHoeI0qRu3lkeOIWRCvVLCYP9k xYEYXEVfwTgZ6ouhGMRfyo81SD7YVpQuCNnjqe6jdrO2KUn81RT1W0/6LTYe9jVewAfw 4xALslmgVKJkw7jRMySlIyw1n5ukRAh7TA9RANx88Pq4i1K2z58sRCugl54+ZasS2vVY YtYQ== MIME-Version: 1.0 X-Received: by 10.50.72.40 with SMTP id a8mr2571234igv.15.1374125800456; Wed, 17 Jul 2013 22:36:40 -0700 (PDT) Received: by 10.43.17.73 with HTTP; Wed, 17 Jul 2013 22:36:40 -0700 (PDT) Date: Wed, 17 Jul 2013 22:36:40 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlrYJi8HFDC44pRZye6m/HShL8veOe6hgvkuCON4FDttXcWAy5fmzxXUzYM+1N3u+kGpXb+ Subject: [its] IEEE 9/2013 Vehicular Technology Conference program with some V2X talks X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 05:36:45 -0000 http://www.ieeevtc.org/vtc2013fall/index.php -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou From alexandru.petrescu@gmail.com Wed Jul 24 01:16:18 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA711E83A9 for ; Wed, 24 Jul 2013 01:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNH9A8IOgA3G for ; Wed, 24 Jul 2013 01:16:08 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id BFED411E8128 for ; Wed, 24 Jul 2013 01:16:04 -0700 (PDT) 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 r6O8FxxO030054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jul 2013 10:15:59 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6O8Fx6X011290; Wed, 24 Jul 2013 10:15:59 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6O8FrLY022433; Wed, 24 Jul 2013 10:15:59 +0200 Message-ID: <51EF8D3A.9050503@gmail.com> Date: Wed, 24 Jul 2013 10:15:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rex Buddenberg References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1372352848.1665.88.camel@localhost> In-Reply-To: <1372352848.1665.88.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] IP agnosticity facing vehicular application types ( Please select area scoping the Charter) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:16:18 -0000 Le 27/06/2013 19:07, Rex Buddenberg a écrit : > On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote: >> and both consider IP is not about safety but rather entertainment. > > ??? This makes no sense. IP is about a set of communications > protocols. > > 'safety' usually implies some high availability requirements. There > are three principles of high availability engineering: > > - elimination of single points of failure. In comms systems this > usually boils down to altroutes and backup power. Provisioning > issue, has nothing to do with choices of technology ('IP' or > non-IP). > > - reliable crossover. In redundant systems the crossover switch > itself can become a single point of failure. And this is where IP > shines: routers do reliable crossover all day every day. I don't > know of any other comms technology that solves this problem by > protocol design or solves it as elegantly. > > - detection of failures as they occur. The function of a management > system, particularly fault management. SNMP is designed to do > exactly this (and a lot more). Rex, Let me bring back this topic. I agree that IP is agnostic with respect to the kinds of applications. Applications of any level of criticality (less or most demanding) are way above up the stack. A UDP stream as much as an RTP real time video stream are situated well above IP. And, a road telecom wireless infrastructure operator would certainly be interested in deploying highly available communications. But traditional non-telecom operators - like cellular - rely extensively on the use of Anchor points, i.e. Base Stations. They make use of these anchors which are, in fact, single points of failure. This would suggest to bring in another line to the above 3 principles of high availability engineering, which contradicts the single point of failure. Or maybe another explanation. Alex > > > Meet these principles for the most demanding applications (remember > that 'IP' is application-agnostic) and you have a super-solution for > everything else. > > > > > > From alexandru.petrescu@gmail.com Wed Jul 24 02:18:59 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA611E83EE for ; Wed, 24 Jul 2013 02:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgnSD4zhaZJg for ; Wed, 24 Jul 2013 02:18:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5B11E83E7 for ; Wed, 24 Jul 2013 02:18:53 -0700 (PDT) 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 r6O9IoJ4000619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jul 2013 11:18:50 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6O9IoPs010985; Wed, 24 Jul 2013 11:18:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6O9ISdn031873; Wed, 24 Jul 2013 11:18:50 +0200 Message-ID: <51EF9BE3.3090409@gmail.com> Date: Wed, 24 Jul 2013 11:18:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Dr. Hans-Joachim Fischer" References: <51E54781.9000605@gmail.com> <51E557CF.5070406@fischer-tech.eu> <51E629C2.6030303@fischer-tech.eu> In-Reply-To: <51E629C2.6030303@fischer-tech.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dickroy@alum.mit.edu, its@ietf.org Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS operating in the 5 GHz frequency band published X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:18:59 -0000 Hello Hans-Joachim, Le 17/07/2013 07:21, Dr. Hans-Joachim Fischer a écrit : > > This is all true, but only half of the story. You can set MIB > parameter dot11OCBActivated to true and consequently > dot11SpectrumManagementRequired to false and nevertheless a station > can implement spectrum management. It is not said that you need to > use a functionality of a semiconductor device which implements > 802.11. The requirement in the harmonized standard is simply that in > the BRAN band you have to check whether a channel is used before you > use it yourself. Ok, that sounds normal to check the channel availability before using it. I guess 802.11p doesn't do this, but 802.11a (where BRAN was originated?) may do it. Also, I think power limits for 802.11p on BRAN frequencies (5470 to 5725MHz) are still below the limits of some of the control and service channels on ITS frequencies (around 5880 and around 5900MHz). Which still makes these two latter channels very attractive for IP-straight-over-802.11p, compared to any other channel. > This is why car-to-car communication in the BRAN band is not very > reasonable, as there are only real peers. I tend to agree the BRAN band is less attractive for car-to-car communications, for these reasons. > For roadside-to-car communication you can design your system such > that communications always is initiated by the roadside ITS station > unit and thus the requirment for spectrum management in combination > with p-mode can be fulfilled. In a sense yes, spectrum management combined with p-mode, and on BRAN bands, may be useful for car-to-roadside. But even in car-to-roadside it may be advantageous to benefit from the p-mode at high power levels (rather than BRAN lower power levels). > By the way, car-to-car communications at 5 GHz in channels with 10 > MHz channel spacing is a dream. In most road traffic scenarios we > will face severe radio channel congestion problems. Well yes and no. In a traffic jam where there are as many p devices as cars, obviously there would be congestion if only pure p-mode were used. But they go slower too. But in other remote areas maybe the vehicles are so distanced and Access Points absent, that there would be little congestion. > Further on, my private opinion, car-to-car communication in no way > can significantly improve road traffic safety. In this sense, there is difficulty of passing 5GHz-band messages in some configurations - if a driver can't see, then there's little chance that the 5GHz-band messages gets through either, voiding the claims of wireless 'invisible' help to safety. (we've experienced this at some intersection configurations: once the line of sight is interrupted by some building or other vehicles, no IP message gets through. Once the line of sight is re-established the communication gets through, but the driver could see as well.) > We need autonomeous systems (in-car radar) Well, I am not an expert on non-IP radio communications. But, I suppose that although in-bumper radars (or above car turning devices) may be more reliable at their very simple task, may not help better than p-mode when there is no line of sight. I think this is so because of their higher and higher frequencies (5, 10, 60, 300GHz). The higher they are the straighter the line of sight must be, the worse they get through rain, the shorter the range, etc. I guess lower frequencies (WiFi 2.4GHz, UHF, and why not 27MHz) would be better at detecting obstacles and approaching vehicles around obstacles. Unless of course operators install some form of mirroring in center of intersections, or equip these traffic lights with wireless repeaters, or similar. > and distribution of trustable traffic information (coming for a > trusted source which can perform sensor fusion and plausibility > checks). Distribution of such trusted information via 5 GHz from > roadside ITS station units, or via LTE, is the solution for day 1 > procurement. This sounds like a requirement. Whereas 800MHz LTE solutions may already be deployed along some routes (to be confirmed), the deployment of ITS stations is in its infancy. When this happens, in order to distribute quickly trusted information via the 5GHz bands, one may need IPv6 communications, with fixed ITS stations, but maybe without the long delays of a complex core network. In this sense, it may be necessary to have simple protocols for quickly establishing connectivity between the vehicle and the nearest fixed ITS station. What do you think? Alex > > > Hans-Joachim > > Am 17.07.2013 00:24, schrieb Richard Roy: >> >> See below regarding G5C (BRAN usage) ... >> >>> -----Original Message----- >> >>> From:Dr. Hans-Joachim Fischer [mailto:HJFischer@fischer-tech.eu] >> >>> Sent: Tuesday, July 16, 2013 4:25 PM >> >>> To:its@ietf.org >> >>> Subject: Re: [its] Fwd: [ETSI_ITS_NEWS] ITS G5: European Standard >>> for ITS >> >>> operating in the 5 GHz frequency band published >> >>> >> >>> >> >>> There seems to be also a further significant change in this EN >>> compared >> >>> to earlier versions (as it was discussed recently at ETSI). The >>> usage of >> >>> the BRAN band is no more supported. >> >> [RR>] From 302 663 v1.2.1: >> >> " The requirement of TPC and DFS is covered in IEEE 802.11-2012 [3] >> through the MIB parameter >> >> dot11SpectrumManagementRequired set to true. When setting the MIB >> parameter dot11OCBActivated to >> >> true, dot11SpectrumManagementRequired is false, thus the two modes >> of operation are mutually exclusive. >> >> Hence, communication outside the context of a basic service set is >> not possible in the ITS-G5C band. But short range >> >> communication with a fixed station in the context of a BSS in >> combination with spectrum management is possible >> >> (e.g. in a garage) even though not specified for ITS-G5 stations at >> time of preparation of the present document." >> >> Unfortunately the ETSI guys didn't get it right this time either. >> There is nothing that states dot11OCBActivated has to be true in >> the G5C band. You simply execute normal 802.11 operations in that >> band using DFS and you are good to go. By writing the blanket >> statement that for ITS-G5 (meaning ALL G5 channels including G5C) >> dot11OCBActivated must be set to true, they shot themselves in the >> foot unnecessarily. (They were warned on many occasions by the >> way:^))) Again, there is NO REASON why a G5C radio needs to have >> dot11OCBActivated set to true. Set it to false for that interface, >> turn on the SpectrumManagement stuff and anything else you want, >> and voila ... DFS! >> >> Point is, anyone can ignore the part of the spec that say >> dot11OCBActivated has to be true in the G5C band and no one should >> care or complain. >> >> RR >> >>> This is a severe drawback for road >> >>> operators who need to use RSUs to connect to passing cars. >>> Allowing the >> >>> BRAN band (which is allowed by the base standard IEEE 802.11 >>> (p-mode) >> >>> and by the ISO 21215 standard (which was published before the EN >>> from >> >>> ETSI covering the same issue)) a RSU could use the CCH to send >>> out >> >>> service advertisement messages (FSAP, ISO 24102-5) which include >>> a >> >>> request to change channel (select a channel in the BRAN band to >>> run the >> >>> session). There we have enough bandwidth to allow for a system >>> where the >> >>> RSU implemented as a multi-channel device which can >>> simultaneously >> >>> operate several orthogonal channels, serving several cars >> >>> simultaneously. ISO 21215 does not restrict its usage to any kind >>> of >> >>> networking protocol. >> >>> >> >>> My two cents on what the end user really needs. >> >>> >> >>> We should be aware that the set of standards from ETSI is >>> designed in a >> >>> way to specify a system around the GeoNetworking / Congestion >>> Control >> >>> Protocols which are covered by IPRs. Luckily nobody needs to >>> implement a >> >>> specific standard as long as there is no related regulation. >> >>> >> >>> >> >>> Hans-Joachim >> >>> >> >>> Am 16.07.2013 15:15, schrieb Alexandru Petrescu: >> >>>> Hi ITSers, >> >>>> >> >>>> For your information, ETSI ITS announces it just published this >>>> document. >> >>>> >> >>>> ETSI EN 302 663 V1.2.1 >> >>>> >> >>> http://www.etsi.org/deliver/etsi_en/302600_302699/302663/01.02.01_60/en_30 >> >> >>> >>> >>> >>> >>> >>> >>> > 2663v010201p.pdf >> >>>> >> >>>> >> >>>> One interesting aspect is that, in my humble reading, it does >>>> not seem >> >>>> to prohibit the use of IP over an access layer operating at >>>> 5880 MHz at >> >>>> 33dBm EIRP (which is relatively high power, approx. 1km in line >>>> of >> >>>> sight). >> >>>> >> >>>> It and its references insist this particular channel G5-SCH1 >>>> is >> >>>> 'dedicated basically for ITS road safety' and that is 'the >>>> default >> >>>> channel for announcing and offering ITS services for safety & >>>> road >> >>>> efficiency under the DCC state ACTIVE and RESTRITIVE of the >>>> CCH. The >> >>>> transmissions of other message-types on the SCH1 are allowed if >>>> channel >> >>>> conditions according to the restrictions in the present >>>> document >> >>> permit.' >> >>>> >> >>>> This would mean, IMHO, that it still possible to exchange IP >>>> packets, >> >>>> directly between vehicles, over a MAC over a particular PHY at >>>> 5880MHz >> >>>> G5-SCH1, provided some conditions are met. >> >>>> >> >>>> One other interesting aspect is the changes from an earlier >>>> version in >> >>>> 2009: >> >>>> - the 10Mhz bands around 5910MHz and 5920MHz are now new bands >> >>>> allocated for 'ITS road traffic efficiency'. (previously they >>>> were >> >>>> not dedicated to anything). >> >>>> - renaming of another channel typically used for Radio LANs. >> >>>> >> >>>> Alex >> >>>> >> >>>> -------- Message original -------- >> >>>> Sujet: [ETSI_ITS_NEWS] ITS G5: European Standard for ITS >>>> operating >> >>> in >> >>>> the 5 GHz frequency band published >> >>>> Date : Wed, 10 Jul 2013 11:05:16 +0200 >> >>>> De : Martin Arndt >> >>>> Répondre à : Martin Arndt >> >>>> Pour : >> >>>> >> >>>> >> >>>> >> >>>> Dear all, >> >>>> >> >>>> Please note that the following European Standard has been >>>> published >> >>>> recently. You can download it for free via the link given >>>> below. >> >>>> >> >>>> *ETSI EN 302 663 V1.2.1 >> >>>> >> >>> > >> >>> >>> >>> >>> >>> >>> >>> > 02663v010201p.pdf>* >> >>>> >> >>>> >> >>>> Intelligent Transport Systems (ITS); >> >>>> >> >>>> Access layer specification for Intelligent Transport Systems >>>> operating >> >>>> in the 5 GHz frequency band >> >>>> >> >>>> This European Standard addresses the European Commission >>>> Standardization >> >>>> Mandate M/453. >> >>>> >> >>>> Kind regards, >> >>>> >> >>>> Martin >> >>>> >> >>>> ############################## >> >>>> >> >>>> Martin ARNDT >> >>>> >> >>>> Technical Officer >> >>>> >> >>>> ETSI Operations (OPS) >> >>>> >> >>>> Committee Support Centre (CSC) >> >>>> >> >>>> Telephone: +33 4 92 94 42 49 >> >>>> >> >>>> Skype: Mr Wavelength >> >>>> >> >>>> Email:martin.arndt@etsi.org >> >>>> >> >>>> Web:http://www.etsi.org >> >>>> >> >>>> ############################## >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> its mailing list >> >>>> its@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/its >> >>>> >> >>> >> >>> -- >> >>> -------------------------------------------------------------------------- >> >> >>> >>> >>> >>> >>> >>> >>> > ---- >> >>> ESF online-news:http://fischer-tech.eu/Feeds/esf.rss >> >>> C-ITS online news:http://its-standards.info/Feeds/cits.rss >> >>> -------------------------------------------------------------------------- >> >> >>> >>> >>> >>> >>> >>> >>> > ---- >> >>> The information contained in this message is confidential and may >>> be >> >>> legally privileged. The message is intended solely for the >>> addressee(s). >> >>> If you are not the intended recipient, you are hereby notified >>> that any >> >>> use, dissemination, or reproduction is strictly prohibited and >>> may be >> >>> unlawful. If you are not the intended recipient, please contact >>> the sender >> >>> by return e-mail and destroy all copies of the original message. >> >>> -------------------------------------------------------------------------- >> >> >>> >>> >>> >>> >>> >>> >>> > ---- >> >>> Dr. Hans-Joachim Fischer >> >>> ESF GmbH >> >>> Fichtenweg 9 >> >>> 89143 Blaubeuren >> >>> +49 (7344) 175340 >> >>> +49 (7344) 919123 (Fax) >> >>> http://fischer-tech.eu : Main web of ESF GmbH >> >>> http://its-standards.eu : News on cooperative ITS >>> standardization >> >>> http://its-testing.org : International consultancy for >>> cooperative ITS >> >>> -------------------------------------------------------------------------- >> >> >>> >>> >>> >>> >>> >>> >>> > ---- >> > > -- > ------------------------------------------------------------------------------ > > > > > > > > ESF online-news:http://fischer-tech.eu/Feeds/esf.rss > C-ITS online news:http://its-standards.info/Feeds/cits.rss > ------------------------------------------------------------------------------ > > > > > > > > The information contained in this message is confidential and may be legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > ------------------------------------------------------------------------------ > > > > > > > > Dr. Hans-Joachim Fischer > ESF GmbH Fichtenweg 9 89143 Blaubeuren +49 (7344) 175340 +49 (7344) > 919123 (Fax) http://fischer-tech.eu : Main web of ESF GmbH > http://its-standards.eu : News on cooperative ITS standardization > http://its-testing.org : International consultancy for cooperative > ITS > ------------------------------------------------------------------------------ > > > > > > > > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From alexandru.petrescu@gmail.com Wed Jul 24 02:32:58 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8911E83F3 for ; Wed, 24 Jul 2013 02:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itm+L8PnVKkM for ; Wed, 24 Jul 2013 02:32:53 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4884111E83F0 for ; Wed, 24 Jul 2013 02:32:52 -0700 (PDT) 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 r6O9WpVX006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Jul 2013 11:32:51 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6O9WpJh017770 for ; Wed, 24 Jul 2013 11:32:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6O9Wk67008876 for ; Wed, 24 Jul 2013 11:32:51 +0200 Message-ID: <51EF9F3D.7000708@gmail.com> Date: Wed, 24 Jul 2013 11:32:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> <51D7ECA4.8090104@gmail.com> In-Reply-To: <51D7ECA4.8090104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] Reminder - Plan for bar BoF, Thursday, Aug. 1st, 21h-22h, place to be confirmed X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:32:58 -0000 Reminder - let us have a bar BoF on Thursday, August 1st, 21h-22h, at a bar yet to be confirmed. Akex Le 06/07/2013 12:08, Alexandru Petrescu a écrit : > The date for ITS bar BoF is now: > > Thursday, August 1st 21h-22h > > I hope this fits, otherwise do not hesitate to object. > > Alex > > Le 05/07/2013 17:39, Dowdell, John a écrit : >> Alex >> >> Sounds good to me >> >> John John Dowdell Solution Architect, COEIC1 Cassidian Newport, UK >> Mobile +44 7710 875008 UAE desk +971 2 503 9017 >> >> ----- Original Message ----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, 2013 >> 04:26 PM GMT Standard Time To: Eliot Lear Cc: >> Dowdell, John; its@ietf.org Subject: Re: [its] Plan >> for bar BoF Monday after Technical Plenary? >> >> manet is followed by 6lo meeting and then bits'n'bytes (demos, >> food) until 21h. >> >> Would 21h-22h bar BoF ITS work? >> >> Alex >> >> Le 05/07/2013 13:24, Eliot Lear a écrit : >>> This woudn't kill me either. >>> >>> Eliot >>> >>> On 7/5/13 1:17 PM, Dowdell, John wrote: >>>> Alex >>>> >>>> I hope to be in town for the manet meeting, but will not >>>> arrive until Tuesday. I wonder if given the overlap between its >>>> and manet, it would be worth moving your BOF closer to the >>>> manet slot on Thursday. >>>> >>>> Regards John >>>> >>>> -----Original Message----- From: its-bounces@ietf.org >>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>> Sent: 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan >>>> for bar BoF Monday after Technical Plenary? >>>> >>>> Hi, >>>> >>>> I would like to plan for a bar BoF ITS in Berlin. >>>> >>>> What do you think about Monday evening after the Technical >>>> Plenary? >>>> >>>> Alex >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> The information contained within this e-mail and any files >>>> attached to this e-mail is private and in addition may include >>>> commercially sensitive information. The contents of this >>>> e-mail are for the intended recipient only and therefore if you >>>> wish to disclose the information contained within this e-mail >>>> or attached files, please contact the sender prior to any such >>>> disclosure. If you are not the intended recipient, any >>>> disclosure, copying or distribution is prohibited. Please also >>>> contact the sender and inform them of the error and delete the >>>> e-mail, including any attached files from your system. >>>> Cassidian Limited, Registered Office : Quadrant House, Celtic >>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>>> http://www.cassidian.com >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>> >>> >>> >> >> >> The information contained within this e-mail and any files >> attached to this e-mail is private and in addition may include >> commercially sensitive information. The contents of this e-mail are >> for the intended recipient only and therefore if you wish to >> disclose the information contained within this e-mail or attached >> files, please contact the sender prior to any such disclosure. If >> you are not the intended recipient, any disclosure, copying or >> distribution is prohibited. Please also contact the sender and >> inform them of the error and delete the e-mail, including any >> attached files from your system. Cassidian Limited, Registered >> Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 >> 8FZ Company No: 04191036 http://www.cassidian.com >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Wed Jul 24 02:37:13 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EE211E83B3 for ; Wed, 24 Jul 2013 02:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk7A0fwBYggA for ; Wed, 24 Jul 2013 02:37:08 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id D43A711E83EF for ; Wed, 24 Jul 2013 02:37:07 -0700 (PDT) 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 r6O9b6AG008262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Jul 2013 11:37:07 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6O9b6Mq020324 for ; Wed, 24 Jul 2013 11:37:06 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6O9b5rN018297 for ; Wed, 24 Jul 2013 11:37:06 +0200 Message-ID: <51EFA041.7020100@gmail.com> Date: Wed, 24 Jul 2013 11:37:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <51C9BBCC.1090304@gmail.com> In-Reply-To: <51C9BBCC.1090304@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] Continue - select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:37:13 -0000 Hello, Thanks to everybody who expressed oppinion towards scoping the activity. Until now, the first topic of establishment of IP networking between neighboring vehicles and vehicle-to-fixed-ITS-station seems to get most support. We need more discussion around scoping the Charter. If you have not already done so, please prioritize one topic among the three below, in order to scope the Charter. Alex Le 25/06/2013 17:48, Alexandru Petrescu a écrit : > Hello participants to ITS email list, > > During recent discussions we mentioned 3 different areas to work on. > They are too many for a meaningful detail work. > > Please select area scoping the Charter, prioritizing according to > the environment you work on. > > 1. establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol. > > 2. layering of IPv6 over IEEE 802.11p communication technology. > > 3. IPv6-based network-layer distribution of content in a geographic > area. > > Yours, > > Alex > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Wed Jul 24 05:09:08 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8111E8205 for ; Wed, 24 Jul 2013 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yDt6tK9qpo1 for ; Wed, 24 Jul 2013 05:08:59 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3292611E8202 for ; Wed, 24 Jul 2013 05:08:58 -0700 (PDT) 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 r6OC8u0I016364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Jul 2013 14:08:56 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6OC8tE3015385 for ; Wed, 24 Jul 2013 14:08:56 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6OC8thg028325 for ; Wed, 24 Jul 2013 14:08:55 +0200 Message-ID: <51EFC3D7.30306@gmail.com> Date: Wed, 24 Jul 2013 14:08:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1372352848.1665.88.camel@localhost> <51EF8D3A.9050503@gmail.com> In-Reply-To: <51EF8D3A.9050503@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] IP agnosticity facing vehicular application types ( Please select area scoping the Charter) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:09:08 -0000 Le 24/07/2013 10:15, Alexandru Petrescu a écrit : > Le 27/06/2013 19:07, Rex Buddenberg a écrit : >> On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote: >>> and both consider IP is not about safety but rather entertainment. >> >> ??? This makes no sense. IP is about a set of communications >> protocols. >> >> 'safety' usually implies some high availability requirements. There >> are three principles of high availability engineering: >> >> - elimination of single points of failure. In comms systems this >> usually boils down to altroutes and backup power. Provisioning >> issue, has nothing to do with choices of technology ('IP' or >> non-IP). >> >> - reliable crossover. In redundant systems the crossover switch >> itself can become a single point of failure. And this is where IP >> shines: routers do reliable crossover all day every day. I don't >> know of any other comms technology that solves this problem by >> protocol design or solves it as elegantly. >> >> - detection of failures as they occur. The function of a management >> system, particularly fault management. SNMP is designed to do >> exactly this (and a lot more). > > Rex, > > Let me bring back this topic. > > I agree that IP is agnostic with respect to the kinds of applications. > Applications of any level of criticality (less or most demanding) are > way above up the stack. A UDP stream as much as an RTP real time video > stream are situated well above IP. > > And, a road telecom wireless infrastructure operator would certainly be > interested in deploying highly available communications. > > But traditional non-telecom operators - like cellular - rely extensively ^non-vehicular telecom operators that is. Alex > on the use of Anchor points, i.e. Base Stations. They make use of these > anchors which are, in fact, single points of failure. This would > suggest to bring in another line to the above 3 principles of high > availability engineering, which contradicts the single point of failure. > Or maybe another explanation. > > Alex > >> >> >> Meet these principles for the most demanding applications (remember >> that 'IP' is application-agnostic) and you have a super-solution for >> everything else. >> >> >> >> >> >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From buddenbergr@gmail.com Wed Jul 24 08:37:29 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8124C11E8142 for ; Wed, 24 Jul 2013 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlifLoFyCnz0 for ; Wed, 24 Jul 2013 08:37:28 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9387011E80D3 for ; Wed, 24 Jul 2013 08:37:28 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id 10so519994pdi.11 for ; Wed, 24 Jul 2013 08:37:28 -0700 (PDT) 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:x-mailer:mime-version:content-transfer-encoding; bh=TZLMwXMtmHpJ4WH1FbTScE169gZKUaBoS8/WS0/MtMI=; b=pALiYyjmSa6E0+Z4scx5MHRnqXvqULhz4GacK0fejsLzWRU3TRNNTWNr3cLC7fdxDz WlvkwPozjYzam3BRy12pjwRDT2MsETdy+NfAwPbcVzGBenzV+2EfP4EVTcZnENqJOc/O nZwQSckHktZkx06Ksd8kbcRzig0IZx48F2S9pViogKRFlpmQgyvMDXYK/+wWKQv8O3Qe ZdGbcmI/OjkkYdQ7sA3Rg8LhUqek96tI42lID+KZDpcQ2EbRk2UOBpQWH9ifUz7r5051 2KvAjkRRSCCVbD/vahcRNTiwriEbov7Q9NuSJGWzZGBqJ53paSNapZGY+c11qJJX8sWp 0wGA== X-Received: by 10.66.252.234 with SMTP id zv10mr44177368pac.186.1374680248201; Wed, 24 Jul 2013 08:37:28 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id py4sm48583293pbc.14.2013.07.24.08.37.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Jul 2013 08:37:27 -0700 (PDT) Message-ID: <1374680245.2008.708.camel@localhost> From: Rex Buddenberg To: Alexandru Petrescu Date: Wed, 24 Jul 2013 08:37:25 -0700 In-Reply-To: <51EF8D3A.9050503@gmail.com> References: <51C9BBCC.1090304@gmail.com> <28782.1372182848@sandelman.ca> <9904FB1B0159DA42B0B887B7FA8119CA1AE654@AZ-FFEXMB04.global.avaya.com> <51CC524D.4060404@gmail.com> <1372352848.1665.88.camel@localhost> <51EF8D3A.9050503@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "Romascanu, Dan \(Dan\)" , "its@ietf.org" , Michael Richardson Subject: Re: [its] IP agnosticity facing vehicular application types ( Please select area scoping the Charter) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:37:29 -0000 Alex, >From below: > > But traditional non-telecom operators - like cellular - rely extensively > > on the use of Anchor points, i.e. Base Stations. They make use of these > > anchors which are, in fact, single points of failure. There are two ways that I can quickly think of to deal with base stations. They are single points of failure only if you let them. One way to ameliorate the problem is to increase the density of base stations so that the router in the vehicle has two or more base stations to talk with. The other way (these are not mutually exclusive) is to relay (v2v) until a vehicle is under a base station's footprint. As others have noted, this is highly volatile and dependent on (automobile) traffic density but it can work. Both qualify is elimination of single points of failure. But they do highlight the need to observe the second principle: reliable crossover. Because you'll be doing lots of crossovers! There are few problems at layer 3 because of the connectionless nature of IP. But some layer 2 protocols contain some state; as do, of course, transport layer connections. On Wed, 2013-07-24 at 10:15 +0200, Alexandru Petrescu wrote: > Le 27/06/2013 19:07, Rex Buddenberg a écrit : > > On Thu, 2013-06-27 at 16:55 +0200, Alexandru Petrescu wrote: > >> and both consider IP is not about safety but rather entertainment. > > > > ??? This makes no sense. IP is about a set of communications > > protocols. > > > > 'safety' usually implies some high availability requirements. There > > are three principles of high availability engineering: > > > > - elimination of single points of failure. In comms systems this > > usually boils down to altroutes and backup power. Provisioning > > issue, has nothing to do with choices of technology ('IP' or > > non-IP). > > > > - reliable crossover. In redundant systems the crossover switch > > itself can become a single point of failure. And this is where IP > > shines: routers do reliable crossover all day every day. I don't > > know of any other comms technology that solves this problem by > > protocol design or solves it as elegantly. > > > > - detection of failures as they occur. The function of a management > > system, particularly fault management. SNMP is designed to do > > exactly this (and a lot more). > > Rex, > > Let me bring back this topic. > > I agree that IP is agnostic with respect to the kinds of applications. > Applications of any level of criticality (less or most demanding) are > way above up the stack. A UDP stream as much as an RTP real time video > stream are situated well above IP. > > And, a road telecom wireless infrastructure operator would certainly be > interested in deploying highly available communications. > > But traditional non-telecom operators - like cellular - rely extensively > on the use of Anchor points, i.e. Base Stations. They make use of these > anchors which are, in fact, single points of failure. This would > suggest to bring in another line to the above 3 principles of high > availability engineering, which contradicts the single point of failure. > Or maybe another explanation. > > Alex > > > > > > > Meet these principles for the most demanding applications (remember > > that 'IP' is application-agnostic) and you have a super-solution for > > everything else. > > > > > > > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From emmanuel.baccelli@gmail.com Thu Jul 25 03:26:19 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A322721F9AD6 for ; Thu, 25 Jul 2013 03:26:19 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfviGd7kQU1u for ; Thu, 25 Jul 2013 03:26:18 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B0F4821F9AD1 for ; Thu, 25 Jul 2013 03:26:18 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id fb19so1115930obc.9 for ; Thu, 25 Jul 2013 03:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=V3HmwE0y9H3waUs1AWckSJd6Ww4K9bVRBzKzj/lM4Ck=; b=e2tNeX3P0vg4YY0fFQw2kLUmDmgLvtpXG4eWgSV6+x+wAof/+233tj62HHf0TGMDnv lwzvfCW3Qpb3inEupBS59ehO3JreLaFtgBBVR65IuHwzm84hUb83Mhi4c7vAWuB6ZOnc Zayo68vjTnHheElzI+bY8Ua78JT9k+Crd7GDWohX7j7Q2YOcKoLml2qYC6UEVC+97DHX OzR7dL7msibtT7zzshm47Hm/23+TEAmGqnhX8JOLlYINremUCjsbsFF5pNZvcEYDJt4Z ft6+X7hU7WDlXKecyLQOTvKVilRi+LBU7dSIrzwWQZkcWEOi65ZygqQj8gruT9kMDTK/ DwJw== X-Received: by 10.60.161.44 with SMTP id xp12mr40974651oeb.91.1374747978275; Thu, 25 Jul 2013 03:26:18 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Thu, 25 Jul 2013 03:25:58 -0700 (PDT) From: Emmanuel Baccelli Date: Thu, 25 Jul 2013 12:25:58 +0200 X-Google-Sender-Auth: Z8pf9e4rvu2xGj-e0zWAy9iNAlE Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=089e01184a24e69df904e2537403 Subject: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 10:26:20 -0000 --089e01184a24e69df904e2537403 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I don't know how technically relevant these are, but I stumbled on an article and a TED talk that advocate for car-to-car communications and ITS. So I thought I'd just share them, just in case there might be something relevant/useful for someone here. http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to_each_other http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be_avoidable.html Best, Emmanuel --089e01184a24e69df904e2537403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,

I don't know how tec= hnically relevant these are, but I stumbled on an article and a TED talk th= at advocate for car-to-car communications and ITS. So I thought I'd jus= t share them, just in case there might be something relevant/useful for som= eone here.


Best,

= Emmanuel
--089e01184a24e69df904e2537403-- From alexandru.petrescu@gmail.com Thu Jul 25 06:32:07 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DC821F9B18 for ; Thu, 25 Jul 2013 06:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.056 X-Spam-Level: X-Spam-Status: No, score=-9.056 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_VISIT=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YngREvfDk5Kp for ; Thu, 25 Jul 2013 06:32:02 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7020C21F8CB4 for ; Thu, 25 Jul 2013 06:32:02 -0700 (PDT) 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 r6PDW11I024535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 25 Jul 2013 15:32:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6PDW0Ir028599 for ; Thu, 25 Jul 2013 15:32:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6PDVu6U015326 for ; Thu, 25 Jul 2013 15:32:00 +0200 Message-ID: <51F128CC.1040806@gmail.com> Date: Thu, 25 Jul 2013 15:31:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:32:07 -0000 Emmanuel, Allow me to rant on this. These and other[*] pointers are good illustrations about how intriguing visions of car-to-car communications could be developped. The TED presentation is particular in that it uses drama tools to sell car-talk technology. In general, the vehicular industry players are excellent dream makers since some time now: the car itself is such. Add this or that option and it's so much better. I personally look at them in some detail, actively searching for one particular facet of such vision: do they mention the challenges of _IP_ communications from vehicle to vehicle? Because some if not all V2V visions getting front stage seem to focus on matters other than IP: radar/lidar-based echo detection of nearby vehicles and pedestrians, fast and rough form recognition, broadcasting tourism information. As stimulating as they may appear, they may have little to do with IP - some demonstrated prototypes not doing IP. When someone says 'V2V' I feel the urge to ask some questions: Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? Is it V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed infrastructure in between? Is it radio beam echoed back by a solid? (aka 'radar') Velocity transmitted from one V to another is how? kmph or mph? transmitted as value or detected by radars? as a sequence of positions with time measured at destination? Is it localization data as WGS84 or as ED50 (or otherwise how to automate the promotion of 802.11p over 800MHz-LTE near old military camps)? IF these V-to-V data transmitted are actually IP packets, what are src and dst addresses? How do vehicles 'discover' each other? Where do they get their addresses from? LED headlights avoid blinding the incoming driver, but are they LiFi and IP-over-LiFi? Because, some of the visions may bear little ressemblance to what may get deployed - they may be too high level. Even on this email list, we have seen statements about visions, and counter statements about some visions being just dreams. Alex [*] The Economist ran recently an entire Quarterly about the Future of the Car "Clean, safe and it drives itself", and an article on "Driverless Automobiles" (imagine _that_ w/o communication - a nightmare). Le 25/07/2013 12:25, Emmanuel Baccelli a écrit : > Hi guys, > > I don't know how technically relevant these are, but I stumbled on > an article and a TED talk that advocate for car-to-car > communications and ITS. So I thought I'd just share them, just in > case there might be something relevant/useful for someone here. > > http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to_each_other > > > > > > > > > http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be_avoidable.html > > Best, > > Emmanuel > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > From emmanuel.baccelli@gmail.com Thu Jul 25 06:55:08 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7289121F9A5F for ; Thu, 25 Jul 2013 06:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[AWL=-1.983, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WKfMzngI5wT for ; Thu, 25 Jul 2013 06:55:07 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB321F9A13 for ; Thu, 25 Jul 2013 06:55:03 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so1519546obc.38 for ; Thu, 25 Jul 2013 06:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=WdzFLWOR0Qt5X5bMmtYuL1TQFD3NUgJNNHKMqMFDAKw=; b=wrtCQ+bw6DGkT3L311YO/8ekgcM2disQRIehuUvYBbagrk2aAqKpQOD+EONaj4gUen SKBLtnexJjlEKQ7QkUgv5E9CFd2N/XrD/RygiUNJFo/p+0QZtsrkZVgSpmw0HToI7yzE lpBtJhWzHENfb+jy93DUQM7D7dTRDhqlpmQA4vwVlBkCAjZLfnufoxgXRS0Pu15ShlZA nFKDuwyS/O+VvWz0tGO5feAzWzclFFT/l5v8E7fvflTULE4Ehn1dUQi3QlTMtQ1GQDM0 besZKa1AIeDHHi+vnjR4hiF5TPUdIEtQXpMIkxp7VB88rqBTeXulCCEjosYBl0VIBAxh atwQ== X-Received: by 10.60.161.44 with SMTP id xp12mr41923708oeb.91.1374760503339; Thu, 25 Jul 2013 06:55:03 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Thu, 25 Jul 2013 06:54:43 -0700 (PDT) In-Reply-To: <51F128CC.1040806@gmail.com> References: <51F128CC.1040806@gmail.com> From: Emmanuel Baccelli Date: Thu, 25 Jul 2013 15:54:43 +0200 X-Google-Sender-Auth: 22J6C-x3hlNTcFXxjmGkuerSTxY Message-ID: To: its@ietf.org Content-Type: multipart/alternative; boundary=089e01184a2473ee2304e2565fad Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:55:08 -0000 --089e01184a2473ee2304e2565fad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alexandru, rant permission granted. These links where not pointing to any technically interesting content as far as *we* are concerned. But we can still use this content to say something like: "if you're motivated by such high level perspectives (as depicted in TED Talk, article, you-name-it), then you should let us do it with IP, because other solutions will suck fast". Best Emmanuel On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Emmanuel, > > Allow me to rant on this. > > These and other[*] pointers are good illustrations about how intriguing > visions of car-to-car communications could be developped. The TED > presentation is particular in that it uses drama tools to sell car-talk > technology. > > In general, the vehicular industry players are excellent dream makers > since some time now: the car itself is such. Add this or that option > and it's so much better. > > I personally look at them in some detail, actively searching for one > particular facet of such vision: do they mention the challenges of _IP_ > communications from vehicle to vehicle? > > Because some if not all V2V visions getting front stage seem to focus > on matters other than IP: radar/lidar-based echo detection of nearby > vehicles and pedestrians, fast and rough form recognition, broadcasting > tourism information. As stimulating as they may appear, they may have > little to do with IP - some demonstrated prototypes not doing IP. > > When someone says 'V2V' I feel the urge to ask some questions: > > Is it V-to-LTE-BaseStation-to-HA-**and-back-to-V? Is it > V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed > infrastructure in between? > > Is it radio beam echoed back by a solid? (aka 'radar') > > Velocity transmitted from one V to another is how? kmph or mph? > transmitted as value or detected by radars? as a sequence of positions > with time measured at destination? Is it localization data as WGS84 or > as ED50 (or otherwise how to automate the promotion of 802.11p over > 800MHz-LTE near old military camps)? > > IF these V-to-V data transmitted are actually IP packets, what are src > and dst addresses? How do vehicles 'discover' each other? Where do > they get their addresses from? > > LED headlights avoid blinding the incoming driver, but are they LiFi and > IP-over-LiFi? > > Because, some of the visions may bear little ressemblance to what may > get deployed - they may be too high level. Even on this email list, we > have seen statements about visions, and counter statements about some > visions being just dreams. > > Alex > [*] The Economist ran recently an entire Quarterly about the Future of > the Car "Clean, safe and it drives itself", and an article on > "Driverless Automobiles" (imagine _that_ w/o communication - a nightmare)= . > > > Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit : > > Hi guys, >> >> I don't know how technically relevant these are, but I stumbled on >> an article and a TED talk that advocate for car-to-car >> communications and ITS. So I thought I'd just share them, just in >> case there might be something relevant/useful for someone here. >> >> http://www.computerworld.com/**s/article/9241037/Feds_want_** >> cars_to_talk_to_each_other >> >> >> >> >> >> >> >> >> >> http://www.ted.com/talks/**jennifer_healey_if_cars_could_** > talk_accidents_might_be_**avoidable.html > >> >> Best, >> >> Emmanuel >> >> >> ______________________________**_________________ 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 > --089e01184a2473ee2304e2565fad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexandru,
rant permission granted. These lin= ks where not pointing to any technically interesting content as far as *we*= are concerned. But we can still use this content to say something like: &q= uot;if you're motivated by such high level perspectives (as depicted in= TED Talk, article, you-name-it), then you should let us do it with IP, bec= ause other solutions will suck fast".
Best
Emmanuel



On Thu, Jul 25,= 2013 at 3:32 PM, Alexandru Petrescu <alexandru.petrescu@gmail.= com> wrote:
Emmanuel,

Allow me to rant on this.

These and other[*] pointers are good illustrations about how intriguing
visions of car-to-car communications could be developped. =A0The TED
presentation is particular in that it uses drama tools to sell car-talk
technology.

In general, the vehicular industry players are excellent dream makers
since some time now: the car itself is such. =A0Add this or that option
and it's so much better.

I personally look at them in some detail, actively searching for one
particular facet of such vision: do they mention the challenges of _IP_
communications from vehicle to vehicle?

Because some if not all V2V visions getting front stage seem to focus
on matters other than IP: radar/lidar-based echo detection of nearby
vehicles and pedestrians, fast and rough form recognition, broadcasting
tourism information. =A0As stimulating as they may appear, they may have little to do with IP - some demonstrated prototypes not doing IP.

When someone says 'V2V' I feel the urge to ask some questions:

Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? =A0Is it
V-to-ITSStation-to-V? =A0Or is it direct V-to-V without any fixed
infrastructure in between?

Is it radio beam echoed back by a solid? (aka 'radar')

Velocity transmitted from one V to another is how? kmph or mph?
transmitted as value or detected by radars? =A0as a sequence of positions with time measured at destination? Is it localization data as WGS84 or
as ED50 (or otherwise how to automate the promotion of 802.11p over
800MHz-LTE near old military camps)?

IF these V-to-V data transmitted are actually IP packets, what are src
and dst addresses? =A0How do vehicles 'discover' each other? =A0Whe= re do
they get their addresses from?

LED headlights avoid blinding the incoming driver, but are they LiFi and IP-over-LiFi?

Because, some of the visions may bear little ressemblance to what may
get deployed - they may be too high level. =A0Even on this email list, we have seen statements about visions, and counter statements about some
visions being just dreams.

Alex
[*] The Economist ran recently an entire Quarterly about the Future of
the Car "Clean, safe and it drives itself", and an article on
"Driverless Automobiles" (imagine _that_ w/o communication - a ni= ghtmare).


Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :
Hi guys,

I don't know how technically relevant these are, but I stumbled on
an article and a TED talk that advocate for car-to-car
communications and ITS. So I thought I'd just share them, just in
case there might be something relevant/useful for someone here.

http://www.computerworld.com/= s/article/9241037/Feds_want_cars_to_talk_to_each_other









http://www.ted.com/talks/<= u>jennifer_healey_if_cars_could_talk_accidents_might_be_a= voidable.html

Best,

Emmanuel


_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its



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

--089e01184a2473ee2304e2565fad-- From emmanuel.baccelli@gmail.com Fri Jul 26 01:23:15 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A17321F8517 for ; Fri, 26 Jul 2013 01:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL3hx2VGbV-g for ; Fri, 26 Jul 2013 01:23:03 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 167A021F849C for ; Fri, 26 Jul 2013 01:23:01 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so3748725obb.14 for ; Fri, 26 Jul 2013 01:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5Q0IJEMkoZmqKm4jB5LcNvZ53swOISpi3OJlo2d0eas=; b=buqQPhe6QsR6E1H2H4qsunBNto7sfPUf0JQxDSqRHRiTAdZCiE5Ot4CTIt+NdS64Q8 V3ZuH7WSJj+ef6UACyS7Ao9KwP5ZJHmA0T6Y13w8MdlzpdNBuyx2fBZyClgJtXFTOTZy lAR2N1z/rCUYAXdJyLaxFYoyYY/jp6inm9AhyidAUtIs7cQIdGPAXbv8Z2dj1vmvxATW 9Ee4HgvyZ4q5EGvBtEKqHM9d4haSP5CWCv5qQ/KG3AxBlwLJeWMGmC307e6TmhHSlu6+ Bg0a7HgsFAnztxJEEXXKPhB3+BUc0vzXd7qnZJ1i4+UQap4wW8X/UHZ6v0KFNK5jLsnI Bd7Q== X-Received: by 10.182.176.34 with SMTP id cf2mr40627179obc.45.1374826971510; Fri, 26 Jul 2013 01:22:51 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Fri, 26 Jul 2013 01:22:30 -0700 (PDT) In-Reply-To: <303EC1E547984298B75F80F687980FAF@SRA4> References: <303EC1E547984298B75F80F687980FAF@SRA4> From: Emmanuel Baccelli Date: Fri, 26 Jul 2013 10:22:30 +0200 X-Google-Sender-Auth: 7QjapzJ5PkHWpS9IPJL7misEIcU Message-ID: To: dickroy@alum.mit.edu Content-Type: multipart/alternative; boundary=e89a8ff1cf8243c10604e265d93f Cc: its@ietf.org Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:23:15 -0000 --e89a8ff1cf8243c10604e265d93f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard, yes you're right, IP does not make coffee. But realistically, nowadays, you rather have to justify why you're *not* using IP, rather than why you *are* using IP. I don't think 5-10% savings are a good enough reason to not use IP. Best, Emmanuel On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy wrote: > See below ...**** > > ** ** > ------------------------------ > > *From:* Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > *Sent:* Thursday, July 25, 2013 6:55 AM > *To:* its@ietf.org > *Subject:* Re: [its] Article + TED talk**** > > ** ** > > Hi Alexandru,**** > > rant permission granted. These links where not pointing to any technicall= y > interesting content as far as *we* are concerned. But we can still use th= is > content to say something like: "if you're motivated by such high level > perspectives (as depicted in TED Talk, article, you-name-it), then you > should let us do it with IP, because other solutions will suck fast".**** > > *[RR>] You really need to understand the application requirements before > making such a statement. In the TED talk, the message was "let your car > [ed: and the pedestrian on the sidewalk and the bicyclist in the bike lan= e] > BROADCAST its kinematic state estimate [ed. and its estimate error > covariance] to all others in the vicinity [ed. at an appropriate rate] so > that all cars in a local area [ed. can build up a Local Dynamic Map or LD= M > and] can avoid collisions. This is all point-to-point communications wit= h > no network required or desired at all ... not even an ad hoc network of > vehicles ... just BSMs/CAMs (here-I-am messages) transmitted to increase > safety on the roads. For this particular application, there is NO need f= or > a 40 byte IPv6 header when a 3 byte header (se FNTP) will suffice. > Maximizing useful content transfer in a capacity constrained channel is = a > VERY good idea. Those 37 saved bytes turn out to be roughly somewhere fr= om > 5-10% (depending on data sent, certificate sizes and a few other things) = of > the transmitted stream (PPDU) over the air, and that's not inconsequentia= l > when talking about your personal physical safety or that of your family! > * > > * * > > *IP is a sound and obviously successful NETWORKING technology ... however > that does NOT mean it can brush your teeth too! That's a job for > toothbrushes!* > > * * > > *RR* > > * ian on the sidewalk] BROADCAST its kinematic state estiamte a***** > > Best**** > > Emmanuel**** > > ** ** > > ** ** > > On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote:**** > > Emmanuel, > > Allow me to rant on this. > > These and other[*] pointers are good illustrations about how intriguing > visions of car-to-car communications could be developped. The TED > presentation is particular in that it uses drama tools to sell car-talk > technology. > > In general, the vehicular industry players are excellent dream makers > since some time now: the car itself is such. Add this or that option > and it's so much better. > > I personally look at them in some detail, actively searching for one > particular facet of such vision: do they mention the challenges of _IP_ > communications from vehicle to vehicle? > > Because some if not all V2V visions getting front stage seem to focus > on matters other than IP: radar/lidar-based echo detection of nearby > vehicles and pedestrians, fast and rough form recognition, broadcasting > tourism information. As stimulating as they may appear, they may have > little to do with IP - some demonstrated prototypes not doing IP. > > When someone says 'V2V' I feel the urge to ask some questions: > > Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? Is it > V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed > infrastructure in between? > > Is it radio beam echoed back by a solid? (aka 'radar') > > Velocity transmitted from one V to another is how? kmph or mph? > transmitted as value or detected by radars? as a sequence of positions > with time measured at destination? Is it localization data as WGS84 or > as ED50 (or otherwise how to automate the promotion of 802.11p over > 800MHz-LTE near old military camps)? > > IF these V-to-V data transmitted are actually IP packets, what are src > and dst addresses? How do vehicles 'discover' each other? Where do > they get their addresses from? > > LED headlights avoid blinding the incoming driver, but are they LiFi and > IP-over-LiFi? > > Because, some of the visions may bear little ressemblance to what may > get deployed - they may be too high level. Even on this email list, we > have seen statements about visions, and counter statements about some > visions being just dreams. > > Alex > [*] The Economist ran recently an entire Quarterly about the Future of > the Car "Clean, safe and it drives itself", and an article on > "Driverless Automobiles" (imagine _that_ w/o communication - a nightmare)= . > > > Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :**** > > ** ** > > Hi guys, > > I don't know how technically relevant these are, but I stumbled on > an article and a TED talk that advocate for car-to-car > communications and ITS. So I thought I'd just share them, just in > case there might be something relevant/useful for someone here. > > > http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to_= each_other > > > > > > > > > **** > > > http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_mig= ht_be_avoidable.html > **** > > > Best, > > Emmanuel > > > _______________________________________________ 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**** > > ** ** > --e89a8ff1cf8243c10604e265d93f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,
yes you're right, IP does not ma= ke coffee.
But realistically, nowadays, you rather have to = justify why you're *not* using IP, rather than why you *are* using IP.<= /div>
I don't think 5-10% savings are a good enough reason to not = use IP.
Best,
Emmanuel


On Fri, Jul 26, 2013 a= t 9:11 AM, Richard Roy <dickroy@alum.mit.edu> wrote:

See below ...

=A0

From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr]
Sent: Thursday, July 25, 201= 3 6:55 AM
To: its@ietf.org
Subject: Re: [its] Article += TED talk

=A0

Hi Alexandru,

rant permission granted. These links where not point= ing to any technically interesting content as far as *we* are concerned. But we can still use this content to say something like: "if you're motivated by such high l= evel perspectives (as depicted in TED Talk, article, you-name-it), then you shou= ld let us do it with IP, because other solutions will suck fast".<= u>

[RR>] You really need to understand the application requirements before making such a statement. =A0In the TED talk, the messag= e was "let your car [ed: and the pedestrian on the sidewalk and the bicyclis= t in the bike lane] BROADCAST its kinematic state estimate [ed. and its estimate error covariance] to all others in the vicinity [ed. at an appropriate rate= ] so that all cars in a local area [ed. can build up a Local Dynamic Map or LDM = and] can avoid collisions. =A0This is all point-to-point communications with no network required or desired at all ... not even an ad hoc network of vehicl= es ... just BSMs/CAMs (here-I-am messages) transmitted to increase safety on t= he roads. =A0For this particular application, there is NO need for a 40 byte I= Pv6 header when a 3 byte header (se FNTP) will suffice. =A0Maximizing useful co= ntent transfer in a capacity constrained channel is a VERY good idea. =A0Those 37= saved bytes turn out to be roughly somewhere from 5-10% (depending on data sent, = certificate sizes and a few other things) of the transmitted stream (PPDU) over the air= , and that's not inconsequential when talking about your personal physica= l safety or that of your family!=A0

=A0

IP is a sound and obviously successful NETWORKING technology ... however that does NOT mean it can brush your teeth too!=A0 That's a= job for toothbrushes!

=A0

RR

=A0=A0=A0ian on the sidewalk] BROADCAST its kinematic state estiamte a

Best

Emmanuel

=A0

=A0

On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu = <alexa= ndru.petrescu@gmail.com> wrote:

Emmanuel,

Allow me to rant on this.

These and other[*] pointers are good illustrations about how intriguing
visions of car-to-car communications could be developped. =A0The TED
presentation is particular in that it uses drama tools to sell car-talk
technology.

In general, the vehicular industry players are excellent dream makers
since some time now: the car itself is such. =A0Add this or that option
and it's so much better.

I personally look at them in some detail, actively searching for one
particular facet of such vision: do they mention the challenges of _IP_
communications from vehicle to vehicle?

Because some if not all V2V visions getting front stage seem to focus
on matters other than IP: radar/lidar-based echo detection of nearby
vehicles and pedestrians, fast and rough form recognition, broadcasting
tourism information. =A0As stimulating as they may appear, they may have little to do with IP - some demonstrated prototypes not doing IP.

When someone says 'V2V' I feel the urge to ask some questions:

Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? =A0Is it
V-to-ITSStation-to-V? =A0Or is it direct V-to-V without any fixed
infrastructure in between?

Is it radio beam echoed back by a solid? (aka 'radar')

Velocity transmitted from one V to another is how? kmph or mph?
transmitted as value or detected by radars? =A0as a sequence of positions with time measured at destination? Is it localization data as WGS84 or
as ED50 (or otherwise how to automate the promotion of 802.11p over
800MHz-LTE near old military camps)?

IF these V-to-V data transmitted are actually IP packets, what are src
and dst addresses? =A0How do vehicles 'discover' each other? =A0Whe= re do
they get their addresses from?

LED headlights avoid blinding the incoming driver, but are they LiFi and IP-over-LiFi?

Because, some of the visions may bear little ressemblance to what may
get deployed - they may be too high level. =A0Even on this email list, we have seen statements about visions, and counter statements about some
visions being just dreams.

Alex
[*] The Economist ran recently an entire Quarterly about the Future of
the Car "Clean, safe and it drives itself", and an article on
"Driverless Automobiles" (imagine _that_ w/o communication - a nightmare).


Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :

=A0

Hi guys,

I don't know how technically relevant these are, but I stumbled on
an article and a TED talk that advocate for car-to-car
communications and ITS. So I thought I'd just share them, just in
case there might be something relevant/useful for someone here.

http://www.computerworld.com/s/artic= le/9241037/Feds_want_cars_to_talk_to_each_other








htt= p://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be= _avoidable.html


Best,

Emmanuel


_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its



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

=A0


--e89a8ff1cf8243c10604e265d93f-- From emmanuel.baccelli@gmail.com Fri Jul 26 01:54:04 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32221F8F07 for ; Fri, 26 Jul 2013 01:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPgNGwAD3fr1 for ; Fri, 26 Jul 2013 01:53:57 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CE5C021F8F78 for ; Fri, 26 Jul 2013 01:53:49 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so3795307obb.14 for ; Fri, 26 Jul 2013 01:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=B4e8Z3rMajnwDNosl7tAwFuF0eyROaM+8UXoC7OZKg4=; b=UJun2Zh+m/4t8jzwDwryr3yiN/23SoSbt6v/lSa4RuDKjsN/UtHN7h337+EMw6KiMK B7YjU+wHfLJ5YZRBgAw3eu/eNtXN/VcOUSJG/3cZhwBzw8CNE+JZb2Fcu94/C1cD5Zxk A1bhcSyCz3Bjw8jbQ1kp1rH2j3zlaYUe2Y/wGeKg8vI/W+y3XqRQSaEiDMYPwZCzstPl T6G7LvJQSChnwm8ZSAnglE5rmgqNeEKGCrjAInNw4X0FI6fQ8gSsM/yuwVHWQJUzUX8/ muKznWlAaFZqEr1v1yixaDxIAMZ39RBt6t8wRzTC9VUmAsn5QfBy7OYBRLB+gZbClssQ TuaQ== X-Received: by 10.60.161.44 with SMTP id xp12mr46334832oeb.91.1374828828130; Fri, 26 Jul 2013 01:53:48 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Fri, 26 Jul 2013 01:53:27 -0700 (PDT) In-Reply-To: References: <303EC1E547984298B75F80F687980FAF@SRA4> From: Emmanuel Baccelli Date: Fri, 26 Jul 2013 10:53:27 +0200 X-Google-Sender-Auth: 0QbGpPUwzlCBH2mMCDFe7XIvMw0 Message-ID: To: dickroy Content-Type: multipart/alternative; boundary=089e01184a24ed89b204e266477b Cc: its@ietf.org Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:54:04 -0000 --089e01184a24ed89b204e266477b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard, I understand your argument. On the other hand, if using IP makes the technology cheaper (which often happens nowadays), then you could actually save lives because more cars will be equipped more quickly. Best Emmanuel On Fri, Jul 26, 2013 at 10:46 AM, Richard Roy wrote: > ** ** > > ** ** > ------------------------------ > > *From:* emmanuel.baccelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] = *On > Behalf Of *Emmanuel Baccelli > *Sent:* Friday, July 26, 2013 1:23 AM > *To:* dickroy@alum.mit.edu > *Cc:* its@ietf.org > > *Subject:* Re: [its] Article + TED talk > **** > > ** ** > > Hi Richard,**** > > yes you're right, IP does not make coffee.**** > > But realistically, nowadays, you rather have to justify why you're *not* > using IP, rather than why you *are* using IP.**** > > I don't think 5-10% savings are a good enough reason to not use IP.**** > > *[RR>] You are of course free to have such thoughts. However, allow me > to suggest that it is a really good reason when safety of life and proper= ty > are involved. If you were the 1 in 10 that lost his/her life because of > extra needless congestion on the channel, congestion which could have bee= n > prevented by not using a verbose and useless protocol for this applicatio= n, > I suggest you'd care ... or at least your family would care. Not all > communications on the planet need IP.* > > * * > > *RR* > > * * > > ** ** > > Best,**** > > Emmanuel**** > > ** ** > > On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy wrote= : > **** > > See below ...**** > > **** > ------------------------------ > > *From:* Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > *Sent:* Thursday, July 25, 2013 6:55 AM > *To:* its@ietf.org > *Subject:* Re: [its] Article + TED talk**** > > **** > > Hi Alexandru,**** > > rant permission granted. These links where not pointing to any technicall= y > interesting content as far as *we* are concerned. But we can still use th= is > content to say something like: "if you're motivated by such high level > perspectives (as depicted in TED Talk, article, you-name-it), then you > should let us do it with IP, because other solutions will suck fast".**** > > *[RR>] You really need to understand the application requirements before > making such a statement. In the TED talk, the message was "let your car > [ed: and the pedestrian on the sidewalk and the bicyclist in the bike lan= e] > BROADCAST its kinematic state estimate [ed. and its estimate error > covariance] to all others in the vicinity [ed. at an appropriate rate] so > that all cars in a local area [ed. can build up a Local Dynamic Map or LD= M > and] can avoid collisions. This is all point-to-point communications wit= h > no network required or desired at all ... not even an ad hoc network of > vehicles ... just BSMs/CAMs (here-I-am messages) transmitted to increase > safety on the roads. For this particular application, there is NO need f= or > a 40 byte IPv6 header when a 3 byte header (se FNTP) will suffice. > Maximizing useful content transfer in a capacity constrained channel is = a > VERY good idea. Those 37 saved bytes turn out to be roughly somewhere fr= om > 5-10% (depending on data sent, certificate sizes and a few other things) = of > the transmitted stream (PPDU) over the air, and that's not inconsequentia= l > when talking about your personal physical safety or that of your family! > ***** > > * ***** > > *IP is a sound and obviously successful NETWORKING technology ... however > that does NOT mean it can brush your teeth too! That's a job for > toothbrushes!***** > > * ***** > > *RR***** > > * ian on the sidewalk] BROADCAST its kinematic state estiamte a***** > > Best**** > > Emmanuel**** > > **** > > **** > > On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote:**** > > Emmanuel, > > Allow me to rant on this. > > These and other[*] pointers are good illustrations about how intriguing > visions of car-to-car communications could be developped. The TED > presentation is particular in that it uses drama tools to sell car-talk > technology. > > In general, the vehicular industry players are excellent dream makers > since some time now: the car itself is such. Add this or that option > and it's so much better. > > I personally look at them in some detail, actively searching for one > particular facet of such vision: do they mention the challenges of _IP_ > communications from vehicle to vehicle? > > Because some if not all V2V visions getting front stage seem to focus > on matters other than IP: radar/lidar-based echo detection of nearby > vehicles and pedestrians, fast and rough form recognition, broadcasting > tourism information. As stimulating as they may appear, they may have > little to do with IP - some demonstrated prototypes not doing IP. > > When someone says 'V2V' I feel the urge to ask some questions: > > Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? Is it > V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed > infrastructure in between? > > Is it radio beam echoed back by a solid? (aka 'radar') > > Velocity transmitted from one V to another is how? kmph or mph? > transmitted as value or detected by radars? as a sequence of positions > with time measured at destination? Is it localization data as WGS84 or > as ED50 (or otherwise how to automate the promotion of 802.11p over > 800MHz-LTE near old military camps)? > > IF these V-to-V data transmitted are actually IP packets, what are src > and dst addresses? How do vehicles 'discover' each other? Where do > they get their addresses from? > > LED headlights avoid blinding the incoming driver, but are they LiFi and > IP-over-LiFi? > > Because, some of the visions may bear little ressemblance to what may > get deployed - they may be too high level. Even on this email list, we > have seen statements about visions, and counter statements about some > visions being just dreams. > > Alex > [*] The Economist ran recently an entire Quarterly about the Future of > the Car "Clean, safe and it drives itself", and an article on > "Driverless Automobiles" (imagine _that_ w/o communication - a nightmare)= . > > > Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :**** > > **** > > Hi guys, > > I don't know how technically relevant these are, but I stumbled on > an article and a TED talk that advocate for car-to-car > communications and ITS. So I thought I'd just share them, just in > case there might be something relevant/useful for someone here. > > > http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to_= each_other > > > > > > > > **** > > > http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_mig= ht_be_avoidable.html > **** > > > Best, > > Emmanuel > > > _______________________________________________ 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**** > > **** > > ** ** > --089e01184a24ed89b204e266477b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,
I understand your argument. On the o= ther hand, if using IP makes the technology cheaper (which often happens no= wadays), then you could actually save lives because more cars will be equip= ped more quickly.=A0
Best
Emmanuel


On Fri, Jul 26, 2013 at 10:46 AM, Ri= chard Roy <dickroy@alum.mit.edu> wrote:

=A0

=A0

From: emmanuel.b= accelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] On Behalf Of Emmanuel Baccelli
Sent: Friday, July 26, 2013 = 1:23 AM
To: dickroy@alum.mit.edu
Cc: its@ietf.org


Subject: Re: [its] Article += TED talk

=A0

Hi Richard,

yes you're right, IP does not make coffee.

But realistically, nowadays, you rather have to just= ify why you're *not* using IP, rather than why you *are* using IP.

I don't think 5-10% savings are a good enough re= ason to not use IP.

[RR>] You are of course free to have such thoughts. = =A0However, allow me to suggest that it is a really good reason when safety of life and property are involved.=A0 If you were the 1 in 10 that lost his/her life be= cause of extra needless congestion on the channel, congestion which could have be= en prevented by not using a verbose and useless protocol for this application,= I suggest you'd care ... or at least your family would care.=A0 Not all communications on the planet need IP.

=A0

RR

=A0

=A0

Best,

Emmanuel

=A0

On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy <dickroy@alum.mit.edu= > wrote:

See below ...

=A0

From: Emmanuel B= accelli [mailto:Emmanuel.Baccelli@inria.fr]
Sent: Thursday, July 25, 201= 3 6:55 AM
To: its@ietf.org
Subject: Re: [its] Article += TED talk

=A0

Hi Alexandru,

rant permission granted. These links where not pointing to any technically interesting cont= ent as far as *we* are concerned. But we can still use this content to say something like: "if you're motivated by such high level perspectiv= es (as depicted in TED Talk, article, you-name-it), then you should let us do it w= ith IP, because other solutions will suck fast".

[RR>] You really need to understand the application requirements before making such a statement. =A0In the TED talk, the message was "let your car [ed: and the pedestrian on the sidewalk and the bicyclist in the bike lane] BROADCAST it= s kinematic state estimate [ed. and its estimate error covariance] to all oth= ers in the vicinity [ed. at an appropriate rate] so that all cars in a local ar= ea [ed. can build up a Local Dynamic Map or LDM and] can avoid collisions. =A0This is all point-to-point communications with no network required or desired at all ... not even an ad hoc network of vehicles ... just BSMs/CAM= s (here-I-am messages) transmitted to increase safety on the roads. =A0For this particular application, there is NO need for a 40 byte IPv6 header whe= n a 3 byte header (se FNTP) will suffice. =A0Maximizing useful content transfer in a capacity constrained channel is a VERY good idea. =A0Those 37 saved bytes turn out to be roughly somewhere from 5-10% (depending on data sent, certificate sizes and a few other things) of the transmitted stream (PPDU) = over the air, and that's not inconsequential when talking about your persona= l physical safety or that of your family!=A0 =

=A0

IP is a sound and obviously successful NETWORKING technology ... however that does NOT mean it can brus= h your teeth too!=A0 That's a job for toothbrushes!=

=A0

RR

=A0=A0=A0ian on the sidewalk] BROADCAST its kinematic state estiamte a=

Best

Emmanuel

=A0

=A0

On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

Emmanuel,

Allow me to rant on this.

These and other[*] pointers are good illustrations about how intriguing
visions of car-to-car communications could be developped. =A0The TED
presentation is particular in that it uses drama tools to sell car-talk
technology.

In general, the vehicular industry players are excellent dream makers
since some time now: the car itself is such. =A0Add this or that option
and it's so much better.

I personally look at them in some detail, actively searching for one
particular facet of such vision: do they mention the challenges of _IP_
communications from vehicle to vehicle?

Because some if not all V2V visions getting front stage seem to focus
on matters other than IP: radar/lidar-based echo detection of nearby
vehicles and pedestrians, fast and rough form recognition, broadcasting
tourism information. =A0As stimulating as they may appear, they may have little to do with IP - some demonstrated prototypes not doing IP.

When someone says 'V2V' I feel the urge to ask some questions:

Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? =A0Is it
V-to-ITSStation-to-V? =A0Or is it direct V-to-V without any fixed
infrastructure in between?

Is it radio beam echoed back by a solid? (aka 'radar')

Velocity transmitted from one V to another is how? kmph or mph?
transmitted as value or detected by radars? =A0as a sequence of positions with time measured at destination? Is it localization data as WGS84 or
as ED50 (or otherwise how to automate the promotion of 802.11p over
800MHz-LTE near old military camps)?

IF these V-to-V data transmitted are actually IP packets, what are src
and dst addresses? =A0How do vehicles 'discover' each other? =A0Whe= re do
they get their addresses from?

LED headlights avoid blinding the incoming driver, but are they LiFi and IP-over-LiFi?

Because, some of the visions may bear little ressemblance to what may
get deployed - they may be too high level. =A0Even on this email list, we have seen statements about visions, and counter statements about some
visions being just dreams.

Alex
[*] The Economist ran recently an entire Quarterly about the Future of
the Car "Clean, safe and it drives itself", and an article on
"Driverless Automobiles" (imagine _that_ w/o communication - a nightmare).


Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :

=A0

Hi guys,

I don't know how technically relevant these are, but I stumbled on
an article and a TED talk that advocate for car-to-car
communications and ITS. So I thought I'd just share them, just in
case there might be something relevant/useful for someone here.

http://www.computerworld.com/s/artic= le/9241037/Feds_want_cars_to_talk_to_each_other







htt= p://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be= _avoidable.html


Best,

Emmanuel


_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its



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

=A0

=A0


--089e01184a24ed89b204e266477b-- From alexandru.petrescu@gmail.com Fri Jul 26 05:10:46 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BD21F8EB3 for ; Fri, 26 Jul 2013 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.918 X-Spam-Level: X-Spam-Status: No, score=-8.918 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_VISIT=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLOMQa8N+85z for ; Fri, 26 Jul 2013 05:10:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9F21F8DDD for ; Fri, 26 Jul 2013 05:10:41 -0700 (PDT) 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 r6QCAeJr029961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jul 2013 14:10:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6QCAdQm010317 for ; Fri, 26 Jul 2013 14:10:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6QC9VK1019994 for ; Fri, 26 Jul 2013 14:10:39 +0200 Message-ID: <51F266F9.6020805@gmail.com> Date: Fri, 26 Jul 2013 14:09:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <303EC1E547984298B75F80F687980FAF@SRA4> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 12:10:47 -0000 Le 26/07/2013 10:53, Emmanuel Baccelli a écrit : > Hi Richard, I understand your argument. On the other hand, if using > IP makes the technology cheaper (which often happens nowadays), Right, and relating to Dick's toothbrush metaphor: not only an IP app to brush the teeth would cost less than the typical toothbrush, but it would improve teeth care (just think what the smartphone's vibrator and camera could do). Alex > then you could actually save lives because more cars will be equipped > more quickly. Best Emmanuel > > > On Fri, Jul 26, 2013 at 10:46 AM, Richard Roy > wrote: > > __ __ > > __ __ > > ------------------------------------------------------------------------ > > *From:*emmanuel.baccelli@gmail.com > > [mailto:emmanuel.baccelli@gmail.com > ] *On Behalf Of *Emmanuel > Baccelli *Sent:* Friday, July 26, 2013 1:23 AM *To:* > dickroy@alum.mit.edu *Cc:* its@ietf.org > > > > *Subject:* Re: [its] Article + TED talk ____ > > __ __ > > Hi Richard,____ > > yes you're right, IP does not make coffee.____ > > But realistically, nowadays, you rather have to justify why you're > *not* using IP, rather than why you *are* using IP.____ > > I don't think 5-10% savings are a good enough reason to not use > IP.____ > > */[RR>] You are of course free to have such thoughts. However, allow > me to suggest that it is a really good reason when safety of life and > property are involved. If you were the 1 in 10 that lost his/her > life because of extra needless congestion on the channel, congestion > which could have been prevented by not using a verbose and useless > protocol for this application, I suggest you'd care ... or at least > your family would care. Not all communications on the planet need > IP.____/* > > */__ __/* > > */RR____/* > > */__ __/* > > __ __ > > Best,____ > > Emmanuel____ > > __ __ > > On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy > wrote:____ > > See below ...____ > > ____ > > ------------------------------------------------------------------------ > > *From:*Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr > ] *Sent:* Thursday, July 25, 2013 > 6:55 AM *To:* its@ietf.org *Subject:* Re: [its] > Article + TED talk____ > > ____ > > Hi Alexandru,____ > > rant permission granted. These links where not pointing to any > technically interesting content as far as *we* are concerned. But we > can still use this content to say something like: "if you're > motivated by such high level perspectives (as depicted in TED Talk, > article, you-name-it), then you should let us do it with IP, because > other solutions will suck fast".____ > > */[RR>] You really need to understand the application requirements > before making such a statement. In the TED talk, the message was > "let your car [ed: and the pedestrian on the sidewalk and the > bicyclist in the bike lane] BROADCAST its kinematic state estimate > [ed. and its estimate error covariance] to all others in the vicinity > [ed. at an appropriate rate] so that all cars in a local area [ed. > can build up a Local Dynamic Map or LDM and] can avoid collisions. > This is all point-to-point communications with no network required or > desired at all ... not even an ad hoc network of vehicles ... just > BSMs/CAMs (here-I-am messages) transmitted to increase safety on the > roads. For this particular application, there is NO need for a 40 > byte IPv6 header when a 3 byte header (se FNTP) will suffice. > Maximizing useful content transfer in a capacity constrained channel > is a VERY good idea. Those 37 saved bytes turn out to be roughly > somewhere from 5-10% (depending on data sent, certificate sizes and a > few other things) of the transmitted stream (PPDU) over the air, and > that's not inconsequential when talking about your personal physical > safety or that of your family! /*____ > > *//*____ > > */IP is a sound and obviously successful NETWORKING technology ... > however that does NOT mean it can brush your teeth too! That's a job > for toothbrushes!/*____ > > *//*____ > > */RR/*____ > > */ ian on the sidewalk] BROADCAST its kinematic state estiamte > a/*____ > > Best____ > > Emmanuel____ > > ____ > > ____ > > On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu > > > wrote:____ > > Emmanuel, > > Allow me to rant on this. > > These and other[*] pointers are good illustrations about how > intriguing visions of car-to-car communications could be developped. > The TED presentation is particular in that it uses drama tools to > sell car-talk technology. > > In general, the vehicular industry players are excellent dream > makers since some time now: the car itself is such. Add this or that > option and it's so much better. > > I personally look at them in some detail, actively searching for one > particular facet of such vision: do they mention the challenges of > _IP_ communications from vehicle to vehicle? > > Because some if not all V2V visions getting front stage seem to > focus on matters other than IP: radar/lidar-based echo detection of > nearby vehicles and pedestrians, fast and rough form recognition, > broadcasting tourism information. As stimulating as they may appear, > they may have little to do with IP - some demonstrated prototypes not > doing IP. > > When someone says 'V2V' I feel the urge to ask some questions: > > Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? Is it > V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed > infrastructure in between? > > Is it radio beam echoed back by a solid? (aka 'radar') > > Velocity transmitted from one V to another is how? kmph or mph? > transmitted as value or detected by radars? as a sequence of > positions with time measured at destination? Is it localization data > as WGS84 or as ED50 (or otherwise how to automate the promotion of > 802.11p over 800MHz-LTE near old military camps)? > > IF these V-to-V data transmitted are actually IP packets, what are > src and dst addresses? How do vehicles 'discover' each other? Where > do they get their addresses from? > > LED headlights avoid blinding the incoming driver, but are they LiFi > and IP-over-LiFi? > > Because, some of the visions may bear little ressemblance to what > may get deployed - they may be too high level. Even on this email > list, we have seen statements about visions, and counter statements > about some visions being just dreams. > > Alex [*] The Economist ran recently an entire Quarterly about the > Future of the Car "Clean, safe and it drives itself", and an article > on "Driverless Automobiles" (imagine _that_ w/o communication - a > nightmare). > > > Le 25/07/2013 12:25, Emmanuel Baccelli a écrit :____ > > ____ > > Hi guys, > > I don't know how technically relevant these are, but I stumbled on an > article and a TED talk that advocate for car-to-car communications > and ITS. So I thought I'd just share them, just in case there might > be something relevant/useful for someone here. > > http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to_each_other > > > > > > > > > ____ > > http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be_avoidable.html____ > > > > Best, > > Emmanuel > > > _______________________________________________ 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 jkenney@us.toyota-itc.com Fri Jul 26 13:19:54 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3711E80FB for ; Fri, 26 Jul 2013 13:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_VISIT=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6Q9zZCshlPI for ; Fri, 26 Jul 2013 13:19:50 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with SMTP id EF0C111E8114 for ; Fri, 26 Jul 2013 13:19:49 -0700 (PDT) Received: from mail-pa0-f43.google.com ([209.85.220.43]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKUfLZ4xt0kPRPNxwgSO20n7oZUPXqORLV@postini.com; Fri, 26 Jul 2013 13:19:50 PDT Received: by mail-pa0-f43.google.com with SMTP id hz10so2648409pad.30 for ; Fri, 26 Jul 2013 13:19:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SPZYQccLlVG4V3VcRYj4D2pLZw8MCqsNi6mwyTvMWyQ=; b=fAh8Kuy/Wryn3MnpQtIo/3M/1nb5p6je8F1XqofRPHTk6v7sHaummO7YA+XlG5IIjU dL4j6+CzBvFEw14OAIHbdXHv7yjTzqdJoG36FUoT1s4Hg+Fc3KvI27lYjXRu/HJT0YaE 8KYQtl7YySKW8u6O0UpLGdsIJH7pmO17m0h+6DggPssjbaI0Hf/SNtaVW1iz1XFDlNJe gqEqb07KYo3nmissb7si5ho01DeDEZc35mtrS1x6j0OneldPWtvi5Cfl4fUNOKLKNbp+ W3Y4WOOyJSYZnixhH/EAgCPLmKJWrxL86n9WZGjzUIdR4GpZ9SPHqw4oJukcPoz+of17 f9Rw== X-Received: by 10.68.224.228 with SMTP id rf4mr55714580pbc.50.1374869987601; Fri, 26 Jul 2013 13:19:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.224.228 with SMTP id rf4mr55714562pbc.50.1374869987413; Fri, 26 Jul 2013 13:19:47 -0700 (PDT) Received: by 10.68.213.102 with HTTP; Fri, 26 Jul 2013 13:19:47 -0700 (PDT) In-Reply-To: References: <303EC1E547984298B75F80F687980FAF@SRA4> Date: Fri, 26 Jul 2013 13:19:47 -0700 Message-ID: From: John Kenney To: Emmanuel Baccelli Content-Type: multipart/alternative; boundary=e89a8ff24ca536641904e26fdd49 X-Gm-Message-State: ALoCoQnQ8R3pxtmh4UjtDHkLHW9evpY5hDTyvKX758SQaMXPpcWjtzWsEEe6a1z/sXT7VnvOtqxop8dkH2zHdJhQAHXjtmNyl5V/9HAHO4bTDoLh8dt6rdiA9ccRNfQhbASB9yDDAzlE Cc: dickroy , its@ietf.org Subject: Re: [its] Article + TED talk X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:19:54 -0000 --e89a8ff24ca536641904e26fdd49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Dick on this. For these single-hop unacknowledged broadcast use cases, which are driving deployment of DSRC/C-ITS, IP offers no advantage in cost, speed of deployment or anything else. The overhead is indeed significant as we face the prospect of heavy channel congestion. We've worked hard to save a few bytes here and there in other parts of the stack, so avoiding the IP/UDP/TCP header overhead made sense. It may be tempting to think these decisions were made by people who were ignorant of IP or otherwise simply didn't know any better. I assure you that is not the case. Best Regards, John Kenney On Fri, Jul 26, 2013 at 1:53 AM, Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > Hi Richard, > I understand your argument. On the other hand, if using IP makes the > technology cheaper (which often happens nowadays), then you could actuall= y > save lives because more cars will be equipped more quickly. > Best > Emmanuel > > > On Fri, Jul 26, 2013 at 10:46 AM, Richard Roy wrote= : > >> ** ** >> >> ** ** >> ------------------------------ >> >> *From:* emmanuel.baccelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] >> *On Behalf Of *Emmanuel Baccelli >> *Sent:* Friday, July 26, 2013 1:23 AM >> *To:* dickroy@alum.mit.edu >> *Cc:* its@ietf.org >> >> *Subject:* Re: [its] Article + TED talk >> **** >> >> ** ** >> >> Hi Richard,**** >> >> yes you're right, IP does not make coffee.**** >> >> But realistically, nowadays, you rather have to justify why you're *not* >> using IP, rather than why you *are* using IP.**** >> >> I don't think 5-10% savings are a good enough reason to not use IP.**** >> >> *[RR>] You are of course free to have such thoughts. However, allow me >> to suggest that it is a really good reason when safety of life and prope= rty >> are involved. If you were the 1 in 10 that lost his/her life because of >> extra needless congestion on the channel, congestion which could have be= en >> prevented by not using a verbose and useless protocol for this applicati= on, >> I suggest you'd care ... or at least your family would care. Not all >> communications on the planet need IP.* >> >> * * >> >> *RR* >> >> * * >> >> ** ** >> >> Best,**** >> >> Emmanuel**** >> >> ** ** >> >> On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy >> wrote:**** >> >> See below ...**** >> >> **** >> ------------------------------ >> >> *From:* Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> *Sent:* Thursday, July 25, 2013 6:55 AM >> *To:* its@ietf.org >> *Subject:* Re: [its] Article + TED talk**** >> >> **** >> >> Hi Alexandru,**** >> >> rant permission granted. These links where not pointing to any >> technically interesting content as far as *we* are concerned. But we can >> still use this content to say something like: "if you're motivated by su= ch >> high level perspectives (as depicted in TED Talk, article, you-name-it), >> then you should let us do it with IP, because other solutions will suck >> fast".**** >> >> *[RR>] You really need to understand the application requirements before >> making such a statement. In the TED talk, the message was "let your car >> [ed: and the pedestrian on the sidewalk and the bicyclist in the bike la= ne] >> BROADCAST its kinematic state estimate [ed. and its estimate error >> covariance] to all others in the vicinity [ed. at an appropriate rate] s= o >> that all cars in a local area [ed. can build up a Local Dynamic Map or L= DM >> and] can avoid collisions. This is all point-to-point communications wi= th >> no network required or desired at all ... not even an ad hoc network of >> vehicles ... just BSMs/CAMs (here-I-am messages) transmitted to increase >> safety on the roads. For this particular application, there is NO need = for >> a 40 byte IPv6 header when a 3 byte header (se FNTP) will suffice. >> Maximizing useful content transfer in a capacity constrained channel is= a >> VERY good idea. Those 37 saved bytes turn out to be roughly somewhere f= rom >> 5-10% (depending on data sent, certificate sizes and a few other things)= of >> the transmitted stream (PPDU) over the air, and that's not inconsequenti= al >> when talking about your personal physical safety or that of your family! >> ***** >> >> * ***** >> >> *IP is a sound and obviously successful NETWORKING technology ... >> however that does NOT mean it can brush your teeth too! That's a job fo= r >> toothbrushes!***** >> >> * ***** >> >> *RR***** >> >> * ian on the sidewalk] BROADCAST its kinematic state estiamte a***** >> >> Best**** >> >> Emmanuel**** >> >> **** >> >> **** >> >> On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com> wrote:**** >> >> Emmanuel, >> >> Allow me to rant on this. >> >> These and other[*] pointers are good illustrations about how intriguing >> visions of car-to-car communications could be developped. The TED >> presentation is particular in that it uses drama tools to sell car-talk >> technology. >> >> In general, the vehicular industry players are excellent dream makers >> since some time now: the car itself is such. Add this or that option >> and it's so much better. >> >> I personally look at them in some detail, actively searching for one >> particular facet of such vision: do they mention the challenges of _IP_ >> communications from vehicle to vehicle? >> >> Because some if not all V2V visions getting front stage seem to focus >> on matters other than IP: radar/lidar-based echo detection of nearby >> vehicles and pedestrians, fast and rough form recognition, broadcasting >> tourism information. As stimulating as they may appear, they may have >> little to do with IP - some demonstrated prototypes not doing IP. >> >> When someone says 'V2V' I feel the urge to ask some questions: >> >> Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? Is it >> V-to-ITSStation-to-V? Or is it direct V-to-V without any fixed >> infrastructure in between? >> >> Is it radio beam echoed back by a solid? (aka 'radar') >> >> Velocity transmitted from one V to another is how? kmph or mph? >> transmitted as value or detected by radars? as a sequence of positions >> with time measured at destination? Is it localization data as WGS84 or >> as ED50 (or otherwise how to automate the promotion of 802.11p over >> 800MHz-LTE near old military camps)? >> >> IF these V-to-V data transmitted are actually IP packets, what are src >> and dst addresses? How do vehicles 'discover' each other? Where do >> they get their addresses from? >> >> LED headlights avoid blinding the incoming driver, but are they LiFi and >> IP-over-LiFi? >> >> Because, some of the visions may bear little ressemblance to what may >> get deployed - they may be too high level. Even on this email list, we >> have seen statements about visions, and counter statements about some >> visions being just dreams. >> >> Alex >> [*] The Economist ran recently an entire Quarterly about the Future of >> the Car "Clean, safe and it drives itself", and an article on >> "Driverless Automobiles" (imagine _that_ w/o communication - a nightmare= ). >> >> >> Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :**** >> >> **** >> >> Hi guys, >> >> I don't know how technically relevant these are, but I stumbled on >> an article and a TED talk that advocate for car-to-car >> communications and ITS. So I thought I'd just share them, just in >> case there might be something relevant/useful for someone here. >> >> >> http://www.computerworld.com/s/article/9241037/Feds_want_cars_to_talk_to= _each_other >> >> >> >> >> >> >> >> **** >> >> >> http://www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_mi= ght_be_avoidable.html >> **** >> >> >> Best, >> >> Emmanuel >> >> >> _______________________________________________ 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 > > --=20 John Kenney Principal Researcher Toyota InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 94043 Tel: 650-694-4160. Mobile: 650-224-6644 --e89a8ff24ca536641904e26fdd49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Dick on this. For these single-hop unacknowledged broadca= st use cases, which are driving deployment of DSRC/C-ITS, IP offers no adva= ntage in cost, speed of deployment or anything else. The overhead is indeed= significant as we face the prospect of heavy channel congestion.=A0 We'= ;ve worked hard to save a few bytes here and there in other parts of the st= ack, so avoiding the IP/UDP/TCP header overhead made sense.
=A0
It may be tempting to think these decisions were made by= people who were ignorant of IP or otherwise simply didn't know any bet= ter. I assure you that is not the case.
=A0
Best Regard= s,
John Kenney

On Fri, Jul 26, 20= 13 at 1:53 AM, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr&= gt; wrote:
Hi Richard,
I understand your argumen= t. On the other hand, if using IP makes the technology cheaper (which often= happens nowadays), then you could actually save lives because more cars wi= ll be equipped more quickly.=A0
Best
Emmanuel


=
On Fri, Jul 26, 2013 at 10:46 AM, Richard Roy <dickroy@alum.mit.edu> wrote:

=A0=

=A0=

From: emmanuel.b= accelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] On Behalf Of Emmanuel Baccelli
Sent: Friday, July 26, 2013 = 1:23 AM
To: dickroy@alum.mit.edu
Cc: its@ietf.org


Subject: Re: [its] Article += TED talk

=A0

Hi Richard,

yes you're right, IP does not make coffee.<= u>

But realistically, nowadays, you rather have to justif= y why you're *not* using IP, rather than why you *are* using IP.

I don't think 5-10% savings are a good enough reas= on to not use IP.

[RR>] You are of course free to have such thoughts= . =A0However, allow me to suggest that it is a really good reason when safety of life and property are involved.=A0 If you were the 1 in 10 that lost his/her life be= cause of extra needless congestion on the channel, congestion which could have be= en prevented by not using a verbose and useless protocol for this application,= I suggest you'd care ... or at least your family would care.=A0 Not all communications on the planet need IP.

=A0

RR

=A0

=A0=

Best,

Emmanuel

=A0<= /font>

On Fri, Jul 26, 2013 at 9:11 AM, Richard Roy <dickroy@alum.mit.edu> wrote:

See below ...<= /u>

=A0=

From: Emmanuel Bac= celli [mailto:Emmanuel.Baccelli@inria.fr]
Sent: Thursday, July 25, 201= 3 6:55 AM
To: its@ietf.org
Subject: Re: [its] Article += TED talk

=A0

Hi Alexandru,

rant permission granted. These links where not pointing to any technically interesting cont= ent as far as *we* are concerned. But we can still use this content to say something like: "if you're motivated by such high level perspectiv= es (as depicted in TED Talk, article, you-name-it), then you should let us do it w= ith IP, because other solutions will suck fast".

[RR>] You really need to understand the application requirements before making such a statement. =A0In the TED talk, the message was "let your car [ed: and the pedestrian on the sidewalk and the bicyclist in the bike lane] BROADCAST it= s kinematic state estimate [ed. and its estimate error covariance] to all oth= ers in the vicinity [ed. at an appropriate rate] so that all cars in a local ar= ea [ed. can build up a Local Dynamic Map or LDM and] can avoid collisions. =A0This is all point-to-point communications with no network required or desired at all ... not even an ad hoc network of vehicles ... just BSMs/CAM= s (here-I-am messages) transmitted to increase safety on the roads. =A0For this particular application, there is NO need for a 40 byte IPv6 header whe= n a 3 byte header (se FNTP) will suffice. =A0Maximizing useful content transfer in a capacity constrained channel is a VERY good idea. =A0Those 37 saved bytes turn out to be roughly somewhere from 5-10% (depending on data sent, certificate sizes and a few other things) of the transmitted stream (PPDU) = over the air, and that's not inconsequential when talking about your persona= l physical safety or that of your family!=A0 =

=A0

IP is a sound and obviously successful NETWORKING technology ... however that does NOT mean it can brus= h your teeth too!=A0 That's a job for toothbrushes!=

=A0

RR

=A0=A0=A0ian on the sidewalk] BROADCAST its kinematic state estiamte a=

Best

Emmanuel

=A0

=A0<= /font>

On Thu, Jul 25, 2013 at 3:32 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:

Emmanuel,

Allow me to rant on this.

These and other[*] pointers are good illustrations about how intriguing
visions of car-to-car communications could be developped. =A0The TED
presentation is particular in that it uses drama tools to sell car-talk
technology.

In general, the vehicular industry players are excellent dream makers
since some time now: the car itself is such. =A0Add this or that option
and it's so much better.

I personally look at them in some detail, actively searching for one
particular facet of such vision: do they mention the challenges of _IP_
communications from vehicle to vehicle?

Because some if not all V2V visions getting front stage seem to focus
on matters other than IP: radar/lidar-based echo detection of nearby
vehicles and pedestrians, fast and rough form recognition, broadcasting
tourism information. =A0As stimulating as they may appear, they may have little to do with IP - some demonstrated prototypes not doing IP.

When someone says 'V2V' I feel the urge to ask some questions:

Is it V-to-LTE-BaseStation-to-HA-and-back-to-V? =A0Is it
V-to-ITSStation-to-V? =A0Or is it direct V-to-V without any fixed
infrastructure in between?

Is it radio beam echoed back by a solid? (aka 'radar')

Velocity transmitted from one V to another is how? kmph or mph?
transmitted as value or detected by radars? =A0as a sequence of positions with time measured at destination? Is it localization data as WGS84 or
as ED50 (or otherwise how to automate the promotion of 802.11p over
800MHz-LTE near old military camps)?

IF these V-to-V data transmitted are actually IP packets, what are src
and dst addresses? =A0How do vehicles 'discover' each other? =A0Whe= re do
they get their addresses from?

LED headlights avoid blinding the incoming driver, but are they LiFi and IP-over-LiFi?

Because, some of the visions may bear little ressemblance to what may
get deployed - they may be too high level. =A0Even on this email list, we have seen statements about visions, and counter statements about some
visions being just dreams.

Alex
[*] The Economist ran recently an entire Quarterly about the Future of
the Car "Clean, safe and it drives itself", and an article on
"Driverless Automobiles" (imagine _that_ w/o communication - a nightmare).


Le 25/07/2013 12:25, Emmanuel Baccelli a =E9crit :

=A0

Hi guys,

I don't know how technically relevant these are, but I stumbled on
an article and a TED talk that advocate for car-to-car
communications and ITS. So I thought I'd just share them, just in
case there might be something relevant/useful for someone here.

http://www.computerworld.com/s/artic= le/9241037/Feds_want_cars_to_talk_to_each_other







http:= //www.ted.com/talks/jennifer_healey_if_cars_could_talk_accidents_might_be_a= voidable.html


Best,

Emmanuel


_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its



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

=A0

=A0



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




--
John Kenney
Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644
--e89a8ff24ca536641904e26fdd49-- From alexandru.petrescu@gmail.com Sun Jul 28 09:47:04 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6021F9CA2 for ; Sun, 28 Jul 2013 09:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKTf2D-GHPz6 for ; Sun, 28 Jul 2013 09:46:58 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07B21F9C78 for ; Sun, 28 Jul 2013 09:46:58 -0700 (PDT) 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 r6SGktVQ014406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 28 Jul 2013 18:46:55 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6SGktpo010804 for ; Sun, 28 Jul 2013 18:46:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.5]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6SGkfkg019215 for ; Sun, 28 Jul 2013 18:46:55 +0200 Message-ID: <51F54AF1.4090207@gmail.com> Date: Sun, 28 Jul 2013 18:46:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <51C9BBCC.1090304@gmail.com> <51EFA041.7020100@gmail.com> In-Reply-To: <51EFA041.7020100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Continue - select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 16:47:04 -0000 Quick reminder - for the bar BoF it would be good if we have at least a rough idea about which of the three areas to pursue with. If you have not already expressed a preference, please do so, among the options below: 1. establishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Alex Le 24/07/2013 11:37, Alexandru Petrescu a écrit : > Hello, > > Thanks to everybody who expressed oppinion towards scoping the > activity. Until now, the first topic of establishment of IP > networking between neighboring vehicles and > vehicle-to-fixed-ITS-station seems to get most support. > > We need more discussion around scoping the Charter. > > If you have not already done so, please prioritize one topic among > the three below, in order to scope the Charter. > > Alex > > Le 25/06/2013 17:48, Alexandru Petrescu a écrit : >> Hello participants to ITS email list, >> >> During recent discussions we mentioned 3 different areas to work >> on. They are too many for a meaningful detail work. >> >> Please select area scoping the Charter, prioritizing according to >> the environment you work on. >> >> 1. establishment of IP networking between neighboring vehicles >> using either MANET protocols or 1-hop ICMP protocol. >> >> 2. layering of IPv6 over IEEE 802.11p communication technology. >> >> 3. IPv6-based network-layer distribution of content in a >> geographic area. >> >> Yours, >> >> 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 benamar73@gmail.com Sun Jul 28 09:56:39 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3B21F9B52 for ; Sun, 28 Jul 2013 09:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usLtDzzgktXp for ; Sun, 28 Jul 2013 09:56:37 -0700 (PDT) Received: from mail-oa0-x241.google.com (mail-oa0-x241.google.com [IPv6:2607:f8b0:4003:c02::241]) by ietfa.amsl.com (Postfix) with ESMTP id EB08421F9AE9 for ; Sun, 28 Jul 2013 09:56:35 -0700 (PDT) Received: by mail-oa0-f65.google.com with SMTP id k14so3002036oag.8 for ; Sun, 28 Jul 2013 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Zct3fh//mwLyFFzOz86FjZbY/PN5QvA/oauyFQGVwJw=; b=UUsRJ4yymoiErhXdcfx3NJib8wEkxUiA4fmNtrb6YClur+JkNoZlVP2UGBV8tvV3U5 fiANesSB8TOzOtpKb/WYFUBXRSISXGhAa5COZvtpi4gzXe3jvFA+NzmlrJVluBdOB5Di phTlj+0vKexgkY+s2Zq24CLYzHxKdi28a2yyI3EgynY/HhVw4lSEgywBf6smOUD3keeZ yOLRpzsC5qYKyszs7CRO9FYdYpnH3gUxR7ma0xnI1ZNFMR6GquxQdG8iLXka3j17WF1u uootCDnjO8Ry6PN23Y+PlCzIC0QlRmkpeGNkwTThnIJoG6Ffp5IMDpzNhYrew02cXHj8 7RDw== MIME-Version: 1.0 X-Received: by 10.182.165.133 with SMTP id yy5mr49973354obb.89.1375030594354; Sun, 28 Jul 2013 09:56:34 -0700 (PDT) Received: by 10.76.68.136 with HTTP; Sun, 28 Jul 2013 09:56:34 -0700 (PDT) In-Reply-To: References: <51C9BBCC.1090304@gmail.com> <51EFA041.7020100@gmail.com> <51F54AF1.4090207@gmail.com> Date: Sun, 28 Jul 2013 16:56:34 +0000 Message-ID: From: Nabil Benamar To: its@ietf.org Content-Type: multipart/alternative; boundary=001a11c2e76a21c52404e29542f3 Subject: [its] Fwd: Continue - select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 16:56:39 -0000 --001a11c2e76a21c52404e29542f3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Nabil Benamar Date: Sun, Jul 28, 2013 at 4:55 PM Subject: Re: [its] Continue - select area scoping the Charter To: Alexandru Petrescu Hi Alexandru, The three topics are of interest...and if it's necessary to choose one among the list, I vote for : layering of IPv6 over IEEE 802.11p communication technology. On Sun, Jul 28, 2013 at 4:46 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Quick reminder - for the bar BoF it would be good if we have at least a > rough idea about which of the three areas to pursue with. > > If you have not already expressed a preference, please do so, among the > options below: > > > 1. establishment of IP networking between neighboring vehicles using > either MANET protocols or 1-hop ICMP protocol. > > 2. layering of IPv6 over IEEE 802.11p communication technology. > > 3. IPv6-based network-layer distribution of content in a geographic > area. > > Alex > > Le 24/07/2013 11:37, Alexandru Petrescu a =E9crit : > > Hello, >> >> Thanks to everybody who expressed oppinion towards scoping the >> activity. Until now, the first topic of establishment of IP >> networking between neighboring vehicles and >> vehicle-to-fixed-ITS-station seems to get most support. >> >> We need more discussion around scoping the Charter. >> >> If you have not already done so, please prioritize one topic among >> the three below, in order to scope the Charter. >> >> Alex >> >> Le 25/06/2013 17:48, Alexandru Petrescu a =E9crit : >> >>> Hello participants to ITS email list, >>> >>> During recent discussions we mentioned 3 different areas to work >>> on. They are too many for a meaningful detail work. >>> >>> Please select area scoping the Charter, prioritizing according to >>> the environment you work on. >>> >>> 1. establishment of IP networking between neighboring vehicles >>> using either MANET protocols or 1-hop ICMP protocol. >>> >>> 2. layering of IPv6 over IEEE 802.11p communication technology. >>> >>> 3. IPv6-based network-layer distribution of content in a >>> geographic area. >>> >>> Yours, >>> >>> 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 >> >> >> > > ______________________________**_________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/**listinfo/its > --=20 *Regards* *Nabil Benamar* * * ** * ---------------------------------------------------------------------------= ----- * --=20 *Regards* *Nabil Benamar* * * ** * ---------------------------------------------------------------------------= ----- * --001a11c2e76a21c52404e29542f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ----------
From: Nabil Benamar <benamar73@gmail.com>
Date: Sun, Jul 28, 2013 at 4:55 PM
Subject: Re: [its] Continue - select = area scoping the Charter
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>

Hi Alexandru,

=A0 =A0 The three topics are of interest...and if it'= ;s necessary to choose one among the list, I vote for :
=A0layering of IPv6 over IEEE 802.11p communication technology.<= /span>

On Sun, Jul 28, 2013 at 4:46 PM, Alexandru Petr= escu <alexandru.petrescu@gmail.com> wrote:
Quick reminder - for the bar BoF it would be= good if we have at least a
rough idea about which of the three areas to pursue with.

If you have not already expressed a preference, please do so, among the
options below:


1. establishment of IP networking between neighboring vehicles using
=A0 =A0either MANET protocols or 1-hop ICMP protocol.

2. layering of IPv6 over IEEE 802.11p communication technology.

3. IPv6-based network-layer distribution of content in a geographic
=A0 =A0area.

Alex

Le 24/07/2013 11:37, Alexandru Petrescu a =E9crit :

Hello,

Thanks to everybody who expressed oppinion towards scoping the
activity. Until now, the first topic of establishment of IP
networking between neighboring vehicles and
vehicle-to-fixed-ITS-station seems to get most support.

We need more discussion around scoping the Charter.

If you have not already done so, please prioritize one topic among
the three below, in order to scope the Charter.

Alex

Le 25/06/2013 17:48, Alexandru Petrescu a =E9crit :
Hello participants to ITS email list,

During recent discussions we mentioned 3 different areas to work
on. They are too many for a meaningful detail work.

Please select area scoping the Charter, prioritizing according to
the environment you work on.

1. establishment of IP networking between neighboring vehicles
using either MANET protocols or 1-hop ICMP protocol.

2. layering of IPv6 over IEEE 802.11p communication technology.

3. IPv6-based network-layer distribution of content in a
geographic area.

Yours,

Alex


_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its




_______________________________________________ its mailing list
its@ietf.org https://ww= w.ietf.org/mailman/listinfo/its




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



<= /div>--
Regards
Nabil Benamar


<= /div>
=
--------------= ------------------------------------------------------------------



--
Regards
Nabil Benamar


<= /div>
=
--------------= ------------------------------------------------------------------
--001a11c2e76a21c52404e29542f3-- From Dirk.von-Hugo@telekom.de Sun Jul 28 11:55:21 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539C421F9CCA for ; Sun, 28 Jul 2013 11:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, FRT_ESTABLISH=2.492, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-UE5LAKfcZb for ; Sun, 28 Jul 2013 11:55:17 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id EC13021F9CAD for ; Sun, 28 Jul 2013 11:55:15 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 28 Jul 2013 20:55:13 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Sun, 28 Jul 2013 20:55:13 +0200 From: To: , Date: Sun, 28 Jul 2013 20:55:12 +0200 Thread-Topic: [its] Continue - select area scoping the Charter Thread-Index: Ac6LshnhEStrtSiPTTCBKxYhHJY18QABSP4g Message-ID: <05C81A773E48DD49B181B04BA21A342A2C6047BCC7@HE113484.emea1.cds.t-internal.com> References: <51C9BBCC.1090304@gmail.com> <51EFA041.7020100@gmail.com> <51F54AF1.4090207@gmail.com> In-Reply-To: <51F54AF1.4090207@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [its] Continue - select area scoping the Charter X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:55:21 -0000 Dear all, My faces are IPv6 over 11p - followed by car2car IP (MANET/ICMP). Thanks Regards Dirk -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexa= ndru Petrescu Sent: Sonntag, 28. Juli 2013 18:47 To: its@ietf.org Subject: Re: [its] Continue - select area scoping the Charter Quick reminder - for the bar BoF it would be good if we have at least a rou= gh idea about which of the three areas to pursue with. If you have not already expressed a preference, please do so, among the opt= ions below: 1. e stablishment of IP networking between neighboring vehicles using either MANET protocols or 1-hop ICMP protocol. 2. layering of IPv6 over IEEE 802.11p communication technology. 3. IPv6-based network-layer distribution of content in a geographic area. Alex Le 24/07/2013 11:37, Alexandru Petrescu a =E9crit : > Hello, > > Thanks to everybody who expressed oppinion towards scoping the=20 > activity. Until now, the first topic of establishment of IP networking=20 > between neighboring vehicles and vehicle-to-fixed-ITS-station seems to=20 > get most support. > > We need more discussion around scoping the Charter. > > If you have not already done so, please prioritize one topic among the=20 > three below, in order to scope the Charter. > > Alex > > Le 25/06/2013 17:48, Alexandru Petrescu a =E9crit : >> Hello participants to ITS email list, >> >> During recent discussions we mentioned 3 different areas to work on.=20 >> They are too many for a meaningful detail work. >> >> Please select area scoping the Charter, prioritizing according to the=20 >> environment you work on. >> >> 1. establishment of IP networking between neighboring vehicles using=20 >> either MANET protocols or 1-hop ICMP protocol. >> >> 2. layering of IPv6 over IEEE 802.11p communication technology. >> >> 3. IPv6-based network-layer distribution of content in a geographic=20 >> area. >> >> Yours, >> >> Alex >> >> >> _______________________________________________ its mailing list=20 >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list=20 > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From pierre.pfister@darou.fr Mon Jul 29 05:03:50 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3C621F97E6 for ; Mon, 29 Jul 2013 05:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEo+H-bN2LgI for ; Mon, 29 Jul 2013 05:03:45 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3321F95DD for ; Mon, 29 Jul 2013 05:03:44 -0700 (PDT) Received: from snake-project.org ([90.39.90.41]) by mwinf5d25 with ME id 6C3i1m0010tXv2q03C3iG2; Mon, 29 Jul 2013 14:03:42 +0200 Received: from [193.48.19.83] (unknown [193.48.19.83]) by snake-project.org (Postfix) with ESMTPSA id CA648C9A1F for ; Mon, 29 Jul 2013 14:03:41 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Pierre PFISTER In-Reply-To: <10806.1375097238@sandelman.ca> Date: Mon, 29 Jul 2013 14:03:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <268D9882-4E75-4C8E-BC46-8B900D39925D@darou.fr> References: <6856.1375095717@sandelman.ca> <10806.1375097238@sandelman.ca> To: its@ietf.org X-Mailer: Apple Mail (2.1085) Subject: [its] Announcing new draft: draft-pfister-moving-net-autoconf-00 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:03:50 -0000 Dear participants to the its mailing list, We just submitted "Routers auto-configuration using Route Information = Option from ICMPv6 Router Advertisements" available at: http://tools.ietf.org/html/draft-pfister-moving-net-autoconf-00 ---- Abstract ---- This draft defines a way for multiple routers that are communicating on a single link to exchange routing information using Router Advertisements. This allows moving networks to communicate with each other through auto-configured routers. This document specifies a new flag for the Router Information option from ICMPv6 Router Advertisement messages and specifies how routers must process such options. -------------------- We have been using this technology in order to establish 3 hops = communications=20 between devices that are located inside moving vehicles (Those devices = are connected on ingress interfaces).=20 Your comments are very welcome. Thanks in advance, Pierre & Alex From alexandru.petrescu@gmail.com Wed Jul 31 00:04:38 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F011E8160 for ; Wed, 31 Jul 2013 00:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.132 X-Spam-Level: X-Spam-Status: No, score=-10.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0XXFt2oAXnZ for ; Wed, 31 Jul 2013 00:04:33 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 200AD11E80E4 for ; Wed, 31 Jul 2013 00:04:31 -0700 (PDT) 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 r6V74Uf7026306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 Jul 2013 09:04:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6V74U5f024455 for ; Wed, 31 Jul 2013 09:04:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6V74T5Z001889 for ; Wed, 31 Jul 2013 09:04:30 +0200 Message-ID: <51F8B6FD.8000708@gmail.com> Date: Wed, 31 Jul 2013 09:04:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> <51D7ECA4.8090104@gmail.com> <51EF9F3D.7000708@gmail.com> In-Reply-To: <51EF9F3D.7000708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Reminder - Plan for bar BoF, Thursday, Aug. 1st, 21h-22h, meet at IETF Registration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:04:38 -0000 Hello, Let us meet at the IETF Registration desk, tomorrow August 1st, at 21h. Depending on conditions, we would then go sit in the zone Pavillion (see the IETF InterContinental room map). Alex Le 24/07/2013 11:32, Alexandru Petrescu a écrit : > Reminder - let us have a bar BoF on Thursday, August 1st, 21h-22h, > at a bar yet to be confirmed. > > Akex > > Le 06/07/2013 12:08, Alexandru Petrescu a écrit : >> The date for ITS bar BoF is now: >> >> Thursday, August 1st 21h-22h >> >> I hope this fits, otherwise do not hesitate to object. >> >> Alex >> >> Le 05/07/2013 17:39, Dowdell, John a écrit : >>> Alex >>> >>> Sounds good to me >>> >>> John John Dowdell Solution Architect, COEIC1 Cassidian Newport, >>> UK Mobile +44 7710 875008 UAE desk +971 2 503 9017 >>> >>> ----- Original Message ----- From: Alexandru Petrescu >>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, 2013 >>> 04:26 PM GMT Standard Time To: Eliot Lear Cc: >>> Dowdell, John; its@ietf.org Subject: Re: [its] >>> Plan for bar BoF Monday after Technical Plenary? >>> >>> manet is followed by 6lo meeting and then bits'n'bytes (demos, >>> food) until 21h. >>> >>> Would 21h-22h bar BoF ITS work? >>> >>> Alex >>> >>> Le 05/07/2013 13:24, Eliot Lear a écrit : >>>> This woudn't kill me either. >>>> >>>> Eliot >>>> >>>> On 7/5/13 1:17 PM, Dowdell, John wrote: >>>>> Alex >>>>> >>>>> I hope to be in town for the manet meeting, but will not >>>>> arrive until Tuesday. I wonder if given the overlap between >>>>> its and manet, it would be worth moving your BOF closer to >>>>> the manet slot on Thursday. >>>>> >>>>> Regards John >>>>> >>>>> -----Original Message----- From: its-bounces@ietf.org >>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >>>>> Sent: 01 July 2013 18:09 To: its@ietf.org Subject: [its] Plan >>>>> for bar BoF Monday after Technical Plenary? >>>>> >>>>> Hi, >>>>> >>>>> I would like to plan for a bar BoF ITS in Berlin. >>>>> >>>>> What do you think about Monday evening after the Technical >>>>> Plenary? >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> The information contained within this e-mail and any files >>>>> attached to this e-mail is private and in addition may >>>>> include commercially sensitive information. The contents of >>>>> this e-mail are for the intended recipient only and >>>>> therefore if you wish to disclose the information contained >>>>> within this e-mail or attached files, please contact the >>>>> sender prior to any such disclosure. If you are not the >>>>> intended recipient, any disclosure, copying or distribution >>>>> is prohibited. Please also contact the sender and inform them >>>>> of the error and delete the e-mail, including any attached >>>>> files from your system. Cassidian Limited, Registered Office >>>>> : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 >>>>> 8FZ Company No: 04191036 http://www.cassidian.com >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> The information contained within this e-mail and any files >>> attached to this e-mail is private and in addition may include >>> commercially sensitive information. The contents of this e-mail >>> are for the intended recipient only and therefore if you wish to >>> disclose the information contained within this e-mail or >>> attached files, please contact the sender prior to any such >>> disclosure. If you are not the intended recipient, any >>> disclosure, copying or distribution is prohibited. Please also >>> contact the sender and inform them of the error and delete the >>> e-mail, including any attached files from your system. Cassidian >>> Limited, Registered Office : Quadrant House, Celtic Springs, >>> Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>> http://www.cassidian.com >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Wed Jul 31 01:07:40 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3411E8147 for ; Wed, 31 Jul 2013 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvAnUNDgzblL for ; Wed, 31 Jul 2013 01:07:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9111E80EE for ; Wed, 31 Jul 2013 01:07:24 -0700 (PDT) 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 r6V87NZD010619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 Jul 2013 10:07:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6V87NjM022662 for ; Wed, 31 Jul 2013 10:07:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.7]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6V87MWS030673 for ; Wed, 31 Jul 2013 10:07:23 +0200 Message-ID: <51F8C5BA.4050100@gmail.com> Date: Wed, 31 Jul 2013 10:07:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> <51D7ECA4.8090104@gmail.com> <51EF9F3D.7000708@gmail.com> <51F8B6FD.8000708@gmail.com> In-Reply-To: <51F8B6FD.8000708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Reminder - Plan for bar BoF, Thursday, Aug. 1st, 21h-22h, meet at IETF Registration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:07:40 -0000 Hello, About remote attendance. Remote attendance is generally encouraged at meetings. For WGs and BoFs there is instant messaging with message relay by willing participants and scribes, live streams and recently even audio feedback. But for this bar BoF ITS there will not be such. We will have a small group focused high-bandwidth discussion. Alex Le 31/07/2013 09:04, Alexandru Petrescu a écrit : > Hello, > > Let us meet at the IETF Registration desk, tomorrow August 1st, at > 21h. > > Depending on conditions, we would then go sit in the zone Pavillion > (see the IETF InterContinental room map). > > Alex > > Le 24/07/2013 11:32, Alexandru Petrescu a écrit : >> Reminder - let us have a bar BoF on Thursday, August 1st, 21h-22h, >> at a bar yet to be confirmed. >> >> Akex >> >> Le 06/07/2013 12:08, Alexandru Petrescu a écrit : >>> The date for ITS bar BoF is now: >>> >>> Thursday, August 1st 21h-22h >>> >>> I hope this fits, otherwise do not hesitate to object. >>> >>> Alex >>> >>> Le 05/07/2013 17:39, Dowdell, John a écrit : >>>> Alex >>>> >>>> Sounds good to me >>>> >>>> John John Dowdell Solution Architect, COEIC1 Cassidian Newport, >>>> UK Mobile +44 7710 875008 UAE desk +971 2 503 9017 >>>> >>>> ----- Original Message ----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, >>>> 2013 04:26 PM GMT Standard Time To: Eliot Lear >>>> Cc: Dowdell, John; its@ietf.org >>>> Subject: Re: [its] Plan for bar BoF Monday after Technical >>>> Plenary? >>>> >>>> manet is followed by 6lo meeting and then bits'n'bytes (demos, >>>> food) until 21h. >>>> >>>> Would 21h-22h bar BoF ITS work? >>>> >>>> Alex >>>> >>>> Le 05/07/2013 13:24, Eliot Lear a écrit : >>>>> This woudn't kill me either. >>>>> >>>>> Eliot >>>>> >>>>> On 7/5/13 1:17 PM, Dowdell, John wrote: >>>>>> Alex >>>>>> >>>>>> I hope to be in town for the manet meeting, but will not >>>>>> arrive until Tuesday. I wonder if given the overlap between >>>>>> its and manet, it would be worth moving your BOF closer to >>>>>> the manet slot on Thursday. >>>>>> >>>>>> Regards John >>>>>> >>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>> Petrescu Sent: 01 July 2013 18:09 To: its@ietf.org >>>>>> Subject: [its] Plan for bar BoF Monday after Technical >>>>>> Plenary? >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would like to plan for a bar BoF ITS in Berlin. >>>>>> >>>>>> What do you think about Monday evening after the Technical >>>>>> Plenary? >>>>>> >>>>>> Alex >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>> The information contained within this e-mail and any files >>>>>> attached to this e-mail is private and in addition may >>>>>> include commercially sensitive information. The contents of >>>>>> this e-mail are for the intended recipient only and >>>>>> therefore if you wish to disclose the information contained >>>>>> within this e-mail or attached files, please contact the >>>>>> sender prior to any such disclosure. If you are not the >>>>>> intended recipient, any disclosure, copying or distribution >>>>>> is prohibited. Please also contact the sender and inform >>>>>> them of the error and delete the e-mail, including any >>>>>> attached files from your system. Cassidian Limited, >>>>>> Registered Office : Quadrant House, Celtic Springs, >>>>>> Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>>>>> http://www.cassidian.com >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> The information contained within this e-mail and any files >>>> attached to this e-mail is private and in addition may include >>>> commercially sensitive information. The contents of this >>>> e-mail are for the intended recipient only and therefore if >>>> you wish to disclose the information contained within this >>>> e-mail or attached files, please contact the sender prior to >>>> any such disclosure. If you are not the intended recipient, any >>>> disclosure, copying or distribution is prohibited. Please also >>>> contact the sender and inform them of the error and delete the >>>> e-mail, including any attached files from your system. >>>> Cassidian Limited, Registered Office : Quadrant House, Celtic >>>> Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 >>>> http://www.cassidian.com >>>> >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Wed Jul 31 12:26:18 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75221F9675 for ; Wed, 31 Jul 2013 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLpv4Y36MJKp for ; Wed, 31 Jul 2013 12:26:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id CCC0721F962D for ; Wed, 31 Jul 2013 12:26:03 -0700 (PDT) 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 r6VJQ1Wg013252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 Jul 2013 21:26:01 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r6VJQ1X9007204 for ; Wed, 31 Jul 2013 21:26:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.10]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r6VJQ0AP013233 for ; Wed, 31 Jul 2013 21:26:00 +0200 Message-ID: <51F964C7.6090102@gmail.com> Date: Wed, 31 Jul 2013 21:25:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: its@ietf.org References: <603F5FD847B5174CBDA37A9DC00532FB09FF7DC6@SUCNPTEXM02.com.ad.uk.ds.corp> <51D7ECA4.8090104@gmail.com> <51EF9F3D.7000708@gmail.com> <51F8B6FD.8000708@gmail.com> <51F8C5BA.4050100@gmail.com> In-Reply-To: <51F8C5BA.4050100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Reminder - Plan for bar BoF, Thursday, Aug. 1st, 21h-22h, meet at IETF Registration X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:26:18 -0000 Hello again, I would like remind: there is no facility whatsoever for remote attendance to this bar BoF. This is a bar BoF, not a full-blown BoF. We will meet informally at the IETF registration desk at 21h and find a place to sit and discuss until 22h. Alex Le 31/07/2013 10:07, Alexandru Petrescu a écrit : > Hello, > > About remote attendance. > > Remote attendance is generally encouraged at meetings. For WGs and > BoFs there is instant messaging with message relay by willing > participants and scribes, live streams and recently even audio > feedback. > > But for this bar BoF ITS there will not be such. We will have a > small group focused high-bandwidth discussion. > > Alex > > Le 31/07/2013 09:04, Alexandru Petrescu a écrit : >> Hello, >> >> Let us meet at the IETF Registration desk, tomorrow August 1st, at >> 21h. >> >> Depending on conditions, we would then go sit in the zone Pavillion >> (see the IETF InterContinental room map). >> >> Alex >> >> Le 24/07/2013 11:32, Alexandru Petrescu a écrit : >>> Reminder - let us have a bar BoF on Thursday, August 1st, >>> 21h-22h, at a bar yet to be confirmed. >>> >>> Akex >>> >>> Le 06/07/2013 12:08, Alexandru Petrescu a écrit : >>>> The date for ITS bar BoF is now: >>>> >>>> Thursday, August 1st 21h-22h >>>> >>>> I hope this fits, otherwise do not hesitate to object. >>>> >>>> Alex >>>> >>>> Le 05/07/2013 17:39, Dowdell, John a écrit : >>>>> Alex >>>>> >>>>> Sounds good to me >>>>> >>>>> John John Dowdell Solution Architect, COEIC1 Cassidian >>>>> Newport, UK Mobile +44 7710 875008 UAE desk +971 2 503 9017 >>>>> >>>>> ----- Original Message ----- From: Alexandru Petrescu >>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, July 05, >>>>> 2013 04:26 PM GMT Standard Time To: Eliot Lear >>>>> Cc: Dowdell, John; its@ietf.org >>>>> Subject: Re: [its] Plan for bar BoF Monday >>>>> after Technical Plenary? >>>>> >>>>> manet is followed by 6lo meeting and then bits'n'bytes >>>>> (demos, food) until 21h. >>>>> >>>>> Would 21h-22h bar BoF ITS work? >>>>> >>>>> Alex >>>>> >>>>> Le 05/07/2013 13:24, Eliot Lear a écrit : >>>>>> This woudn't kill me either. >>>>>> >>>>>> Eliot >>>>>> >>>>>> On 7/5/13 1:17 PM, Dowdell, John wrote: >>>>>>> Alex >>>>>>> >>>>>>> I hope to be in town for the manet meeting, but will not >>>>>>> arrive until Tuesday. I wonder if given the overlap >>>>>>> between its and manet, it would be worth moving your BOF >>>>>>> closer to the manet slot on Thursday. >>>>>>> >>>>>>> Regards John >>>>>>> >>>>>>> -----Original Message----- From: its-bounces@ietf.org >>>>>>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>>>>> Petrescu Sent: 01 July 2013 18:09 To: its@ietf.org >>>>>>> Subject: [its] Plan for bar BoF Monday after Technical >>>>>>> Plenary? >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I would like to plan for a bar BoF ITS in Berlin. >>>>>>> >>>>>>> What do you think about Monday evening after the >>>>>>> Technical Plenary? >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its The >>>>>>> information contained within this e-mail and any files >>>>>>> attached to this e-mail is private and in addition may >>>>>>> include commercially sensitive information. The contents >>>>>>> of this e-mail are for the intended recipient only and >>>>>>> therefore if you wish to disclose the information >>>>>>> contained within this e-mail or attached files, please >>>>>>> contact the sender prior to any such disclosure. If you >>>>>>> are not the intended recipient, any disclosure, copying >>>>>>> or distribution is prohibited. Please also contact the >>>>>>> sender and inform them of the error and delete the >>>>>>> e-mail, including any attached files from your system. >>>>>>> Cassidian Limited, Registered Office : Quadrant House, >>>>>>> Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: >>>>>>> 04191036 http://www.cassidian.com >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> The information contained within this e-mail and any files >>>>> attached to this e-mail is private and in addition may >>>>> include commercially sensitive information. The contents of >>>>> this e-mail are for the intended recipient only and >>>>> therefore if you wish to disclose the information contained >>>>> within this e-mail or attached files, please contact the >>>>> sender prior to any such disclosure. If you are not the >>>>> intended recipient, any disclosure, copying or distribution >>>>> is prohibited. Please also contact the sender and inform them >>>>> of the error and delete the e-mail, including any attached >>>>> files from your system. Cassidian Limited, Registered Office >>>>> : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 >>>>> 8FZ Company No: 04191036 http://www.cassidian.com >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ its mailing >>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alison@she-devel.com Wed Jul 31 15:58:14 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8488621F9C72 for ; Wed, 31 Jul 2013 15:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbbKPSLohTa5 for ; Wed, 31 Jul 2013 15:58:10 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6321F9AA7 for ; Wed, 31 Jul 2013 15:58:10 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so2899278oag.0 for ; Wed, 31 Jul 2013 15:58:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=E6UTFFKN2wfVFz9oyiAhHEbs+jis1ve2c3iGLRlL73E=; b=TYQ6qR3OxMmcw6bOZ5qTQM2ZR25xd/D8sdv9FI/XylkKtl2LcS8668BRp0j8CQhhjf eOmOpxYy3imJnuOjZbO1OWbXOYGIj7QKEPxeog9L0sa1HlmGKRM0r+oCwE00IOScVnFq 6rfZEh8Hx+a3uZ7AdZq9g9pir8PooLEC15yEGqyXsAF+eROhDbxXiO1DHT658IhBtvIQ 0JJZcZsS9J79hTkikIBSQZ69CwTHuFKl+By/iLvWyYJfQQrzlPFEjx/1PABm6YFO9pII SQMDTww6StV31QxkqHt8ODzeIuSgLrNoD1TAlLI+/tfT9eF5gB+uDkFhIgCxFUloSYNC VfIw== MIME-Version: 1.0 X-Received: by 10.50.62.75 with SMTP id w11mr943149igr.19.1375311488690; Wed, 31 Jul 2013 15:58:08 -0700 (PDT) Received: by 10.43.17.73 with HTTP; Wed, 31 Jul 2013 15:58:08 -0700 (PDT) Date: Wed, 31 Jul 2013 15:58:08 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlI+K9Q9FapAzkOofvRgX8wKEfiEYNyvoK/HoABJLjkxOZbNFFUxx9dvPEjoggDC2EOLWr0 Subject: [its] "OVERBROAD PATENT ON IN-FLIGHT/IN-CAR NETWORKING" X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:58:14 -0000 http://patents.stackexchange.com/questions/4624/vehicle-networking-http-to-can-bus-gateway-lear-patent-application-prior -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} The intermediary between the head and the hands must be the heart. -- Thea von Harbou