From alexandru.petrescu@gmail.com Sat Mar 9 03:44:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7390A21F849A for ; Sat, 9 Mar 2013 03:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[AWL=0.750, 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 t9XYJxthRzTA for ; Sat, 9 Mar 2013 03:44:22 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id B469221F845E for ; Sat, 9 Mar 2013 03:44:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r29BiIhb032467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 9 Mar 2013 12:44:18 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r29BiIhg027555 for ; Sat, 9 Mar 2013 12:44:18 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r29BiCSK029192 for ; Sat, 9 Mar 2013 12:44:17 +0100 Message-ID: <513B2079.7060104@gmail.com> Date: Sat, 09 Mar 2013 12:43:53 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Meet at IETF Registration Desk, Monday 19h30 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, 09 Mar 2013 11:44:22 -0000 I would like to meet ITS enthusiasts Monday 19h30 at IETF Registration Desk to discuss Charter proposal, and in general about advancement of ITS at IETF and other SDOs. As hallway discussion, and why not dine. Alex PS: RFC6771 and RFC5434 (successful bar bofs and bofs) From alexandru.petrescu@gmail.com Mon Mar 11 15:09: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 BEF6521F855C for ; Mon, 11 Mar 2013 15:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.041 X-Spam-Level: X-Spam-Status: No, score=-10.041 tagged_above=-999 required=5 tests=[AWL=0.208, 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 qgplZf1ku9MU for ; Mon, 11 Mar 2013 15:09:49 -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 C1B0621F860A for ; Mon, 11 Mar 2013 15:09:37 -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 r2BM9aNC013982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Mar 2013 23:09:36 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BM9ZaV001216; Mon, 11 Mar 2013 23:09:35 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BM9PS4023441; Mon, 11 Mar 2013 23:09:35 +0100 Message-ID: <513E55F2.2000001@gmail.com> Date: Mon, 11 Mar 2013 23:08:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Abdussalam Baryun References: <511E914B.6010702@gmail.com> <511F8808.8000306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] RoLL and Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:09:49 -0000 Le 18/02/2013 12:43, Abdussalam Baryun a écrit : > On 2/16/13, Alexandru Petrescu wrote: >> RoLL stands for Routing over Low-Power and Lossy Links. > > ROLL is Routing over LLN, its lossy network not only lossy links, I > think ITS is runing for lossy networks, I am not at much ease with RoLL terminology, sorry. But let me say that when a network loses packets, maybe TCP could be used. In that sense, TCP would compare to RPL? >> But with V2V one would be looking more at high-power links, because >> the higher the power the higher the speed of vehicles (e.g. in >> France at 100mW WiFi a V2V entertaining videoconference allows for >> two convoyed vehicles speed of around 90km/h, because the 100mW >> corresponds to approximately 50meter distance, which is the >> security distance in France for speed of 90km/h, no more). This >> would mean it's impossible to use RoLL on a highway where the >> recommended speed is much above 90km/h. > > ROLL is not for high power, but don't forget that Vehicles are not > all large as cars or trucks, they may be small transporters machines > in buildings/homes. Ah! I didnt think that use case... When I say high-power emitters I mean more in terms of distance between vehicles, not necessarily the size of the vehicle (although the two may be related). So... two small golf-cars may communicate using short-range links like WiFi, if the golf court is small, ie the distance between the vehicles is small. Two small golf-cars would not be able to communicate using WiFi if the diestance between them is too long. RPL is mostly for short-range links, like WiFi and even shorter like 802.15.4. >> RoLL is designed for links in the short-range family, like >> 802.15.4. Whereas for V2V one would look at longer-range. > > Why we make the scope narrow to longer-range, I think ITS needs both > long and short range to become intelligent otherwise it will not > become intelligent, :-) maybe we should rename ITS into DTS - dumb transportation systems (like in 'smart end - dumb network'). But I agree with you both long-range and short-range links should be considered. Just that in the case of V2V protocols the long-range links are more important because only them can make V2V possible. Today nobody uses long-range no-infrastructure links between vehicles in a V2V manner. If we are able to use a long-range technology between two vehicles then there is chance of novelty. To make that work we need the highest-power no-infrastructure technology available. >> Inside a vehicle, RoLL would run ok on lossy links. But we also >> consider in a vehicle to use more reliable links, like Ethernet >> cable, OBD-II interfaces, CAN. Currently AUTOSAR SDO seems >> interested in IP in vehicles, but I am not sure whether they >> mention RoLL? > > Yes I like to have cables and/or wireless inside vehicles, depends > on the transport resource and reason actually. I agree. In a vehicle, there exist already a number of links standardized, like 'CAN'. I think it is little reasonable to imagine that the links designed for office/building are to be reused in vehicles. And on these links RPL is made to work. In a vehicle it's different... Rather than reusing 802.15.4 in a vehicle, I'd start with considering CAN and OBD-II. But that's just an oppinion. >> Now of course, one could say that the RPL protocol could run on >> anything, not necessarily low-power links and lossy links. At >> which point I could reply that there are other routing protocols >> which could run on anything as well. > > The bueaty of RPL is that it used for buildings and homes, so it can > be used in our intelligence for our ITS. Not sure about that :-) Buildings and homes have many things in common, which are not in cars: issued from the fact that walls dont move, dont change their attachment points. Assign a set of IP addresses to devices fixed to walls and there they stay so for years. In a vehicle on the other hand... Turn on the wrong button in a building and then check the other button, but in a vehicle dont press break if you mean to accelerate. > Most transports in the world are between buildings and homes :-) Yett the vehicle is different from both (from a communicaiton standpoint). Alex > >> >> But what RoLL doesn't have and what we'd propose to do here is a >> mechanism to exchange routes, and to do address autoconfiguration >> for vehicles. >> > > IMO, we only need to use the RoLL techniques which help in our scope > and ignore its techniques that is not related. We may take some other > techniques as well or create a new mechanism depending which is > better way on the discussion table. > >> Depending on these aspects, we need to identify how to add RoLL in >> the ITS picture. > > Yes, I agree totally, > >> >> What do you think? >> > > I think we are on the right track to best transports :) > > From alexandru.petrescu@gmail.com Mon Mar 11 15:42: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 C419821F9045 for ; Mon, 11 Mar 2013 15:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=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 xfFVAPt0tmkS for ; Mon, 11 Mar 2013 15:42: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 6438221F9044 for ; Mon, 11 Mar 2013 15:42: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 r2BMgvkc013746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Mar 2013 23:42:57 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BMgvnx004835 for ; Mon, 11 Mar 2013 23:42:57 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BMgnx4029098 for ; Mon, 11 Mar 2013 23:42:56 +0100 Message-ID: <513E5DC6.1060108@gmail.com> Date: Mon, 11 Mar 2013 23:42:14 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "its@ietf.org" References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Updated Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:42:59 -0000 Participants to the ITS effort at IETF, Following suggestions I have updated the Draft Charter Proposal for ITS. It reads below. Please comment. (I hope I got your comments right). It has additions about RoLL, PMIP, smartcities, 2 new milestones. Yours, Alex -------------------------------------------------------------------- Intelligent Transportation Systems at IETF Draft Charter Proposal February 15th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal bar BoF Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) are composed of interconnected systems of machines; vehicles, mobile devices and fixed embedded devices (actuator and sensors). These machines communicate with fixed access points which are are deployed along terrestrial roads (e.g. Road-Side Units), shores along water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless access to equipment deployed in mobile vehicles (e.g. On-Board Units). The entire system is connected to the Internet through one or several IP paths. In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two different radios). Due to the mobile nature of the system, several problems exist with respect to IP addressing and route establishment such that Internet communications can be realized (a typical IP network is using mostly IP addresses topologically valid at a single point, and relatively stable routing system). In addition, several new problems specific to vehicular communications at application layer are exposed when the communication protocol is IP. Several Standards Development Organizations outside IETF work towards developping protocols for vehicular communications. In some cases IP protocols are used for transport, in other cases IP protocols are modified for the purpose. The examples of SDOs and respective groups and documents are: ETSI ITS, ISO TC, IEEE 802.11p, AUTOSAR, IPSO. A number of IETF protocols are being considered in the context of Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, ND, ULA, DHCPv6, RPL, PMIPv6. Others, such as Global HAHA, are not excluded. At IETF several Working Groups such as 6MAN, V6OPS, DHC, MIF, MANET, DMM, RoLL, NETEXT, LISP produce work which is highly pertinent to the ITS context. New efforts at IETF are also relevant: 6TSCH effort (for communication inside a vehicle) and I2RS WG. Ongoing work ------------ Overall, in this group, the ongoing work items are to identify the following: (0) Scenarios and Requirements for IP in Intelligent Transportation Systems. (1) vehicular-specific problems to be solved with IETF protocols, (2) interactions with SDOs, (3) existing IETF protocols which may solve the problems. (4) EtherTypes for transporting IP over a MAC specific to vehicular communications. (5) country-level frequencies for long-range vehicular communications with an IP-friendly MAC layer. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developped which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. One particular use case should be identified as supporting basis for further developments. One particular use case could be under the form of an instrumented ambulance. The ambulance is connected to the Internet and offers wireless and wired access to a large number of individual equipments deployed in-vehicle. There is a need to identify which existing protocols may be reused to realize the connection between the ambulance and the hospital. The smart-city use case is also important for networking country- and world-wide transports. The use case should lead to development of requirements and services for transports within cities, or countries, making them smart. The ITS technologies may use techniques from MANET and from RoLL adapted to this smart-city use case. One may need to consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in community networks. A hybrid routing protocol could be used. IP-over-foo, where foo is one particular link-layer which is identified as very pertinent for vehicular communications. One particular example is IEEE 802.11p, but is not the only one; clarifications whether IP-over-80211p is actually possible, due to lack of country-level regulation. IP is not 'safety' but rather 'entertainment'. Other link-layers which are pertinent are 802.11abgn, and 802.11ai, and 802.11ak. The preferred ones will be those allowing long-range communications between vehicles, at high-power levels. Addressing mechanisms for vehicular communications: methods of converting a Vehicular Identification Number, or geographical coordinates, into an IPv6 address, and vice-versa. Scoping of IPv6 addresses: addresses within a vehicle, between vehicles, to infrastructure. Distributing addresses between vehicles, using dynamic mechanisms, such as DHCP or ND, which respect constraints of applications. Route exchanges between vehicles, and between vehicles and road-side units. This includes the identification of a need to realize the exchanges, the constraints related to loop-free graphs and networks which scale to large sizes, their interaction with the imposed physical topology. It is possible to adapt MANET and RoLL protocols to use in ITS. A distinction could be made between protocols used within a vehicle, and protocols used between two vehicles. Fast Network Transport Protocol is a protocol designed at ISO for vehicular communications. Feedback is solicited from IETF about this protocol. GeoNetworking is a protocol designed at ETSI. Feedback is solicited from IETF about this protocol. Coordinate work with ISO SDO, about developping a V2V protocol based on route exchanges using Router Advertisements. Milestones: Mar 2013 - Meet in Orlando Jul 2013 - Meet in Berlin Dec 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems" Dec 2013 - Present status from ISO about V2V From alexandru.petrescu@gmail.com Mon Mar 11 16:06:09 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1721F8C77 for ; Mon, 11 Mar 2013 16:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.185, 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 3J8ClMkiLWkv for ; Mon, 11 Mar 2013 16:06:09 -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 CFCE221F8C69 for ; Mon, 11 Mar 2013 16:06:08 -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 r2BN67WO007305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Mar 2013 00:06:07 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2BN671d007783 for ; Tue, 12 Mar 2013 00:06:07 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.8]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2BN6552000576 for ; Tue, 12 Mar 2013 00:06:07 +0100 Message-ID: <513E6339.6000806@gmail.com> Date: Tue, 12 Mar 2013 00:05:29 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: its@ietf.org References: <513B2079.7060104@gmail.com> In-Reply-To: <513B2079.7060104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] Meet at IETF Registration Desk, Monday 19h30 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:06:09 -0000 Repeat, I propose to meet at IETF Registration Desk at 19h30. First entertain a bit the Charter ideas, then bar/restaurant/whatever. Alex Le 09/03/2013 12:43, Alexandru Petrescu a écrit : > I would like to meet ITS enthusiasts > > Monday > 19h30 > at IETF Registration Desk > > to discuss Charter proposal, and in general about advancement of ITS at > IETF and other SDOs. > > As hallway discussion, and why not dine. > > Alex > PS: RFC6771 and RFC5434 (successful bar bofs and bofs) > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > > From william.d.ivancic@nasa.gov Mon Mar 11 16:26:43 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 9A0FB21F8D1A for ; Mon, 11 Mar 2013 16:26:43 -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 VedhW1ZqJ4Y6 for ; Mon, 11 Mar 2013 16:26:42 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (NDMSNPF01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF1D21F8EE7 for ; Mon, 11 Mar 2013 16:26:40 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (NDJSPPT105.ndc.nasa.gov [198.117.1.199]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 29EF7260013; Mon, 11 Mar 2013 18:26:40 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt105.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r2BNQdQM009307; Mon, 11 Mar 2013 18:26:39 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub04.ndc.nasa.gov ([10.202.202.163]) with mapi; Mon, 11 Mar 2013 18:26:40 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Alexandru Petrescu , "its@ietf.org" Date: Mon, 11 Mar 2013 18:26:40 -0500 Thread-Topic: [its] Updated Draft Charter proposal Thread-Index: Ac4eqcntBRj+Vep4SwGvtPBKOwsWMwABhlDQ Message-ID: In-Reply-To: <513E5DC6.1060108@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.9.8327, 1.0.431, 0.0.0000 definitions=2013-03-11_04:2013-03-08, 2013-03-11, 1970-01-01 signatures=0 Subject: Re: [its] Updated Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 23:26:43 -0000 Propose From: "In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two different radios)." To: In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two OR MORE different radios SIMULTANEOUSLY)." Question: Do you want simultaneous use of multiple radios or not? Will Ivancic > From: Alexandru Petrescu > Date: Mon, 11 Mar 2013 17:42:14 -0500 > To: "its@ietf.org" > Subject: [its] Updated Draft Charter proposal >=20 > In this system, disjoint and > heterogeneous radio systems are used (e.g. a vehicle uses two > different radios). From abdussalambaryun@gmail.com Tue Mar 12 03:38:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59F421F8921 for ; Tue, 12 Mar 2013 03:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, J_CHICKENPOX_13=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 41WYe4wwda3U for ; Tue, 12 Mar 2013 03:38:22 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0600E21F8917 for ; Tue, 12 Mar 2013 03:38:22 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so4895039pbc.28 for ; Tue, 12 Mar 2013 03:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=u0uFfzFGhJSv4yE9ZGgUY1beNkV/gGRiDAsNZmChbOg=; b=ZI856zEMlTR+rEYFaQXq0HUM2v/Lg3cFHKN19X71x1ZIujDCoglpDgnDHoZVj5Awbg 3LU8T+orxCpgb5u1GS4FOSpGGYi1HbKy5XUtHxkXsOHoHBtN5tS583nKv7j50Ho2Lkvv OKQu0rHZYSzqOHAxW3R1YmSg3zCs7PPrBBUwamE8L6SFzWtUp1ngtqZRK/33VTpe8AN/ 7L9oraxA4NRu7FuLqBqbSAEf2nhiDJ+M94l4YHWH6cMIfWhYtNwxAaxjjx79JAbOrS+S zL4sh3FP8sUAC5XEIMTRqA/RWjOAqL01pE2fHrQEBMomwrJ6CG+gBO4ITISlNu5ZOUKf jx/Q== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr36404186pbc.163.1363084701637; Tue, 12 Mar 2013 03:38:21 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Tue, 12 Mar 2013 03:38:21 -0700 (PDT) In-Reply-To: <513E5DC6.1060108@gmail.com> References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> <513E5DC6.1060108@gmail.com> Date: Tue, 12 Mar 2013 11:38:21 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Updated Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 10:38:23 -0000 IMHO, the charter is well representing ITS, I hope that this opens more discussions at Orlando to see other opinions. thanking you AB On 3/11/13, Alexandru Petrescu wrote: > Participants to the ITS effort at IETF, > > Following suggestions I have updated the Draft Charter Proposal for ITS. > It reads below. Please comment. (I hope I got your comments right). > > It has additions about RoLL, PMIP, smartcities, 2 new milestones. > > Yours, > > Alex > > -------------------------------------------------------------------- > > Intelligent Transportation Systems at IETF > Draft Charter Proposal > February 15th, 2013 > http://ietf.org/mailman/listinfo/its > > > Intelligent Transportation Systems (its) > ---------------------------------------- > Current Status: Informal bar BoF > > Chairs: > TBD > TBD > > Assigned Area Director: > TBD () > > Mailing list > Address: its@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/its > Archive: > http://www.ietf.org/mail-archive/web/its/current/maillist.html > > Draft Charter Proposal: > > Context > ------- > > Intelligent Transportation Systems (ITS) are composed of > interconnected systems of machines; vehicles, mobile devices and fixed > embedded devices (actuator and sensors). These machines communicate > with fixed access points which are are deployed along terrestrial > roads (e.g. Road-Side Units), shores along water paths; alternatively, > mobile or fixed access points may be deployed above ground; they all > offer wireless access to equipment deployed in mobile vehicles (e.g. > On-Board Units). The entire system is connected to the Internet > through one or several IP paths. In this system, disjoint and > heterogeneous radio systems are used (e.g. a vehicle uses two > different radios). > > Due to the mobile nature of the system, several problems exist with > respect to IP addressing and route establishment such that Internet > communications can be realized (a typical IP network is using mostly > IP addresses topologically valid at a single point, and relatively > stable routing system). In addition, several new problems specific to > vehicular communications at application layer are exposed when the > communication protocol is IP. > > Several Standards Development Organizations outside IETF work towards > developping protocols for vehicular communications. In some cases IP > protocols are used for transport, in other cases IP protocols are > modified for the purpose. The examples of SDOs and respective groups > and documents are: ETSI ITS, ISO TC, IEEE 802.11p, AUTOSAR, IPSO. > > A number of IETF protocols are being considered in the context of > Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, > ND, ULA, DHCPv6, RPL, PMIPv6. Others, such as Global HAHA, are not > excluded. At IETF several Working Groups such as 6MAN, V6OPS, DHC, > MIF, MANET, DMM, RoLL, NETEXT, LISP produce work which is highly > pertinent to the ITS context. > > New efforts at IETF are also relevant: 6TSCH effort (for communication > inside a vehicle) and I2RS WG. > > Ongoing work > ------------ > Overall, in this group, the ongoing work items are to identify the > following: > (0) Scenarios and Requirements for IP in Intelligent Transportation > Systems. > (1) vehicular-specific problems to be solved with IETF protocols, > (2) interactions with SDOs, > (3) existing IETF protocols which may solve the problems. > (4) EtherTypes for transporting IP over a MAC specific to vehicular > communications. > (5) country-level frequencies for long-range vehicular communications > with an IP-friendly MAC layer. > > Potential new work items > ------------------------ > The following potential work items exist: > > Scenarios and requirements for vehicular communications will be > developped which introduce at IETF the terms V2V, V2I, V2R and > intra-vehicular paradigms. > > One particular use case should be identified as supporting basis for > further developments. > > One particular use case could be under the form of an instrumented > ambulance. The ambulance is connected to the Internet and offers > wireless and wired access to a large number of individual equipments > deployed in-vehicle. There is a need to identify which existing > protocols may be reused to realize the connection between the > ambulance and the hospital. > > The smart-city use case is also important for networking country- and > world-wide transports. The use case should lead to development of > requirements and services for transports within cities, or countries, > making them smart. The ITS technologies may use techniques from MANET > and from RoLL adapted to this smart-city use case. One may need to > consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in > community networks. A hybrid routing protocol could be used. > > IP-over-foo, where foo is one particular link-layer which is > identified as very pertinent for vehicular communications. One > particular example is IEEE 802.11p, but is not the only one; > clarifications whether IP-over-80211p is actually possible, due to > lack of country-level regulation. IP is not 'safety' but rather > 'entertainment'. Other link-layers which are pertinent are > 802.11abgn, and 802.11ai, and 802.11ak. The preferred ones will be > those allowing long-range communications between vehicles, at > high-power levels. > > Addressing mechanisms for vehicular communications: methods of > converting a Vehicular Identification Number, or geographical > coordinates, into an IPv6 address, and vice-versa. Scoping of IPv6 > addresses: addresses within a vehicle, between vehicles, to > infrastructure. Distributing addresses between vehicles, using > dynamic mechanisms, such as DHCP or ND, which respect constraints of > applications. > > Route exchanges between vehicles, and between vehicles and road-side > units. This includes the identification of a need to realize the > exchanges, the constraints related to loop-free graphs and networks > which scale to large sizes, their interaction with the imposed > physical topology. > > It is possible to adapt MANET and RoLL protocols to use in ITS. A > distinction could be made between protocols used within a vehicle, and > protocols used between two vehicles. > > Fast Network Transport Protocol is a protocol designed at ISO for > vehicular communications. Feedback is solicited from IETF about this > protocol. > > GeoNetworking is a protocol designed at ETSI. Feedback is solicited > from IETF about this protocol. > > Coordinate work with ISO SDO, about developping a V2V protocol based > on route exchanges using Router Advertisements. > > Milestones: > Mar 2013 - Meet in Orlando > Jul 2013 - Meet in Berlin > Dec 2013 - Present drafts "Scenarios and Requirements for IP in > Intelligent Transportation Systems" > Dec 2013 - Present status from ISO about V2V > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From abdussalambaryun@gmail.com Tue Mar 12 03:40: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 70EE421F855C for ; Tue, 12 Mar 2013 03:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 SzDz3UMrOw0y for ; Tue, 12 Mar 2013 03:40:49 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B198521F8552 for ; Tue, 12 Mar 2013 03:40:43 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id z8so803544dad.19 for ; Tue, 12 Mar 2013 03:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vo/uNPnH/g3aGjggRFDs/nazU7nNSSaJjczv4O584To=; b=bYM94z8i5K8SDM0XcFBLgfeGNmz6PBCX4gKfVN9isvOHHEO0yoEOzMZ+D/MxNo0O/e DSXKMeoIjkvUNXoTiX3FFDIGHox2WeLylETUO2X+vO9ucyAfB4LuoouWj43TaUA3dQRO RMug4OFXt6fsPw9D+o+6rQmRG1Pf7q49eTpu4IMZPegTvp0iWGJjnLsOxlOwEIC4+77N P9kc1NgjWFTVZ7nJM12xSo7bbURVDCMTaBKuSqcTkkIgrtLExd/gKbZ8Q2FwkJU+Sii+ IpJVWkjJ/s+/47F2JcwiiwrWlmBoe+5CG0xtI3n6pbAEUBY+xP8GSC9gpXhFHp6j19Md 6gRw== MIME-Version: 1.0 X-Received: by 10.68.179.98 with SMTP id df2mr35567560pbc.215.1363084843067; Tue, 12 Mar 2013 03:40:43 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Tue, 12 Mar 2013 03:40:42 -0700 (PDT) In-Reply-To: References: <513E5DC6.1060108@gmail.com> Date: Tue, 12 Mar 2013 11:40:42 +0100 Message-ID: From: Abdussalam Baryun To: "Ivancic, William D. (GRC-RHN0)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Updated Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 10:40:49 -0000 I think I understand from that as example of possible multiple radio use, AB On 3/12/13, Ivancic, William D. (GRC-RHN0) wrote: > Propose > > From: "In this system, disjoint and > heterogeneous radio systems are used (e.g. a vehicle uses two > different radios)." > > To: In this system, disjoint and > heterogeneous radio systems are used (e.g. a vehicle uses two OR MORE > different radios SIMULTANEOUSLY)." > > Question: > > Do you want simultaneous use of multiple radios or not? > > Will Ivancic > > >> From: Alexandru Petrescu >> Date: Mon, 11 Mar 2013 17:42:14 -0500 >> To: "its@ietf.org" >> Subject: [its] Updated Draft Charter proposal >> >> In this system, disjoint and >> heterogeneous radio systems are used (e.g. a vehicle uses two >> different radios). > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From karagian@cs.utwente.nl Tue Mar 12 03:51: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 46F1421F8952 for ; Tue, 12 Mar 2013 03:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_13=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 uIeXgfRvqIhO for ; Tue, 12 Mar 2013 03:51:03 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53921F8917 for ; Tue, 12 Mar 2013 03:51:01 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 12 Mar 2013 11:51:02 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 11:50:57 +0100 From: To: Thread-Topic: [its] Updated Draft Charter proposal Thread-Index: AQHOHw27Dm9oQSc39kKfeEESLwlZp5ih3zWw Date: Tue, 12 Mar 2013 10:50:57 +0000 Message-ID: References: <511E914B.6010702@gmail.com> <511F8A00.4080408@gmail.com> <513E5DC6.1060108@gmail.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: its@ietf.org Subject: Re: [its] Updated Draft Charter proposal X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 10:51:04 -0000 Dear Alex, Dear all, Thanks for setting up the text for the ITS charter! Sorry for being silent the last months, but I was somehow overloaded! I see that some issues/topics that have been presented during the previous = IETF ITS meetings (including some that I had presented) are included in the= charter and that is good! I could include more issues/topics, but I think that it is good to first st= art with a small number of issues/topics! Please note that I will not be attending the IETF meeting in Orlando, but I= would like to emphasize that I am supporting this activity! Best regards, Georgios > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: dinsdag 12 maart 2013 11:38 > To: Alexandru Petrescu > Cc: its@ietf.org > Subject: Re: [its] Updated Draft Charter proposal >=20 > IMHO, the charter is well representing ITS, I hope that this opens more > discussions at Orlando to see other opinions. >=20 > thanking you > AB >=20 > On 3/11/13, Alexandru Petrescu wrote: > > Participants to the ITS effort at IETF, > > > > Following suggestions I have updated the Draft Charter Proposal for ITS= . > > It reads below. Please comment. (I hope I got your comments right). > > > > It has additions about RoLL, PMIP, smartcities, 2 new milestones. > > > > Yours, > > > > Alex > > > > -------------------------------------------------------------------- > > > > Intelligent Transportation Systems at IETF > > Draft Charter Proposal > > February 15th, 2013 > > http://ietf.org/mailman/listinfo/its > > > > > > Intelligent Transportation Systems (its) > > ---------------------------------------- > > Current Status: Informal bar BoF > > > > Chairs: > > TBD > > TBD > > > > Assigned Area Director: > > TBD () > > > > Mailing list > > Address: its@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/its > > Archive: > > http://www.ietf.org/mail-archive/web/its/current/maillist.html > > > > Draft Charter Proposal: > > > > Context > > ------- > > > > Intelligent Transportation Systems (ITS) are composed of > > interconnected systems of machines; vehicles, mobile devices and fixed > > embedded devices (actuator and sensors). These machines communicate > > with fixed access points which are are deployed along terrestrial > > roads (e.g. Road-Side Units), shores along water paths; alternatively, > > mobile or fixed access points may be deployed above ground; they all > > offer wireless access to equipment deployed in mobile vehicles (e.g. > > On-Board Units). The entire system is connected to the Internet > > through one or several IP paths. In this system, disjoint and > > heterogeneous radio systems are used (e.g. a vehicle uses two > > different radios). > > > > Due to the mobile nature of the system, several problems exist with > > respect to IP addressing and route establishment such that Internet > > communications can be realized (a typical IP network is using mostly > > IP addresses topologically valid at a single point, and relatively > > stable routing system). In addition, several new problems specific to > > vehicular communications at application layer are exposed when the > > communication protocol is IP. > > > > Several Standards Development Organizations outside IETF work towards > > developping protocols for vehicular communications. In some cases IP > > protocols are used for transport, in other cases IP protocols are > > modified for the purpose. The examples of SDOs and respective groups > > and documents are: ETSI ITS, ISO TC, IEEE 802.11p, AUTOSAR, IPSO. > > > > A number of IETF protocols are being considered in the context of > > Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, > > ND, ULA, DHCPv6, RPL, PMIPv6. Others, such as Global HAHA, are not > > excluded. At IETF several Working Groups such as 6MAN, V6OPS, DHC, > > MIF, MANET, DMM, RoLL, NETEXT, LISP produce work which is highly > > pertinent to the ITS context. > > > > New efforts at IETF are also relevant: 6TSCH effort (for communication > > inside a vehicle) and I2RS WG. > > > > Ongoing work > > ------------ > > Overall, in this group, the ongoing work items are to identify the > > following: > > (0) Scenarios and Requirements for IP in Intelligent Transportation > > Systems. > > (1) vehicular-specific problems to be solved with IETF protocols, > > (2) interactions with SDOs, > > (3) existing IETF protocols which may solve the problems. > > (4) EtherTypes for transporting IP over a MAC specific to vehicular > > communications. > > (5) country-level frequencies for long-range vehicular communications > > with an IP-friendly MAC layer. > > > > Potential new work items > > ------------------------ > > The following potential work items exist: > > > > Scenarios and requirements for vehicular communications will be > > developped which introduce at IETF the terms V2V, V2I, V2R and > > intra-vehicular paradigms. > > > > One particular use case should be identified as supporting basis for > > further developments. > > > > One particular use case could be under the form of an instrumented > > ambulance. The ambulance is connected to the Internet and offers > > wireless and wired access to a large number of individual equipments > > deployed in-vehicle. There is a need to identify which existing > > protocols may be reused to realize the connection between the > > ambulance and the hospital. > > > > The smart-city use case is also important for networking country- and > > world-wide transports. The use case should lead to development of > > requirements and services for transports within cities, or countries, > > making them smart. The ITS technologies may use techniques from > MANET > > and from RoLL adapted to this smart-city use case. One may need to > > consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in > > community networks. A hybrid routing protocol could be used. > > > > IP-over-foo, where foo is one particular link-layer which is > > identified as very pertinent for vehicular communications. One > > particular example is IEEE 802.11p, but is not the only one; > > clarifications whether IP-over-80211p is actually possible, due to > > lack of country-level regulation. IP is not 'safety' but rather > > 'entertainment'. Other link-layers which are pertinent are > > 802.11abgn, and 802.11ai, and 802.11ak. The preferred ones will be > > those allowing long-range communications between vehicles, at > > high-power levels. > > > > Addressing mechanisms for vehicular communications: methods of > > converting a Vehicular Identification Number, or geographical > > coordinates, into an IPv6 address, and vice-versa. Scoping of IPv6 > > addresses: addresses within a vehicle, between vehicles, to > > infrastructure. Distributing addresses between vehicles, using > > dynamic mechanisms, such as DHCP or ND, which respect constraints of > > applications. > > > > Route exchanges between vehicles, and between vehicles and road-side > > units. This includes the identification of a need to realize the > > exchanges, the constraints related to loop-free graphs and networks > > which scale to large sizes, their interaction with the imposed > > physical topology. > > > > It is possible to adapt MANET and RoLL protocols to use in ITS. A > > distinction could be made between protocols used within a vehicle, and > > protocols used between two vehicles. > > > > Fast Network Transport Protocol is a protocol designed at ISO for > > vehicular communications. Feedback is solicited from IETF about this > > protocol. > > > > GeoNetworking is a protocol designed at ETSI. Feedback is solicited > > from IETF about this protocol. > > > > Coordinate work with ISO SDO, about developping a V2V protocol based > > on route exchanges using Router Advertisements. > > > > Milestones: > > Mar 2013 - Meet in Orlando > > Jul 2013 - Meet in Berlin > > Dec 2013 - Present drafts "Scenarios and Requirements for IP in > > Intelligent Transportation Systems" > > Dec 2013 - Present status from ISO about V2V > > > > > > _______________________________________________ > > its mailing 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 Tue Mar 12 13:43:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD34C11E8121 for ; Tue, 12 Mar 2013 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 YmvDRVq-d9hC for ; Tue, 12 Mar 2013 13:43:57 -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 D7B3311E80D2 for ; Tue, 12 Mar 2013 13:43:56 -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 r2CKhug7003778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Mar 2013 21:43:56 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CKhtkY018834 for ; Tue, 12 Mar 2013 21:43:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CKhoA7017941 for ; Tue, 12 Mar 2013 21:43:55 +0100 Message-ID: <513F936C.1010408@gmail.com> Date: Tue, 12 Mar 2013 21:43:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: its@ietf.org References: <513B2079.7060104@gmail.com> In-Reply-To: <513B2079.7060104@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] what happened (was: Meet at IETF Registration Desk, Monday 19h30) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:43:57 -0000 ITS list participants, I would like to let you know what happened at this bar bof, because bar it was. There was no slide presentation. A few people passed to say high and chat ITS: Michael Richardson, Jouni Korhonen, Ralf, Kevin, SM, Dapeng Liu, Alper Yegin. I had some light conversation about why using VIN to derive addresses. Then 3 of us went to the bar. I got a few comments about the Charter Proposal: Suggestion from Jouni – focus the Charter on 1 or 2 simple to achieve things, maybe recharter later. From Michael – delete the ongoing activities, focus on things to achieve ; list 6 potential chairpersons ; run the Charter to ADs ask advice ; VIN-ULA : how about ULA with some parts of VIN in clear and other parts of VIN hashed for privacy. Someone asked - why EtherType of IPv6 on Ethernet is not enough (0x86DD), why do we ask for another one for IPv6-over-80211p? That was it. If I forgot something please let me know, so we can better frame how to pursue. I will modify the Charter Proposal accordingly, and also according to the email list discussion. Yours, Alex Le 09/03/2013 12:43, Alexandru Petrescu a écrit : > I would like to meet ITS enthusiasts > > Monday 19h30 at IETF Registration Desk > > to discuss Charter proposal, and in general about advancement of ITS > at IETF and other SDOs. > > As hallway discussion, and why not dine. > > Alex PS: RFC6771 and RFC5434 (successful bar bofs and bofs) > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Tue Mar 12 15:02: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 638AB11E810D for ; Tue, 12 Mar 2013 15:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 0Ru6AfrB5KhT for ; Tue, 12 Mar 2013 15:02:44 -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 836A611E810B for ; Tue, 12 Mar 2013 15:02:44 -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 r2CM2hbe006103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Mar 2013 23:02:43 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2CM2hJv027846; Tue, 12 Mar 2013 23:02:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.14]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2CM2aK1000473; Tue, 12 Mar 2013 23:02:42 +0100 Message-ID: <513FA5E2.2080303@gmail.com> Date: Tue, 12 Mar 2013 23:02:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 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: "its@ietf.org" Subject: Re: [its] simultaneous use o fmultiple radios or not (was: Updated Draft Charter proposal) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 22:02:45 -0000 Will, Thanks for the comment. I have inserted something about this in the Draft Charter Proposal, but let me discuss. The simultaneous use of multiple egress interfaces is a technique allowing to expand the available bandwidth for a vehicle connection. A known car network problem is the discrepancy between the outside bandwidth and the inside bandwith. The egress interface is typically a cellular link, which is originally intended for unique personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. LTE). But within same vehicle, one uses a Ethernet or WiFi links, which may use 300Mbit/s or even 1Gbit/s. If all the devices within the vehicle talk to the Servers at the same time, it becomes obvious that the LTE link is a bottleneck. The problem is specific to vehicular networks, and different from office networks. In office networks the upstream link is typically much higher bandwidth than the link for office PCs. E.g. 10GByte vs 1GByte Ethernet. In vehicular networks, the cellular link is the bottleneck because it is much less bandwidth than the in-car link. To solve this, there exist approaches where one proposes to use several such egress external links on the vehicle, at the same time. This would add up the bandwidth; e.g. use 10 USB LTE dongles to achieve an aggregated bandwidth of 500Mbit/s towards the infrastructure. This would enlarge this bottleneck. At IETF, there is this draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding Support for Mobile IPv4" that I co-author there. I dont think it advances ok, but should advance there. However, that draft is not really corresponding to my intention about simultaneous use of multiple interfaces. It's more an evolution of what 'flow binding updates' means to Mobile IPv6. I am not aware of any other draft at IETF doing simultaneous use of multiple interfaces for bandwidth augmentation. If you read until here, then please reply to see whether there is interest in developping such solution. This would mean to add it in the Charter Proposal, and commit to some work items. We are already very short on space left about new things to do. Yours, Alex Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit : > Propose > > From: "In this system, disjoint and heterogeneous radio systems are > used (e.g. a vehicle uses two different radios)." > > To: In this system, disjoint and heterogeneous radio systems are > used (e.g. a vehicle uses two OR MORE different radios > SIMULTANEOUSLY)." > > Question: > > Do you want simultaneous use of multiple radios or not? > > Will Ivancic > > >> From: Alexandru Petrescu Date: Mon, >> 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >> Subject: [its] Updated Draft Charter proposal >> >> In this system, disjoint and heterogeneous radio systems are used >> (e.g. a vehicle uses two different radios). > > > From buddenbergr@gmail.com Tue Mar 12 15:22:23 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0457311E812D for ; Tue, 12 Mar 2013 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24] 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 OzzEEuAfDb1Y for ; Tue, 12 Mar 2013 15:22:22 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEA11E812B for ; Tue, 12 Mar 2013 15:22:20 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id p1so122847dad.41 for ; Tue, 12 Mar 2013 15:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=Ql1njE8sqhRfvM8GxHQf3IUZu4NOpgsOb5f+MB9zVIc=; b=TISMLERi5ibo375M1o4vy/sH38cEW3exLi7Sv19cRZFH3FuwXRBOqGFsEarsgogw+F MZ8bQ8vEQDbpCYs6iDtOMRUIfm8IgT1Ltr9Z7f7i8/wE/r/wO0xlN+gAiOai8cnt7UDR 4kfiLyc5HPTm5YTtij222WKOeyMMPSjb0c7UKgUJrc+pOdCPWnSE7IKTbNd6xQro6Mhx nkcl+WQRf1zLtzfwqq5k+VudMPleOkl4YvrNf3O2rQ7JmtsvyyoVDvV54dG/vqnNgEEk 9lMV5pd5cAk8Dys9Tsy3LojGqgXRPITUdKxDz8bbUmibJJe2XQhaImsoCkUb5l42XXjc wocQ== X-Received: by 10.68.203.226 with SMTP id kt2mr1219424pbc.3.1363126936679; Tue, 12 Mar 2013 15:22:16 -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 ESMTPS id gf6sm26719275pbc.24.2013.03.12.15.22.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 Mar 2013 15:22:15 -0700 (PDT) Message-ID: <1363126933.1813.330.camel@localhost> From: Rex Buddenberg To: Alexandru Petrescu Date: Tue, 12 Mar 2013 14:22:13 -0800 In-Reply-To: <513FA5E2.2080303@gmail.com> References: <513FA5E2.2080303@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not (was: Updated Draft Charter proposal) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 22:22:23 -0000 Alex, Your numbers are essentially correct -- radio links are about 10-4 smaller sized than wired ones. But a more powerful argument for multiple interfaces is availability. In addition to radio being four orders of magnitude less capacious than wired, radio has about 4 orders of magnitude higher error rates. There are myriad reasons that a radio link of whatever flavor will go away. For short term or longer term duration. So the obvious way to counter this is to have >1 radio link. The arithmetic to support is standard high Ao engineering stuff. > I am not aware of any other draft at IETF doing simultaneous use of > multiple interfaces for bandwidth augmentation. > Not sure what you're trying to say with this quote: every router has multiple interfaces and they are often used in parallel for bandwidth augmentation. This is an inherent part of IP ... RFC 791. Getting them to behave properly has sometimes been a problem, but it's generally outside of the standardization realm. Current reality: US Navy has a router on each ship. There are usually three LANs on the ship side (segregation for security reasons, VPN). But there are multiple interfaces on the radio side -- one for each satcom channel, for example. Will's question is easily answered: yes. On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: > Will, > > Thanks for the comment. > > I have inserted something about this in the Draft Charter Proposal, but > let me discuss. > > The simultaneous use of multiple egress interfaces is a technique > allowing to expand the available bandwidth for a vehicle connection. > > A known car network problem is the discrepancy between the outside > bandwidth and the inside bandwith. The egress interface is typically a > cellular link, which is originally intended for unique personal use; > that is bandwidth 50Mbit/s and latency 50ms (e.g. LTE). But within same > vehicle, one uses a Ethernet or WiFi links, which may use 300Mbit/s or > even 1Gbit/s. If all the devices within the vehicle talk to the Servers > at the same time, it becomes obvious that the LTE link is a bottleneck. > > The problem is specific to vehicular networks, and different from office > networks. In office networks the upstream link is typically much higher > bandwidth than the link for office PCs. E.g. 10GByte vs 1GByte > Ethernet. In vehicular networks, the cellular link is the bottleneck > because it is much less bandwidth than the in-car link. > > To solve this, there exist approaches where one proposes to use several > such egress external links on the vehicle, at the same time. This would > add up the bandwidth; e.g. use 10 USB LTE dongles to achieve an > aggregated bandwidth of 500Mbit/s towards the infrastructure. This > would enlarge this bottleneck. > > At IETF, there is this draft-ietf-mip4-multiple-tunnel-support-05.txt > "Flow Binding Support for Mobile IPv4" that I co-author there. I dont > think it advances ok, but should advance there. > > However, that draft is not really corresponding to my intention about > simultaneous use of multiple interfaces. It's more an evolution of what > 'flow binding updates' means to Mobile IPv6. > > I am not aware of any other draft at IETF doing simultaneous use of > multiple interfaces for bandwidth augmentation. > > If you read until here, then please reply to see whether there is > interest in developping such solution. This would mean to add it in the > Charter Proposal, and commit to some work items. We are already very > short on space left about new things to do. > > Yours, > > Alex > > > Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit : > > Propose > > > > From: "In this system, disjoint and heterogeneous radio systems are > > used (e.g. a vehicle uses two different radios)." > > > > To: In this system, disjoint and heterogeneous radio systems are > > used (e.g. a vehicle uses two OR MORE different radios > > SIMULTANEOUSLY)." > > > > Question: > > > > Do you want simultaneous use of multiple radios or not? > > > > Will Ivancic > > > > > >> From: Alexandru Petrescu Date: Mon, > >> 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" > >> Subject: [its] Updated Draft Charter proposal > >> > >> In this system, disjoint and heterogeneous radio systems are used > >> (e.g. a vehicle uses two different radios). > > > > > > > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From thierry.ernst@mines-paristech.fr Wed Mar 13 06:14:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4667021F85C0 for ; Wed, 13 Mar 2013 06:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 m3vKp-Cp6pa6 for ; Wed, 13 Mar 2013 06:14:21 -0700 (PDT) Received: from boipeva.ensmp.fr (smtp-1.ensmp.fr [194.214.158.101]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1521F8530 for ; Wed, 13 Mar 2013 06:14:20 -0700 (PDT) Received: from Mont-Ventoux-2.local (vir78-2-82-247-222-224.fbx.proxad.net [82.247.222.224]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.5/8.14.3/JMMC-11/Mar/2010) with ESMTP id r2DDEIH4000856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Mar 2013 14:14:18 +0100 (MET) Message-ID: <51407BAA.2070201@mines-paristech.fr> Date: Wed, 13 Mar 2013 14:14:18 +0100 From: Thierry Ernst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietfa.amsl.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at boipeva with ID 51407BAA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Auth: USER-ID thierry.ernst X-j-chkmail-Enveloppe: 51407BAA.000 from vir78-2-82-247-222-224.fbx.proxad.net/vir78-2-82-247-222-224.fbx.proxad.net/82.247.222.224/Mont-Ventoux-2.local/ X-Mailman-Approved-At: Wed, 13 Mar 2013 06:19:23 -0700 Subject: [its] ITSSv6 news about IPv6 for Cooperative ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:15:12 -0000 From thierry.ernst@mines-paristech.fr Wed Mar 13 06:45:10 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3CC21F8CAA for ; Wed, 13 Mar 2013 06:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, 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 vWwUtgaKlqDk for ; Wed, 13 Mar 2013 06:45:10 -0700 (PDT) Received: from boipeva.ensmp.fr (smtp-1.ensmp.fr [194.214.158.101]) by ietfa.amsl.com (Postfix) with ESMTP id D2ED921F8CA3 for ; Wed, 13 Mar 2013 06:45:08 -0700 (PDT) Received: from Mont-Ventoux-2.local (vir78-2-82-247-222-224.fbx.proxad.net [82.247.222.224]) (authenticated bits=0) by boipeva.ensmp.fr (8.14.5/8.14.3/JMMC-11/Mar/2010) with ESMTP id r2DDj6Xo001231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Mar 2013 14:45:06 +0100 (MET) Message-ID: <514082E2.9010604@mines-paristech.fr> Date: Wed, 13 Mar 2013 14:45:06 +0100 From: Thierry Ernst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org Content-Type: multipart/alternative; boundary="------------010001090201090204030206" X-Miltered: at boipeva with ID 514082E2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Auth: USER-ID thierry.ernst X-j-chkmail-Enveloppe: 514082E2.000 from vir78-2-82-247-222-224.fbx.proxad.net/vir78-2-82-247-222-224.fbx.proxad.net/82.247.222.224/Mont-Ventoux-2.local/ Subject: [its] ITSSv6 news about IPv6 for Cooperative ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 13:45:10 -0000 This is a multi-part message in MIME format. --------------010001090201090204030206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit [Sorry for the duplicate mail, the previous one apparently came up empty] Dear all, The ITSSv6 project published its latest newsletter: http://www.itssv6.eu/files/2013/03/ITSSv6_Newsletter_March2013.pdf Next one (undecided date) will include a large section about ISO/CEN/ETSI IPv6-related standards. To ensure you receive the latest information about ITSSv6 (progress, newsletters, events, new IPv6 stack release, etc), please subscribe to our announce mailing list by sending an email to *sympa_inria@inria.fr* from your preferred email address with as subject line the instruction subscribe itssv6-announce FirstName FamilyName (replacing FirstName FamilyName with your own name). Please also visit our web site http://www.itssv6.eu Regards, Thierry Ernst - ITSSv6 Project Coordinator --------------010001090201090204030206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
[Sorry for the duplicate mail, the previous one apparently came up empty]

Dear all,

The ITSSv6 project published its latest newsletter:
http://www.itssv6.eu/files/2013/03/ITSSv6_Newsletter_March2013.pdf

Next one (undecided date) will include a large section about ISO/CEN/ETSI IPv6-related standards.

To ensure you receive the latest information about ITSSv6 (progress, newsletters, events, new IPv6 stack release, etc), please subscribe to our announce mailing list by sending an email to sympa_inria@inria.fr from your preferred email address with as subject line the instruction subscribe itssv6-announce FirstName FamilyName (replacing FirstName FamilyName with your own name).

Please also visit our web site http://www.itssv6.eu

Regards,
Thierry Ernst - ITSSv6 Project Coordinator
--------------010001090201090204030206-- From alexandru.petrescu@gmail.com Wed Mar 13 08:49: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 48EA021F8935 for ; Wed, 13 Mar 2013 08:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.516 X-Spam-Level: X-Spam-Status: No, score=-9.516 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 g6btnKLOL8kC for ; Wed, 13 Mar 2013 08:49:54 -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 EB48521F8930 for ; Wed, 13 Mar 2013 08:49: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 r2DFnqlE026051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2013 16:49:52 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DFnpMY015308; Wed, 13 Mar 2013 16:49:52 +0100 (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 r2DFnkEp006216; Wed, 13 Mar 2013 16:49:51 +0100 Message-ID: <51409FFF.2010309@gmail.com> Date: Wed, 13 Mar 2013 16:49:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Rex Buddenberg References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost> In-Reply-To: <1363126933.1813.330.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 15:49:55 -0000 Ok, So we talk radios as egress interfaces. I.e. have several egress interfaces on a Mobile Router (gateway in the vehicle). When one of the radio fails, the MR uses another one, such that the Internet is always available to vehicle. This sounds reasonable. It is for me a sort of architectural requirement, to be strongly kept in mind, for designing any new protocol. Le 12/03/2013 23:22, Rex Buddenberg a écrit : > Alex, > > Your numbers are essentially correct -- radio links are about 10-4 > smaller sized than wired ones. > > But a more powerful argument for multiple interfaces is > availability. In addition to radio being four orders of magnitude > less capacious than wired, radio has about 4 orders of magnitude > higher error rates. There are myriad reasons that a radio link of > whatever flavor will go away. For short term or longer term > duration. > > So the obvious way to counter this is to have >1 radio link. The > arithmetic to support is standard high Ao engineering stuff. > > >> I am not aware of any other draft at IETF doing simultaneous use >> of multiple interfaces for bandwidth augmentation. >> > > Not sure what you're trying to say with this quote: every router has > multiple interfaces and they are often used in parallel for bandwidth > augmentation. This is an inherent part of IP ... RFC 791. Getting > them to behave properly has sometimes been a problem, but it's > generally outside of the standardization realm. I wonder what the others think about this? (I do have some idea, but not sure I as contributor would like to do anything about this particular topic right now here, because other things here in ITS are more mature.) > Current reality: US Navy has a router on each ship. There are > usually three LANs on the ship side (segregation for security > reasons, VPN). But there are multiple interfaces on the radio side -- > one for each satcom channel, for example. Sure... this not surprising and is needed so! However, what is the mechanism used by US Navy to make all these egress interfaces look as one single interface in the router on the ship? What is the scheduling intelligence to transparently divide a traffic flow evenly among all these interfaces? (without trolling, I think there isnt any; I think they put one application on one radio, another application on another radio, and so on) > Will's question is easily answered: yes. Yes, I agree. And from that answer, what we need right now is to know how to put this in a Charter - is it by making it into a Problem Statement such that scenarios and solutions for this particular multi-interface scenario be developped? Or just have it there as a design principle? Or just to reuse some existing protocol? Knowing that there are already two things that are maturing as we speak and that should get more attention in the Charter proposal: V2V and addressing. And that we should focus the Charter proposal. And that for any thing that we put in the Charter proposal we shoudl have commitment of effort to write drafts. Alex > > > > On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >> Will, >> >> Thanks for the comment. >> >> I have inserted something about this in the Draft Charter Proposal, >> but let me discuss. >> >> The simultaneous use of multiple egress interfaces is a technique >> allowing to expand the available bandwidth for a vehicle >> connection. >> >> A known car network problem is the discrepancy between the outside >> bandwidth and the inside bandwith. The egress interface is >> typically a cellular link, which is originally intended for unique >> personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. >> LTE). But within same vehicle, one uses a Ethernet or WiFi links, >> which may use 300Mbit/s or even 1Gbit/s. If all the devices >> within the vehicle talk to the Servers at the same time, it becomes >> obvious that the LTE link is a bottleneck. >> >> The problem is specific to vehicular networks, and different from >> office networks. In office networks the upstream link is typically >> much higher bandwidth than the link for office PCs. E.g. 10GByte >> vs 1GByte Ethernet. In vehicular networks, the cellular link is >> the bottleneck because it is much less bandwidth than the in-car >> link. >> >> To solve this, there exist approaches where one proposes to use >> several such egress external links on the vehicle, at the same >> time. This would add up the bandwidth; e.g. use 10 USB LTE dongles >> to achieve an aggregated bandwidth of 500Mbit/s towards the >> infrastructure. This would enlarge this bottleneck. >> >> At IETF, there is this >> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding >> Support for Mobile IPv4" that I co-author there. I dont think it >> advances ok, but should advance there. >> >> However, that draft is not really corresponding to my intention >> about simultaneous use of multiple interfaces. It's more an >> evolution of what 'flow binding updates' means to Mobile IPv6. >> >> I am not aware of any other draft at IETF doing simultaneous use >> of multiple interfaces for bandwidth augmentation. >> >> If you read until here, then please reply to see whether there is >> interest in developping such solution. This would mean to add it >> in the Charter Proposal, and commit to some work items. We are >> already very short on space left about new things to do. >> >> Yours, >> >> Alex >> >> >> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit : >>> Propose >>> >>> From: "In this system, disjoint and heterogeneous radio systems >>> are used (e.g. a vehicle uses two different radios)." >>> >>> To: In this system, disjoint and heterogeneous radio systems >>> are used (e.g. a vehicle uses two OR MORE different radios >>> SIMULTANEOUSLY)." >>> >>> Question: >>> >>> Do you want simultaneous use of multiple radios or not? >>> >>> Will Ivancic >>> >>> >>>> From: Alexandru Petrescu Date: >>>> Mon, 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >>>> Subject: [its] Updated Draft Charter proposal >>>> >>>> In this system, disjoint and heterogeneous radio systems are >>>> used (e.g. a vehicle uses two different radios). >>> >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > > From sratliff@cisco.com Wed Mar 13 09:15: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 DCB6121F8C69 for ; Wed, 13 Mar 2013 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.596 X-Spam-Level: X-Spam-Status: No, score=-8.596 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 Bp5hgwzDpuIO for ; Wed, 13 Mar 2013 09:15:27 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 53CDB21F8C71 for ; Wed, 13 Mar 2013 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7565; q=dns/txt; s=iport; t=1363191327; x=1364400927; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e2SPYvuz1nKCHCUKzqhaBxlsaI/xJ6Hj3waHI8pJr+M=; b=CYhOYJehT9cgjMGiMbo9LBEb7pmfSXy0No/J4yFxR0/iz0sbfy/EnDRR dOyI2RvGJIA/PP2RJ55gDcogdX3wnOn1EI8SZwzbjFspipy/Di5m7z/Gx 8202dq2EpQ5Uuyxu7fBnNabU5qhC8BTORU1xBPQ0IDEaxthtcgbsY3MLv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKGkQFGtJV2c/2dsb2JhbABDxH+BWRZ0gioBAQEDAQEBAWsLBQsCAQgRAwECAQokIQYLHQgCBAENBQgTh2cDCQYMuF0NiUQTBIxFghUCJgsHgl9hA4g9jDmNPYUZgwqCKA X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="scan'208";a="187064061" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Mar 2013 16:15:24 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2DGFO3X026343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 16:15:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 11:15:24 -0500 From: "Stan Ratliff (sratliff)" To: Alexandru Petrescu , Joe Macker , "JP Vasseur (jvasseur)" Thread-Topic: [its] simultaneous use o fmultiple radios or not Thread-Index: AQHOIAJr/WT+mCC3UEaflZZnDSymQ5ikH7kA Date: Wed, 13 Mar 2013 16:15:23 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1004FEA9@xmb-aln-x03.cisco.com> References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost> <51409FFF.2010309@gmail.com> In-Reply-To: <51409FFF.2010309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.210.236] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6B38575509C5C449951373B86652D6BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , "its@ietf.org" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:15:29 -0000 Alex, This describes almost exactly the deployments I've worked with. It is yet a= nother reason I say that starting a new working group for the ITS effort is= over-kill. Please don't get me wrong - this is interesting work, and shoul= d be addressed. However, it needs to be done (IMO) within the auspices of t= he MANET working group. Possibly ROLL, but I'm thinking MANET is a better f= it.=20 Regards, Stan On Mar 13, 2013, at 11:49 AM, Alexandru Petrescu wrote: > Ok, >=20 > So we talk radios as egress interfaces. I.e. have several egress > interfaces on a Mobile Router (gateway in the vehicle). When one of the > radio fails, the MR uses another one, such that the Internet is always > available to vehicle. >=20 > This sounds reasonable. >=20 > It is for me a sort of architectural requirement, to be strongly kept in > mind, for designing any new protocol. >=20 > Le 12/03/2013 23:22, Rex Buddenberg a =E9crit : >> Alex, >>=20 >> Your numbers are essentially correct -- radio links are about 10-4 >> smaller sized than wired ones. >>=20 >> But a more powerful argument for multiple interfaces is >> availability. In addition to radio being four orders of magnitude >> less capacious than wired, radio has about 4 orders of magnitude >> higher error rates. There are myriad reasons that a radio link of >> whatever flavor will go away. For short term or longer term >> duration. >>=20 >> So the obvious way to counter this is to have >1 radio link. The >> arithmetic to support is standard high Ao engineering stuff. >>=20 >>=20 >>> I am not aware of any other draft at IETF doing simultaneous use >>> of multiple interfaces for bandwidth augmentation. >>>=20 >>=20 >> Not sure what you're trying to say with this quote: every router has >> multiple interfaces and they are often used in parallel for bandwidth >> augmentation. This is an inherent part of IP ... RFC 791. Getting >> them to behave properly has sometimes been a problem, but it's >> generally outside of the standardization realm. >=20 > I wonder what the others think about this? (I do have some idea, but > not sure I as contributor would like to do anything about this > particular topic right now here, because other things here in ITS are > more mature.) >=20 >> Current reality: US Navy has a router on each ship. There are >> usually three LANs on the ship side (segregation for security >> reasons, VPN). But there are multiple interfaces on the radio side -- >> one for each satcom channel, for example. >=20 > Sure... this not surprising and is needed so! >=20 > However, what is the mechanism used by US Navy to make all these egress > interfaces look as one single interface in the router on the ship? What > is the scheduling intelligence to transparently divide a traffic flow > evenly among all these interfaces? (without trolling, I think there > isnt any; I think they put one application on one radio, another > application on another radio, and so on) >=20 >> Will's question is easily answered: yes. >=20 > Yes, I agree. >=20 > And from that answer, what we need right now is to know how to put this > in a Charter - is it by making it into a Problem Statement such that > scenarios and solutions for this particular multi-interface scenario be > developped? Or just have it there as a design principle? Or just to > reuse some existing protocol? >=20 > Knowing that there are already two things that are maturing as we speak > and that should get more attention in the Charter proposal: V2V and > addressing. >=20 > And that we should focus the Charter proposal. >=20 > And that for any thing that we put in the Charter proposal we shoudl > have commitment of effort to write drafts. >=20 > Alex >=20 >>=20 >>=20 >>=20 >> On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >>> Will, >>>=20 >>> Thanks for the comment. >>>=20 >>> I have inserted something about this in the Draft Charter Proposal, >>> but let me discuss. >>>=20 >>> The simultaneous use of multiple egress interfaces is a technique >>> allowing to expand the available bandwidth for a vehicle >>> connection. >>>=20 >>> A known car network problem is the discrepancy between the outside >>> bandwidth and the inside bandwith. The egress interface is >>> typically a cellular link, which is originally intended for unique >>> personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. >>> LTE). But within same vehicle, one uses a Ethernet or WiFi links, >>> which may use 300Mbit/s or even 1Gbit/s. If all the devices >>> within the vehicle talk to the Servers at the same time, it becomes >>> obvious that the LTE link is a bottleneck. >>>=20 >>> The problem is specific to vehicular networks, and different from >>> office networks. In office networks the upstream link is typically >>> much higher bandwidth than the link for office PCs. E.g. 10GByte >>> vs 1GByte Ethernet. In vehicular networks, the cellular link is >>> the bottleneck because it is much less bandwidth than the in-car >>> link. >>>=20 >>> To solve this, there exist approaches where one proposes to use >>> several such egress external links on the vehicle, at the same >>> time. This would add up the bandwidth; e.g. use 10 USB LTE dongles >>> to achieve an aggregated bandwidth of 500Mbit/s towards the >>> infrastructure. This would enlarge this bottleneck. >>>=20 >>> At IETF, there is this >>> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding >>> Support for Mobile IPv4" that I co-author there. I dont think it >>> advances ok, but should advance there. >>>=20 >>> However, that draft is not really corresponding to my intention >>> about simultaneous use of multiple interfaces. It's more an >>> evolution of what 'flow binding updates' means to Mobile IPv6. >>>=20 >>> I am not aware of any other draft at IETF doing simultaneous use >>> of multiple interfaces for bandwidth augmentation. >>>=20 >>> If you read until here, then please reply to see whether there is >>> interest in developping such solution. This would mean to add it >>> in the Charter Proposal, and commit to some work items. We are >>> already very short on space left about new things to do. >>>=20 >>> Yours, >>>=20 >>> Alex >>>=20 >>>=20 >>> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a =E9crit : >>>> Propose >>>>=20 >>>> From: "In this system, disjoint and heterogeneous radio systems >>>> are used (e.g. a vehicle uses two different radios)." >>>>=20 >>>> To: In this system, disjoint and heterogeneous radio systems >>>> are used (e.g. a vehicle uses two OR MORE different radios >>>> SIMULTANEOUSLY)." >>>>=20 >>>> Question: >>>>=20 >>>> Do you want simultaneous use of multiple radios or not? >>>>=20 >>>> Will Ivancic >>>>=20 >>>>=20 >>>>> From: Alexandru Petrescu Date: >>>>> Mon, 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >>>>> Subject: [its] Updated Draft Charter proposal >>>>>=20 >>>>> In this system, disjoint and heterogeneous radio systems are >>>>> used (e.g. a vehicle uses two different radios). >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From william.d.ivancic@nasa.gov Wed Mar 13 10:40: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 EDC5C21F8DEE for ; Wed, 13 Mar 2013 10:40:15 -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 mgjt8S41oivy for ; Wed, 13 Mar 2013 10:40:15 -0700 (PDT) Received: from npfrelay.ndc.nasa.gov (NDMSNPF01.ndc.nasa.gov [IPv6:2001:4d0:8302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 536F921F8CA3 for ; Wed, 13 Mar 2013 10:40:15 -0700 (PDT) Received: from ndjsppt104.ndc.nasa.gov (NDJSPPT104.ndc.nasa.gov [198.117.1.198]) by npfrelay.ndc.nasa.gov (Postfix) with ESMTP id BF9AC260241; Wed, 13 Mar 2013 12:40:14 -0500 (CDT) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt104.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id r2DHeCfO014620; Wed, 13 Mar 2013 12:40:12 -0500 Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Wed, 13 Mar 2013 12:40:12 -0500 From: "Ivancic, William D. (GRC-RHN0)" To: Alexandru Petrescu , Rex Buddenberg Date: Wed, 13 Mar 2013 12:40:09 -0500 Thread-Topic: [its] simultaneous use o fmultiple radios or not Thread-Index: Ac4gAnJle2dkTwtGTxSTIeri/RdmqwAD1wGq Message-ID: In-Reply-To: <51409FFF.2010309@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.8626, 1.0.431, 0.0.0000 definitions=2013-03-13_07:2013-03-13, 2013-03-13, 1970-01-01 signatures=0 Cc: "its@ietf.org" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:40:16 -0000 This is more of what I was getting at. I was pretty active in mext, monami= 6 and a few other mobile-ip related groups working mobile networking. Some o= f the first code I used working the Cisco allowed you to use multiple egress interfaces, but only one at a time. If the preferred link when down, the next best (as pre configured) link would be used. If I had 5 egress interfaces with 5 different radio systems, I could use any of these, but only one at a time. I might have wired, wifi, 4G, UHF with priority in tha= t order. Note, they all may be provided by different service providers. My question was do you want to be able to simultaneously use multiple link? If so, the problems becomes very interesting. It also may be one wants specific traffic to use specific links. Buy the way, I am currently working on spacesuit communications. Spacesuits are mini-spacecraft with full life support and such. They really are an intelligent vehicle, but probably less intelligent than a car. There is a current concept for the next generation to have two radios, a low-rate highly reliable radio and a wifi-type radio with large bandwidth. Weather or no they would both be used simultaneously is an open question. Obviously, high-rate, high-resolution video would not be permitted over the UHF low-rate link. Multi-homed from IETF 67 in 2006. Slides 5 and 11 "Multi-Homed Mobile Networks," 67th IETF, nemo and monami working groups, November 9-10, 2006 San Diego, California ( Powerpoint ) file size 679,424 bytes=20 http://roland.grc.nasa.gov/~ivancic/papers_presentations/2006/IETF67nemo-mo= n ami6-final.ppt Will From buddenbergr@gmail.com Wed Mar 13 11:06: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 0494921F8735 for ; Wed, 13 Mar 2013 11:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=2.005, 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 HkOwxtMl3i5d for ; Wed, 13 Mar 2013 11:06:38 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF221F8E06 for ; Wed, 13 Mar 2013 11:06:37 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so1280319pbb.18 for ; Wed, 13 Mar 2013 11:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=kB7vGhW2b5j6njSzLhw5Tpw7u4UPh4vUtxKagh6QDY4=; b=0CDtxl2bYsFonKfIubNKvNbNXsKHL1KBQ2QTYbUa9DEyoxlTu1ckUsIIKbXerVmTFK xin44mxANYJ+WgK4qVhSfMIBsTSvhtuQ8lrpbJRaL+NyrpkSJEZw5lglK5pTS4zLAu2n glbY1SnADQkwQACXHnykUZAsRRerpQwlzWt7IuNaGpqbsxvOkFvDm8n4+uyOX90SNNhC 302OdFe6T7vkXyUF6aEp+K8H8cBiyXBI5ZAtXDsfyeZSYyS6rAeTeCPSHLTf8TBZsgs/ ntQO3u8yWgKM9WjMhuNg82P8uL8zUlMHyiWG+M9+BUchbB/LYD/P+b5RZLRDtVD2kZSI 3f0g== X-Received: by 10.68.239.194 with SMTP id vu2mr46956044pbc.147.1363197997734; Wed, 13 Mar 2013 11:06:37 -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 ESMTPS id vq9sm30577598pbc.36.2013.03.13.11.06.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Mar 2013 11:06:36 -0700 (PDT) Message-ID: <1363197994.1813.348.camel@localhost> From: Rex Buddenberg To: "Ivancic, William D. (GRC-RHN0)" Date: Wed, 13 Mar 2013 10:06:34 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:06:39 -0000 Will, I think we're thinking alike. On Wed, 2013-03-13 at 12:40 -0500, Ivancic, William D. (GRC-RHN0) wrote: > This is more of what I was getting at. I was pretty active in mext, monami6 > and a few other mobile-ip related groups working mobile networking. Some of > the first code I used working the Cisco allowed you to use multiple egress > interfaces, but only one at a time. If the preferred link when down, the > next best (as pre configured) link would be used. If I had 5 egress > interfaces with 5 different radio systems, I could use any of these, but > only one at a time. I might have wired, wifi, 4G, UHF with priority in that > order. Note, they all may be provided by different service providers. Good use case. The basic design of IP (and especially TCP) accommodates. TCP is designed to deal with packets that arrive out of order, which is likely if you have diverse routes. > > My question was do you want to be able to simultaneously use multiple link? Yes, as we both said before. > If so, the problems becomes very interesting. There's been a whole area of research on 'best route'. Early routing information protocols defined that as 'least number of hops' and were immune to explanations that the least-hop route might be the lowest capacity one. And a lot of load-balancing algorithms were pretty elementary. > It also may be one wants > specific traffic to use specific links. Smells like a linkage to DSCP to me. We've tried linking priority to users and linking priority to port numbers... both too easy to be gamed. And the prioritization mechanism becomes counterproductive if it's too cute. > > Buy the way, I am currently working on spacesuit communications. Spacesuits > are mini-spacecraft with full life support and such. They really are an > intelligent vehicle, but probably less intelligent than a car. Depends on how you define 'intelligent'. Interesting use case. I'd guess that a space suit (and the body inside) is somewhat better instrumented than a car. > There is a > current concept for the next generation to have two radios, a low-rate > highly reliable radio and a wifi-type radio with large bandwidth. Weather > or no they would both be used simultaneously is an open question. > Obviously, high-rate, high-resolution video would not be permitted over the > UHF low-rate link. This maps onto automobiles just fine. The instrumented ambulance use case works too: use the high capacity link when it's available (suburbia) but use anything that works (rural). > > Multi-homed from IETF 67 in 2006. Slides 5 and 11 > > "Multi-Homed Mobile Networks," 67th IETF, nemo and monami working groups, > November 9-10, 2006 San Diego, California ( Powerpoint ) file size 679,424 > bytes > > http://roland.grc.nasa.gov/~ivancic/papers_presentations/2006/IETF67nemo-mon > ami6-final.ppt > > Will > > > From alexandru.petrescu@gmail.com Wed Mar 13 11:26:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11021F8DD4 for ; Wed, 13 Mar 2013 11:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 P0kYme3ikIlB for ; Wed, 13 Mar 2013 11:26:30 -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 650F121F8D22 for ; Wed, 13 Mar 2013 11:26:30 -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 r2DIQQdl009815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2013 19:26:26 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DIQP1k022152; Wed, 13 Mar 2013 19:26:26 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2DIQIDZ019228; Wed, 13 Mar 2013 19:26:24 +0100 Message-ID: <5140C4AE.2000107@gmail.com> Date: Wed, 13 Mar 2013 19:25:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jong-Hyouk Lee Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Pascal Thubert \(pthubert\)" , Michael Richardson , "its@ietf.org" , jouni korhonen , Alper Yegin , Hosnieh Rafiee , Roland Bless Subject: [its] dinner tonight ITS, out of IETF hotel, 19h45 X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:26:31 -0000 With Jong-Hyouk we go out have dinner tonight: 19h45 at IETF Registration Desk. If you don't have dinner plans for this evening, please join us. We'll take the IETF shuttle to one of the above places... let's pick one. http://www.ietf.org/meeting/86/shuttles.html Alex From alexandru.petrescu@gmail.com Wed Mar 13 11:52:37 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7511E8116 for ; Wed, 13 Mar 2013 11:52:37 -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 SYM0o4tmCZBj for ; Wed, 13 Mar 2013 11:52:36 -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 602E611E8118 for ; Wed, 13 Mar 2013 11:52: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 r2DIqWYV004481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2013 19:52:33 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DIqWJL026180; Wed, 13 Mar 2013 19:52:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2DIqR0a026928; Wed, 13 Mar 2013 19:52:31 +0100 Message-ID: <5140CACF.2040708@gmail.com> Date: Wed, 13 Mar 2013 19:51:59 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFED60@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFF51E@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFF805@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFF805@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , Abdussalam Baryun Subject: Re: [its] What do we need to make ITS WG go forward? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:52:37 -0000 Le 28/01/2013 19:29, Stan Ratliff (sratliff) a écrit : > > On Jan 28, 2013, at 1:27 PM, Abdussalam Baryun wrote: > >>>> I think names of groups don't matter it is the effort and >>>> welling of participants that make the change in technology, >>> >>> We agree there - the name of the group doesn't matter. I'm basing >>> my opinion on the work to be done - ITS and MANET are operating >>> in the same general solution space. To create a separate group is >>> to invite the same types of issues that MANET has with ROLL (e.g. >>> when is a sensor net a MANET?). >>> >> >> I don't think that ITS is a general solution, it is specific like >> ROLL. However, I like to see all participants of ITS what they >> think also. In my opinion that MANET WG is not ready yet, it is >> very difficult to move things there, because there works purpose >> are fiting many situations and scenarios. Which I like, but also >> feel that this WG is needed. > > OK, we disagree. Like you, I await other opinions. YEs, me too. Let me follow up with a separate email about MANET protocols and n-hop vehicular communications. Alex > > Stan > > > From alexandru.petrescu@gmail.com Wed Mar 13 11:53: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 4E50911E8121 for ; Wed, 13 Mar 2013 11:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.135 X-Spam-Level: X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 SMM3B5N2u0tI for ; Wed, 13 Mar 2013 11:53:50 -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 7D0EC11E8118 for ; Wed, 13 Mar 2013 11:53:50 -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 r2DIrnft031647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Mar 2013 19:53:49 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DIrn95026349 for ; Wed, 13 Mar 2013 19:53:49 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2DIrlxA027366 for ; Wed, 13 Mar 2013 19:53:48 +0100 Message-ID: <5140CB20.2050306@gmail.com> Date: Wed, 13 Mar 2013 19:53:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:53:51 -0000 Hello ITS participants, While working on Charter Proposal we are distinguishing between 1-hop V2V communications (a single subnet between several vehicles), and n-hop communications (vehicle-to-vehicle-to-vehicle, each time a different subnet between vehicles). I would like to ask participants whether there is interest in n-hop routing protocols for vehicular communications. Is work needed on MANET protocols for this? Are there special requirements for this? (i.e. a case where a MANET protocol is not sufficient for n-hop vehicular communications). Yours, Alex From jonghyouk@gmail.com Wed Mar 13 12:11: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 D949611E80A4 for ; Wed, 13 Mar 2013 12:11: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 LSVYETUqVRR6 for ; Wed, 13 Mar 2013 12:11:38 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1275311E81AB for ; Wed, 13 Mar 2013 12:11:37 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id fj18so687138vbb.40 for ; Wed, 13 Mar 2013 12:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=swaoLawkciKktzLu7Ts8KVtYykspdaC/Mj1iCND3w0c=; b=UG/I2lB5+AS2+GVsSHeq6AC7imQZyMPriluiKKLIWqmLVF8LJusLLz5vhJOfZiATbC unGglgmHkEtBBwUOytLEVS93VdMQebzS7TyFthAE/28mMxfpuw+ho3/pHZpQavTVla5N z4kTI7lIguaJtaobSdtWClOcJQckjY768Tkw9cfkARjiPcAkmpJrSv+WtQqC3PEOA8qQ 8sXCeV1/pNyBb7nF0wB3hHU3bDJ3fwao2bSKlyq8vNoUWleuTc6/EhAwW9qqbFc0xDrm eUzL8Sr1JSiR84JYrOjrm2KiQqkrRYVe9hQIlFW+7f5uxlBUO51SuF2yKcACyPNxCN3f D/3Q== MIME-Version: 1.0 X-Received: by 10.52.94.17 with SMTP id cy17mr7591102vdb.68.1363201897488; Wed, 13 Mar 2013 12:11:37 -0700 (PDT) Received: by 10.59.4.1 with HTTP; Wed, 13 Mar 2013 12:11:37 -0700 (PDT) In-Reply-To: <5140CB20.2050306@gmail.com> References: <5140CB20.2050306@gmail.com> Date: Wed, 13 Mar 2013 15:11:37 -0400 Message-ID: From: Jong-Hyouk Lee To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf307f3378db71e704d7d32cc1 Cc: "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:11:39 -0000 --20cf307f3378db71e704d7d32cc1 Content-Type: text/plain; charset=UTF-8 Hello all, IMHO, n-hop routing protocols (based on MANET) are not much needed to be discussed at least at this moment. One-hop IP communications for ITS seem enough to be studied in the first stage at the IETF. For instance, in EU, a combination of IPv6 and Geonetworking (i.e., a special designed protocol for vehicular communications that support one-hop and n-hop routing based on geographical information taken from GPS) has been specified at the ETSI ITS TC and tested at the FP7 project, GeoNet. IPv6 packets over Geonetworking are delivered in a manner of one-hop and n-hop while utilizing geographical information. For instance, IPv6 packets are sent to multiple receivers in a specific geographical area. It make that from the view point of IPv6, it is one-hop, but it is actually n-hops as the IPv6 packets are forwarded as many as needed to reach to the destination. In this way, routing performance is better and the n-hop topology maintain cost is removed. Cheers. On Wed, Mar 13, 2013 at 2:53 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hello ITS participants, > > While working on Charter Proposal we are distinguishing between 1-hop > V2V communications (a single subnet between several vehicles), and n-hop > communications (vehicle-to-vehicle-to-**vehicle, each time a different > subnet between vehicles). > > I would like to ask participants whether there is interest in n-hop > routing protocols for vehicular communications. > > Is work needed on MANET protocols for this? > > Are there special requirements for this? (i.e. a case where a MANET > protocol is not sufficient for n-hop vehicular communications). > > Yours, > > Alex > > ______________________________**_________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/**listinfo/its > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --20cf307f3378db71e704d7d32cc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all,

IMHO, n-hop routing protocols (based on MANET= ) are not much needed to be discussed at least at this=C2=A0moment.

One-hop IP communications for ITS seem enough to be studi= ed in the first stage at the IETF. For instance, in EU, a combination of IP= v6 and Geonetworking (i.e., a special designed protocol for vehicular commu= nications that support one-hop and n-hop routing based on geographical info= rmation taken from GPS) has been specified at the ETSI ITS TC and tested at= the FP7 project, GeoNet. IPv6 packets over Geonetworking are delivered in = a manner of one-hop and n-hop while utilizing geographical information. For= instance, IPv6 packets are sent to multiple receivers in a specific geogra= phical area. It make that from the view point of IPv6, it is one-hop, but i= t is actually n-hops as the IPv6 packets are forwarded as many as needed to= reach to the destination.

In this way, routing performance is better and the n-ho= p topology=C2=A0maintain cost is removed.=C2=A0

Ch= eers.=C2=A0

On Wed, Mar 13, 2013 a= t 2:53 PM, Alexandru Petrescu <alexandru.petrescu@gmail.com= > wrote:
Hello ITS participants,

While working on Charter Proposal we are distinguishing between 1-hop
V2V communications (a single subnet between several vehicles), and n-hop communications (vehicle-to-vehicle-to-vehicle, each time a different=
subnet between vehicles).

I would like to ask participants whether there is interest in n-hop
routing protocols for vehicular communications.

Is work needed on MANET protocols for this?

Are there special requirements for this? (i.e. a case where a MANET
protocol is not sufficient for n-hop vehicular communications).

Yours,

Alex

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



--
RSM Dep= artment, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewher= e between /dev/null and /dev/random

#email:=C2=A0j= onghyouk (at) gmail (dot) com
--20cf307f3378db71e704d7d32cc1-- From alexandru.petrescu@gmail.com Wed Mar 13 13:12:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F1D11E8134 for ; Wed, 13 Mar 2013 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 ihfPxcW-Jxxn for ; Wed, 13 Mar 2013 13:12:57 -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 C7C9911E815F for ; Wed, 13 Mar 2013 13:12:56 -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 r2DKCtjp024015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Mar 2013 21:12:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DKCsfr004335; Wed, 13 Mar 2013 21:12:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2DKCmuW013714; Wed, 13 Mar 2013 21:12:53 +0100 Message-ID: <5140DDA4.3050204@gmail.com> Date: Wed, 13 Mar 2013 21:12:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "its@ietf.org" Subject: [its] SmartCity and ITS, SmartCity and infrastructure-less V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:12:58 -0000 Hello Abdussalam, You suggested the SmartCity use case. May I ask you, and participants to the ITS email list, which part ot the SmartCity is relevant to ITS? Do you see a gap between existing protocols and SmartCity use case? Which protocols should we work on, and how? I am trying to understand whether SmartCity may consider vehicle-to-vehicle communications without assistance of infrastructure? (because SmartCity itself sounds like being the infrastructure)? Alex From mcr@sandelman.ca Wed Mar 13 16:23: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 4625711E8128 for ; Wed, 13 Mar 2013 16:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] 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 6vvwgTV5sT7A for ; Wed, 13 Mar 2013 16:23:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6411E810D for ; Wed, 13 Mar 2013 16:23:02 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 09D8622060 for ; Wed, 13 Mar 2013 23:23:02 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 310B5CA0C7 for ; Wed, 13 Mar 2013 19:23:01 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-reply-to: <513F936C.1010408@gmail.com> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Tue, 12 Mar 2013 21:43:24 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 13 Mar 2013 19:23:01 -0400 Message-ID: <19858.1363216981@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [its] what happened (was: Meet at IETF Registration Desk, Monday 19h30) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:23:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is not eno= ugh Alexandru> (0x86DD), why do we ask for another one for Alexandru> IPv6-over-80211p? That was me. I discussed this with others, and they were also perplexed as well. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRQQpUAAoJEKD0KQ7Gj3P2QTIH/jySK3IRLZy+jw10FIRdOlcm ASGXB8lS7UQ8Pq4zsEqNzwO1GS2fJE9dhUIOTSo322J/PAxpwxefwY5SP06r15u8 S5KGTxvcU6VA3pOozGOxlYCYZBXtfzMPmkb314LEw7LM1m/XWh82Lry4444GfTDL Y7XXDTK3sGUuFoeigAfc85EErlAcEDzaW4tmLqeT4NHfZI8Qwd64dm643Dw+5OVv 3HLWcbw/zuyNySqaHc5lvKSwD/dGDRUvFBm8kL/VvhxzosHL6ov42J2kToGqkBHm SPmUtxbW4/ukvt7oVPuqguDFierDoFpAfZwIHYfM1ojxJGuNLUCVm1VeOqdAzeg= =r6x1 -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Wed Mar 13 16:43:41 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3A11E8150 for ; Wed, 13 Mar 2013 16:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.139 X-Spam-Level: X-Spam-Status: No, score=-11.139 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, 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 IJDOagd3aEb3 for ; Wed, 13 Mar 2013 16:43:39 -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 8E7A711E80E8 for ; Wed, 13 Mar 2013 16:43:38 -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 r2DNhbHG025712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 00:43:37 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2DNhbjw028701 for ; Thu, 14 Mar 2013 00:43:37 +0100 (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 r2DNhVsj031830 for ; Thu, 14 Mar 2013 00:43:36 +0100 Message-ID: <51410F07.7030407@gmail.com> Date: Thu, 14 Mar 2013 00:43:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> In-Reply-To: <19858.1363216981@sandelman.ca> Content-Type: multipart/mixed; boundary="------------060908090400010005060903" Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:43:41 -0000 This is a multi-part message in MIME format. --------------060908090400010005060903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Le 14/03/2013 00:23, Michael Richardson a écrit : > >>>>>> "Alexandru" == Alexandru Petrescu >>>>>> writes: > Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is not > enough Alexandru> (0x86DD), why do we ask for another one for > Alexandru> IPv6-over-80211p? > > That was me. I discussed this with others, and they were also > perplexed as well. Well. The existing IPv6-over-Ethernet EtherType is 0x86DD. But there are several differences between Ethernet (WiFi) and 802.11p. - 802.11p doesnt have security and doesnt have BSS. - In some regions, 802.11p is not allowed by local regulator for anything that is 'non-safety'. ('safety' means an application to avoid car crashes, for exemple). I.e. 802.11p is not allowed for IP. - In laboratory people easily set up IP-straight-over-IP, but that does not mean it is legal by regulator (in terms of allowed frequency range). In some such settings the EtherType is 0x0707 (instead of 0x86DD IPv6-over-Ethernet). There is a new EtherType for IP-over-ETSI-over-80211p ("Your Ethernet Type Field number is: #8947"), check attached email. But that is not IPv6-straight-over-80211p, it is IPv6-over-ETSI-over-80211P. For all these reasons, should there be a new EtherType for IP-straight-over-80211p? What happens if people assume that IPv6-straight-over-80211p is 0x86DD but implementations do 0x0707 (as some do today, in a wait for such an _agreed_ such new EtherType)? Alex > > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > --------------060908090400010005060903 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" X-Mozilla-Keys: Received: from muguet1.intra.cea.fr (132.166.192.6) by EXCAH-A2.intra.cea.fr (132.166.88.76) with Microsoft SMTP Server id 14.2.318.4; Wed, 30 Jan 2013 10:52:54 +0100 Received: from epeire2.extra.cea.fr (epeire2.extra.cea.fr [132.167.198.32]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-in-1.2) with ESMTP id r0U9qsCq012921 for ; Wed, 30 Jan 2013 10:52:54 +0100 Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by epeire2.extra.cea.fr (8.14.4/8.14.4) with ESMTP id r0U9qrTQ027503 for ; Wed, 30 Jan 2013 10:52:54 +0100 (envelope-from alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-in-3.2) with ESMTP id r0U9qmiC006311 for ; Wed, 30 Jan 2013 10:52:53 +0100 X-Originating-IP: 10.0.21.133 Received: from spool.mail.gandi.net (mspool2-d.mgt.gandi.net [10.0.21.133]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BF2C741C07B; Wed, 30 Jan 2013 10:52:48 +0100 (CET) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by spool.mail.gandi.net (Postfix) with ESMTP id B9D121780D6; Wed, 30 Jan 2013 10:52:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from spool.mail.gandi.net ([10.0.21.133]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DHqu8W6yKxxV; Wed, 30 Jan 2013 10:52:46 +0100 (CET) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by spool.mail.gandi.net (Postfix) with ESMTPS id 03089178131 for ; Wed, 30 Jan 2013 10:52:45 +0100 (CET) Received: by mail-wg0-f53.google.com with SMTP id fn15so998411wgb.8 for ; Wed, 30 Jan 2013 01:52:45 -0800 (PST) X-Received: by 10.194.216.66 with SMTP id oo2mr7240895wjc.4.1359539564883; Wed, 30 Jan 2013 01:52:44 -0800 (PST) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.194.62.166 with SMTP id z6csp110802wjr; Wed, 30 Jan 2013 01:52:43 -0800 (PST) X-Received: by 10.68.189.65 with SMTP id gg1mr10926456pbc.57.1359539563011; Wed, 30 Jan 2013 01:52:43 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org. [2001:1890:126c::1:1e]) by mx.google.com with ESMTP id b9si1198870pax.194.2013.01.30.01.52.42; Wed, 30 Jan 2013 01:52:42 -0800 (PST) Received-SPF: pass (google.com: domain of its-bounces@ietf.org designates 2001:1890:126c::1:1e as permitted sender) client-ip=2001:1890:126c::1:1e; Authentication-Results: mx.google.com; spf=pass (google.com: domain of its-bounces@ietf.org designates 2001:1890:126c::1:1e as permitted sender) smtp.mail=its-bounces@ietf.org; dkim=pass (test mode) header.i=@ietf.org Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C2821F86F5; Wed, 30 Jan 2013 01:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1359539561; bh=Mz9Sjznja78tZ105/QWKH+E6xq4YERHxRvGik+/tQu0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Type:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=vYJXHb6O9hzvZI69aPzGIJRr1UasneBSynhZaLupg9C11no4R4sfHbA7WmCZS5u5u RsRfTXBJGiI9xb6BXN2FtLCaxXFi/jrjsD3M1SVZLHDxwUHzQWCKG6b2LkGF3MEN9/ ktmQYCbzgXXzTpqYtt+OCHuWSuN091tr2JPN8n4M= 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 5BFF121F8526 for ; Wed, 30 Jan 2013 01:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJAIhsrvg9-z for ; Wed, 30 Jan 2013 01:52:38 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id D91BC21F86EA for ; Wed, 30 Jan 2013 01:52:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,567,1355094000"; d="vcf'?scan'208,217";a="612602" Received: from dhcp-rocq-242.inria.fr ([128.93.62.242]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Jan 2013 10:52:36 +0100 Message-ID: <5108ED64.3010501@inria.fr> Date: Wed, 30 Jan 2013 10:52:36 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 To: References: <2ED1D3801ACAAB459FDB4EAC9EAD090C0FFFE9E2@xmb-aln-x03.cisco.com> <51064E08.9020401@gmail.com> <5106619F.7020002@inria.fr> <51067D07.9020409@gmail.com> <5108E3AB.8080205@inria.fr> <5108EA48.90003@gmail.com> In-Reply-To: <5108EA48.90003@gmail.com> Content-Type: multipart/mixed; boundary="------------010204000407030206070707" Subject: Re: [its] What do we need to make ITS WG go forward? - EtherType for ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: Errors-To: its-bounces@ietf.org X-CEA-Source: externe X-CEA-Spam: 10% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description TO_IN_SUBJECT 0.500 To address is found in the subject line EU_TLD 0.100 Contains .eu (European) top-level domain HTML_NO_HTTP 0.100 Html part does not contain 'http://' BODYTEXTP_SIZE_3000_LESS 0.000 Body size of the text/plain part is less than 3k BODY_SIZE_10000_PLUS 0.000 Message body size is 10000 bytes or more DKIM_SIGNATURE 0.000 DKIM_Signature WEBMAIL_SOURCE 0.000 message appears to come from a webmail service WEBMAIL_XOIP 0.000 Contains a header line seen in webmail systems WEBMAIL_X_IP_HDR 0.000 Conntains a known webmail X-IP header X-CEA-Spam-Hits: TO_IN_SUBJECT 0.5, EU_TLD 0.1, HTML_NO_HTTP 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_10000_PLUS 0, DKIM_SIGNATURE 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HIGHBITS 0, __INT_PROD_COMP 0, __INT_PROD_ONLINE 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_PHRASE1_E 0, __RUS_HASHBUSTER_KOI8R 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SUBJ_ALPHA_END 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NS , __USER_AGENT 0, __X_FORWARDED_FOR_GMAIL 0, __YOUTUBE_RCVD 0 Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com X-MS-Exchange-Organization-AuthSource: EXCAH-A2.intra.cea.fr X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-TM-AS-Product-Ver: SMEX-10.2.0.1135-6.800.1017-19576.000 X-TM-AS-Result: No--43.978700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-MS-Exchange-Organization-AVStamp-Mailbox: SMEXr^dE;967300;0;This mail has been scanned by Trend Micro ScanMail for Microsoft Exchange; X-MS-Exchange-Organization-SCL: 0 MIME-Version: 1.0 --------------010204000407030206070707 Content-Type: multipart/alternative; boundary="------------060004000508060303090408" --------------060004000508060303090408 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable ETSI members have access to this document: this letter from Angela N.=20 Thomas / IEEE Registration Authority it reads: /Following is the Ethernet Type Field that you have requested from the=20 IEEE. Please take a moment// //to verify that the information contained in the company address area=20 (above) is correct. If it// //is not entirely correct, please notify the IEEE immediately.// //The Ethertype tutorial on our web site at:// //http://standards.ieee.org/regauth/ethertype/type-tut.html// //It should be stressed that the IEEE assignment committee has made=20 every effort to ensure that// //there is no duplication of assignments, but does not guarantee that=20 duplicate assignments have// //not occurred. We urge that all requests for numbers be administered by=20 one person within your// //company.// //Your Ethernet Type Field number is: #8947// //For more information on the uses of your ethernet type field, please=20 see the relevant standards.// /// Re what Alex wrote, IPv6 works over GeoNetworking which is a protocol=20 defined by ETSI to work over G5 (ETSI's 11p). So, why would you need an=20 additional EtherType ? Regards, Thierry On 30/01/13 10:39, Alexandru Petrescu wrote: > Le 30/01/2013 10:11, Thierry Ernst a =C3=A9crit : >> >> Alex, >> >> IEEE have assigned Ethernet Type Field number #8947 for ITS use (ETSI >> TC ITS's GeoNetworking). Check the following document available on >> the ETSI server: >> >> ITS(13)000020 >> =20 >> >> Ethernet Type Field number for GeoNetworking >> http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)000020_Eth= ernet_Type_Field_number_for_GeoNetworking.pdf=20 >> > > Thierry, > > I >> > may be wrong, but here are my thoughts. > > I am trying to access these URLs you provide above but they are passwor= d > protected. What is the username and password? > > The URL indicates ETSI, not IEEE. > > The IEEE URL for EtherTypes is the following, I believe: > http://standards.ieee.org/develop/regauth/ethertype/eth.txt > > That eth.txt file does not contain 0707 nor 8947. But it does contain, > for example 86DD which is 'IPv6'. > > The 0x0707 EtherType is present in an implementation which is supposed > compliant with ETSI ITS (plugtests). Wireshark dump available upon=20 > request. > > Besides, if this is to be about IPv6, I think it should be reserved at > IANA as well, in addition to reserving it at IEEE. The IANA URL for > IEEE 802 Numbers is at: > http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml > > (the #8947 that you mention above does not seem to figure in this IANA > URL). > > This is why I believe this number should be reserved both as an > EtherType at IEEE and at IANA. > > Yours, > > Alex > >> >> Regards, Thierry. >> >> >> On 28/01/13 14:28, Alexandru Petrescu wrote: >>> Le 28/01/2013 14:16, Joe Klein a =C3=A9crit : >>>> I really dislike the fact that ISO is charging for the ISO 21217 >>>> - Architecture & ISO 21210 - IPv6 Networking. >>>> >>>> Does this make it any better? Safer? Should ISO now have >>>> cybersecurity and safety liability if the specification leads to >>>> deaths and damage to property? >>> >>> Does it make any better interoperable as well? >>> >>> EtherType 0x0707 described in ITS documents, implemented, but not >>> specified by IEEE nor reserved at IANA - does not make it >>> interoperable. >>> >>> One wouldn't think that this 0x0707 ethertype be reserved by >>> somebody who is not IANA nor IEEE? >>> >>> (see a good example of interoperability: IPv6 0x86dd ethertype is >>> reserved at IEEE and at IANA >>> http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml= ) >>> >>> >>> > Alex >>> >>> Or should these standards remain in >>>> the public domain, for researches to review and validate? >>>> >>>> Just my 2 cents. >>>> >>>> Joe >>>> >>>> >>>> >>>> On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst >>>> wrote: >>>>> >>>>> Dear all, >>>>> >>>>> At this stage, I don't think a new working group is needed. >>>>> First, it would need a charter, and support from the industry. >>>>> But more importantly, IETF WGs are not usually sector-driven, >>>>> so it means the different issues pertaining to ITS should be >>>>> brought to VARIOUS existing WGs, and a WG should only be >>>>> created if there is an important issue for which there is no >>>>> existing WG that could work on it. >>>>> >>>>> This said, as mentioned earlier, ITS is not only about >>>>> vehicular communications, though the issues listed by Alexandru >>>>> below mostly consider vehicular communications. >>>>> >>>>> What ITS really needs is the definition of a common >>>>> communication architecture and the definition of what features >>>>> should be comprised for an IPv6 networking stack deployed for >>>>> ITS use cases. This cannot be done at IETF, and actually >>>>> already exists at ISO: - ISO 21217 - Architecture - ISO 21210 - >>>>> IPv6 Networking >>>>> >>>>> As an input to the discussion, please consider reading >>>>> documents D2.1 and D2.2 available on the ITSSv6 project web >>>>> page: http://www.itssv6.eu/documentation/ D2.2 provides an >>>>> analysis of the currently published version of ISO 21210, but >>>>> new work items have been launched since then to address >>>>> remaining issues. >>>>> >>>>> Regards, Thierry. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 28/01/13 11:08, Alexandru Petrescu wrote: >>>>>> >>>>>> Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =C3=A9crit : >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> This is just one opinion, but I'd like to understand why >>>>>>> ITS would need its own IETF group. The work here is the >>>>>>> same (IMO) as what is taking place in MANET. I would vote >>>>>>> that this work be taken up in MANET. >>>>>> >>>>>> >>>>>> Stan, >>>>>> >>>>>> Thank you for the offer. I considered this offer since some >>>>>> time. >>>>>> >>>>>> I try to understand whether some of these items on which I >>>>>> have interest could be brought in in MANET WG: - V2V using >>>>>> prefix exchange - VIN-based IP addressing scheme - ND Prefix >>>>>> Delegation - PMIP-based network mobility - IPv6 >>>>>> single-address connecion 'sharing' with a cellular operator >>>>>> and a vehicular moving network (type '64share' of v6ops). - >>>>>> Default Route with DHCPv6. >>>>>> >>>>>> Please let me know. >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Regards, Stan >>>>>>> >>>>>>> On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote: >>>>>>> >>>>>>>> Hi Nabil, >>>>>>>> >>>>>>>> I think we already done some steps but not sure how far >>>>>>>> now. We will need to propose the WG and provide the WG >>>>>>>> charter, as use cases and work to be done in this group. >>>>>>>> This charter needs to be approved by the IESG. I have not >>>>>>>> attended the last meeting so not sure about the status >>>>>>>> now, >>>>>>>> >>>>>>>> AB >>>>>>>> >>>>>>>> On 1/26/13, Nabil Benamar wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I'm still interested in this list and want to join >>>>>>>>> voices previously heard to make it a working group. So >>>>>>>>> what should we exactly do, to achieve this goal ? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/1/26 Abdussalam Baryun >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I was interested in this group but not sure where are >>>>>>>>>> we so far. Is there progress, or is there >>>>>>>>>> issues/efforts that need to be completed and >>>>>>>>>> volunteered. >>>>>>>>>> >>>>>>>>>> AB _______________________________________________ >>>>>>>>>> its mailing list its@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C **Cordialem= ent, Regards* * * * * >>>>>>>>> *=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8=B1=D9=88 = Nabil Benamar* Professor of computer >>>>>>>>> sciences Simulation and Modelisation Laboratory Human >>>>>>>>> Sciences Faculty of Meknes Moulay Ismail* *University* >>>>>>>>> Meknes, Morocco *GSM: * *+ 212 6 70832236 >>>>>>>>> http://nabilbenamar.com/ >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------= -----------------=20 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>> * >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ its >>>>>>>> mailing list its@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>>> >>>>>>> _______________________________________________ its >>>>>>> mailing list its@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/its >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> _______________________________________________ its mailing list >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>> >>> >>> >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >> > > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --------------060004000508060303090408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

ETSI members have access to this document: this letter from Angela N. Thomas / IEEE Registration Authority it reads:
Following is the Ethernet Type Field that you have requested from the IEEE. Please take a moment
to verify that the information contained in the company address area (above) is correct. If it
is not entirely correct, please notify the IEEE immediately.
The Ethertype tutorial on our web site at:
http://standards.ieee.org/regauth= /ethertype/type-tut.html
It should be stressed that the IEEE assignment committee has made every effort to ensure that
there is no duplication of assignments, but does not guarantee that duplicate assignments have
not occurred. We urge that all requests for numbers be administered by one person within your
company.
Your Ethernet Type Field number is: #8947
For more information on the uses of your ethernet type field, please see the relevant standards.
 

Re what Alex wrote, IPv6 works over GeoNetworking which is a protocol defined by ETSI to work over G5 (ETSI's 11p). So, why would you need an additional EtherType ?

Regards,
Thierry


On 30/01/13 10:39, Alexandru Petrescu wrote:
Le 30/01/2013 10:11, Thierry Ernst a =C3=A9crit :

Alex,

IEEE have assigned Ethernet Type Field number #8947 for ITS use (ETSI
TC ITS's GeoNetworking). Check the following document available on
the ETSI server:

ITS(13)000020
<http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS%= 2813%29000020_Ethernet_Type_Field_number_for_GeoNetworking.pdf>
 Ethernet Type Field number for GeoNetworking
http://docbox.etsi.org/ITS/ITS/05-CONTRIBUTIONS/2013/ITS(13)00002= 0_Ethernet_Type_Field_number_for_GeoNetworking.pdf

Thierry,

I

may be wrong, but here are my thoughts.

I am trying to access these URLs you provide above but they are password
protected.  What is the username and password?

The URL indicates ETSI, not IEEE.

The IEEE URL for EtherTypes is the following, I believe:
http://standards.ieee.org/develop/regaut= h/ethertype/eth.txt

That eth.txt file does not contain 0707 nor 8947.  But it does contain,
for example 86DD which is 'IPv6'.

The 0x0707 EtherType is present in an implementation which is supposed
compliant with ETSI ITS (plugtests).  Wireshark dump available upon request.

Besides, if this is to be about IPv6, I think it should be reserved at
IANA as well, in addition to reserving it at IEEE.  The IANA URL for
IEEE 802 Numbers is at:
http://www.iana.org/assignments/ieee= -802-numbers/ieee-802-numbers.xml

(the #8947 that you mention above does not seem to figure in this IANA
 URL).

This is why I believe this number should be reserved both as an
EtherType at IEEE and at IANA.

Yours,

Alex


Regards, Thierry.


On 28/01/13 14:28, Alexandru Petrescu wrote:
Le 28/01/2013 14:16, Joe Klein a =C3=A9cr= it :
I really dislike the fact that ISO is charging for the ISO 21217
- Architecture & ISO 21210 - IPv6 Networking.

Does this make it any better? Safer?  Should ISO now have
cybersecurity and safety liability if the specification leads to
deaths and damage to property?

Does it make any better interoperable as well?

EtherType 0x0707 described in ITS documents, implemented, but not
specified by IEEE nor reserved at IANA - does not make it
interoperable.

One wouldn't think that this 0x0707 ethertype be reserved by
somebody who is not IANA nor IEEE?

(see a good example of interoperability: IPv6 0x86dd ethertype is
reserved at IEEE and at IANA
http://www.iana.org/assignments/ieee= -802-numbers/ieee-802-numbers.xml)



Alex

Or should these standards remain in
the public domain, for researches to review and validate?

Just my 2 cents.

Joe



On Mon, Jan 28, 2013 at 6:31 AM, Thierry Ernst
<thierry.ernst@inria.fr> wrote:

Dear all,

At this stage, I don't think a new working group is needed.
First, it would need a charter, and support from the industry.
But more importantly, IETF WGs are not usually sector-driven,
so it means the different issues pertaining to ITS should be
brought to VARIOUS existing WGs, and a WG should only be
created if there is an important issue for which there is no
existing WG that could work on it.

This said, as mentioned earlier, ITS is not only about
vehicular communications, though the issues listed by Alexandru
below mostly consider vehicular communications.

What ITS really needs is the definition of a common
communication architecture and the definition of what features
should be comprised for an IPv6 networking stack deployed for
ITS use cases. This cannot be done at IETF, and actually
already exists at ISO: - ISO 21217 - Architecture - ISO 21210 -
IPv6 Networking

As an input to the discussion, please consider reading
documents D2.1 and D2.2 available on the ITSSv6 project web
page: http://www.itssv6.eu/documentation/ D2.2 provi= des an
analysis of the currently published version of ISO 21210, but
new work items have been launched since then to address
remaining issues.

Regards, Thierry.





On 28/01/13 11:08, Alexandru Petrescu wrote:

Le 28/01/2013 05:02, Stan Ratliff (sratliff) a =C3=A9crit :

All,

This is just one opinion, but I'd like to understand why
ITS would need its own IETF group. The work here is the
same (IMO) as what is taking place in MANET. I would vote
that this work be taken up in MANET.


Stan,

Thank you for the offer.  I considered this offer sinc= e some
time.

I try to understand whether some of these items on which I
have interest could be brought in in MANET WG: - V2V using
prefix exchange - VIN-based IP addressing scheme - ND Prefix
Delegation - PMIP-based network mobility - IPv6
single-address connecion 'sharing' with a cellular operator
and a vehicular moving network (type '64share' of v6ops). -
Default Route with DHCPv6.

Please let me know.

Yours,

Alex


Regards, Stan

On Jan 26, 2013, at 9:34 AM, Abdussalam Baryun wrote:

Hi Nabil,

I think we already done some steps but not sure how far
now. We will need to propose the WG and provide the WG
charter, as use cases and work to be done in this group.
This charter needs to be approved by the IESG. I have not
attended the last meeting so not sure about the status
now,

AB

On 1/26/13, Nabil Benamar <benamar73@gmail.com> wrote:

Hi All,

I'm still interested in this list and want to join
voices previously heard to make it a working group. So
what should we exactly do, to achieve this goal ?


2013/1/26 Abdussalam Baryun
<abdussalambaryun@gmail.com>

Hi All,

I was interested in this group but not sure where are
we so far. Is there progress, or is there
issues/efforts that need to be completed and
volunteered.

AB _______________________________________________
its mailing list its@ietf.org
https://www.ietf.org/mailman/listinfo/it= s




-- * * *=D8=AA=D8=AD=D9=8A=D8=A7=D8=AA=D9=8A =D8=8C *= *Cordialement, Regards* * * * *
*=D9=86=D8=A8=D9=8A=D9=84 =D8=A8=D9=86=D8=B9=D9=85=D8= =B1=D9=88 Nabil Benamar* Professor of computer
sciences Simulation and Modelisation Laboratory Human
Sciences Faculty of Meknes Moulay Ismail* *University*
Meknes, Morocco *GSM: * *+ 212 6 70832236
http://nabilbenamar.com/

*

---------------------------------------------------------------------------= -----







*


_______________________________________________ its
mailing list its@ietf.org
https://www.ietf.org/mailman/listinfo/its


_______________________________________________ its
mailing list its@ietf.org
https://www.ietf.org/mailman/listinfo/its



_______________________________________________ its mailing
list its@ietf.org https://www.ietf.org/mailman/listinfo/its



_______________________________________________ its mailing
list its@ietf.org https://www.ietf.org/mailman/listinfo/its

_______________________________________________ its mailing list
its@ietf.org https://www.ietf.org/mailman/listinfo/its



_______________________________________________ its mailing list
its@ietf.org https://www.ietf.org/mailman/listinfo/its



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



_______________________________________________
its mailing list
it= s@ietf.org
https://www.ietf.org/mailman/listinfo/its

--------------060004000508060303090408-- --------------010204000407030206070707 Content-Type: text/x-vcard; charset="utf-8"; name="thierry_ernst.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="thierry_ernst.vcf" YmVnaW46dmNhcmQNCmZuOlRoaWVycnkgIEVybnN0DQpuOkVybnN0O1RoaWVycnkgDQpvcmc6SU5S SUEgLSBQcm9qZWN0IFRlYW0gSU1BUkEgLSBMYVJBIEpSVQ0KdGVsO3dvcms6KzMzIDEgMzk2MyA1 OSAzMA0KdGVsO2ZheDorMzMgMSAzOSA2MyA1NCA5MQ0KdGVsO2NlbGw6KzMzIDYgNzYgNTYgMjUg OTYNCnVybDpodHRwOi8vd3d3LmxhcmEucHJkLmZyDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoN Cg== --------------010204000407030206070707 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its --------------010204000407030206070707-- --------------060908090400010005060903-- From r.kuntz@gmail.com Thu Mar 14 02:52: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 7CC5421F8D31 for ; Thu, 14 Mar 2013 02:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.885 X-Spam-Level: ** X-Spam-Status: No, score=2.885 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 NYQZjFuSVarY for ; Thu, 14 Mar 2013 02:52:35 -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 BB90521F8CEF for ; Thu, 14 Mar 2013 02:52:34 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id d46so1958885wer.3 for ; Thu, 14 Mar 2013 02:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=sZXWDfnrD2q2xjOZng/rD1Bc5Lva4aAwlvSCJqwHFmg=; b=eB233OkpbWtGZpI4tNqo7U/izK6hQVCbhmbOxRJx7WHybdi71042G6pG0ggFNJBFNe zrZaxsgQxbL9lKaVaXIQhhnsZ8LlfhRaApHNhsmnT6VUWpRhlBME1w8hk9umE6jVxeAG HS0JK/vPqqS/Z7p8mrJG3XK/PQq/SWMG+UahB782ksWRDIi8L04UVSqa2EOdRPm9yGm/ lP5FADjcTfKpmrrrn536FK/AAiV9qRxkw8r8yxlrhb6ECTyK4lEOdKRVsbuuT44dtgUE XMwIWEoqKq+fajxXETPj6kSqSaF2wnGcBE9DiMXlYsmWNWSHR4nKOSGemhiq2a9HL1iZ Q/Yg== X-Received: by 10.180.185.204 with SMTP id fe12mr2611450wic.2.1363254753894; Thu, 14 Mar 2013 02:52:33 -0700 (PDT) Received: from fry.lan (bro67-1-87-91-122-114.dsl.sta.abo.bbox.fr. [87.91.122.114]) by mx.google.com with ESMTPS id du2sm7868419wib.0.2013.03.14.02.52.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 02:52:32 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Romain KUNTZ In-Reply-To: <51410F07.7030407@gmail.com> Date: Thu, 14 Mar 2013 10:52:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1499) Cc: its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 09:52:35 -0000 Hello Alex, On Mar 14, 2013, at 0:43 , Alexandru Petrescu = wrote: > Le 14/03/2013 00:23, Michael Richardson a =E9crit : >>=20 >>>>>>> "Alexandru" =3D=3D Alexandru Petrescu >>>>>>> writes: >> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is not >> enough Alexandru> (0x86DD), why do we ask for another one for >> Alexandru> IPv6-over-80211p? >>=20 >> That was me. I discussed this with others, and they were also >> perplexed as well. >=20 > Well. >=20 > The existing IPv6-over-Ethernet EtherType is 0x86DD. Yes and it should remain the same whatever the lower layer. What would = be the benefits of having a new one? I still do not understand why you = need a new ethertype. IPv6 should be agnostic to the lower layers and = work exactly the same on top of 802.11p. That's the principle of the OSI = layer separation! It should not behave differently so there is no reason = to have a new Ethertype.=20 > But there are several differences between Ethernet (WiFi) and 802.11p. >=20 > - 802.11p doesnt have security and doesnt have BSS. >=20 > - In some regions, 802.11p is not allowed by local regulator for > anything that is 'non-safety'. ('safety' means an application to > avoid car crashes, for exemple). I.e. 802.11p is not allowed for IP. >=20 > - In laboratory people easily set up IP-straight-over-IP, but that = does > not mean it is legal by regulator (in terms of allowed frequency > range). In some such settings the EtherType is 0x0707 (instead of > 0x86DD IPv6-over-Ethernet). >=20 > There is a new EtherType for IP-over-ETSI-over-80211p ("Your > Ethernet Type Field number is: #8947"), check attached email. But = that > is not IPv6-straight-over-80211p, it is IPv6-over-ETSI-over-80211P. GN is a different L3 protocol so it is normal to have a new ethertype = for it.=20 Regards, Romain > For all these reasons, should there be a new EtherType for > IP-straight-over-80211p? >=20 > What happens if people assume that IPv6-straight-over-80211p is 0x86DD > but implementations do 0x0707 (as some do today, in a wait for such an > _agreed_ such new EtherType)? >=20 > Alex >=20 >>=20 >>=20 >>=20 >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From abdussalambaryun@gmail.com Thu Mar 14 03:58:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C381B21F8FEB for ; Thu, 14 Mar 2013 03:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.674 X-Spam-Level: X-Spam-Status: No, score=-3.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 f915UnPVGnky for ; Thu, 14 Mar 2013 03:58:31 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3A83721F8E79 for ; Thu, 14 Mar 2013 03:58:31 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id ma3so2039253pbc.11 for ; Thu, 14 Mar 2013 03:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sX3sNentnk12O7BsZvJ5WbUE4PoAtHjwlapZ4knvMMk=; b=Rj58ofWko+J1V10iQHspRJYqLW1GCrGgMhiu1Z4KypjyhTvokHAmQLxcPmZwo6RLvL 0QXY9tIBvkplD/BujZTescp5vOWKCIU8ydvMho6F4JOGYgZAZeZza3LNAihtACIiF+ts NeqROfjaNox54LOtCOnU8UpALq6X59yohrmZQ4C15EVy7ZuFiDBuwOQX2Yrze1r+b+lk pPu8jHPXZmiugsllevXZMRxNuIgk7cFbHzCbtHktz8jC/MeQzttlYi/ljPE79Z31AXRe pMK4TIZXiY8Unn5stxcnfdTLxEfgjQ4nQ65nMQ5uYZhDYwlV+gRo7CYXRm6ddelyIYpE icwg== MIME-Version: 1.0 X-Received: by 10.68.11.135 with SMTP id q7mr4787145pbb.5.1363258710876; Thu, 14 Mar 2013 03:58:30 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Thu, 14 Mar 2013 03:58:30 -0700 (PDT) In-Reply-To: <5140DDA4.3050204@gmail.com> References: <5140DDA4.3050204@gmail.com> Date: Thu, 14 Mar 2013 11:58:30 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] SmartCity and ITS, SmartCity and infrastructure-less V2V X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 10:58:31 -0000 Hi Alex, ITS is about transportation systems and I think SmartCities will not be smart if it does not have ITS. People/citisens need to use the ITS to make their own decisions to choose transport-vehicle/travel-place/travel-time/etc or to wait for other opportunities. The beauty of the current and future SmartCities is that they are including both infrastructure and infrastructureless, so the ITS needs both. My comment below; On 3/13/13, Alexandru Petrescu wrote: > Hello Abdussalam, > > You suggested the SmartCity use case. > > May I ask you, and participants to the ITS email list, which part ot the > SmartCity is relevant to ITS? The transportation services parts, we only consider past transports, current, and future, to help make thoes communications better. > > Do you see a gap between existing protocols and SmartCity use case? > Which protocols should we work on, and how? Yes I see gap because the IETF existing protocols (still general) does not involve applicability and intelligence of transportation services. Existing protocols are about separate IETF areas, but the ITS WG has included cross areas as you mentioned related WGs in the charter. We will have to define in our drafts. > > I am trying to understand whether SmartCity may consider > vehicle-to-vehicle communications without assistance of infrastructure? > (because SmartCity itself sounds like being the infrastructure)? SmartCity is about the cities M2M, ITS is about using it for such services, SmartCities is not only about infrastructure. Regarding V2V it is part of the M2M coomunication, but we only focus our standards on the part of SmartCities that are for transportation use-cases. Abdussalam Baryun University of Glamorgan, UK From abdussalambaryun@gmail.com Thu Mar 14 04:29: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 1B3DC21F8FC6 for ; Thu, 14 Mar 2013 04:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 J5usD0xbX+sS for ; Thu, 14 Mar 2013 04:29:13 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9021F8F86 for ; Thu, 14 Mar 2013 04:29:13 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id ma3so2074894pbc.11 for ; Thu, 14 Mar 2013 04:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FIvc1gsaVTMeXCnqOoSJ7zqZifI1OoI7Wiw9B4oQQ4M=; b=KFv5RuvBu62FoabIH5i89occLWwurZDKrwiNNUbq35qrVrJSSVvQWA75xOAjrFK6q4 IpFRvzY9HDlC55tiCilAEGzpaqE0lmumSMUbHeaFzmb9vT01Wf6RovNFYvEschHw2MMB qi/ST3ynIjtcVjsIgtYLvWHOUJNs1Rsz4hO6Po6onzu0kfYdJQa3RJdsDniLeUDFUx1p ZcXk49X9RuCIadySZGpIAXiUFmCYL3gcJ7Im/dChrq+q7dFS+RpZHtrS4fmlRLdqqkCo 1bK40IPjGb98LzVoB9lcHR3SzRTfGM01ui1MyHDM+UeFNgllX4MDyxlUnaOy9x336K/Q AIyQ== MIME-Version: 1.0 X-Received: by 10.68.11.135 with SMTP id q7mr5019298pbb.5.1363260553240; Thu, 14 Mar 2013 04:29:13 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Thu, 14 Mar 2013 04:29:12 -0700 (PDT) In-Reply-To: <5140CB20.2050306@gmail.com> References: <5140CB20.2050306@gmail.com> Date: Thu, 14 Mar 2013 12:29:12 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 11:29:14 -0000 Hi Alex, I don't think MANET WG has considered the use-case of ITS WG as we stated in our charter, and I don't think they will recharter either because they still not completed the two standards required for them (I am an active participant in MANET WG). This MANET WG still not defined its subnets, which is important for ITS WG and I tried with that WG, but they want to postpone, or they think it is dangerous (as they mentioned twice). IMHO, the ITS should consider 1-hop and n-hops data-transports, but for different purposes from other IETF-WGs. For example in RFC6130 protocols the 1-hop and 2-hop of nieghbors is considered for route discovery. I think in the ITS we may include transport-service discovery of nieghbors. In MANET the routing n-hops are all infrastructure-less but in ITS may involve both. In MANET-WG routings always assumes that all Router Machines (i.e. as we are taliking M2M) have the same MANET-routing protocol, in ITS-WG we need to assume that all Router Machines have the proposed ITS protocol. In addition, to make the steps simple in works we may start with the 1-hop for infrastructure and 1-hop for infrastructureless, but then we make n-hop. Alex, I would like to know your opinion as well, Abdussalam Baryun university of Glamorgan, UK On 3/13/13, Alexandru Petrescu wrote: > Hello ITS participants, > > While working on Charter Proposal we are distinguishing between 1-hop > V2V communications (a single subnet between several vehicles), and n-hop > communications (vehicle-to-vehicle-to-vehicle, each time a different > subnet between vehicles). > > I would like to ask participants whether there is interest in n-hop > routing protocols for vehicular communications. > > Is work needed on MANET protocols for this? > > Are there special requirements for this? (i.e. a case where a MANET > protocol is not sufficient for n-hop vehicular communications). > > Yours, > > Alex > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > From adrian@olddog.co.uk Thu Mar 14 05:11: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 0E64F21F8F62 for ; Thu, 14 Mar 2013 05:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 2625tYxf9dJG for ; Thu, 14 Mar 2013 05:11:54 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A821F8F7B for ; Thu, 14 Mar 2013 05:11:51 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2ECBmK1013882; Thu, 14 Mar 2013 12:11:49 GMT Received: from webmail.easyspace.com (webmail4.iomartmail.com [10.12.10.174]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2ECBmEk013877; Thu, 14 Mar 2013 12:11:48 GMT MIME-Version: 1.0 X-Mailer: AtMail PHP 5.7 Message-ID: <55290.1363263108@olddog.co.uk> To: "Alexandru Petrescu" , "Abdussalam Baryun" Content-Type: text/plain; charset="utf-8" X-Origin: 130.129.16.183 X-Atmail-Account: adrian@olddog.co.uk Date: Thu, 14 Mar 2013 12:11:48 +0000 From: Adrian Farrel Content-Transfer-Encoding: quoted-printable Cc: "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications -MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:11:55 -0000 I think that Alex and Abdussalam are right to distinguish the two use-cases= of v2v and routed. Of course, that distinction only exists if v2v is a direct media link, rath= er than routed through a=20 network of street architecture. Similarly, v2v is only different if it is n= ot simply an extension=20 of intra-vehicle networking. Wrt routed (v2v2v2v2v) networking, it really should be observed that this w= as one of prime=20 motivating factors for MANET, and handling that environment would need to b= e discussed with MANET=20 before it appears on any future ITS charter. Adrian On Thu 14/03/13 11:29 AM , "Abdussalam Baryun" abdussalambaryun@gmail.com s= ent: > Hi Alex, >=20 > I don't think MANET WG has considered the use-case of ITS WG as we > stated in our charter, and I don't think they will recharter either > because they still not completed the two standards required for them > (I am an active participant in MANET WG). This MANET WG still not > defined its subnets, which is important for ITS WG and I tried with > that WG, but they want to postpone, or they think it is dangerous (as > they mentioned twice). >=20 > IMHO, the ITS should consider 1-hop and n-hops data-transports, but > for different purposes from other IETF-WGs. For example in RFC6130 > protocols the 1-hop and 2-hop of nieghbors is considered for route > discovery. I think in the ITS we may include transport-service > discovery of nieghbors. In MANET the routing n-hops are all > infrastructure-less but in ITS may involve both. In MANET-WG routings > always assumes that all Router Machines (i.e. as we are taliking M2M) > have the same MANET-routing protocol, in ITS-WG we need to assume that > all Router Machines have the proposed ITS protocol. >=20 > In addition, to make the steps simple in works we may start with the > 1-hop for infrastructure and 1-hop for infrastructureless, but then we > make n-hop. Alex, I would like to know your opinion as well, >=20 > Abdussalam Baryun > university of Glamorgan, UK >=20 > On 3/13/13, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote:> Hello ITS participants, > > > > While working on Charter Proposal we are > distinguishing between 1-hop> V2V communications (a single subnet between > several vehicles), and n-hop> communications (vehicle-to-vehicle-to-vehic= le, > each time a different> subnet between vehicles). > > > > I would like to ask participants whether there > is interest in n-hop> routing protocols for vehicular > communications.> > > Is work needed on MANET protocols for > this?> > > Are there special requirements for this? (i.e. a > case where a MANET> protocol is not sufficient for n-hop vehicular > communications).> > > 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 >=20 >=20 From alexandru.petrescu@gmail.com Thu Mar 14 05:45: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 137D521F8F7B for ; Thu, 14 Mar 2013 05:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.65 X-Spam-Level: X-Spam-Status: No, score=-7.65 tagged_above=-999 required=5 tests=[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 5KCnn6tcn6kT for ; Thu, 14 Mar 2013 05:45:11 -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 85AE321F8F50 for ; Thu, 14 Mar 2013 05:45:11 -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 r2ECjAA8003882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Mar 2013 13:45:10 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2ECjAxA013336 for ; Thu, 14 Mar 2013 13:45:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2ECj8wk012219 for ; Thu, 14 Mar 2013 13:45:09 +0100 Message-ID: <5141C637.5000203@gmail.com> Date: Thu, 14 Mar 2013 13:44:39 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> In-Reply-To: <51410F07.7030407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 12:45:13 -0000 Le 14/03/2013 00:43, Alexandru Petrescu a écrit : > Le 14/03/2013 00:23, Michael Richardson a écrit : >> >>>>>>> "Alexandru" == Alexandru Petrescu >>>>>>> writes: >> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is >> not enough Alexandru> (0x86DD), why do we ask for another one for >> Alexandru> IPv6-over-80211p? >> >> That was me. I discussed this with others, and they were also >> perplexed as well. > > Well. > > The existing IPv6-over-Ethernet EtherType is 0x86DD. > > But there are several differences between Ethernet (WiFi) and > 802.11p. > > - 802.11p doesnt have security and doesnt have BSS. > > - In some regions, 802.11p is not allowed by local regulator for > anything that is 'non-safety'. ('safety' means an application to > avoid car crashes, for exemple). I.e. 802.11p is not allowed for > IP. > > - In laboratory people easily set up IP-straight-over-IP, but that > does not mean it is legal by regulator (in terms of allowed > frequency range). In some such settings the EtherType is 0x0707 > (instead of 0x86DD IPv6-over-Ethernet). In private I was told the following, and I stand corrected. A certain 802.11p hardware uses 0x0707 EtherType for some unknown intermediate protocol (wireshark doesnt understand it). That 0x0707 is not for IPv6. It may be for IPv6-over-geonetworking-over-80211p. This may be corrected in the future to use #8947. Alex > There is a new EtherType for IP-over-ETSI-over-80211p ("Your Ethernet > Type Field number is: #8947"), check attached email. But that is not > IPv6-straight-over-80211p, it is IPv6-over-ETSI-over-80211P. > > For all these reasons, should there be a new EtherType for > IP-straight-over-80211p? > > What happens if people assume that IPv6-straight-over-80211p is > 0x86DD but implementations do 0x0707 (as some do today, in a wait for > such an _agreed_ such new EtherType)? > > 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 alexandru.petrescu@gmail.com Thu Mar 14 06:00:26 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728E021F905A for ; Thu, 14 Mar 2013 06:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.65 X-Spam-Level: X-Spam-Status: No, score=-7.65 tagged_above=-999 required=5 tests=[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 kTYJfVlcQHQl for ; Thu, 14 Mar 2013 06:00:25 -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 3EFEB21F9058 for ; Thu, 14 Mar 2013 06:00:25 -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 r2ED0O9N011053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 14:00:24 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2ED0NRj020512; Thu, 14 Mar 2013 14:00:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2ED0IPm021332; Thu, 14 Mar 2013 14:00:23 +0100 Message-ID: <5141C9C5.6030308@gmail.com> Date: Thu, 14 Mar 2013 13:59:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Romain KUNTZ References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> In-Reply-To: <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:00:26 -0000 Le 14/03/2013 10:52, Romain KUNTZ a écrit : > Hello Alex, > > On Mar 14, 2013, at 0:43 , Alexandru Petrescu > wrote: > >> Le 14/03/2013 00:23, Michael Richardson a écrit : >>> >>>>>>>> "Alexandru" == Alexandru Petrescu >>>>>>>> writes: >>> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is >>> not enough Alexandru> (0x86DD), why do we ask for another one for >>> Alexandru> IPv6-over-80211p? >>> >>> That was me. I discussed this with others, and they were also >>> perplexed as well. >> >> Well. >> >> The existing IPv6-over-Ethernet EtherType is 0x86DD. > > Yes and it should remain the same whatever the lower layer. What > would be the benefits of having a new one? I still do not understand > why you need a new ethertype. IPv6 should be agnostic to the lower > layers and work exactly the same on top of 802.11p Romain - when you say 'the same', it means to me that 0x86DD is good to be the same over WiFi, over Ethernet, over 802.15.4... and over 802.11p - all IEEE links. In principle I agree with that. (it would however be different to non-IEEE links). The most oppinions I hear is that we should continue to use 0x86DD for IPv6-straight-over-80211p. To which I tend to agree. At the same time, I know it may be impossible for me in the place where I live to use IPv6-straight-over-80211p for V2V, because of frequency regulation. I dont think at IETF we could influence frequency regulation in some particular country. What to do to be able to use IPv6-straight-over-80211p? What to do to be able to use it in a secure manner, (because it doesnt offer link-layer security, like WiFi does with WEP etc.)? > That's the principle of the OSI layer separation! It should not > behave differently so there is no reason to have a new Ethertype. Should not, ok, but it does behave differently than WiFi. For example it doesnt have link layer security. >> But there are several differences between Ethernet (WiFi) and >> 802.11p. >> >> - 802.11p doesnt have security and doesnt have BSS. >> >> - In some regions, 802.11p is not allowed by local regulator for >> anything that is 'non-safety'. ('safety' means an application to >> avoid car crashes, for exemple). I.e. 802.11p is not allowed for >> IP. >> >> - In laboratory people easily set up IP-straight-over-IP, but that >> does not mean it is legal by regulator (in terms of allowed >> frequency range). In some such settings the EtherType is 0x0707 >> (instead of 0x86DD IPv6-over-Ethernet). >> >> There is a new EtherType for IP-over-ETSI-over-80211p ("Your >> Ethernet Type Field number is: #8947"), check attached email. But >> that is not IPv6-straight-over-80211p, it is >> IPv6-over-ETSI-over-80211P. > > GN is a different L3 protocol so it is normal to have a new > ethertype for it. But they also have defined IPv6-over-geonetworking-over-80211p (not only geonetworking-over-80211p): what EtherType should that use? The 0x86DD? Or that #8947? Alex > > Regards, Romain > >> For all these reasons, should there be a new EtherType for >> IP-straight-over-80211p? >> >> What happens if people assume that IPv6-straight-over-80211p is >> 0x86DD but implementations do 0x0707 (as some do today, in a wait >> for such an _agreed_ such new EtherType)? >> >> 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 mcr@sandelman.ca Thu Mar 14 06:16: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 C0C7721F9067 for ; Thu, 14 Mar 2013 06:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] 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 qC-HASGrugGt for ; Thu, 14 Mar 2013 06:16:46 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 425B121F9062 for ; Thu, 14 Mar 2013 06:16:46 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 9BAFA22060; Thu, 14 Mar 2013 13:16:45 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C2218CA0C7; Thu, 14 Mar 2013 09:16:41 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-reply-to: <51410F07.7030407@gmail.com> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> Comments: In-reply-to Alexandru Petrescu message dated "Thu, 14 Mar 2013 00:43:03 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Mar 2013 09:16:41 -0400 Message-ID: <16627.1363267001@sandelman.ca> Sender: mcr@sandelman.ca Cc: its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:16:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> But there are several differences between Ethernet (WiFi) Alexandru> and 802.11p. Alexandru> - 802.11p doesnt have security and doesnt have BSS. Alexandru> - In some regions, 802.11p is not allowed by local Alexandru> regulator for anything that is 'non-safety'. ('safety' Alexandru> means an application to avoid car crashes, for exemple). Alexandru> I.e. 802.11p is not allowed for IP. I'd like to see the text. I don't see how do avoid crashes with only one car hop, I'd expect a mesh, and I'd want a layer-3 mesh, so IP. I don't think that "safety" can imply the absense of some technology, rather it should restrict what applications. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRQc24AAoJEKD0KQ7Gj3P2OcIIAJ8JZeMdrm7rgo5P0SjZ0KMf SCj1yYzrZ0KAFOq3dX7/uWfusizIvbYyOc3+WAkw0eI20vVweogfZ5gAcOft0aAk mo11e0sCUtw18QUMFfaLnG0JLmTA9wNergb+CB6EYO47fr+61N5ICG59itqQI1ww 3sLG7JV1RGjKTqMMCPCjZwQzGTKl0lomXMevIO2HWOT8VMYUMtlttLBUX1QQMdhr zzGmCiBLgjrcjRXVLtVPq8Y76H8v8bOkrpWj54rLDyHR+nDkaYTT8PpTm/WZ+boW qqNThkr6FqCjzRw2ZkaBZvtY06yAB2cfvsjhwvUanerkQeTVvy+QK99xHoJ1vXM= =u67s -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Thu Mar 14 06:39:26 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBEE11E8112 for ; Thu, 14 Mar 2013 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.95 X-Spam-Level: X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zz3i56hJ-+j5 for ; Thu, 14 Mar 2013 06:39: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 9766D11E811D for ; Thu, 14 Mar 2013 06:39:25 -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 r2EDdND0003423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 14:39:23 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EDdM34005448; Thu, 14 Mar 2013 14:39:22 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EDdHP9013962; Thu, 14 Mar 2013 14:39:22 +0100 Message-ID: <5141D2E8.3030608@gmail.com> Date: Thu, 14 Mar 2013 14:38:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dickroy@alum.mit.edu References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com><19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:39:27 -0000 Le 14/03/2013 05:05, Richard Roy a écrit : >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Wednesday, March 13, 2013 4:43 PM > >> To: its@ietf.org > >> Subject: Re: [its] what happened > >> > >> Le 14/03/2013 00:23, Michael Richardson a écrit : > >>> > >>>>>>>> "Alexandru" == Alexandru Petrescu > >>>>>>>> writes: > >>> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is >>> not > >>> enough Alexandru> (0x86DD), why do we ask for another one for > >>> Alexandru> IPv6-over-80211p? > >>> > >>> That was me. I discussed this with others, and they were also > >>> perplexed as well. > >> > >> Well. > >> > >> The existing IPv6-over-Ethernet EtherType is 0x86DD. > >> > >> But there are several differences between Ethernet (WiFi) and >> 802.11p. > >> > >> - 802.11p doesnt have security and doesnt have BSS. > >> > >> - In some regions, 802.11p is not allowed by local regulator for > >> anything that is 'non-safety'. ('safety' means an application to > >> avoid car crashes, for exemple). I.e. 802.11p is not allowed for >> IP. > > */[RR>] Not true. 802.11 at 5.9GHz in the US has more channels > (174,176,178,180,182,183, and 184) than just a safety channel (172 > in FCC parlance), and IP can be used on those. Ok, that is good to know. Thank you for letting us know. May I ask you the following. What are the precise conditions of using IPv6 over these channels? What power levels? (dBm, or Watt) Should I register my device to a central authority? Or may I use it without informing them? Are there areas where the use of that frequency for IP-over-80211p is forbidden? (like near certain radio-telescope sites, like with the 70GHz regulation of V2V) The power levels is important for direct V2V communications, the more power the more distanced the vehicles can be, in the absence of infrastructure. The registration to a central authority puts significant hurdles to experimentation. The area restriction puts significant hurdles to the automation process (need to automatically turn off IP-over-80211p when the vehicle is in a certain area, but the reliance on GPS is not that pervasive - in certain regions Glonass, Galileo and others are preferred). > Furthermore, the restriction on IP usage happens to come from IEEE > 1609.3, Yes, in Europe this comes from ETSI recommendations and all the way up to the country-level Frequency Regulators which implement them in various ways (some country allow others dont). > not 802.11 since 802.11 knows nothing about networking protocols, and > even worse, the restriction is on the CCH (channel 178) and NOT the > safety channel (172), Bizarre, isn't it! Well, that's just the way > it is ... for the moment anyway. Right... > No such restriction on IP exists in Europe, yet, and plans are to > keep it that way; Well no. There exist such restrictions at least in the country where I live in Europe. One is not allowed to use IP-over-80211p-over-the frequency-over-which-only-80211p-can-run. There are several such countries. > not that for safety apps and single hop V2V comms you wouldn't want a > more stripped down protocol such as FNTP (see ISO 29281-1). /* Well... we'd need to consider what is the potential work item about FNTP at IETF. I need clarification about that, and it's a separate topic. I also wanted to mention... One person asked me why I think that IP is not for 'safety'? The counter-example (IP _is_ for safety) is the following: I as passenger in a car see an accident forming in the other lane - I instantly message jabber to other vehicles about what I see so they slow down. That's IP and is safety... Alex > > *//* > >> > >> - In laboratory people easily set up IP-straight-over-IP, but that >> does > >> not mean it is legal by regulator (in terms of allowed frequency > >> range). In some such settings the EtherType is 0x0707 (instead of > >> 0x86DD IPv6-over-Ethernet). > > */[RR>] 0x0707 is not a registered ethertype./* > >> > >> There is a new EtherType for IP-over-ETSI-over-80211p ("Your > >> Ethernet Type Field number is: #8947"), check attached email. But >> that > >> is not IPv6-straight-over-80211p, it is >> IPv6-over-ETSI-over-80211P. > > */[RR>] No it is not. This ethertype is for a completely different > networking protocol called GeoNetworking which has little if nothing > to do with IPv6, other than it, like most all other networking > protocols can be modified to allow tunneling of IPv6 packets through > the network protocol. In 99.999% of the use cases ETSI is > contemplating for this protocol, IPv6 plays no part at all. Finally, > while you may hear that GeoNetworking only works over 5.9GHz, that's > not true either. ETSI would like to mandate its use therefore, > however, to date, opposition to such a catastrophe has been > sustained and successful, and there is currently no requirement for > its use. /* > > *//* > > *//* > >> > >> For all these reasons, should there be a new EtherType for > >> IP-straight-over-80211p? > > */[RR>] Since there are no valid reasons above, this seems to be a > non-question to quote David Slepian./* > >> > >> What happens if people assume that IPv6-straight-over-80211p is >> 0x86DD > >> but implementations do 0x0707 (as some do today, in a wait for such >> an > >> _agreed_ such new EtherType)? > > */[RR>] Implementations using a non-registered ethertype do so at > their own risk. Anyone using 0x86DD to point to IPv6 should be just > fine ... it's registered!/* > > */"/* > > */86DD USC/ISI IPv6/* > > */ 4676 Admiralty Way Internet Protocol Version 6/* > > */ Marina del Rey CA 90292 Crawford, M., > "Transmission of IPv6 Packets over Ethernet Networks," RFC-2464,/* > > */ UNITED STATES Internet Society, Dec. 1998./* > > */ http://www.ietf.org/rfc/rfc2464.txt/* > > */"/* > > */RR/* > > *//* > >> > >> Alex > >> > >>> > >>> > >>> > >>> _______________________________________________ its mailing list > >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its > >>> > From fjros@um.es Thu Mar 14 07: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 C603E11E820C for ; Thu, 14 Mar 2013 07:57:27 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 jjp6g8zBkje4 for ; Thu, 14 Mar 2013 07:57:22 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 5404711E819F for ; Thu, 14 Mar 2013 07:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id EE5C05D6FB; Thu, 14 Mar 2013 15:57:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DqF6bTIbofix; Thu, 14 Mar 2013 15:57:16 +0100 (CET) Received: from eduroam_um-230-184.inf.um.es (eduroam_um-230-184.inf.um.es [155.54.230.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon13.um.es (Postfix) with ESMTPSA id 8A6D25D900; Thu, 14 Mar 2013 15:57:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <5141C9C5.6030308@gmail.com> Date: Thu, 14 Mar 2013 15:57:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:57:28 -0000 Hi Alex, I agree with Romain in this regard. Please find some comments below. El 14/03/2013, a las 13:59, Alexandru Petrescu escribi=F3: > Le 14/03/2013 10:52, Romain KUNTZ a =E9crit : >> Hello Alex, >>=20 >> On Mar 14, 2013, at 0:43 , Alexandru Petrescu >> wrote: >>=20 >>> Le 14/03/2013 00:23, Michael Richardson a =E9crit : >>>>=20 >>>>>>>>> "Alexandru" =3D=3D Alexandru Petrescu >>>>>>>>> writes: >>>> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet is >>>> not enough Alexandru> (0x86DD), why do we ask for another one for >>>> Alexandru> IPv6-over-80211p? >>>>=20 >>>> That was me. I discussed this with others, and they were also >>>> perplexed as well. >>>=20 >>> Well. >>>=20 >>> The existing IPv6-over-Ethernet EtherType is 0x86DD. >>=20 >> Yes and it should remain the same whatever the lower layer. What >> would be the benefits of having a new one? I still do not understand >> why you need a new ethertype. IPv6 should be agnostic to the lower >> layers and work exactly the same on top of 802.11p >=20 > Romain - when you say 'the same', it means to me that 0x86DD is good = to > be the same over WiFi, over Ethernet, over 802.15.4... and over = 802.11p > - all IEEE links. In principle I agree with that. (it would however = be > different to non-IEEE links). >=20 > The most oppinions I hear is that we should continue to use 0x86DD for > IPv6-straight-over-80211p. To which I tend to agree. >=20 > At the same time, I know it may be impossible for me in the place = where > I live to use IPv6-straight-over-80211p for V2V, because of frequency > regulation. I dont think at IETF we could influence frequency > regulation in some particular country. >=20 > What to do to be able to use IPv6-straight-over-80211p? >=20 In Europe, I think that you can't (please someone correct me if I'm = wrong). The 5 GHz band is reserved for CEN DSRC and ETSI ITS. And ETSI = ITS clearly states that IPv6 traffic is transported over the ITS-G5 = interface (11p) via the GeoNetworking protocol (by means of the = adaptation sublayer GN6ASL). Please check the references provided by = Thierry and the related ETSI standards. > What to do to be able to use it in a secure manner, (because it doesnt > offer link-layer security, like WiFi does with WEP etc.)? >=20 802.11p does not offer link-layer security because stations operate = outside the context of a BSS. A possible approach? Delegate security to = upper layers. >> That's the principle of the OSI layer separation! It should not >> behave differently so there is no reason to have a new Ethertype. >=20 > Should not, ok, but it does behave differently than WiFi. For example > it doesnt have link layer security. >=20 And WiFi behaves differently than Ethernet... but that has nothing to = do. The purpose of EtherType is to identify the upper layer protocol. >>> But there are several differences between Ethernet (WiFi) and >>> 802.11p. >>>=20 >>> - 802.11p doesnt have security and doesnt have BSS. >>>=20 >>> - In some regions, 802.11p is not allowed by local regulator for >>> anything that is 'non-safety'. ('safety' means an application to >>> avoid car crashes, for exemple). I.e. 802.11p is not allowed for >>> IP. >>>=20 >>> - In laboratory people easily set up IP-straight-over-IP, but that >>> does not mean it is legal by regulator (in terms of allowed >>> frequency range). In some such settings the EtherType is 0x0707 >>> (instead of 0x86DD IPv6-over-Ethernet). >>>=20 >>> There is a new EtherType for IP-over-ETSI-over-80211p ("Your >>> Ethernet Type Field number is: #8947"), check attached email. But >>> that is not IPv6-straight-over-80211p, it is >>> IPv6-over-ETSI-over-80211P. >>=20 >> GN is a different L3 protocol so it is normal to have a new >> ethertype for it. >=20 > But they also have defined IPv6-over-geonetworking-over-80211p (not = only > geonetworking-over-80211p): what EtherType should that use? The = 0x86DD? > Or that #8947? >=20 The one for GeoNetworking, since IPv6 is 'hidden' from the link layer = perspective. Best, fran > Alex >=20 >>=20 >> Regards, Romain >>=20 >>> For all these reasons, should there be a new EtherType for >>> IP-straight-over-80211p? >>>=20 >>> What happens if people assume that IPv6-straight-over-80211p is >>> 0x86DD but implementations do 0x0707 (as some do today, in a wait >>> for such an _agreed_ such new EtherType)? >>>=20 >>> Alex >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ its mailing list >>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>=20 >>> _______________________________________________ >>> its mailing list its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From alexandru.petrescu@gmail.com Thu Mar 14 08:19:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7B11E822A for ; Thu, 14 Mar 2013 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.233 X-Spam-Level: X-Spam-Status: No, score=-9.233 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.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 VIJjyUllpO9L for ; Thu, 14 Mar 2013 08:19:18 -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 CDD0111E823C for ; Thu, 14 Mar 2013 08:19:17 -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 r2EFJFdd004920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 16:19:16 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EFJF6s022209; Thu, 14 Mar 2013 16:19:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EFJA2c015771; Thu, 14 Mar 2013 16:19:14 +0100 Message-ID: <5141EA50.4010201@gmail.com> Date: Thu, 14 Mar 2013 16:18:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:19:22 -0000 Le 14/03/2013 15:57, Francisco Javier Ros Muñoz a écrit : > Hi Alex, > > I agree with Romain in this regard. Please find some comments below. In this case, I tend to agree as well - only one EtherType for IPv6-over-80211p and IPv6-over-Ethernet: 0x86DD. But I still think there may be some discrepancy, see below... > El 14/03/2013, a las 13:59, Alexandru Petrescu escribió: > >> Le 14/03/2013 10:52, Romain KUNTZ a écrit : >>> Hello Alex, >>> >>> On Mar 14, 2013, at 0:43 , Alexandru Petrescu >>> wrote: >>> >>>> Le 14/03/2013 00:23, Michael Richardson a écrit : >>>>> >>>>>>>>>> "Alexandru" == Alexandru Petrescu >>>>>>>>>> writes: >>>>> Alexandru> Someone asked - why EtherType of IPv6 on Ethernet >>>>> is not enough Alexandru> (0x86DD), why do we ask for another >>>>> one for Alexandru> IPv6-over-80211p? >>>>> >>>>> That was me. I discussed this with others, and they were >>>>> also perplexed as well. >>>> >>>> Well. >>>> >>>> The existing IPv6-over-Ethernet EtherType is 0x86DD. >>> >>> Yes and it should remain the same whatever the lower layer. What >>> would be the benefits of having a new one? I still do not >>> understand why you need a new ethertype. IPv6 should be agnostic >>> to the lower layers and work exactly the same on top of 802.11p >> >> Romain - when you say 'the same', it means to me that 0x86DD is >> good to be the same over WiFi, over Ethernet, over 802.15.4... and >> over 802.11p - all IEEE links. In principle I agree with that. >> (it would however be different to non-IEEE links). >> >> The most oppinions I hear is that we should continue to use 0x86DD >> for IPv6-straight-over-80211p. To which I tend to agree. >> >> At the same time, I know it may be impossible for me in the place >> where I live to use IPv6-straight-over-80211p for V2V, because of >> frequency regulation. I dont think at IETF we could influence >> frequency regulation in some particular country. >> >> What to do to be able to use IPv6-straight-over-80211p? >> > In Europe, I think that you can't (please someone correct me if I'm > wrong). The 5 GHz band is reserved for CEN DSRC and ETSI ITS. And > ETSI ITS clearly states that IPv6 traffic is transported over the > ITS-G5 interface (11p) via the GeoNetworking protocol (by means of > the adaptation sublayer GN6ASL). Please check the references provided > by Thierry and the related ETSI standards. Yes, I am checking. >> What to do to be able to use it in a secure manner, (because it >> doesnt offer link-layer security, like WiFi does with WEP etc.)? >> > 802.11p does not offer link-layer security because stations operate > outside the context of a BSS. A possible approach? Delegate security > to upper layers. Ok, but which one? Should it be Neighbor Discovery security like SeND? Is it HTTPS? Another one? >>> That's the principle of the OSI layer separation! It should not >>> behave differently so there is no reason to have a new >>> Ethertype. >> >> Should not, ok, but it does behave differently than WiFi. For >> example it doesnt have link layer security. >> > And WiFi behaves differently than Ethernet... but that has nothing to > do. The purpose of EtherType is to identify the upper layer > protocol. Ok... >>>> But there are several differences between Ethernet (WiFi) and >>>> 802.11p. >>>> >>>> - 802.11p doesnt have security and doesnt have BSS. >>>> >>>> - In some regions, 802.11p is not allowed by local regulator >>>> for anything that is 'non-safety'. ('safety' means an >>>> application to avoid car crashes, for exemple). I.e. 802.11p >>>> is not allowed for IP. >>>> >>>> - In laboratory people easily set up IP-straight-over-IP, but >>>> that does not mean it is legal by regulator (in terms of >>>> allowed frequency range). In some such settings the EtherType >>>> is 0x0707 (instead of 0x86DD IPv6-over-Ethernet). >>>> >>>> There is a new EtherType for IP-over-ETSI-over-80211p ("Your >>>> Ethernet Type Field number is: #8947"), check attached email. >>>> But that is not IPv6-straight-over-80211p, it is >>>> IPv6-over-ETSI-over-80211P. >>> >>> GN is a different L3 protocol so it is normal to have a new >>> ethertype for it. >> >> But they also have defined IPv6-over-geonetworking-over-80211p (not >> only geonetworking-over-80211p): what EtherType should that use? >> The 0x86DD? Or that #8947? >> > The one for GeoNetworking, since IPv6 is 'hidden' from the link layer > perspective. I interpret GeoNetworking to be like other Adaptation layers inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 has this Adaptation layer which does fragmentation/reassembly. That makes it to be IPv6-over-AdaptationLayer-over-802154. But, I think that uses a single EtherType - 0x86DD, and not two. Whereas, with geonetworking as 'adaptation layer', if I am not wrong, we see two different EtherTypes: one for IPv6-over-geonetworking-over-80211p and another one for IPv6-over-80211p. Alex > > Best, fran > >> Alex >> >>> >>> Regards, Romain >>> >>>> For all these reasons, should there be a new EtherType for >>>> IP-straight-over-80211p? >>>> >>>> What happens if people assume that IPv6-straight-over-80211p >>>> is 0x86DD but implementations do 0x0707 (as some do today, in a >>>> wait for such an _agreed_ such new EtherType)? >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ its mailing >>>>> list its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>> >>>> >>> joint.eml>_______________________________________________ its >>>> mailing list its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >>> >>> >> >> >> _______________________________________________ its mailing list >> its@ietf.org https://www.ietf.org/mailman/listinfo/its > > -- Francisco J. Ros, PhD Dept. of Information and Communications > Engineering University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > > > From fjros@um.es Thu Mar 14 08:32:00 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA611E8223 for ; Thu, 14 Mar 2013 08:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 cTMNmxpfil55 for ; Thu, 14 Mar 2013 08:31:56 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5AF11E8225 for ; Thu, 14 Mar 2013 08:31:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 98A0F538DA; Thu, 14 Mar 2013 16:31:54 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tenQfmC0lepj; Thu, 14 Mar 2013 16:31:54 +0100 (CET) Received: from eduroam_um-230-184.inf.um.es (eduroam_um-230-184.inf.um.es [155.54.230.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon11.um.es (Postfix) with ESMTPSA id 082055393E; Thu, 14 Mar 2013 16:31:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-1-568339522 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <5141EA50.4010201@gmail.com> Date: Thu, 14 Mar 2013 16:31:52 +0100 Message-Id: <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:32:00 -0000 --Apple-Mail-1-568339522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alex, El 14/03/2013, a las 16:18, Alexandru Petrescu escribi=F3: > I interpret GeoNetworking to be like other Adaptation layers inserted > between IPv6 and the MAC. RFC4944 IPv6-over-802154 has this = Adaptation > layer which does fragmentation/reassembly. That makes it to be > IPv6-over-AdaptationLayer-over-802154. >=20 GeoNetworking is not an adaptation layer, it is a first class routing = protocol. GN6ASL is the adaptation layer on top of GeoNetworking in = order to present a virtual link to IPv6, possibly spanning multiple = physical links. > But, I think that uses a single EtherType - 0x86DD, and not two. >=20 > Whereas, with geonetworking as 'adaptation layer', if I am not wrong, = we > see two different EtherTypes: one for > IPv6-over-geonetworking-over-80211p and another one for = IPv6-over-80211p. >=20 They are different EtherTypes, since they carry a different (immediate) = upper layer protocol. Best, fran > Alex -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ --Apple-Mail-1-568339522 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I interpret = GeoNetworking to be like other Adaptation layers inserted
between = IPv6 and the MAC.  RFC4944 IPv6-over-802154 has this = Adaptation
layer which does fragmentation/reassembly.  That = makes it to = be
IPv6-over-AdaptationLayer-over-802154.

GeoNetworking is not an adaptation layer, it is a first class routing = protocol. GN6ASL is the adaptation layer on top of GeoNetworking in = order to present a virtual link to IPv6, possibly spanning multiple = physical links.
But, I think = that uses a single EtherType - 0x86DD, and not two.

Whereas, with = geonetworking as 'adaptation layer', if I am not wrong, we
see two = different EtherTypes: one for
IPv6-over-geonetworking-over-80211p and = another one for IPv6-over-80211p.

They = are different EtherTypes, since they carry a different (immediate) upper = layer = protocol.

Best,
fran

--
Francisco J. Ros, = PhD
Dept. of Information and Communications = Engineering
University of Murcia, Murcia (Spain)




= --Apple-Mail-1-568339522-- From abdussalambaryun@gmail.com Thu Mar 14 09:53: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 2048511E8106 for ; Thu, 14 Mar 2013 09:53:03 -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 iA79s0L+hS2a for ; Thu, 14 Mar 2013 09:52:57 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 043B111E8129 for ; Thu, 14 Mar 2013 09:52:56 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id wy12so2477120pbc.35 for ; Thu, 14 Mar 2013 09:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KbO3/eZUQo9M1DMnpJHpfQThuAZ348DEA+VUrjMPPMo=; b=BAU2KIf9vZLu9mpr8ySnSymPL7LxLOx9IBuu7pNufRwN9Nrt4vvqa7xDoFenMCGHcU UMaLEkBieYBDwr5eMywvFMNq/vdbsfBXF+rN2Mp5I5S56TBnonuXbsVybxNMk0RZ/b+z lrjhiYIpINrGyICNk/k76krVGzbzdjlUYVcGvlslzXGe1mJs3jOXzTLSJGogDX1Tdhl7 KSElS0v+3R8sBopcon/LCNJHWhmDFaSWwPQRD3g4M4evbP06ZZidGqwT5loWZwWbMMDr RxPGe9BOS/SzgMfQA6lZg22QNJv725+ob+Hux64hi+oaoIDurfUNl1oP7JA7UCci9vdt 35+w== MIME-Version: 1.0 X-Received: by 10.68.237.100 with SMTP id vb4mr7292128pbc.202.1363279976671; Thu, 14 Mar 2013 09:52:56 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Thu, 14 Mar 2013 09:52:56 -0700 (PDT) In-Reply-To: <55290.1363263108@olddog.co.uk> References: <55290.1363263108@olddog.co.uk> Date: Thu, 14 Mar 2013 17:52:56 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications -MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:53:03 -0000 I think v2v can be motivated for many WGs, I think MANET WG should consider to focus its charter or motivations, because MANET covers also LLNs as it was already discussed and MANET WG participants don't want to let go of any application specific even though they are considering general specific. AB On 3/14/13, Adrian Farrel wrote: > I think that Alex and Abdussalam are right to distinguish the two use-cases > of v2v and routed. > > Of course, that distinction only exists if v2v is a direct media link, > rather than routed through a > network of street architecture. Similarly, v2v is only different if it is > not simply an extension > of intra-vehicle networking. > > Wrt routed (v2v2v2v2v) networking, it really should be observed that this > was one of prime > motivating factors for MANET, and handling that environment would need to be > discussed with MANET > before it appears on any future ITS charter. > > Adrian > > On Thu 14/03/13 11:29 AM , "Abdussalam Baryun" abdussalambaryun@gmail.com > sent: >> Hi Alex, >> >> I don't think MANET WG has considered the use-case of ITS WG as we >> stated in our charter, and I don't think they will recharter either >> because they still not completed the two standards required for them >> (I am an active participant in MANET WG). This MANET WG still not >> defined its subnets, which is important for ITS WG and I tried with >> that WG, but they want to postpone, or they think it is dangerous (as >> they mentioned twice). >> >> IMHO, the ITS should consider 1-hop and n-hops data-transports, but >> for different purposes from other IETF-WGs. For example in RFC6130 >> protocols the 1-hop and 2-hop of nieghbors is considered for route >> discovery. I think in the ITS we may include transport-service >> discovery of nieghbors. In MANET the routing n-hops are all >> infrastructure-less but in ITS may involve both. In MANET-WG routings >> always assumes that all Router Machines (i.e. as we are taliking M2M) >> have the same MANET-routing protocol, in ITS-WG we need to assume that >> all Router Machines have the proposed ITS protocol. >> >> In addition, to make the steps simple in works we may start with the >> 1-hop for infrastructure and 1-hop for infrastructureless, but then we >> make n-hop. Alex, I would like to know your opinion as well, >> >> Abdussalam Baryun >> university of Glamorgan, UK >> >> On 3/13/13, Alexandru Petrescu < >> alexandru.petrescu@gmail.com> wrote:> Hello ITS participants, >> > >> > While working on Charter Proposal we are >> distinguishing between 1-hop> V2V communications (a single subnet between >> several vehicles), and n-hop> communications >> (vehicle-to-vehicle-to-vehicle, >> each time a different> subnet between vehicles). >> > >> > I would like to ask participants whether there >> is interest in n-hop> routing protocols for vehicular >> communications.> >> > Is work needed on MANET protocols for >> this?> >> > Are there special requirements for this? (i.e. a >> case where a MANET> protocol is not sufficient for n-hop vehicular >> communications).> >> > 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 alexandru.petrescu@gmail.com Thu Mar 14 10:10:25 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 C0AFA11E8174 for ; Thu, 14 Mar 2013 10:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.112 X-Spam-Level: X-Spam-Status: No, score=-9.112 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 KUwt1-Tne6oH for ; Thu, 14 Mar 2013 10:10:21 -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 E307411E8126 for ; Thu, 14 Mar 2013 10:10:19 -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 r2EHAIZO015548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 18:10:18 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EHAI5D030259; Thu, 14 Mar 2013 18:10:18 +0100 (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 r2EHA1d3012882; Thu, 14 Mar 2013 18:10:12 +0100 Message-ID: <5142044A.3000608@gmail.com> Date: Thu, 14 Mar 2013 18:09:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> In-Reply-To: <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:10:25 -0000 Fran, Thank you for the explanation that I kind of understand. I will continue to discuss about this, to adapt our terminology. Le 14/03/2013 16:31, Francisco Javier Ros Muñoz a écrit : > Alex, > > El 14/03/2013, a las 16:18, Alexandru Petrescu escribió: >> I interpret GeoNetworking to be like other Adaptation layers >> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 has >> this Adaptation layer which does fragmentation/reassembly. That >> makes it to be IPv6-over-AdaptationLayer-over-802154. >> > GeoNetworking is not an adaptation layer, it is a first class routing > protocol. I think we may need to adapt our terminology in order to understand each other. A routing protocol typically acts at IP and above (RIP, OSPF, RPL, AODV, OLSR - all are above IP). It's strange to see that GeoNetworking is routing protocol but is below IP. That would rather be a 'bridging protocol'? (bridging protocols are often as complex as routing protocols, just they're below IP). > GN6ASL is the adaptation layer on top of GeoNetworking in order to > present a virtual link to IPv6, possibly spanning multiple physical > links. Ah! So we talk adaptation layer, geonetworking, and only then IP... >> But, I think that uses a single EtherType - 0x86DD, and not two. >> >> Whereas, with geonetworking as 'adaptation layer', if I am not >> wrong, we see two different EtherTypes: one for >> IPv6-over-geonetworking-over-80211p and another one for >> IPv6-over-80211p. >> > They are different EtherTypes, since they carry a different > (immediate) upper layer protocol. Ok, so if GeoNetworking is much more than just an simple adaptation layer (like the frag/reass adaptation layer of IP-over-802154) then maybe this is why there are two different EtherTypes (one for pure IPv6 and one for IPv6-over-geonetworking). Alex > Best, fran > >> Alex > > -- Francisco J. Ros, PhD Dept. of Information and Communications > Engineering University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > From fjros@um.es Thu Mar 14 10:25: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 19E3921F910A for ; Thu, 14 Mar 2013 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 TVj9urNrPuOE for ; Thu, 14 Mar 2013 10:25:52 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBBB21F9109 for ; Thu, 14 Mar 2013 10:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 2DA4E538DC; Thu, 14 Mar 2013 18:25:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1jzR9sgNqFpD; Thu, 14 Mar 2013 18:25:46 +0100 (CET) Received: from eduroam_um-230-184.inf.um.es (eduroam_um-230-184.inf.um.es [155.54.230.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon11.um.es (Postfix) with ESMTPSA id 33BAE53958; Thu, 14 Mar 2013 18:25:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <5142044A.3000608@gmail.com> Date: Thu, 14 Mar 2013 18:25:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> <5142044A.3000608@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:25:53 -0000 Hi again, El 14/03/2013, a las 18:09, Alexandru Petrescu escribi=F3: > Fran, >=20 > Thank you for the explanation that I kind of understand. >=20 > I will continue to discuss about this, to adapt our terminology. >=20 > Le 14/03/2013 16:31, Francisco Javier Ros Mu=F1oz a =E9crit : >> Alex, >>=20 >> El 14/03/2013, a las 16:18, Alexandru Petrescu escribi=F3: >>> I interpret GeoNetworking to be like other Adaptation layers >>> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 has >>> this Adaptation layer which does fragmentation/reassembly. That >>> makes it to be IPv6-over-AdaptationLayer-over-802154. >>>=20 >> GeoNetworking is not an adaptation layer, it is a first class routing >> protocol. >=20 > I think we may need to adapt our terminology in order to understand = each > other. >=20 > A routing protocol typically acts at IP and above (RIP, OSPF, RPL, = AODV, > OLSR - all are above IP). >=20 > It's strange to see that GeoNetworking is routing protocol but is = below > IP. Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a = network layer protocol, just as IP is. GN is not intended to be = transported over IP, but over ITS-G5. Therefore, GN is not intended to = compute a routing table for IP. On the contrary, GN is able to transport = IPv6 datagrams thanks to the adaptation layer GN6ASL. Hopefully this makes things clearer :-) > That would rather be a 'bridging protocol'? (bridging protocols are > often as complex as routing protocols, just they're below IP). >=20 >> GN6ASL is the adaptation layer on top of GeoNetworking in order to >> present a virtual link to IPv6, possibly spanning multiple physical >> links. >=20 > Ah! So we talk adaptation layer, geonetworking, and only then IP... >=20 The protocol stack would look like this: [ App - Transport - IPv6 - = GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ App - Transport - IPv6 - = GN - ITS-G5 ] Regards, fran >>> But, I think that uses a single EtherType - 0x86DD, and not two. >>>=20 >>> Whereas, with geonetworking as 'adaptation layer', if I am not >>> wrong, we see two different EtherTypes: one for >>> IPv6-over-geonetworking-over-80211p and another one for >>> IPv6-over-80211p. >>>=20 >> They are different EtherTypes, since they carry a different >> (immediate) upper layer protocol. >=20 > Ok, so if GeoNetworking is much more than just an simple adaptation > layer (like the frag/reass adaptation layer of IP-over-802154) then > maybe this is why there are two different EtherTypes (one for pure = IPv6 > and one for IPv6-over-geonetworking). >=20 > Alex >=20 >> Best, fran >>=20 >>> Alex >>=20 >> -- Francisco J. Ros, PhD Dept. of Information and Communications >> Engineering University of Murcia, Murcia (Spain) >> http://masimum.inf.um.es/fjrm/ >>=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From alexandru.petrescu@gmail.com Thu Mar 14 11:39:16 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD021F910A for ; Thu, 14 Mar 2013 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 1h0suRmBGNpY for ; Thu, 14 Mar 2013 11:39:15 -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 175E321F8EA7 for ; Thu, 14 Mar 2013 11:39:14 -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 r2EIdDXJ017023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 19:39:13 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EIdDXQ016073; Thu, 14 Mar 2013 19:39:13 +0100 (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 r2EId9sC011276; Thu, 14 Mar 2013 19:39:12 +0100 Message-ID: <51421930.7040308@gmail.com> Date: Thu, 14 Mar 2013 19:38:40 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> <5142044A.3000608@gmail.com> <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> In-Reply-To: <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:39:16 -0000 Le 14/03/2013 18:25, Francisco Javier Ros Muñoz a écrit : > Hi again, > > El 14/03/2013, a las 18:09, Alexandru Petrescu escribió: > >> Fran, >> >> Thank you for the explanation that I kind of understand. >> >> I will continue to discuss about this, to adapt our terminology. >> >> Le 14/03/2013 16:31, Francisco Javier Ros Muñoz a écrit : >>> Alex, >>> >>> El 14/03/2013, a las 16:18, Alexandru Petrescu escribió: >>>> I interpret GeoNetworking to be like other Adaptation layers >>>> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 >>>> has this Adaptation layer which does fragmentation/reassembly. >>>> That makes it to be IPv6-over-AdaptationLayer-over-802154. >>>> >>> GeoNetworking is not an adaptation layer, it is a first class >>> routing protocol. >> >> I think we may need to adapt our terminology in order to >> understand each other. >> >> A routing protocol typically acts at IP and above (RIP, OSPF, RPL, >> AODV, OLSR - all are above IP). >> >> It's strange to see that GeoNetworking is routing protocol but is >> below IP. > > Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a > network layer protocol, just as IP is. GN is not intended to be > transported over IP, but over ITS-G5. Therefore, GN is not intended > to compute a routing table for IP. On the contrary, GN is able to > transport IPv6 datagrams thanks to the adaptation layer GN6ASL. > Hopefully this makes things clearer :-) Yes, it is clearer. It also looks as if GeoNetworking is of sort of Layer-3 protocol. Something like IP-in-IP encapsulation where the first IP is GeoNetworking. >> That would rather be a 'bridging protocol'? (bridging protocols are >> often as complex as routing protocols, just they're below IP). >> >>> GN6ASL is the adaptation layer on top of GeoNetworking in order >>> to present a virtual link to IPv6, possibly spanning multiple >>> physical links. >> >> Ah! So we talk adaptation layer, geonetworking, and only then >> IP... >> > The protocol stack would look like this: [ App - Transport - IPv6 - > GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ > App - Transport - IPv6 - GN - ITS-G5 ] A-ha... do you know whether there is a wireshark protocol dissector for [ App - Transport - IPv6 - GN - ITS-G5 ] Can I see this in Wireshark? (wireshark is an open-source packet analyzer tool which contains a large number of protocol intepreters). Yours, Alex > > Regards, fran > >>>> But, I think that uses a single EtherType - 0x86DD, and not >>>> two. >>>> >>>> Whereas, with geonetworking as 'adaptation layer', if I am not >>>> wrong, we see two different EtherTypes: one for >>>> IPv6-over-geonetworking-over-80211p and another one for >>>> IPv6-over-80211p. >>>> >>> They are different EtherTypes, since they carry a different >>> (immediate) upper layer protocol. >> >> Ok, so if GeoNetworking is much more than just an simple adaptation >> layer (like the frag/reass adaptation layer of IP-over-802154) then >> maybe this is why there are two different EtherTypes (one for pure >> IPv6 and one for IPv6-over-geonetworking). >> >> Alex >> >>> Best, fran >>> >>>> Alex >>> >>> -- 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 > > -- Francisco J. Ros, PhD Dept. of Information and Communications > Engineering University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > > > From jonghyouk@gmail.com Thu Mar 14 12:07:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2269611E8194 for ; Thu, 14 Mar 2013 12:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, 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 IL2AAH6grnjF for ; Thu, 14 Mar 2013 12:07:56 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id E05A511E80F2 for ; Thu, 14 Mar 2013 12:07:55 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf10so675677vcb.29 for ; Thu, 14 Mar 2013 12:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uovkGoehiVA+BFjPfmv7r7vwGdROko+ouhPcrjjW/7A=; b=1KAkusKFJaue4BGJip72PBq2cL7nvRyVpv6ZVHw3T/YYDYpmh3DKXwJB6FpsZyLvSp 20UUawphMZDe7lx4jyh/FzVOhx0WKVoPfKEX4nUGV8wv88qcen8e/i1NoY/GBw1RsxBy oEhqHTN+ilPrX9jsJ4HHhF6Etp03/u7xHVxAUPwKvjxWoZT1/F1OHAahgmtWLwpOSy7d j0+TZS5EcI7/mYzevKqMFyvC6GmlIaQn4Z6mFCpktajtxMYyYcjVkT+kHe/MX3jM1GMF rY2e5OYd0yhSGqfijREQVgyMN1vSnbAx0zzx0lHoAbwTyFqlJQFsFHofRmWTKuP8dght c9OQ== MIME-Version: 1.0 X-Received: by 10.52.94.17 with SMTP id cy17mr2874936vdb.68.1363288075398; Thu, 14 Mar 2013 12:07:55 -0700 (PDT) Received: by 10.59.4.1 with HTTP; Thu, 14 Mar 2013 12:07:55 -0700 (PDT) In-Reply-To: <51421930.7040308@gmail.com> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> <5142044A.3000608@gmail.com> <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> <51421930.7040308@gmail.com> Date: Thu, 14 Mar 2013 15:07:55 -0400 Message-ID: From: Jong-Hyouk Lee To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf307f337875f8d104d7e73d1b Cc: Romain KUNTZ , its@ietf.org, =?UTF-8?Q?Francisco_Javier_Ros_Mu=C3=B1oz?= Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:07:57 -0000 --20cf307f337875f8d104d7e73d1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hummm, I remember that a Geonetworking extension to Wireshark was developed and reported at the ETSI ITS TC list. On Thu, Mar 14, 2013 at 2:38 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 14/03/2013 18:25, Francisco Javier Ros Mu=C3=B1oz a =C3=A9crit : > > Hi again, >> >> El 14/03/2013, a las 18:09, Alexandru Petrescu escribi=C3=B3: >> >> Fran, >>> >>> Thank you for the explanation that I kind of understand. >>> >>> I will continue to discuss about this, to adapt our terminology. >>> >>> Le 14/03/2013 16:31, Francisco Javier Ros Mu=C3=B1oz a =C3=A9crit : >>> >>>> Alex, >>>> >>>> El 14/03/2013, a las 16:18, Alexandru Petrescu escribi=C3=B3: >>>> >>>>> I interpret GeoNetworking to be like other Adaptation layers >>>>> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 >>>>> has this Adaptation layer which does fragmentation/reassembly. >>>>> That makes it to be IPv6-over-AdaptationLayer-**over-802154. >>>>> >>>>> GeoNetworking is not an adaptation layer, it is a first class >>>> routing protocol. >>>> >>> >>> I think we may need to adapt our terminology in order to >>> understand each other. >>> >>> A routing protocol typically acts at IP and above (RIP, OSPF, RPL, >>> AODV, OLSR - all are above IP). >>> >>> It's strange to see that GeoNetworking is routing protocol but is >>> below IP. >>> >> >> Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a >> network layer protocol, just as IP is. GN is not intended to be >> transported over IP, but over ITS-G5. Therefore, GN is not intended >> to compute a routing table for IP. On the contrary, GN is able to >> transport IPv6 datagrams thanks to the adaptation layer GN6ASL. >> Hopefully this makes things clearer :-) >> > > Yes, it is clearer. > > It also looks as if GeoNetworking is of sort of Layer-3 protocol. > > Something like IP-in-IP encapsulation where the first IP is GeoNetworking= . > > > That would rather be a 'bridging protocol'? (bridging protocols are >>> often as complex as routing protocols, just they're below IP). >>> >>> GN6ASL is the adaptation layer on top of GeoNetworking in order >>>> to present a virtual link to IPv6, possibly spanning multiple >>>> physical links. >>>> >>> >>> Ah! So we talk adaptation layer, geonetworking, and only then >>> IP... >>> >>> The protocol stack would look like this: [ App - Transport - IPv6 - >> GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ >> App - Transport - IPv6 - GN - ITS-G5 ] >> > > A-ha... do you know whether there is a wireshark protocol dissector for > > > [ App - Transport - IPv6 - GN - ITS-G5 ] > > Can I see this in Wireshark? (wireshark is an open-source packet > analyzer tool which contains a large number of protocol intepreters). > > Yours, > > Alex > > > >> Regards, fran >> >> But, I think that uses a single EtherType - 0x86DD, and not >>>>> two. >>>>> >>>>> Whereas, with geonetworking as 'adaptation layer', if I am not >>>>> wrong, we see two different EtherTypes: one for >>>>> IPv6-over-geonetworking-over-**80211p and another one for >>>>> IPv6-over-80211p. >>>>> >>>>> They are different EtherTypes, since they carry a different >>>> (immediate) upper layer protocol. >>>> >>> >>> Ok, so if GeoNetworking is much more than just an simple adaptation >>> layer (like the frag/reass adaptation layer of IP-over-802154) then >>> maybe this is why there are two different EtherTypes (one for pure >>> IPv6 and one for IPv6-over-geonetworking). >>> >>> Alex >>> >>> Best, fran >>>> >>>> Alex >>>>> >>>> >>>> -- 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 >>> >> >> -- 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 > --=20 RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --20cf307f337875f8d104d7e73d1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hummm, I remember that a Geonetworking extension to=C2=A0Wireshark was deve= loped and reported at the ETSI ITS TC list.

On Thu, Mar 14, 2013 at 2:38 PM, Alexandru Petrescu &l= t;alexand= ru.petrescu@gmail.com> wrote:
Le 14/03/2013 18:25, Francisco Javier Ros Mu= =C3=B1oz a =C3=A9crit :

Hi again,

El 14/03/2013, a las 18:09, Alexandru Petrescu escribi=C3=B3:

Fran,

Thank you for the explanation that I kind of understand.

I will continue to discuss about this, to adapt our terminology.

Le 14/03/2013 16:31, Francisco Javier Ros Mu=C3=B1oz a =C3=A9crit :
Alex,

El 14/03/2013, a las 16:18, Alexandru Petrescu escribi=C3=B3: <snip><= br>
I interpret GeoNetworking to be like other Adaptation layers
inserted between IPv6 and the MAC. =C2=A0RFC4944 IPv6-over-802154
has this Adaptation layer which does fragmentation/reassembly.
That makes it to be IPv6-over-AdaptationLayer-over-802154.

GeoNetworking is not an adaptation layer, it is a first class
routing protocol.

I think we may need to adapt our terminology in order to
understand each other.

A routing protocol typically acts at IP and above (RIP, OSPF, RPL,
AODV, OLSR - all are above IP).

It's strange to see that GeoNetworking is routing protocol but is
below IP.

Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a network layer protocol, just as IP is. GN is not intended to be
transported over IP, but over ITS-G5. Therefore, GN is not intended
to compute a routing table for IP. On the contrary, GN is able to
transport IPv6 datagrams thanks to the adaptation layer GN6ASL.
Hopefully this makes things clearer :-)

Yes, it is clearer.

It also looks as if GeoNetworking is of sort of Layer-3 protocol.

Something like IP-in-IP encapsulation where the first IP is GeoNetworking.<= div class=3D"im">

That would rather be a 'bridging protocol'? (bridging protocols are=
often as complex as routing protocols, just they're below IP).

GN6ASL is the adaptation layer on top of GeoNetworking in order
to present a virtual link to IPv6, possibly spanning multiple
physical links.

Ah! =C2=A0So we talk adaptation layer, geonetworking, and only then
IP...

The protocol stack would look like this: [ App - Transport - IPv6 -
GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ App - Transport - IPv6 - GN - ITS-G5 ]

A-ha... do you know whether there is a wireshark protocol dissector for

[ App - Transport - IPv6 - GN - ITS-G5 ]

Can I see this in Wireshark? (wireshark is an open-source packet
analyzer tool which contains a large number of protocol intepreters).

Yours,

Alex



Regards, fran

But, I think that uses a single EtherType - 0x86DD, and not
two.

Whereas, with geonetworking as 'adaptation layer', if I am not
=C2=A0wrong, we see two different EtherTypes: one for
IPv6-over-geonetworking-over-80211p and another one for
IPv6-over-80211p.

They are different EtherTypes, since they carry a different
(immediate) upper layer protocol.

Ok, so if GeoNetworking is much more than just an simple adaptation
layer (like the frag/reass adaptation layer of IP-over-802154) then
maybe this is why there are two different EtherTypes (one for pure
IPv6 and one for IPv6-over-geonetworking).

Alex

Best, fran

Alex

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






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

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








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



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com
--20cf307f337875f8d104d7e73d1b-- From fjros@um.es Thu Mar 14 12:47: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 B4A3611E8231 for ; Thu, 14 Mar 2013 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 fQ9rCbOpQzzT for ; Thu, 14 Mar 2013 12:47:26 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8589411E8239 for ; Thu, 14 Mar 2013 12:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 5D57053954; Thu, 14 Mar 2013 20:47:15 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qj6im4dx3sge; Thu, 14 Mar 2013 20:47:14 +0100 (CET) Received: from [192.168.1.3] (79.109.154.227.dyn.user.ono.com [79.109.154.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fjros) by xenon11.um.es (Postfix) with ESMTPSA id 2062F53918; Thu, 14 Mar 2013 20:47:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= In-Reply-To: <51421930.7040308@gmail.com> Date: Thu, 14 Mar 2013 20:47:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09B7EDD6-AE86-4912-B733-BBBC36733224@um.es> References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> <5142044A.3000608@gmail.com> <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> <51421930.7040308@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1085) Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:47:27 -0000 El 14/03/2013, a las 19:38, Alexandru Petrescu escribi=F3: > Le 14/03/2013 18:25, Francisco Javier Ros Mu=F1oz a =E9crit : >> Hi again, >>=20 >> El 14/03/2013, a las 18:09, Alexandru Petrescu escribi=F3: >>=20 >>> Fran, >>>=20 >>> Thank you for the explanation that I kind of understand. >>>=20 >>> I will continue to discuss about this, to adapt our terminology. >>>=20 >>> Le 14/03/2013 16:31, Francisco Javier Ros Mu=F1oz a =E9crit : >>>> Alex, >>>>=20 >>>> El 14/03/2013, a las 16:18, Alexandru Petrescu escribi=F3: >>>>> I interpret GeoNetworking to be like other Adaptation layers >>>>> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 >>>>> has this Adaptation layer which does fragmentation/reassembly. >>>>> That makes it to be IPv6-over-AdaptationLayer-over-802154. >>>>>=20 >>>> GeoNetworking is not an adaptation layer, it is a first class >>>> routing protocol. >>>=20 >>> I think we may need to adapt our terminology in order to >>> understand each other. >>>=20 >>> A routing protocol typically acts at IP and above (RIP, OSPF, RPL, >>> AODV, OLSR - all are above IP). >>>=20 >>> It's strange to see that GeoNetworking is routing protocol but is >>> below IP. >>=20 >> Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a >> network layer protocol, just as IP is. GN is not intended to be >> transported over IP, but over ITS-G5. Therefore, GN is not intended >> to compute a routing table for IP. On the contrary, GN is able to >> transport IPv6 datagrams thanks to the adaptation layer GN6ASL. >> Hopefully this makes things clearer :-) >=20 > Yes, it is clearer. >=20 > It also looks as if GeoNetworking is of sort of Layer-3 protocol. >=20 Absolutely. That's what I meant with 'network layer protocol'. > Something like IP-in-IP encapsulation where the first IP is = GeoNetworking. >=20 >>> That would rather be a 'bridging protocol'? (bridging protocols are >>> often as complex as routing protocols, just they're below IP). >>>=20 >>>> GN6ASL is the adaptation layer on top of GeoNetworking in order >>>> to present a virtual link to IPv6, possibly spanning multiple >>>> physical links. >>>=20 >>> Ah! So we talk adaptation layer, geonetworking, and only then >>> IP... >>>=20 >> The protocol stack would look like this: [ App - Transport - IPv6 - >> GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ >> App - Transport - IPv6 - GN - ITS-G5 ] >=20 > A-ha... do you know whether there is a wireshark protocol dissector = for >=20 > [ App - Transport - IPv6 - GN - ITS-G5 ] >=20 I have never used them, but you can find several dissectors for ETSI ITS = in the following link: http://www.amb-consulting.com/en/#downloads Regards, fran > Can I see this in Wireshark? (wireshark is an open-source packet > analyzer tool which contains a large number of protocol intepreters). >=20 > Yours, >=20 > Alex >=20 >>=20 >> Regards, fran >>=20 >>>>> But, I think that uses a single EtherType - 0x86DD, and not >>>>> two. >>>>>=20 >>>>> Whereas, with geonetworking as 'adaptation layer', if I am not >>>>> wrong, we see two different EtherTypes: one for >>>>> IPv6-over-geonetworking-over-80211p and another one for >>>>> IPv6-over-80211p. >>>>>=20 >>>> They are different EtherTypes, since they carry a different >>>> (immediate) upper layer protocol. >>>=20 >>> Ok, so if GeoNetworking is much more than just an simple adaptation >>> layer (like the frag/reass adaptation layer of IP-over-802154) then >>> maybe this is why there are two different EtherTypes (one for pure >>> IPv6 and one for IPv6-over-geonetworking). >>>=20 >>> Alex >>>=20 >>>> Best, fran >>>>=20 >>>>> Alex >>>>=20 >>>> -- Francisco J. Ros, PhD Dept. of Information and Communications >>>> Engineering University of Murcia, Murcia (Spain) >>>> http://masimum.inf.um.es/fjrm/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ its mailing list >>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>=20 >> -- Francisco J. Ros, PhD Dept. of Information and Communications >> Engineering University of Murcia, Murcia (Spain) >> http://masimum.inf.um.es/fjrm/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 -- Francisco J. Ros, PhD Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ From alexandru.petrescu@gmail.com Thu Mar 14 13:10:20 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDF611E8103 for ; Thu, 14 Mar 2013 13:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.556 X-Spam-Level: X-Spam-Status: No, score=-9.556 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.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 BWpVJL31Yzbx for ; Thu, 14 Mar 2013 13:10:19 -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 999A411E8146 for ; Thu, 14 Mar 2013 13:10:18 -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 r2EKAAsf023838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Mar 2013 21:10:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2EKAA0b028261; Thu, 14 Mar 2013 21:10:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.3]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2EKA7jf028064; Thu, 14 Mar 2013 21:10:09 +0100 Message-ID: <51422E81.8080702@gmail.com> Date: Thu, 14 Mar 2013 21:09:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Francisco_Javier_Ros_Mu=F1oz?= References: <513B2079.7060104@gmail.com> <513F936C.1010408@gmail.com> <19858.1363216981@sandelman.ca> <51410F07.7030407@gmail.com> <95995C66-C630-43D7-A2C2-FE4411D68E47@gmail.com> <5141C9C5.6030308@gmail.com> <5141EA50.4010201@gmail.com> <9778F375-F28F-415F-B1B7-ABE6D32E9DCE@um.es> <5142044A.3000608@gmail.com> <549EEDB7-5892-411E-91A5-5FD14D57297A@um.es> <51421930.7040308@gmail.com> <09B7EDD6-AE86-4912-B733-BBBC36733224@um.es> In-Reply-To: <09B7EDD6-AE86-4912-B733-BBBC36733224@um.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Romain KUNTZ , its@ietf.org Subject: Re: [its] what happened X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:10:20 -0000 Le 14/03/2013 20:47, Francisco Javier Ros Muñoz a écrit : > El 14/03/2013, a las 19:38, Alexandru Petrescu escribió: > >> Le 14/03/2013 18:25, Francisco Javier Ros Muñoz a écrit : >>> Hi again, >>> >>> El 14/03/2013, a las 18:09, Alexandru Petrescu escribió: >>> >>>> Fran, >>>> >>>> Thank you for the explanation that I kind of understand. >>>> >>>> I will continue to discuss about this, to adapt our terminology. >>>> >>>> Le 14/03/2013 16:31, Francisco Javier Ros Muñoz a écrit : >>>>> Alex, >>>>> >>>>> El 14/03/2013, a las 16:18, Alexandru Petrescu escribió: >>>>>> I interpret GeoNetworking to be like other Adaptation layers >>>>>> inserted between IPv6 and the MAC. RFC4944 IPv6-over-802154 >>>>>> has this Adaptation layer which does fragmentation/reassembly. >>>>>> That makes it to be IPv6-over-AdaptationLayer-over-802154. >>>>>> >>>>> GeoNetworking is not an adaptation layer, it is a first class >>>>> routing protocol. >>>> >>>> I think we may need to adapt our terminology in order to >>>> understand each other. >>>> >>>> A routing protocol typically acts at IP and above (RIP, OSPF, RPL, >>>> AODV, OLSR - all are above IP). >>>> >>>> It's strange to see that GeoNetworking is routing protocol but is >>>> below IP. >>> >>> Ok, I see what you mean. Then let's say that GeoNetworking (GN) is a >>> network layer protocol, just as IP is. GN is not intended to be >>> transported over IP, but over ITS-G5. Therefore, GN is not intended >>> to compute a routing table for IP. On the contrary, GN is able to >>> transport IPv6 datagrams thanks to the adaptation layer GN6ASL. >>> Hopefully this makes things clearer :-) >> >> Yes, it is clearer. >> >> It also looks as if GeoNetworking is of sort of Layer-3 protocol. >> > Absolutely. That's what I meant with 'network layer protocol'. > >> Something like IP-in-IP encapsulation where the first IP is GeoNetworking. >> >>>> That would rather be a 'bridging protocol'? (bridging protocols are >>>> often as complex as routing protocols, just they're below IP). >>>> >>>>> GN6ASL is the adaptation layer on top of GeoNetworking in order >>>>> to present a virtual link to IPv6, possibly spanning multiple >>>>> physical links. >>>> >>>> Ah! So we talk adaptation layer, geonetworking, and only then >>>> IP... >>>> >>> The protocol stack would look like this: [ App - Transport - IPv6 - >>> GN6ASL - GN - ITS-G5 ] Regarding protocol headers, you'd get this: [ >>> App - Transport - IPv6 - GN - ITS-G5 ] >> >> A-ha... do you know whether there is a wireshark protocol dissector for >> >> [ App - Transport - IPv6 - GN - ITS-G5 ] >> > I have never used them, but you can find several dissectors for ETSI ITS in the following link: > http://www.amb-consulting.com/en/#downloads Ok, we'll look at that, thanks. Alex > > Regards, > fran > >> Can I see this in Wireshark? (wireshark is an open-source packet >> analyzer tool which contains a large number of protocol intepreters). >> >> Yours, >> >> Alex >> >>> >>> Regards, fran >>> >>>>>> But, I think that uses a single EtherType - 0x86DD, and not >>>>>> two. >>>>>> >>>>>> Whereas, with geonetworking as 'adaptation layer', if I am not >>>>>> wrong, we see two different EtherTypes: one for >>>>>> IPv6-over-geonetworking-over-80211p and another one for >>>>>> IPv6-over-80211p. >>>>>> >>>>> They are different EtherTypes, since they carry a different >>>>> (immediate) upper layer protocol. >>>> >>>> Ok, so if GeoNetworking is much more than just an simple adaptation >>>> layer (like the frag/reass adaptation layer of IP-over-802154) then >>>> maybe this is why there are two different EtherTypes (one for pure >>>> IPv6 and one for IPv6-over-geonetworking). >>>> >>>> Alex >>>> >>>>> Best, fran >>>>> >>>>>> Alex >>>>> >>>>> -- 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 >>> >>> -- Francisco J. Ros, PhD Dept. of Information and Communications >>> Engineering University of Murcia, Murcia (Spain) >>> http://masimum.inf.um.es/fjrm/ >>> >>> >>> >>> >>> >>> >> >> > > -- > Francisco J. Ros, PhD > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > http://masimum.inf.um.es/fjrm/ > > > > > > From jvasseur@cisco.com Fri Mar 15 11:03:30 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA8821F8945 for ; Fri, 15 Mar 2013 11:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 6+yWroQC5+vX for ; Fri, 15 Mar 2013 11:03:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A4DE821F88E3 for ; Fri, 15 Mar 2013 11:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9392; q=dns/txt; s=iport; t=1363370608; x=1364580208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qsi2vJMEad2IJDCy0+XsRXBwbanVCkohcuWYVhnHyzg=; b=ac/ddifr2D7j9N1LYsL+1z1jFaCIp6hBsFzjw/YgBkQBDmig/btHiCJZ lAV6xOWczHKYRljnUxCv9RrjIwoWjjqmTVtD7dIjes949LA6zxxHzrxMS QhRN4ZOqaBBRzYfJt6g5uiOp5TGPdSXmyUH4i+SolzDQvqnrpS5WLwl/a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANhhQ1GtJV2Z/2dsb2JhbABDDrN9kRWBZxZ0gioBAQEDAQEBAWsLBQcEAgEIEQMBAQEBCh0HIQYLFAkIAgQOBQgTh2cDCQYMuVINiVcEjEyCFgImCwcGgllhA4g/jDyNSIUagks/gig X-IronPort-AV: E=Sophos;i="4.84,853,1355097600"; d="scan'208";a="188034037" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Mar 2013 18:03:28 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2FI3Rqh019353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 18:03:27 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 13:03:27 -0500 From: "JP Vasseur (jvasseur)" To: "" Thread-Topic: [its] simultaneous use o fmultiple radios or not Thread-Index: AQHOIadkYkqfyQK4pE+1JKhU+jRBYg== Date: Fri, 15 Mar 2013 18:03:27 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost><51409FFF.2010309@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1004FEA9@xmb-aln-x03.cisco.com> <20BDCA7BA42F448A834B973FCDE58B04@SRA4> In-Reply-To: <20BDCA7BA42F448A834B973FCDE58B04@SRA4> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.237] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Mar 2013 11:04:52 -0700 Cc: Rex Buddenberg , Alexandru Petrescu , "" , Joe Macker , "Stan Ratliff \(sratliff\)" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:03:30 -0000 Hi, This is clearly a working intersecting two WG: MANET for sure, and ROLL for= routing, since RPL has been used for car to car communication.=20 Cheers. JP. On Mar 13, 2013, at 9:19 PM, Richard Roy wrote: > Definitely plan for multiple simultaneous radio links. Whether or not a > particular ITS station (ITS terminology for a (possibly mobile) network > node) can support such simultaneous transmission will be assessed by ITS > station management, and if for some reason the radio modules interfere wi= th > each other on Tx, simultaneous Tx from both will be prohibited. However, > this is not something that concerns the network layer protocols directly = and > for the purposes of this effort, I suggest you just assume simultaneous T= x. > ITS stations assume multiple flows (to the same or different app processe= s) > and ITS station management manages the communication resources in realtim= e. > The issue is getting the back end networking protocols to set up and supp= ort > these flows. >=20 > RR >=20 >> -----Original Message----- >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >> Sent: Wednesday, March 13, 2013 9:15 AM >> To: Alexandru Petrescu; Joe Macker; JP Vasseur (jvasseur) >> Cc: Rex Buddenberg; its@ietf.org; Ivancic, William D. (GRC-RHN0) >> Subject: Re: [its] simultaneous use o fmultiple radios or not >>=20 >> Alex, >>=20 >> This describes almost exactly the deployments I've worked with. It is ye= t >> another reason I say that starting a new working group for the ITS effor= t >> is over-kill. Please don't get me wrong - this is interesting work, and >> should be addressed. However, it needs to be done (IMO) within the >> auspices of the MANET working group. Possibly ROLL, but I'm thinking MAN= ET >> is a better fit. >>=20 >> Regards, >> Stan >>=20 >> On Mar 13, 2013, at 11:49 AM, Alexandru Petrescu wrote: >>=20 >>> Ok, >>>=20 >>> So we talk radios as egress interfaces. I.e. have several egress >>> interfaces on a Mobile Router (gateway in the vehicle). When one of th= e >>> radio fails, the MR uses another one, such that the Internet is always >>> available to vehicle. >>>=20 >>> This sounds reasonable. >>>=20 >>> It is for me a sort of architectural requirement, to be strongly kept i= n >>> mind, for designing any new protocol. >>>=20 >>> Le 12/03/2013 23:22, Rex Buddenberg a =E9crit : >>>> Alex, >>>>=20 >>>> Your numbers are essentially correct -- radio links are about 10-4 >>>> smaller sized than wired ones. >>>>=20 >>>> But a more powerful argument for multiple interfaces is >>>> availability. In addition to radio being four orders of magnitude >>>> less capacious than wired, radio has about 4 orders of magnitude >>>> higher error rates. There are myriad reasons that a radio link of >>>> whatever flavor will go away. For short term or longer term >>>> duration. >>>>=20 >>>> So the obvious way to counter this is to have >1 radio link. The >>>> arithmetic to support is standard high Ao engineering stuff. >>>>=20 >>>>=20 >>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>> of multiple interfaces for bandwidth augmentation. >>>>>=20 >>>>=20 >>>> Not sure what you're trying to say with this quote: every router has >>>> multiple interfaces and they are often used in parallel for bandwidth >>>> augmentation. This is an inherent part of IP ... RFC 791. Getting >>>> them to behave properly has sometimes been a problem, but it's >>>> generally outside of the standardization realm. >>>=20 >>> I wonder what the others think about this? (I do have some idea, but >>> not sure I as contributor would like to do anything about this >>> particular topic right now here, because other things here in ITS are >>> more mature.) >>>=20 >>>> Current reality: US Navy has a router on each ship. There are >>>> usually three LANs on the ship side (segregation for security >>>> reasons, VPN). But there are multiple interfaces on the radio side -- >>>> one for each satcom channel, for example. >>>=20 >>> Sure... this not surprising and is needed so! >>>=20 >>> However, what is the mechanism used by US Navy to make all these egress >>> interfaces look as one single interface in the router on the ship? Wha= t >>> is the scheduling intelligence to transparently divide a traffic flow >>> evenly among all these interfaces? (without trolling, I think there >>> isnt any; I think they put one application on one radio, another >>> application on another radio, and so on) >>>=20 >>>> Will's question is easily answered: yes. >>>=20 >>> Yes, I agree. >>>=20 >>> And from that answer, what we need right now is to know how to put this >>> in a Charter - is it by making it into a Problem Statement such that >>> scenarios and solutions for this particular multi-interface scenario be >>> developped? Or just have it there as a design principle? Or just to >>> reuse some existing protocol? >>>=20 >>> Knowing that there are already two things that are maturing as we speak >>> and that should get more attention in the Charter proposal: V2V and >>> addressing. >>>=20 >>> And that we should focus the Charter proposal. >>>=20 >>> And that for any thing that we put in the Charter proposal we shoudl >>> have commitment of effort to write drafts. >>>=20 >>> Alex >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >>>>> Will, >>>>>=20 >>>>> Thanks for the comment. >>>>>=20 >>>>> I have inserted something about this in the Draft Charter Proposal, >>>>> but let me discuss. >>>>>=20 >>>>> The simultaneous use of multiple egress interfaces is a technique >>>>> allowing to expand the available bandwidth for a vehicle >>>>> connection. >>>>>=20 >>>>> A known car network problem is the discrepancy between the outside >>>>> bandwidth and the inside bandwith. The egress interface is >>>>> typically a cellular link, which is originally intended for unique >>>>> personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. >>>>> LTE). But within same vehicle, one uses a Ethernet or WiFi links, >>>>> which may use 300Mbit/s or even 1Gbit/s. If all the devices >>>>> within the vehicle talk to the Servers at the same time, it becomes >>>>> obvious that the LTE link is a bottleneck. >>>>>=20 >>>>> The problem is specific to vehicular networks, and different from >>>>> office networks. In office networks the upstream link is typically >>>>> much higher bandwidth than the link for office PCs. E.g. 10GByte >>>>> vs 1GByte Ethernet. In vehicular networks, the cellular link is >>>>> the bottleneck because it is much less bandwidth than the in-car >>>>> link. >>>>>=20 >>>>> To solve this, there exist approaches where one proposes to use >>>>> several such egress external links on the vehicle, at the same >>>>> time. This would add up the bandwidth; e.g. use 10 USB LTE dongles >>>>> to achieve an aggregated bandwidth of 500Mbit/s towards the >>>>> infrastructure. This would enlarge this bottleneck. >>>>>=20 >>>>> At IETF, there is this >>>>> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding >>>>> Support for Mobile IPv4" that I co-author there. I dont think it >>>>> advances ok, but should advance there. >>>>>=20 >>>>> However, that draft is not really corresponding to my intention >>>>> about simultaneous use of multiple interfaces. It's more an >>>>> evolution of what 'flow binding updates' means to Mobile IPv6. >>>>>=20 >>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>> of multiple interfaces for bandwidth augmentation. >>>>>=20 >>>>> If you read until here, then please reply to see whether there is >>>>> interest in developping such solution. This would mean to add it >>>>> in the Charter Proposal, and commit to some work items. We are >>>>> already very short on space left about new things to do. >>>>>=20 >>>>> Yours, >>>>>=20 >>>>> Alex >>>>>=20 >>>>>=20 >>>>> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a =E9crit : >>>>>> Propose >>>>>>=20 >>>>>> From: "In this system, disjoint and heterogeneous radio systems >>>>>> are used (e.g. a vehicle uses two different radios)." >>>>>>=20 >>>>>> To: In this system, disjoint and heterogeneous radio systems >>>>>> are used (e.g. a vehicle uses two OR MORE different radios >>>>>> SIMULTANEOUSLY)." >>>>>>=20 >>>>>> Question: >>>>>>=20 >>>>>> Do you want simultaneous use of multiple radios or not? >>>>>>=20 >>>>>> Will Ivancic >>>>>>=20 >>>>>>=20 >>>>>>> From: Alexandru Petrescu Date: >>>>>>> Mon, 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >>>>>>> Subject: [its] Updated Draft Charter proposal >>>>>>>=20 >>>>>>> In this system, disjoint and heterogeneous radio systems are >>>>>>> used (e.g. a vehicle uses two different radios). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ its mailing list >>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> its mailing list >>> its@ietf.org >>> https://www.ietf.org/mailman/listinfo/its >>=20 >=20 >=20 From michelle.wetterwald@eurecom.fr Fri Mar 15 13:23: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 1F78A21F8AA8 for ; Fri, 15 Mar 2013 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24] 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 Sgs31YZTmmXT for ; Fri, 15 Mar 2013 13:23:01 -0700 (PDT) Received: from smtp2.eurecom.fr (smtp3.eurecom.fr [193.55.113.213]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9921F8A5E for ; Fri, 15 Mar 2013 13:23:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,853,1355094000"; d="scan'208";a="1057415" Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago2i.eurecom.fr with ESMTP; 15 Mar 2013 21:22:22 +0100 Received: from [172.23.5.71] (acrdsl4.static.otenet.gr [79.129.114.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id CF50D2C; Fri, 15 Mar 2013 21:22:21 +0100 (CET) Message-ID: <514382FF.6020206@eurecom.fr> Date: Fri, 15 Mar 2013 21:22:23 +0100 From: Michelle Wetterwald User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost><51409FFF.2010309@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1004FEA9@xmb-aln-x03.cisco.com> <20BDCA7BA42F448A834B973FCDE58B04@SRA4> <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , Alexandru Petrescu , "" , Joe Macker , "Stan Ratliff \(sratliff\)" , "" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:23:03 -0000 Dear all, You may also be interested by the work done in the MIF (Multiple Interfaces) WG , which addresses the mechanisms required to support the attachment to multiple provisioning domains, cf RFCs 6418 and 6419. It falls directly in this topic from networking point of view. Regards, Michelle On 15/03/2013 19:03, JP Vasseur (jvasseur) wrote: > Hi, > > This is clearly a working intersecting two WG: MANET for sure, and ROLL for routing, since RPL has been used for car to car communication. > > Cheers. > > JP. > > On Mar 13, 2013, at 9:19 PM, Richard Roy wrote: > >> Definitely plan for multiple simultaneous radio links. Whether or not a >> particular ITS station (ITS terminology for a (possibly mobile) network >> node) can support such simultaneous transmission will be assessed by ITS >> station management, and if for some reason the radio modules interfere with >> each other on Tx, simultaneous Tx from both will be prohibited. However, >> this is not something that concerns the network layer protocols directly and >> for the purposes of this effort, I suggest you just assume simultaneous Tx. >> ITS stations assume multiple flows (to the same or different app processes) >> and ITS station management manages the communication resources in realtime. >> The issue is getting the back end networking protocols to set up and support >> these flows. >> >> RR >> >>> -----Original Message----- >>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>> Sent: Wednesday, March 13, 2013 9:15 AM >>> To: Alexandru Petrescu; Joe Macker; JP Vasseur (jvasseur) >>> Cc: Rex Buddenberg; its@ietf.org; Ivancic, William D. (GRC-RHN0) >>> Subject: Re: [its] simultaneous use o fmultiple radios or not >>> >>> Alex, >>> >>> This describes almost exactly the deployments I've worked with. It is yet >>> another reason I say that starting a new working group for the ITS effort >>> is over-kill. Please don't get me wrong - this is interesting work, and >>> should be addressed. However, it needs to be done (IMO) within the >>> auspices of the MANET working group. Possibly ROLL, but I'm thinking MANET >>> is a better fit. >>> >>> Regards, >>> Stan >>> >>> On Mar 13, 2013, at 11:49 AM, Alexandru Petrescu wrote: >>> >>>> Ok, >>>> >>>> So we talk radios as egress interfaces. I.e. have several egress >>>> interfaces on a Mobile Router (gateway in the vehicle). When one of the >>>> radio fails, the MR uses another one, such that the Internet is always >>>> available to vehicle. >>>> >>>> This sounds reasonable. >>>> >>>> It is for me a sort of architectural requirement, to be strongly kept in >>>> mind, for designing any new protocol. >>>> >>>> Le 12/03/2013 23:22, Rex Buddenberg a écrit : >>>>> Alex, >>>>> >>>>> Your numbers are essentially correct -- radio links are about 10-4 >>>>> smaller sized than wired ones. >>>>> >>>>> But a more powerful argument for multiple interfaces is >>>>> availability. In addition to radio being four orders of magnitude >>>>> less capacious than wired, radio has about 4 orders of magnitude >>>>> higher error rates. There are myriad reasons that a radio link of >>>>> whatever flavor will go away. For short term or longer term >>>>> duration. >>>>> >>>>> So the obvious way to counter this is to have >1 radio link. The >>>>> arithmetic to support is standard high Ao engineering stuff. >>>>> >>>>> >>>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>>> of multiple interfaces for bandwidth augmentation. >>>>>> >>>>> Not sure what you're trying to say with this quote: every router has >>>>> multiple interfaces and they are often used in parallel for bandwidth >>>>> augmentation. This is an inherent part of IP ... RFC 791. Getting >>>>> them to behave properly has sometimes been a problem, but it's >>>>> generally outside of the standardization realm. >>>> I wonder what the others think about this? (I do have some idea, but >>>> not sure I as contributor would like to do anything about this >>>> particular topic right now here, because other things here in ITS are >>>> more mature.) >>>> >>>>> Current reality: US Navy has a router on each ship. There are >>>>> usually three LANs on the ship side (segregation for security >>>>> reasons, VPN). But there are multiple interfaces on the radio side -- >>>>> one for each satcom channel, for example. >>>> Sure... this not surprising and is needed so! >>>> >>>> However, what is the mechanism used by US Navy to make all these egress >>>> interfaces look as one single interface in the router on the ship? What >>>> is the scheduling intelligence to transparently divide a traffic flow >>>> evenly among all these interfaces? (without trolling, I think there >>>> isnt any; I think they put one application on one radio, another >>>> application on another radio, and so on) >>>> >>>>> Will's question is easily answered: yes. >>>> Yes, I agree. >>>> >>>> And from that answer, what we need right now is to know how to put this >>>> in a Charter - is it by making it into a Problem Statement such that >>>> scenarios and solutions for this particular multi-interface scenario be >>>> developped? Or just have it there as a design principle? Or just to >>>> reuse some existing protocol? >>>> >>>> Knowing that there are already two things that are maturing as we speak >>>> and that should get more attention in the Charter proposal: V2V and >>>> addressing. >>>> >>>> And that we should focus the Charter proposal. >>>> >>>> And that for any thing that we put in the Charter proposal we shoudl >>>> have commitment of effort to write drafts. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >>>>>> Will, >>>>>> >>>>>> Thanks for the comment. >>>>>> >>>>>> I have inserted something about this in the Draft Charter Proposal, >>>>>> but let me discuss. >>>>>> >>>>>> The simultaneous use of multiple egress interfaces is a technique >>>>>> allowing to expand the available bandwidth for a vehicle >>>>>> connection. >>>>>> >>>>>> A known car network problem is the discrepancy between the outside >>>>>> bandwidth and the inside bandwith. The egress interface is >>>>>> typically a cellular link, which is originally intended for unique >>>>>> personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. >>>>>> LTE). But within same vehicle, one uses a Ethernet or WiFi links, >>>>>> which may use 300Mbit/s or even 1Gbit/s. If all the devices >>>>>> within the vehicle talk to the Servers at the same time, it becomes >>>>>> obvious that the LTE link is a bottleneck. >>>>>> >>>>>> The problem is specific to vehicular networks, and different from >>>>>> office networks. In office networks the upstream link is typically >>>>>> much higher bandwidth than the link for office PCs. E.g. 10GByte >>>>>> vs 1GByte Ethernet. In vehicular networks, the cellular link is >>>>>> the bottleneck because it is much less bandwidth than the in-car >>>>>> link. >>>>>> >>>>>> To solve this, there exist approaches where one proposes to use >>>>>> several such egress external links on the vehicle, at the same >>>>>> time. This would add up the bandwidth; e.g. use 10 USB LTE dongles >>>>>> to achieve an aggregated bandwidth of 500Mbit/s towards the >>>>>> infrastructure. This would enlarge this bottleneck. >>>>>> >>>>>> At IETF, there is this >>>>>> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding >>>>>> Support for Mobile IPv4" that I co-author there. I dont think it >>>>>> advances ok, but should advance there. >>>>>> >>>>>> However, that draft is not really corresponding to my intention >>>>>> about simultaneous use of multiple interfaces. It's more an >>>>>> evolution of what 'flow binding updates' means to Mobile IPv6. >>>>>> >>>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>>> of multiple interfaces for bandwidth augmentation. >>>>>> >>>>>> If you read until here, then please reply to see whether there is >>>>>> interest in developping such solution. This would mean to add it >>>>>> in the Charter Proposal, and commit to some work items. We are >>>>>> already very short on space left about new things to do. >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit : >>>>>>> Propose >>>>>>> >>>>>>> From: "In this system, disjoint and heterogeneous radio systems >>>>>>> are used (e.g. a vehicle uses two different radios)." >>>>>>> >>>>>>> To: In this system, disjoint and heterogeneous radio systems >>>>>>> are used (e.g. a vehicle uses two OR MORE different radios >>>>>>> SIMULTANEOUSLY)." >>>>>>> >>>>>>> Question: >>>>>>> >>>>>>> Do you want simultaneous use of multiple radios or not? >>>>>>> >>>>>>> Will Ivancic >>>>>>> >>>>>>> >>>>>>>> From: Alexandru Petrescu Date: >>>>>>>> Mon, 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >>>>>>>> Subject: [its] Updated Draft Charter proposal >>>>>>>> >>>>>>>> In this system, disjoint and heterogeneous radio systems are >>>>>>>> used (e.g. a vehicle uses two different radios). >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ its mailing list >>>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> its mailing list >>>> its@ietf.org >>>> https://www.ietf.org/mailman/listinfo/its >> > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From abdussalambaryun@gmail.com Fri Mar 15 18:00:22 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359921F8AAC for ; Fri, 15 Mar 2013 18:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 8Y06qZ+45RZZ for ; Fri, 15 Mar 2013 18:00:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6848921F8994 for ; Fri, 15 Mar 2013 18:00:22 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wz12so4499860pbc.31 for ; Fri, 15 Mar 2013 18:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Gakq4m1KznN0Q/Srfl4rHNDbgItwBPXX7So/1iPjyxw=; b=CBu6stcX7MtR6aNj1d2yZzQdoWA8A02iF5qLBYp1+3oY1msWRLcknbsGrNjCqDOI80 OJq2+KTmCiyglEbUajrjYxZJhPsSEGdIG/wade4xPGc9NQpAXWgmmrmAa4+l6OOfQ1Dp rrVkvB6MwXCkUvg8cLUyfEhz+8WXKnZPj5+sQ8m9owbEoZWv1jiQQO6XgE3DbBsCYfEH RHo7T18xz4RovtbZ9Awg61TwDZZjGjp8e9CZL4/h5nNaKQY8bdToJ62nauygZDLjDH5B qms5S25NDE0e3ixtSNH5Zp2BzMK/s6HttsoYvRzXoriC6fzvGR5fsaDpSb/OAISL5mcZ IlAw== MIME-Version: 1.0 X-Received: by 10.68.237.100 with SMTP id vb4mr20783339pbc.202.1363395621986; Fri, 15 Mar 2013 18:00:21 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Fri, 15 Mar 2013 18:00:21 -0700 (PDT) In-Reply-To: <5140CB20.2050306@gmail.com> References: <5140CB20.2050306@gmail.com> Date: Sat, 16 Mar 2013 02:00:21 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 01:00:22 -0000 On 3/13/13, Alexandru Petrescu wrote: > Hello ITS participants, > > While working on Charter Proposal we are distinguishing between 1-hop > V2V communications (a single subnet between several vehicles), and n-hop > communications (vehicle-to-vehicle-to-vehicle, each time a different > subnet between vehicles). > > I would like to ask participants whether there is interest in n-hop > routing protocols for vehicular communications. > > Is work needed on MANET protocols for this? Yes, I recommend the use of DSRv2 which I am trying to complete. The AODVv2 is also an option, > > Are there special requirements for this? (i.e. a case where a MANET > protocol is not sufficient for n-hop vehicular communications). as long as the MANET WG don't want to consider defining L2 technologies used then I think will not be sufficient. I will update my draft that was about defining MANET subnets and to including v2v technology. http://tools.ietf.org/id/draft-baryun-manet-technology-00.txt AB From abdussalambaryun@gmail.com Sat Mar 16 04:51:10 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF5E21F8AF4 for ; Sat, 16 Mar 2013 04:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Rq8rlZWQU7so for ; Sat, 16 Mar 2013 04:51:10 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8621F8AD8 for ; Sat, 16 Mar 2013 04:51:09 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xa12so4879835pbc.8 for ; Sat, 16 Mar 2013 04:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=132kuyfoHrzHHuZEsXM1njYZXFVQRX4OMxTgVJoC/vM=; b=fhgZFL5vqdhELWuQYtoKMZzqA5YDYbYoKjZAmNDC6V1bJYU3ykb6cz0YC2vSD9Od8m FrTR8H0qmdK9AZ6IsyFy+ff773A/x0fCVEt/JQrqSiEhg5Vk/zln74c3xW3iGqhMziLg 7pqbxU9BzYiWFSHNJKFUgFWPTg89cMgBzGU8r51aGlOPZH0OZxiFa0m+F9QEQComWI4Y brVA4lcxQHtHgY3G8u+auWEgFylpXIPPU2UZiEtx0nIuO2sBqsKu6nkSCnW2aKvmqyCx gzr/ngDqb0Vo2szUE6kRgNXv50Mx/4Jw1soMh9D8vfPjRh8APuspdynDKUT2nNTs36rr AboQ== MIME-Version: 1.0 X-Received: by 10.68.237.100 with SMTP id vb4mr23699731pbc.202.1363434669726; Sat, 16 Mar 2013 04:51:09 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sat, 16 Mar 2013 04:51:09 -0700 (PDT) In-Reply-To: References: <5140CB20.2050306@gmail.com> Date: Sat, 16 Mar 2013 12:51:09 +0100 Message-ID: From: Abdussalam Baryun To: Jong-Hyouk Lee Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 11:51:11 -0000 Do you mean GeoNet in layer 2 or layer 3 tested at FP7 project, is there reference? AB On 3/13/13, Jong-Hyouk Lee wrote: > Hello all, > > IMHO, n-hop routing protocols (based on MANET) are not much needed to be > discussed at least at this moment. > > One-hop IP communications for ITS seem enough to be studied in the first > stage at the IETF. For instance, in EU, a combination of IPv6 and > Geonetworking (i.e., a special designed protocol for vehicular > communications that support one-hop and n-hop routing based on geographical > information taken from GPS) has been specified at the ETSI ITS TC and > tested at the FP7 project, GeoNet. IPv6 packets over Geonetworking are > delivered in a manner of one-hop and n-hop while utilizing geographical > information. For instance, IPv6 packets are sent to multiple receivers in a > specific geographical area. It make that from the view point of IPv6, it is > one-hop, but it is actually n-hops as the IPv6 packets are forwarded as > many as needed to reach to the destination. > > In this way, routing performance is better and the n-hop topology maintain > cost is removed. > > Cheers. > > On Wed, Mar 13, 2013 at 2:53 PM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > >> Hello ITS participants, >> >> While working on Charter Proposal we are distinguishing between 1-hop >> V2V communications (a single subnet between several vehicles), and n-hop >> communications (vehicle-to-vehicle-to-**vehicle, each time a different >> subnet between vehicles). >> >> I would like to ask participants whether there is interest in n-hop >> routing protocols for vehicular communications. >> >> Is work needed on MANET protocols for this? >> >> Are there special requirements for this? (i.e. a case where a MANET >> protocol is not sufficient for n-hop vehicular communications). >> >> Yours, >> >> Alex >> >> ______________________________**_________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/**listinfo/its >> > > > > -- > RSM Department, TELECOM Bretagne, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ > From manabu.tsukada@inria.fr Sat Mar 16 13:33: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 B100221F8470 for ; Sat, 16 Mar 2013 13:33: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 0CDvtiZ+wG9c for ; Sat, 16 Mar 2013 13:33:48 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEFF21F845B for ; Sat, 16 Mar 2013 13:33:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,857,1355094000"; d="scan'208";a="7942062" Received: from ver78-4-82-244-181-122.fbx.proxad.net (HELO [192.168.0.15]) ([82.244.181.122]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 16 Mar 2013 21:33:46 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Manabu Tsukada In-Reply-To: Date: Sat, 16 Mar 2013 21:33:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5140CB20.2050306@gmail.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1499) Cc: Alexandru Petrescu , Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] n-hop routing protocols for vehicular communications - MANET X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:33:49 -0000 Hi Abdussalam, GeoNetworking is in layer 3, however it also works as sub-layer from = IPv6 point of view. We call it as IPv6 GeoNetworking (GN6). IP packet is = encapsulated by GeoNetworking header.=20 GN6 adaptation sub-layer (GN6ASL) provides GeoNetworking layer interface = to IPv6. In our Linux implementation (http://www.cargeo6.org/), the = GeoNetworking interface is shown like Ethernet Type (like eth0). Thus = the IP layer protocols works on top of GeoNetworking.=20 The GeoNet project (FP7) finished in 2010. The specification and = evaluation are available here. http://www.geonet-project.eu/. =20 However, we should discuss based on ETSI GeoNetworking standards in = 2013.=20 - GeoNetworking (ETSI-TS-102-636-4-1, ETSI-TS-102-636-4-2, = ETSI-TS-102-636-5-1)=20 - IPv6 GeoNetworking (ETSI-TS-102-636-6-1) The result of GeoNet project (FP7) and ETSI GeoNetworking has similar = concept but it is not exactly same as protocols.=20 Regards, Manabu On Mar 16, 2013, at 12:51 , Abdussalam Baryun = wrote: > Do you mean GeoNet in layer 2 or layer 3 tested at FP7 project, is > there reference? >=20 > AB >=20 > On 3/13/13, Jong-Hyouk Lee wrote: >> Hello all, >>=20 >> IMHO, n-hop routing protocols (based on MANET) are not much needed to = be >> discussed at least at this moment. >>=20 >> One-hop IP communications for ITS seem enough to be studied in the = first >> stage at the IETF. For instance, in EU, a combination of IPv6 and >> Geonetworking (i.e., a special designed protocol for vehicular >> communications that support one-hop and n-hop routing based on = geographical >> information taken from GPS) has been specified at the ETSI ITS TC and >> tested at the FP7 project, GeoNet. IPv6 packets over Geonetworking = are >> delivered in a manner of one-hop and n-hop while utilizing = geographical >> information. For instance, IPv6 packets are sent to multiple = receivers in a >> specific geographical area. It make that from the view point of IPv6, = it is >> one-hop, but it is actually n-hops as the IPv6 packets are forwarded = as >> many as needed to reach to the destination. >>=20 >> In this way, routing performance is better and the n-hop topology = maintain >> cost is removed. >>=20 >> Cheers. >>=20 >> On Wed, Mar 13, 2013 at 2:53 PM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com> wrote: >>=20 >>> Hello ITS participants, >>>=20 >>> While working on Charter Proposal we are distinguishing between = 1-hop >>> V2V communications (a single subnet between several vehicles), and = n-hop >>> communications (vehicle-to-vehicle-to-**vehicle, each time a = different >>> subnet between vehicles). >>>=20 >>> I would like to ask participants whether there is interest in n-hop >>> routing protocols for vehicular communications. >>>=20 >>> Is work needed on MANET protocols for this? >>>=20 >>> Are there special requirements for this? (i.e. a case where a MANET >>> protocol is not sufficient for n-hop vehicular communications). >>>=20 >>> Yours, >>>=20 >>> Alex >>>=20 >>> ______________________________**_________________ >>> its mailing list >>> its@ietf.org >>> = https://www.ietf.org/mailman/**listinfo/its >>>=20 >>=20 >>=20 >>=20 >> -- >> RSM Department, TELECOM Bretagne, France >> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random >>=20 >> #email: jonghyouk (at) gmail (dot) com >> #webpage: http://sites.google.com/site/hurryon/ >>=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its --- Manabu TSUKADA INRIA Paris-Rocquencourt France - Project Team IMARA From kml@patheticgeek.net Sat Mar 16 14:55:37 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB26121F867B for ; Sat, 16 Mar 2013 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 jaIT8mewwBGy for ; Sat, 16 Mar 2013 14:55:36 -0700 (PDT) Received: from mail.patheticgeek.net (patheticgeek.net [166.84.136.10]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E921F867A for ; Sat, 16 Mar 2013 14:55:36 -0700 (PDT) Received: from temprokkaku (newmail [166.84.136.10]) by newmail.patheticgeek.net (Postfix) with ESMTP id 0E62B209375 for ; Thu, 14 Mar 2013 15:29:18 -0400 (EDT) Date: Wed, 13 Mar 2013 17:21:12 -0700 From: Kevin Lahey To: its@ietf.org Message-ID: <20130313172112.671bcf40@temprokkaku> In-Reply-To: <1363197994.1813.348.camel@localhost> References: <1363197994.1813.348.camel@localhost> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.12; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 21:55:38 -0000 On Wed, 13 Mar 2013 10:06:34 -0800 Rex Buddenberg wrote: > The basic design of IP (and especially TCP) accommodates. TCP is > designed to deal with packets that arrive out of order, which is likely > if you have diverse routes. Careful -- TCP is actually very sensitive to reordering. Fast retransmission will be triggered after a small number of duplicate ACKs, which are triggered when a packet arrives out of order (or is lost). Some stacks can recognize repeated reorderings and relax this rule, at the cost of lower performance. The multipath schemes with which I'm familiar try hard to steer all packets in a flow to the same link. Cheers, Kevin kml@patheticgeek.net From alexandru.petrescu@gmail.com Sat Mar 16 18:44: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 CA59321F85A2 for ; Sat, 16 Mar 2013 18:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.492 X-Spam-Level: X-Spam-Status: No, score=-9.492 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 2wEt4IkiJZJN for ; Sat, 16 Mar 2013 18:44:57 -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 16BA321F85A1 for ; Sat, 16 Mar 2013 18:44: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 r2H1ioZv018928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 Mar 2013 02:44:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2H1iobI002033; Sun, 17 Mar 2013 02:44:50 +0100 (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 r2H1ijEY016207; Sun, 17 Mar 2013 02:44:49 +0100 Message-ID: <51451FEB.9080404@gmail.com> Date: Sun, 17 Mar 2013 02:44:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Michelle Wetterwald References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost><51409FFF.2010309@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1004FEA9@xmb-aln-x03.cisco.com> <20BDCA7BA42F448A834B973FCDE58B04@SRA4> <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> <514382FF.6020206@eurecom.fr> In-Reply-To: <514382FF.6020206@eurecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , "" , "JP Vasseur \(jvasseur\)" , Joe Macker , "Stan Ratliff \(sratliff\)" , "" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use o fmultiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 01:44:59 -0000 Hello, There is indeed re-chartering discussion in the MIF Working Group, according to these intarea slides of Ted Lemon (new Area Director): http://www.ietf.org/proceedings/86/slides/slides-86-intarea-3.pdf It says 'Multiple Provisioning Domains'. Alex Le 15/03/2013 21:22, Michelle Wetterwald a écrit : > Dear all, > > You may also be interested by the work done in the MIF (Multiple > Interfaces) WG , which addresses the mechanisms required to support the > attachment to multiple provisioning domains, cf RFCs 6418 and 6419. It > falls directly in this topic from networking point of view. > > Regards, > > Michelle > > On 15/03/2013 19:03, JP Vasseur (jvasseur) wrote: >> Hi, >> >> This is clearly a working intersecting two WG: MANET for sure, and >> ROLL for routing, since RPL has been used for car to car communication. >> >> Cheers. >> >> JP. >> >> On Mar 13, 2013, at 9:19 PM, Richard Roy wrote: >> >>> Definitely plan for multiple simultaneous radio links. Whether or not a >>> particular ITS station (ITS terminology for a (possibly mobile) network >>> node) can support such simultaneous transmission will be assessed by ITS >>> station management, and if for some reason the radio modules >>> interfere with >>> each other on Tx, simultaneous Tx from both will be prohibited. >>> However, >>> this is not something that concerns the network layer protocols >>> directly and >>> for the purposes of this effort, I suggest you just assume >>> simultaneous Tx. >>> ITS stations assume multiple flows (to the same or different app >>> processes) >>> and ITS station management manages the communication resources in >>> realtime. >>> The issue is getting the back end networking protocols to set up and >>> support >>> these flows. >>> >>> RR >>> >>>> -----Original Message----- >>>> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com] >>>> Sent: Wednesday, March 13, 2013 9:15 AM >>>> To: Alexandru Petrescu; Joe Macker; JP Vasseur (jvasseur) >>>> Cc: Rex Buddenberg; its@ietf.org; Ivancic, William D. (GRC-RHN0) >>>> Subject: Re: [its] simultaneous use o fmultiple radios or not >>>> >>>> Alex, >>>> >>>> This describes almost exactly the deployments I've worked with. It >>>> is yet >>>> another reason I say that starting a new working group for the ITS >>>> effort >>>> is over-kill. Please don't get me wrong - this is interesting work, and >>>> should be addressed. However, it needs to be done (IMO) within the >>>> auspices of the MANET working group. Possibly ROLL, but I'm thinking >>>> MANET >>>> is a better fit. >>>> >>>> Regards, >>>> Stan >>>> >>>> On Mar 13, 2013, at 11:49 AM, Alexandru Petrescu wrote: >>>> >>>>> Ok, >>>>> >>>>> So we talk radios as egress interfaces. I.e. have several egress >>>>> interfaces on a Mobile Router (gateway in the vehicle). When one >>>>> of the >>>>> radio fails, the MR uses another one, such that the Internet is always >>>>> available to vehicle. >>>>> >>>>> This sounds reasonable. >>>>> >>>>> It is for me a sort of architectural requirement, to be strongly >>>>> kept in >>>>> mind, for designing any new protocol. >>>>> >>>>> Le 12/03/2013 23:22, Rex Buddenberg a écrit : >>>>>> Alex, >>>>>> >>>>>> Your numbers are essentially correct -- radio links are about 10-4 >>>>>> smaller sized than wired ones. >>>>>> >>>>>> But a more powerful argument for multiple interfaces is >>>>>> availability. In addition to radio being four orders of magnitude >>>>>> less capacious than wired, radio has about 4 orders of magnitude >>>>>> higher error rates. There are myriad reasons that a radio link of >>>>>> whatever flavor will go away. For short term or longer term >>>>>> duration. >>>>>> >>>>>> So the obvious way to counter this is to have >1 radio link. The >>>>>> arithmetic to support is standard high Ao engineering stuff. >>>>>> >>>>>> >>>>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>>>> of multiple interfaces for bandwidth augmentation. >>>>>>> >>>>>> Not sure what you're trying to say with this quote: every router has >>>>>> multiple interfaces and they are often used in parallel for bandwidth >>>>>> augmentation. This is an inherent part of IP ... RFC 791. Getting >>>>>> them to behave properly has sometimes been a problem, but it's >>>>>> generally outside of the standardization realm. >>>>> I wonder what the others think about this? (I do have some idea, but >>>>> not sure I as contributor would like to do anything about this >>>>> particular topic right now here, because other things here in ITS are >>>>> more mature.) >>>>> >>>>>> Current reality: US Navy has a router on each ship. There are >>>>>> usually three LANs on the ship side (segregation for security >>>>>> reasons, VPN). But there are multiple interfaces on the radio side -- >>>>>> one for each satcom channel, for example. >>>>> Sure... this not surprising and is needed so! >>>>> >>>>> However, what is the mechanism used by US Navy to make all these >>>>> egress >>>>> interfaces look as one single interface in the router on the ship? >>>>> What >>>>> is the scheduling intelligence to transparently divide a traffic flow >>>>> evenly among all these interfaces? (without trolling, I think there >>>>> isnt any; I think they put one application on one radio, another >>>>> application on another radio, and so on) >>>>> >>>>>> Will's question is easily answered: yes. >>>>> Yes, I agree. >>>>> >>>>> And from that answer, what we need right now is to know how to put >>>>> this >>>>> in a Charter - is it by making it into a Problem Statement such that >>>>> scenarios and solutions for this particular multi-interface >>>>> scenario be >>>>> developped? Or just have it there as a design principle? Or just to >>>>> reuse some existing protocol? >>>>> >>>>> Knowing that there are already two things that are maturing as we >>>>> speak >>>>> and that should get more attention in the Charter proposal: V2V and >>>>> addressing. >>>>> >>>>> And that we should focus the Charter proposal. >>>>> >>>>> And that for any thing that we put in the Charter proposal we shoudl >>>>> have commitment of effort to write drafts. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> >>>>>> On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >>>>>>> Will, >>>>>>> >>>>>>> Thanks for the comment. >>>>>>> >>>>>>> I have inserted something about this in the Draft Charter Proposal, >>>>>>> but let me discuss. >>>>>>> >>>>>>> The simultaneous use of multiple egress interfaces is a technique >>>>>>> allowing to expand the available bandwidth for a vehicle >>>>>>> connection. >>>>>>> >>>>>>> A known car network problem is the discrepancy between the outside >>>>>>> bandwidth and the inside bandwith. The egress interface is >>>>>>> typically a cellular link, which is originally intended for unique >>>>>>> personal use; that is bandwidth 50Mbit/s and latency 50ms (e.g. >>>>>>> LTE). But within same vehicle, one uses a Ethernet or WiFi links, >>>>>>> which may use 300Mbit/s or even 1Gbit/s. If all the devices >>>>>>> within the vehicle talk to the Servers at the same time, it becomes >>>>>>> obvious that the LTE link is a bottleneck. >>>>>>> >>>>>>> The problem is specific to vehicular networks, and different from >>>>>>> office networks. In office networks the upstream link is typically >>>>>>> much higher bandwidth than the link for office PCs. E.g. 10GByte >>>>>>> vs 1GByte Ethernet. In vehicular networks, the cellular link is >>>>>>> the bottleneck because it is much less bandwidth than the in-car >>>>>>> link. >>>>>>> >>>>>>> To solve this, there exist approaches where one proposes to use >>>>>>> several such egress external links on the vehicle, at the same >>>>>>> time. This would add up the bandwidth; e.g. use 10 USB LTE dongles >>>>>>> to achieve an aggregated bandwidth of 500Mbit/s towards the >>>>>>> infrastructure. This would enlarge this bottleneck. >>>>>>> >>>>>>> At IETF, there is this >>>>>>> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow Binding >>>>>>> Support for Mobile IPv4" that I co-author there. I dont think it >>>>>>> advances ok, but should advance there. >>>>>>> >>>>>>> However, that draft is not really corresponding to my intention >>>>>>> about simultaneous use of multiple interfaces. It's more an >>>>>>> evolution of what 'flow binding updates' means to Mobile IPv6. >>>>>>> >>>>>>> I am not aware of any other draft at IETF doing simultaneous use >>>>>>> of multiple interfaces for bandwidth augmentation. >>>>>>> >>>>>>> If you read until here, then please reply to see whether there is >>>>>>> interest in developping such solution. This would mean to add it >>>>>>> in the Charter Proposal, and commit to some work items. We are >>>>>>> already very short on space left about new things to do. >>>>>>> >>>>>>> Yours, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit : >>>>>>>> Propose >>>>>>>> >>>>>>>> From: "In this system, disjoint and heterogeneous radio systems >>>>>>>> are used (e.g. a vehicle uses two different radios)." >>>>>>>> >>>>>>>> To: In this system, disjoint and heterogeneous radio systems >>>>>>>> are used (e.g. a vehicle uses two OR MORE different radios >>>>>>>> SIMULTANEOUSLY)." >>>>>>>> >>>>>>>> Question: >>>>>>>> >>>>>>>> Do you want simultaneous use of multiple radios or not? >>>>>>>> >>>>>>>> Will Ivancic >>>>>>>> >>>>>>>> >>>>>>>>> From: Alexandru Petrescu Date: >>>>>>>>> Mon, 11 Mar 2013 17:42:14 -0500 To: "its@ietf.org" >>>>>>>>> Subject: [its] Updated Draft Charter proposal >>>>>>>>> >>>>>>>>> In this system, disjoint and heterogeneous radio systems are >>>>>>>>> used (e.g. a vehicle uses two different radios). >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ its mailing list >>>>>>> its@ietf.org https://www.ietf.org/mailman/listinfo/its >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> its mailing list >>>>> its@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/its >>> >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its > > > From alexandru.petrescu@gmail.com Sat Mar 16 18:52:44 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 315D521F856F for ; Sat, 16 Mar 2013 18:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.097 X-Spam-Level: X-Spam-Status: No, score=-10.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 K0zk2cXWd7pN for ; Sat, 16 Mar 2013 18:52:43 -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 DB33F21F8503 for ; Sat, 16 Mar 2013 18:52:42 -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 r2H1qf1K020213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 17 Mar 2013 02:52:42 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2H1qf7r004366 for ; Sun, 17 Mar 2013 02:52:41 +0100 (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 r2H1qbfN018876 for ; Sun, 17 Mar 2013 02:52:41 +0100 Message-ID: <514521C4.7090607@gmail.com> Date: Sun, 17 Mar 2013 02:52:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> In-Reply-To: <20130313172112.671bcf40@temprokkaku> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 01:52:44 -0000 Le 14/03/2013 01:21, Kevin Lahey a écrit : > On Wed, 13 Mar 2013 10:06:34 -0800 Rex Buddenberg > wrote: > >> The basic design of IP (and especially TCP) accommodates. TCP is >> designed to deal with packets that arrive out of order, which is >> likely if you have diverse routes. > > Careful -- TCP is actually very sensitive to reordering. Fast > retransmission will be triggered after a small number of duplicate > ACKs, which are triggered when a packet arrives out of order (or is > lost). I noticed a similar behaviour of TCP. > Some stacks can recognize repeated reorderings and relax this rule, > at the cost of lower performance. And, just to say that it is possible to use such multi-interface technique with other things than TCP - e.g. a UDP video stream upstream. And the non-TCP software on the Correspondent Node would be in charge of reordering. Alex > > The multipath schemes with which I'm familiar try hard to steer all > packets in a flow to the same link. > > Cheers, > > Kevin kml@patheticgeek.net > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > From alexandru.petrescu@gmail.com Sun Mar 17 11:39:42 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710EF21F8845 for ; Sun, 17 Mar 2013 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.434 X-Spam-Level: * X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 oLK90t7QtKTa for ; Sun, 17 Mar 2013 11:39:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABC21F88C1 for ; Sun, 17 Mar 2013 11:39:33 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0E08D94027F for ; Sun, 17 Mar 2013 19:39:28 +0100 (CET) Message-ID: <51460DE0.3080809@gmail.com> Date: Sun, 17 Mar 2013 19:39:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: multipart/mixed; boundary="------------040501090409040705040006" X-Antivirus: avast! (VPS 130317-0, 17/03/2013), Outbound message X-Antivirus-Status: Clean Subject: [its] Updated draft Charter proposal after Orlando X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:39:42 -0000 This is a multi-part message in MIME format. --------------040501090409040705040006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dears, In Orlando we discussed with several participants, and we further improved the draft Charter proposal. See attached the Charter proposal frozen after Orlando. Most notably it contains security aspects, and re-formulation of certain paragraphs to look more like a Charter rather than requirements for a particular design. The multiple-interfaces discussion is not much reflected because I couldnt yet frame my mind clearly around it. This is still open. The n-hop routing protocols MANET - is reflected a bit in the Charter Proposal, but it is also still open. The overall discussion is open to update this proposal in the period from now until Berlin. Yours, Alex --------------040501090409040705040006 Content-Type: text/plain; charset=windows-1252; name="its-6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its-6.txt" Intelligent Transportation Systems at IETF Draft Charter Proposal March 17th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal bar BoF Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) are composed of interconnected systems of machines; vehicles, mobile devices and fixed embedded devices (actuator and sensors). These machines communicate with fixed access points which are are deployed along terrestrial roads (e.g. Road-Side Units), and along shores of water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless communications to equipment deployed in mobile vehicles (e.g. On-Board Units), in a secure manner. The entire system may be connected to the Internet; in certain cases the vehicles are disconnected from the Internet yet are inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint and heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively). Communication security requirements are of paramount importance in the context of vehicular communications. Using IP should not introduce new risks, especially when safety-specific applications are involved. For example, crash avoidance inter-vehicle communication systems should be secured (safety of humans is at stake); as another practical example, within the vehicle, introducing IP communications to an otherwise non-IP rearview camera should not allow for attacker IP devices to DoS the displafy, or turn the volume to a sudden high. Certain security requirements may be generic IP communications security, whereas others may be specific to vehicular communications. Due to the mobile nature of the system, several problems exist with respect to IP addressing and route establishment such that IP communications can be realized. In the case of 1-hop Vehicle-to-Vehicle communications (V2V), without infrastructure, there is a problem in identifying which subnets and addresses are used on the link between two vehicles; also there is a problem in deciding how one vehicle learns the prefix deployed in a vehicle in close vicinity. In the case of n-hop V2V2V communications there is a need of identification which address configuration and dynamic routing protocol should be employed. In the case of Vehicle-to-Infrastructure (V2I) communications, there is a problem in propagating the prefix contained in a vehicle to the routers of the infrastructures without destabilizing the Internet routing (a typical IP network is using mostly IP addresses topologically valid at a single point, and relatively stable routing system). One particular use case is under the form of an instrumented ambulance. The ambulance is connected to the Internet and offers wireless and wired access to a large number of individual equipments deployed in-vehicle. The ambulance may move through a traffic jam and signal its presence to nearby vehicles with visual means and also with communication packets. Automatic driving through traffic jams involves wireless communications between vehicles. Constant links between vehicles constitute good support for establishing IP communications. An IP device in one vehicle may signal its actual speed to another IP device in the vehicle nearby. The smart-city use case is also important for networking country- and world-wide transports. The use case should lead to development of requirements and services for transports within cities, or countries, making them smart. The ITS technologies may use techniques from MANET and from RoLL adapted to this smart-city use case. One may need to consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in community networks. A hybrid routing protocol could be used. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications (such as the use of geonetworking at ETSI, or 6lowpan intermediate layers at IPSO). The relevant SDOs and respective groups are: ETSI ITS, ISO TC 204, IEEE 802.11p, AUTOSAR, IPSO. Opportunities exist to develop liaisons with these SDOs. A number of IETF protocols are being considered in the context of Intelligent Transportation Systems - most notably IPv6, Mobile IPv6, ND, ULA, DHCPv6, RPL, PMIPv6. Others, such as Global HAHA, are not excluded. At IETF several Working Groups such as 6MAN, V6OPS, DHC, MIF, MANET, DMM, RoLL, NETEXT, LISP produce work which is highly pertinent to the ITS context. A gap analysis should be performed to identify whether work in these groups can be reused for vehicular communications. A problem statement draft should be written. New efforts at IETF are also relevant: 6TSCH. The 6TSCH effort dealing with time-synchronized 802.15.4 link layers may have pertinence to safety applications of ITS, and it should be clarified whether it pertains to long-range communication between vehicles. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios. Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications. If limitations are identified as part of the above deliverable, specify new protocols or extensions to existing protocols that removes the identified limitations to achieve IP vehicular communications. A problem statement draft should be written which documents the existing protocols, analyses the gaps of their behaviour in 1-hop V2V networks and expresses the need for a new solution. Supplementary work items ------------------------ Infrastructure-less 1-hop route exchanges between vehicles, or between vehicles and road-side units which are disconnected from the infrastructure. A widely-used link-scoped IP protocol should be reused for prefix exchanges between vehicles in close vicinity; a single subnet is used between such vehicles, which are otherwise disconnected from the infrastructure. IEEE 802.11p is a link layer technology specific to vehicular communications, and which may be used for IP for ITS. In certain places this link layer technology is named "G5". Several trials of using IP directly over 802.11p links (without intermediate layers) have been performed in laboratory environments. A vehicle may have a multiplicity of interfaces, and a multiplicity of addresses outside and inside the vehicle, at the same time, for different purposes. For the use of IPv6 addresses inside a vehicle it is necessary the addressing schemes which couled be employed, and which address auto-configuration mechanism(s) (or a combination thereof) should be employed such that to be inline with the in-vehicle application requirements scenarios. For outside the vehicle, the use of IPv6 addresses in a subnet formed by the egress interfaces of the vehicles, in a 1-hop ad-hoc manner, is considered. For the fixed network deployed outside the vehicle - the use of Proxy Mobile IPv6 protocol on the fixed mobility management entities may prove advantageous to offer mobility to a moving network deployed in a vehicle. For the security inside the vehicular on-board network, requirements specific to vehicular communications should be formulated. For the security on the link between two vehicles, a secure Neighbor Discovery mechanism should be used. Milestones: Mar 2013 - Meet in Orlando done Jul 2013 - Meet in Berlin Jul 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems", and Gap Analysis Jul 2013 - Present drafts on Route Exchange between vehicles Nov 2013 - Present status from ISO --------------040501090409040705040006-- From abdussalambaryun@gmail.com Sun Mar 17 15:01:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088AB21F8A68 for ; Sun, 17 Mar 2013 15:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 rYju61TL7+N8 for ; Sun, 17 Mar 2013 15:01:29 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id A852F21F8A47 for ; Sun, 17 Mar 2013 15:01:29 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id rr4so5865970pbb.27 for ; Sun, 17 Mar 2013 15:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lv5BuExg9dJP/Q12iViKVVWtVUzuvSo+TnfsdEZrnYc=; b=kGT+3gqoFoOitsNORRVwfJSFqoPIE/Uldnwdewn2cMb14QaOmuflBcCmCCIw3W28Df p35yiHEZGkVLJO5/i6vw4OqPqS5s21fxr3CCenWGdEzX4n5H1NtsYu6qb//jZ1GXBlra 7YfXZUyIW3uTLvc3dNHs4fbPz1mziziuQCfogO9uTc3C92mSDNXQiJhBiq+rYwk71flN 4J6Ty6kS0+5C4TU4PLn4+BGdDp6xJv8b/DKv3l8hYCMPYPMbuB383FfbNjFe5wchU01g TE3yXx9yfxxRx1UswqKSKu1v/c1nvzMsX+bcVh0fPexAygo6ncRzwXHIk4r8RFD89c4G xFFQ== MIME-Version: 1.0 X-Received: by 10.68.196.1 with SMTP id ii1mr29957978pbc.93.1363557689490; Sun, 17 Mar 2013 15:01:29 -0700 (PDT) Received: by 10.68.33.132 with HTTP; Sun, 17 Mar 2013 15:01:29 -0700 (PDT) In-Reply-To: <51460DE0.3080809@gmail.com> References: <51460DE0.3080809@gmail.com> Date: Sun, 17 Mar 2013 23:01:29 +0100 Message-ID: From: Abdussalam Baryun To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Cc: "its@ietf.org" Subject: Re: [its] Updated draft Charter proposal after Orlando X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:01:31 -0000 Hi Alex IMO, the charter is representing well the ITS, and I think we need input from some related ADs or WG chairs, because this WG may involve cross-section with other IETF-work or other OSD-work (as mentioned in charter). If there are discussions will be done at other lists related to this charter please inform this list by reference, so we can focus the discussion for progress of this WG. AB On 3/17/13, Alexandru Petrescu wrote: > Dears, > > In Orlando we discussed with several participants, and we further > improved the draft Charter proposal. See attached the Charter proposal > frozen after Orlando. > > Most notably it contains security aspects, and re-formulation of certain > paragraphs to look more like a Charter rather than requirements for a > particular design. > > The multiple-interfaces discussion is not much reflected because I > couldnt yet frame my mind clearly around it. This is still open. > > The n-hop routing protocols MANET - is reflected a bit in the Charter > Proposal, but it is also still open. > > The overall discussion is open to update this proposal in the period > from now until Berlin. > > Yours, > > Alex > From wes@mti-systems.com Sun Mar 17 18:07:44 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 6B1CE21F8C1F for ; Sun, 17 Mar 2013 18:07:44 -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 n1mB-8VrQnbp for ; Sun, 17 Mar 2013 18:07:44 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB921F8A3F for ; Sun, 17 Mar 2013 18:07:43 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r2I17gAq003246 for ; Sun, 17 Mar 2013 21:07:42 -0400 Received: (qmail 14206 invoked by uid 0); 18 Mar 2013 01:07:42 -0000 Received: from unknown (HELO ?192.168.1.100?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 18 Mar 2013 01:07:42 -0000 Message-ID: <514668DC.1030901@mti-systems.com> Date: Sun, 17 Mar 2013 21:07:40 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Kevin Lahey References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> In-Reply-To: <20130313172112.671bcf40@temprokkaku> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 01:07:44 -0000 On 3/13/2013 8:21 PM, Kevin Lahey wrote: > On Wed, 13 Mar 2013 10:06:34 -0800 > Rex Buddenberg wrote: > >> The basic design of IP (and especially TCP) accommodates. TCP is >> designed to deal with packets that arrive out of order, which is likely >> if you have diverse routes. > > Careful -- TCP is actually very sensitive to reordering. Fast > retransmission will be triggered after a small number of duplicate > ACKs, which are triggered when a packet arrives out of order (or > is lost). Some stacks can recognize repeated reorderings and > relax this rule, at the cost of lower performance. > > The multipath schemes with which I'm familiar try hard to steer > all packets in a flow to the same link. > I agree that for normal TCP, multipath routing that causes reordering is a really bad idea. Recently, Multipath TCP, (MPTCP) was developed which handles the use of multiple links in the transport layer, and avoids the issues that normal TCP would have. MPTCP can utilize multiple L3 paths simultaneously: http://tools.ietf.org/html/rfc6824 This requires the end-host to have multiple addresses visible to it, which could be a design constraint on the way the mobile network is setup. -- Wes Eddy MTI Systems From alexandru.petrescu@gmail.com Sun Mar 17 19:52:16 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0159E21F874E for ; Sun, 17 Mar 2013 19:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.143, 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 f0nn11E2fd8V for ; Sun, 17 Mar 2013 19:52:15 -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 4F04021F84F9 for ; Sun, 17 Mar 2013 19:52:13 -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 r2I2qBpg026102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 03:52:11 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2I2qAP7001923; Mon, 18 Mar 2013 03:52:11 +0100 (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 r2I2qAAL021059; Mon, 18 Mar 2013 03:52:10 +0100 Message-ID: <5146815A.2070104@gmail.com> Date: Mon, 18 Mar 2013 03:52:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Abdussalam Baryun References: <51460DE0.3080809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "its@ietf.org" Subject: Re: [its] Updated draft Charter proposal after Orlando X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 02:52:16 -0000 Le 17/03/2013 23:01, Abdussalam Baryun a écrit : > Hi Alex > > IMO, the charter is representing well the ITS, and I think we need > input from some related ADs or WG chairs, because this WG may > involve cross-section with other IETF-work or other OSD-work (as > mentioned in charter). ADs and several WG Chairs follow this list. We need to further trim down the Charter, as it's quite comprehensive right now. > If there are discussions will be done at other lists related to this > charter please inform this list by reference, so we can focus the > discussion for progress of this WG. All issues about this Charter proposal would need to be now discussed here on this email list its. Alex > > AB > > On 3/17/13, Alexandru Petrescu wrote: >> Dears, >> >> In Orlando we discussed with several participants, and we further >> improved the draft Charter proposal. See attached the Charter >> proposal frozen after Orlando. >> >> Most notably it contains security aspects, and re-formulation of >> certain paragraphs to look more like a Charter rather than >> requirements for a particular design. >> >> The multiple-interfaces discussion is not much reflected because I >> couldnt yet frame my mind clearly around it. This is still open. >> >> The n-hop routing protocols MANET - is reflected a bit in the >> Charter Proposal, but it is also still open. >> >> The overall discussion is open to update this proposal in the >> period from now until Berlin. >> >> Yours, >> >> Alex >> > > From buddenbergr@gmail.com Sun Mar 17 20:07: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 B6CAF21F8CAE for ; Sun, 17 Mar 2013 20:07:12 -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 vBDXqmuWUFgm for ; Sun, 17 Mar 2013 20:07:11 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8B21F89FC for ; Sun, 17 Mar 2013 20:07:11 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp2so6013522pbb.20 for ; Sun, 17 Mar 2013 20:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=3am+3jmGUKCtnSpUfGLf/u/7qI2syYFf4Pl65DfH8yc=; b=rii9ydse/HYR2MOOv/nReJkUk9GObSxd1V62WMu8oILp8yNQAbmw6eYJomK/T96mn8 cNclF/R364Oqpzz6W4q1MAiUzQrdUsGvE4aZ2mz80tEOHKMMkI6lW4qHKrDrkKEvTnQ9 y6oCuTj2az7wLrw4KMTChRrjcLX2WWagwy+0CkfLctiLI/77N28ABrDDeiJtEFG0A3dv o5X/3DxopUM7+ZEnE+S7QiXs7KLz9KOLgDL98tL2qk9phBuFPEAS5jcLVxuRy1kI4a6Z i8r5amQqbMZWgoFKTxsVPKi6B7d7VS/O9KB59JgSVvxC6UwAdfZjIKrN/iRtfKpSRPTf yPsQ== X-Received: by 10.68.224.1 with SMTP id qy1mr31570425pbc.169.1363576031221; Sun, 17 Mar 2013 20:07:11 -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 ESMTPS id yr10sm6389555pab.6.2013.03.17.20.07.09 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Mar 2013 20:07:10 -0700 (PDT) Message-ID: <1363576028.1813.421.camel@localhost> From: Rex Buddenberg To: Wesley Eddy Date: Sun, 17 Mar 2013 19:07:08 -0800 In-Reply-To: <514668DC.1030901@mti-systems.com> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Kevin Lahey , its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 03:07:12 -0000 below On Sun, 2013-03-17 at 21:07 -0400, Wesley Eddy wrote: > On 3/13/2013 8:21 PM, Kevin Lahey wrote: > > On Wed, 13 Mar 2013 10:06:34 -0800 > > Rex Buddenberg wrote: > > > >> The basic design of IP (and especially TCP) accommodates. TCP is > >> designed to deal with packets that arrive out of order, which is likely > >> if you have diverse routes. > > > > Careful -- TCP is actually very sensitive to reordering. Fast > > retransmission will be triggered after a small number of duplicate > > ACKs, which are triggered when a packet arrives out of order (or > > is lost). Some stacks can recognize repeated reorderings and > > relax this rule, at the cost of lower performance. > > > > The multipath schemes with which I'm familiar try hard to steer > > all packets in a flow to the same link. > > > > > I agree that for normal TCP, multipath routing that causes reordering > is a really bad idea. I think you have the problem backwards. Rather than fit the plumbing to the transport protocol, we need to have a transport protocol that handles the reality of the media. Radio is hard. It always will be hard (at least harder than wireline). - four orders of magnitude less capacity (mbits vice gbits) - four orders of magnitued more noise (= bit errors, = damaged and discarded packets). - a number of mission critical applications lining up (my favorite use case is 'instrumented ambulance' where high availability is a driving requirement (probably the dominant one). > > Recently, Multipath TCP, (MPTCP) was developed which handles the use > of multiple links in the transport layer, and avoids the issues that > normal TCP would have. I suspect that rather than thrash TCP, we have a situation where a lot of data will be multiCAST in nature. So we might be better off thrashing NORM instead. > > MPTCP can utilize multiple L3 paths simultaneously: > http://tools.ietf.org/html/rfc6824 > > This requires the end-host to have multiple addresses visible to it, > which could be a design constraint on the way the mobile network is > setup. > From wes@mti-systems.com Sun Mar 17 21:40: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 5445821F8673 for ; Sun, 17 Mar 2013 21:40:39 -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 b1FPXuiuO5V3 for ; Sun, 17 Mar 2013 21:40:38 -0700 (PDT) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 58F1721F8667 for ; Sun, 17 Mar 2013 21:40:38 -0700 (PDT) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r2I4eb50004122 for ; Mon, 18 Mar 2013 00:40:37 -0400 Received: (qmail 9413 invoked by uid 0); 18 Mar 2013 04:40:37 -0000 Received: from unknown (HELO ?192.168.1.100?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 18 Mar 2013 04:40:37 -0000 Message-ID: <51469AC3.4050702@mti-systems.com> Date: Mon, 18 Mar 2013 00:40:35 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Rex Buddenberg References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <1363576028.1813.421.camel@localhost> In-Reply-To: <1363576028.1813.421.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kevin Lahey , its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 04:40:39 -0000 On 3/17/2013 11:07 PM, Rex Buddenberg wrote: > below > > On Sun, 2013-03-17 at 21:07 -0400, Wesley Eddy wrote: >> On 3/13/2013 8:21 PM, Kevin Lahey wrote: >>> On Wed, 13 Mar 2013 10:06:34 -0800 >>> Rex Buddenberg wrote: >>> >>>> The basic design of IP (and especially TCP) accommodates. TCP is >>>> designed to deal with packets that arrive out of order, which is likely >>>> if you have diverse routes. >>> >>> Careful -- TCP is actually very sensitive to reordering. Fast >>> retransmission will be triggered after a small number of duplicate >>> ACKs, which are triggered when a packet arrives out of order (or >>> is lost). Some stacks can recognize repeated reorderings and >>> relax this rule, at the cost of lower performance. >>> >>> The multipath schemes with which I'm familiar try hard to steer >>> all packets in a flow to the same link. >>> >> >> >> I agree that for normal TCP, multipath routing that causes reordering >> is a really bad idea. > > I think you have the problem backwards. Rather than fit the plumbing to > the transport protocol, we need to have a transport protocol that > handles the reality of the media. Well, I don't think the group is chartering to include new transport work, so doing things that break badly with existing transports seems like a poor idea. All packets within a flow need to either go over the same link, or some kind of tunnel protocol for fixing reordering in the transport stream is necessary. >> >> Recently, Multipath TCP, (MPTCP) was developed which handles the use >> of multiple links in the transport layer, and avoids the issues that >> normal TCP would have. > > I suspect that rather than thrash TCP, we have a situation where a lot > of data will be multiCAST in nature. So we might be better off > thrashing NORM instead. If there are actually applications using NORM for ITS ... that doesn't seem to be the common assumption. -- Wes Eddy MTI Systems From Ronald.intVelt@tno.nl Mon Mar 18 03:29:25 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 A955121F8C93 for ; Mon, 18 Mar 2013 03:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 yGTiqxwnAI0B for ; Mon, 18 Mar 2013 03:29:25 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id C0F4121F8C9E for ; Mon, 18 Mar 2013 03:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,863,1355094000"; d="scan'208";a="977364" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 18 Mar 2013 11:29:23 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.241]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 11:29:23 +0100 From: "Velt, R. (Ronald) in 't" To: Wesley Eddy , Kevin Lahey Thread-Topic: [its] simultaneous use of multiple radios or not Thread-Index: AQHOIpECZsGRtlT+UkuqisTpeEBU1JiqlBMAgACq3eA= Date: Mon, 18 Mar 2013 10:29:21 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> In-Reply-To: <514668DC.1030901@mti-systems.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:29:25 -0000 Hi, >-----Original Message----- >From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of >Wesley Eddy >Sent: maandag 18 maart 2013 2:08 >To: Kevin Lahey >Cc: its@ietf.org >Subject: Re: [its] simultaneous use of multiple radios or not > >On 3/13/2013 8:21 PM, Kevin Lahey wrote: >> On Wed, 13 Mar 2013 10:06:34 -0800 >> Rex Buddenberg wrote: >> >>> The basic design of IP (and especially TCP) accommodates. TCP is >>> designed to deal with packets that arrive out of order, which is >>> likely if you have diverse routes. >> >> Careful -- TCP is actually very sensitive to reordering. Fast >> retransmission will be triggered after a small number of duplicate >> ACKs, which are triggered when a packet arrives out of order (or is >> lost). Some stacks can recognize repeated reorderings and relax this >> rule, at the cost of lower performance. >> >> The multipath schemes with which I'm familiar try hard to steer all >> packets in a flow to the same link. >> > > >I agree that for normal TCP, multipath routing that causes reordering is a= really >bad idea. > >Recently, Multipath TCP, (MPTCP) was developed which handles the use of >multiple links in the transport layer, and avoids the issues that normal T= CP >would have. > >MPTCP can utilize multiple L3 paths simultaneously: >http://tools.ietf.org/html/rfc6824 > >This requires the end-host to have multiple addresses visible to it, which= could >be a design constraint on the way the mobile network is setup. Right. Can I ask what model is being assumed here? Is this entity with mult= iple radio interfaces supposed to be a router or a multi-homed host? I tend= to think it is the former, with hosts residing on some in-vehicle (etherne= t or CAN-bus based) link attached to it. If that's the case, one would have= to perform some special tricks to make the hosts see multiple source addre= sses. = Ronald in 't Velt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From alexandru.petrescu@gmail.com Mon Mar 18 08:18: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 1D3DA21F8F4F for ; Mon, 18 Mar 2013 08:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 frr9HlSepm23 for ; Mon, 18 Mar 2013 08:18:31 -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 2A94B21F8F35 for ; Mon, 18 Mar 2013 08:18:30 -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 r2IFIUHM001039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Mar 2013 16:18:30 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2IFIUTn021861 for ; Mon, 18 Mar 2013 16:18:30 +0100 (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 r2IFISdq007889 for ; Mon, 18 Mar 2013 16:18:29 +0100 Message-ID: <5147301F.7070605@gmail.com> Date: Mon, 18 Mar 2013 16:17:51 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <1363576028.1813.421.camel@localhost> <51469AC3.4050702@mti-systems.com> In-Reply-To: <51469AC3.4050702@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:18:32 -0000 Le 18/03/2013 05:40, Wesley Eddy a écrit : > On 3/17/2013 11:07 PM, Rex Buddenberg wrote: >> below >> >> On Sun, 2013-03-17 at 21:07 -0400, Wesley Eddy wrote: >>> On 3/13/2013 8:21 PM, Kevin Lahey wrote: >>>> On Wed, 13 Mar 2013 10:06:34 -0800 Rex Buddenberg >>>> wrote: >>>> >>>>> The basic design of IP (and especially TCP) accommodates. >>>>> TCP is designed to deal with packets that arrive out of >>>>> order, which is likely if you have diverse routes. >>>> >>>> Careful -- TCP is actually very sensitive to reordering. Fast >>>> retransmission will be triggered after a small number of >>>> duplicate ACKs, which are triggered when a packet arrives out >>>> of order (or is lost). Some stacks can recognize repeated >>>> reorderings and relax this rule, at the cost of lower >>>> performance. >>>> >>>> The multipath schemes with which I'm familiar try hard to >>>> steer all packets in a flow to the same link. >>>> >>> >>> >>> I agree that for normal TCP, multipath routing that causes >>> reordering is a really bad idea. >> >> I think you have the problem backwards. Rather than fit the >> plumbing to the transport protocol, we need to have a transport >> protocol that handles the reality of the media. > > > Well, I don't think the group is chartering to include new transport > work, Right - it's not, unless we want it to. If enough interest is expressed that could be done as well. There was a proposal from ISO participant to consider an ISO standard under development - FNTP. I have had it in the Charter proposal under the form of reviewing FNTP for ISO. But then I was told that this may not be a specific Working Item in a WG - to which I agree. So I removed it. But let me write another email about this specific topic - should we review documents for other SDOs and have that as specific WG items? Alex so doing things that break badly with existing transports seems > like a poor idea. All packets within a flow need to either go over > the same link, or some kind of tunnel protocol for fixing reordering > in the transport stream is necessary. > > >>> >>> Recently, Multipath TCP, (MPTCP) was developed which handles the >>> use of multiple links in the transport layer, and avoids the >>> issues that normal TCP would have. >> >> I suspect that rather than thrash TCP, we have a situation where a >> lot of data will be multiCAST in nature. So we might be better >> off thrashing NORM instead. > > > If there are actually applications using NORM for ITS ... that > doesn't seem to be the common assumption. > > From alexandru.petrescu@gmail.com Mon Mar 18 08:22: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 A78D321F8F98 for ; Mon, 18 Mar 2013 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=0.131, 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 3F2WXOdAApBS for ; Mon, 18 Mar 2013 08:22:58 -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 9A35B21F8F8C for ; Mon, 18 Mar 2013 08:22:57 -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 r2IFMtNR026674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Mar 2013 16:22:56 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2IFMtAr023832 for ; Mon, 18 Mar 2013 16:22:55 +0100 (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 r2IFMtEB004497 for ; Mon, 18 Mar 2013 16:22:55 +0100 Message-ID: <5147312A.2070102@gmail.com> Date: Mon, 18 Mar 2013 16:22:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:22:58 -0000 In the past, there were several public and private requests to review documents of external SDOs related to vehicular networks. E.g. FNTP (a transport protocol at ISO) and GeoNetworking (an IPv6-friendly network-layer protocol at ETSI ITS). There may be others. Do you think these should make into WG items for ITS? Alex From alexandru.petrescu@gmail.com Mon Mar 18 08:50:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D721F8BC5 for ; Mon, 18 Mar 2013 08:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.128, 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 ZxnOMfS8v3Kc for ; Mon, 18 Mar 2013 08:50: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 B9AE221F8BB3 for ; Mon, 18 Mar 2013 08:50:55 -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 r2IFoo92025373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 16:50:50 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2IFoneU004928; Mon, 18 Mar 2013 16:50:50 +0100 (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 r2IFojmM028499; Mon, 18 Mar 2013 16:50:49 +0100 Message-ID: <514737B0.2060603@gmail.com> Date: Mon, 18 Mar 2013 16:50:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "JP Vasseur (jvasseur)" References: <513FA5E2.2080303@gmail.com> <1363126933.1813.330.camel@localhost><51409FFF.2010309@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1004FEA9@xmb-aln-x03.cisco.com> <20BDCA7BA42F448A834B973FCDE58B04@SRA4> <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333C9C0@xmb-rcd-x02.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , "" , Joe Macker , "Stan Ratliff \(sratliff\)" , "" , "Ivancic, William D. \(GRC-RHN0\)" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:50:57 -0000 Le 15/03/2013 19:03, JP Vasseur (jvasseur) a écrit : > Hi, > > This is clearly a working intersecting two WG: MANET for sure, and > ROLL for routing, since RPL has been used for car to car > communication. JP, I am happy to learn that RPL has been used for car to car communications. RPL is based on ND messages and there are other protocols based on ND messages which have been used in car to car communications. Intersection is clearly there in these ND messages. Alex > > Cheers. > > JP. > > On Mar 13, 2013, at 9:19 PM, Richard Roy wrote: > >> Definitely plan for multiple simultaneous radio links. Whether or >> not a particular ITS station (ITS terminology for a (possibly >> mobile) network node) can support such simultaneous transmission >> will be assessed by ITS station management, and if for some reason >> the radio modules interfere with each other on Tx, simultaneous Tx >> from both will be prohibited. However, this is not something that >> concerns the network layer protocols directly and for the purposes >> of this effort, I suggest you just assume simultaneous Tx. ITS >> stations assume multiple flows (to the same or different app >> processes) and ITS station management manages the communication >> resources in realtime. The issue is getting the back end networking >> protocols to set up and support these flows. >> >> RR >> >>> -----Original Message----- From: Stan Ratliff (sratliff) >>> [mailto:sratliff@cisco.com] Sent: Wednesday, March 13, 2013 9:15 >>> AM To: Alexandru Petrescu; Joe Macker; JP Vasseur (jvasseur) Cc: >>> Rex Buddenberg; its@ietf.org; Ivancic, William D. (GRC-RHN0) >>> Subject: Re: [its] simultaneous use o fmultiple radios or not >>> >>> Alex, >>> >>> This describes almost exactly the deployments I've worked with. >>> It is yet another reason I say that starting a new working group >>> for the ITS effort is over-kill. Please don't get me wrong - this >>> is interesting work, and should be addressed. However, it needs >>> to be done (IMO) within the auspices of the MANET working group. >>> Possibly ROLL, but I'm thinking MANET is a better fit. >>> >>> Regards, Stan >>> >>> On Mar 13, 2013, at 11:49 AM, Alexandru Petrescu wrote: >>> >>>> Ok, >>>> >>>> So we talk radios as egress interfaces. I.e. have several >>>> egress interfaces on a Mobile Router (gateway in the vehicle). >>>> When one of the radio fails, the MR uses another one, such that >>>> the Internet is always available to vehicle. >>>> >>>> This sounds reasonable. >>>> >>>> It is for me a sort of architectural requirement, to be >>>> strongly kept in mind, for designing any new protocol. >>>> >>>> Le 12/03/2013 23:22, Rex Buddenberg a écrit : >>>>> Alex, >>>>> >>>>> Your numbers are essentially correct -- radio links are about >>>>> 10-4 smaller sized than wired ones. >>>>> >>>>> But a more powerful argument for multiple interfaces is >>>>> availability. In addition to radio being four orders of >>>>> magnitude less capacious than wired, radio has about 4 orders >>>>> of magnitude higher error rates. There are myriad reasons >>>>> that a radio link of whatever flavor will go away. For short >>>>> term or longer term duration. >>>>> >>>>> So the obvious way to counter this is to have >1 radio link. >>>>> The arithmetic to support is standard high Ao engineering >>>>> stuff. >>>>> >>>>> >>>>>> I am not aware of any other draft at IETF doing >>>>>> simultaneous use of multiple interfaces for bandwidth >>>>>> augmentation. >>>>>> >>>>> >>>>> Not sure what you're trying to say with this quote: every >>>>> router has multiple interfaces and they are often used in >>>>> parallel for bandwidth augmentation. This is an inherent >>>>> part of IP ... RFC 791. Getting them to behave properly has >>>>> sometimes been a problem, but it's generally outside of the >>>>> standardization realm. >>>> >>>> I wonder what the others think about this? (I do have some >>>> idea, but not sure I as contributor would like to do anything >>>> about this particular topic right now here, because other >>>> things here in ITS are more mature.) >>>> >>>>> Current reality: US Navy has a router on each ship. There >>>>> are usually three LANs on the ship side (segregation for >>>>> security reasons, VPN). But there are multiple interfaces on >>>>> the radio side -- one for each satcom channel, for example. >>>> >>>> Sure... this not surprising and is needed so! >>>> >>>> However, what is the mechanism used by US Navy to make all >>>> these egress interfaces look as one single interface in the >>>> router on the ship? What is the scheduling intelligence to >>>> transparently divide a traffic flow evenly among all these >>>> interfaces? (without trolling, I think there isnt any; I think >>>> they put one application on one radio, another application on >>>> another radio, and so on) >>>> >>>>> Will's question is easily answered: yes. >>>> >>>> Yes, I agree. >>>> >>>> And from that answer, what we need right now is to know how to >>>> put this in a Charter - is it by making it into a Problem >>>> Statement such that scenarios and solutions for this particular >>>> multi-interface scenario be developped? Or just have it there >>>> as a design principle? Or just to reuse some existing >>>> protocol? >>>> >>>> Knowing that there are already two things that are maturing as >>>> we speak and that should get more attention in the Charter >>>> proposal: V2V and addressing. >>>> >>>> And that we should focus the Charter proposal. >>>> >>>> And that for any thing that we put in the Charter proposal we >>>> shoudl have commitment of effort to write drafts. >>>> >>>> Alex >>>> >>>>> >>>>> >>>>> >>>>> On Tue, 2013-03-12 at 23:02 +0100, Alexandru Petrescu wrote: >>>>>> Will, >>>>>> >>>>>> Thanks for the comment. >>>>>> >>>>>> I have inserted something about this in the Draft Charter >>>>>> Proposal, but let me discuss. >>>>>> >>>>>> The simultaneous use of multiple egress interfaces is a >>>>>> technique allowing to expand the available bandwidth for a >>>>>> vehicle connection. >>>>>> >>>>>> A known car network problem is the discrepancy between the >>>>>> outside bandwidth and the inside bandwith. The egress >>>>>> interface is typically a cellular link, which is originally >>>>>> intended for unique personal use; that is bandwidth >>>>>> 50Mbit/s and latency 50ms (e.g. LTE). But within same >>>>>> vehicle, one uses a Ethernet or WiFi links, which may use >>>>>> 300Mbit/s or even 1Gbit/s. If all the devices within the >>>>>> vehicle talk to the Servers at the same time, it becomes >>>>>> obvious that the LTE link is a bottleneck. >>>>>> >>>>>> The problem is specific to vehicular networks, and >>>>>> different from office networks. In office networks the >>>>>> upstream link is typically much higher bandwidth than the >>>>>> link for office PCs. E.g. 10GByte vs 1GByte Ethernet. In >>>>>> vehicular networks, the cellular link is the bottleneck >>>>>> because it is much less bandwidth than the in-car link. >>>>>> >>>>>> To solve this, there exist approaches where one proposes to >>>>>> use several such egress external links on the vehicle, at >>>>>> the same time. This would add up the bandwidth; e.g. use >>>>>> 10 USB LTE dongles to achieve an aggregated bandwidth of >>>>>> 500Mbit/s towards the infrastructure. This would enlarge >>>>>> this bottleneck. >>>>>> >>>>>> At IETF, there is this >>>>>> draft-ietf-mip4-multiple-tunnel-support-05.txt "Flow >>>>>> Binding Support for Mobile IPv4" that I co-author there. I >>>>>> dont think it advances ok, but should advance there. >>>>>> >>>>>> However, that draft is not really corresponding to my >>>>>> intention about simultaneous use of multiple interfaces. >>>>>> It's more an evolution of what 'flow binding updates' means >>>>>> to Mobile IPv6. >>>>>> >>>>>> I am not aware of any other draft at IETF doing >>>>>> simultaneous use of multiple interfaces for bandwidth >>>>>> augmentation. >>>>>> >>>>>> If you read until here, then please reply to see whether >>>>>> there is interest in developping such solution. This would >>>>>> mean to add it in the Charter Proposal, and commit to some >>>>>> work items. We are already very short on space left about >>>>>> new things to do. >>>>>> >>>>>> Yours, >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> Le 12/03/2013 00:26, Ivancic, William D. (GRC-RHN0) a écrit >>>>>> : >>>>>>> Propose >>>>>>> >>>>>>> From: "In this system, disjoint and heterogeneous radio >>>>>>> systems are used (e.g. a vehicle uses two different >>>>>>> radios)." >>>>>>> >>>>>>> To: In this system, disjoint and heterogeneous radio >>>>>>> systems are used (e.g. a vehicle uses two OR MORE >>>>>>> different radios SIMULTANEOUSLY)." >>>>>>> >>>>>>> Question: >>>>>>> >>>>>>> Do you want simultaneous use of multiple radios or not? >>>>>>> >>>>>>> Will Ivancic >>>>>>> >>>>>>> >>>>>>>> From: Alexandru Petrescu >>>>>>>> Date: Mon, 11 Mar 2013 17:42:14 -0500 To: >>>>>>>> "its@ietf.org" Subject: [its] Updated >>>>>>>> Draft Charter proposal >>>>>>>> >>>>>>>> In this system, disjoint and heterogeneous radio >>>>>>>> systems are used (e.g. a vehicle uses two different >>>>>>>> radios). >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ its mailing >>>>>> 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 Ted.Lemon@nominum.com Mon Mar 18 08:52: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 966A221F8BDE for ; Mon, 18 Mar 2013 08:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 eV-5Pz3LTxie for ; Mon, 18 Mar 2013 08:52:11 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2A321F8BB3 for ; Mon, 18 Mar 2013 08:52:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUUc4KpHvc1xttYJIc2LaoSQj+X/Y0Kmk@postini.com; Mon, 18 Mar 2013 08:52:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CE7491B8E23 for ; Mon, 18 Mar 2013 08:52:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C7B97190043; Mon, 18 Mar 2013 08:52:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 08:52:10 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [its] Should we have WG items that are reviews of vehicular SDO documents? Thread-Index: AQHOI+x59nh/yXiCU0eim+/f3S1I+pisDpiA Date: Mon, 18 Mar 2013 15:52:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> References: <5147312A.2070102@gmail.com> In-Reply-To: <5147312A.2070102@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:52:11 -0000 On Mar 18, 2013, at 11:22 AM, Alexandru Petrescu wrote: > Do you think these should make into WG items for ITS? Yes. From jonghyouk@gmail.com Mon Mar 18 09:34:41 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675AF21F8F00 for ; Mon, 18 Mar 2013 09:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.716, 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 nVfvFwPpnkVA for ; Mon, 18 Mar 2013 09:34:33 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04C21F89CB for ; Mon, 18 Mar 2013 09:31:58 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id pb11so4549833veb.33 for ; Mon, 18 Mar 2013 09:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9BMZ4ZkE9LhB1mbkhShtGPO8O7a8nrFbPN8xPd22l3U=; b=h8lXFi+5CkMxTiggFck3/LGQcm6uXy/AkoLmL3WwIpSGDoCBxgk29tqv9v44MQ3z9g Twcjgxs2OuVuZUpESAzGVwfxEIqWaKIHCzQ2MrGuTd+4ESriYfNTuESBee/i6M+9Kww1 j724F4ahYwQ/mgo7QDbns1IXGPLST9qDptKRq2gaOnK+YX1GcH8xVKcwTslN+kgwVz+Q 9DCuTELN3BjZwjRnj3nzJ+wqRwYiWIZwIzgdZWnMa5L8PUTct5dasRSz2vZcZWcSyipg KahEBVq1C9riDyDUtBwXgvaTxRP2GSRFHkfqETOZHtISOCAcA4d9jhqiRqLmug2Lb0uz 0uRQ== MIME-Version: 1.0 X-Received: by 10.58.186.241 with SMTP id fn17mr20780591vec.8.1363624317985; Mon, 18 Mar 2013 09:31:57 -0700 (PDT) Received: by 10.59.4.1 with HTTP; Mon, 18 Mar 2013 09:31:57 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> References: <5147312A.2070102@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> Date: Mon, 18 Mar 2013 17:31:57 +0100 Message-ID: From: Jong-Hyouk Lee To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b6dcf4614ac8c04d835874b Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:34:41 -0000 --047d7b6dcf4614ac8c04d835874b Content-Type: text/plain; charset=UTF-8 Hi Alex, Just you need to be clear. Making what to be WG items? If you asking "reviewing of the standardized documents (related to IP) by other SDO to be WG items here", definitely no! We could review and give some comments or revision requests to other SDO when we would find something wrong there. Otherwise, why do we officially study and do review for other SDO here without official requests from them? Cheers. On Mon, Mar 18, 2013 at 4:52 PM, Ted Lemon wrote: > On Mar 18, 2013, at 11:22 AM, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > > Do you think these should make into WG items for ITS? > > Yes. > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --047d7b6dcf4614ac8c04d835874b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alex,

Just you need to be clear. Making what to be WG= items? If you asking "reviewing of the standardized documents (relate= d to IP) by other SDO to be WG items here", definitely no!

We could review and give some comments or revision requests = to other SDO when we would find something wrong there. Otherwise, why do we= officially study and do review for other SDO here without official request= s from them?

Cheers.

On Mon, Mar 1= 8, 2013 at 4:52 PM, Ted Lemon <Ted.Lemon@nominum.com> wr= ote:
On Mar 18, 2013, at 11:22 = AM, Alexandru Petrescu <= alexandru.petrescu@gmail.com> wrote:
> Do you think these should make into WG items for ITS?

Yes.

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



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com
--047d7b6dcf4614ac8c04d835874b-- From Ted.Lemon@nominum.com Mon Mar 18 09:38:20 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B219D21F8F16 for ; Mon, 18 Mar 2013 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NAuBCXd1zxOd for ; Mon, 18 Mar 2013 09:38:12 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E0FC521F8EFE for ; Mon, 18 Mar 2013 09:36:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUUdClEZLTa2pkD5B1iKjMXfdV/kS1TW/@postini.com; Mon, 18 Mar 2013 09:36:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 988401B8E1F for ; Mon, 18 Mar 2013 09:36:36 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7F551190043; Mon, 18 Mar 2013 09:36:36 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 09:36:36 -0700 From: Ted Lemon To: Jong-Hyouk Lee Thread-Topic: [its] Should we have WG items that are reviews of vehicular SDO documents? Thread-Index: AQHOI/YcYGgF1Z66RU6MDZvkNP8vE5isGu6A Date: Mon, 18 Mar 2013 16:36:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> References: <5147312A.2070102@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3632FD409B44EB49941089A22447E18A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:38:20 -0000 On Mar 18, 2013, at 12:31 PM, Jong-Hyouk Lee wrote: > Just you need to be clear. Making what to be WG items? If you asking "rev= iewing of the standardized documents (related to IP) by other SDO to be WG = items here", definitely no! >=20 > We could review and give some comments or revision requests to other SDO = when we would find something wrong there. Otherwise, why do we officially s= tudy and do review for other SDO here without official requests from them? What I was agreeing to was surveying documents produced by other SDOs to se= e if they relate to the proposed work, and of course liaising with the othe= r SDOs about the work that's done in its, if its winds up being chartered. = Sorry if I misunderstood the question. From jonghyouk@gmail.com Mon Mar 18 09:39: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 4249021F8C4F for ; Mon, 18 Mar 2013 09:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.478, 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 bRBgJh2tJI-J for ; Mon, 18 Mar 2013 09:39:27 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB921F8F9F for ; Mon, 18 Mar 2013 09:38:22 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so4618494vea.29 for ; Mon, 18 Mar 2013 09:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j23XbT67edugMO06pDGCyLAxPJiPZrV4yh0X4y9zLpc=; b=hB2xH19XrpzhwHuwiyhgcwspwVEA+dIrAzxmLNbQmwyTGrb6xg8pniGzS6Ob2xaTYS FKOguprreYPVh6T+73fcNfzJUmm/EZdoaRJOsoF7fh97ni0ofJq/TV8bbkTh3q0/oQ3K fgR85pjHPaZESsk4DDDE+uSfF+0aUkJ39t1T2U9d59E2ruEwsw2MdFyEc8F2cs+VwXBb trg52bwgX/fCPp8In29BFtclsxyOXsu5BjMwlGzsEz2n+u9Er7psawLM0ybfvYfEGDy9 pFV9RDp6RAap9Ai1/oclo7ecjCbnUXNUC4Udj6eQH/fzBAMrpZ+vAoCQfSMLKrmE5XvZ tM+g== MIME-Version: 1.0 X-Received: by 10.52.67.75 with SMTP id l11mr17951879vdt.29.1363624701609; Mon, 18 Mar 2013 09:38:21 -0700 (PDT) Received: by 10.59.4.1 with HTTP; Mon, 18 Mar 2013 09:38:21 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> References: <5147312A.2070102@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> Date: Mon, 18 Mar 2013 17:38:21 +0100 Message-ID: From: Jong-Hyouk Lee To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf307f3a40f264e804d8359d80 Cc: Alexandru Petrescu , "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:39:35 -0000 --20cf307f3a40f264e804d8359d80 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 18, 2013 at 5:36 PM, Ted Lemon wrote: > On Mar 18, 2013, at 12:31 PM, Jong-Hyouk Lee wrote: > > Just you need to be clear. Making what to be WG items? If you asking > "reviewing of the standardized documents (related to IP) by other SDO to be > WG items here", definitely no! > > > > We could review and give some comments or revision requests to other SDO > when we would find something wrong there. Otherwise, why do we officially > study and do review for other SDO here without official requests from them? > > What I was agreeing to was surveying documents produced by other SDOs to > see if they relate to the proposed work, and of course liaising with the > other SDOs about the work that's done in its, if its winds up being > chartered. Yepp, sure! > Sorry if I misunderstood the question. > > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --20cf307f3a40f264e804d8359d80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2013 at 5:36 PM, Ted Lem= on <Ted.Lemon@nominum.com> wrote:
On Mar 18, 2013, at 12:31 PM, Jong-Hyouk Lee <jonghyouk@gmail.com> wrote:
> Just you need to be clear. Making what to be WG items? If you asking &= quot;reviewing of the standardized documents (related to IP) by other SDO t= o be WG items here", definitely no!
>
> We could review and give some comments or revision requests to other S= DO when we would find something wrong there. Otherwise, why do we officiall= y study and do review for other SDO here without official requests from the= m?

What I was agreeing to was surveying documents produced by other SDOs= to see if they relate to the proposed work, and of course liaising with th= e other SDOs about the work that's done in its, if its winds up being c= hartered. =C2=A0

Yepp, sure!=C2=A0
=C2=A0
Sorry if I misunderstood the question.




--
RSM Dep= artment, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewher= e between /dev/null and /dev/random

#email:=C2=A0j= onghyouk (at) gmail (dot) com
--20cf307f3a40f264e804d8359d80-- From alexandru.petrescu@gmail.com Mon Mar 18 10:21: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 6191C21F900B for ; Mon, 18 Mar 2013 10:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 07qnb+TmUXgo for ; Mon, 18 Mar 2013 10:21:10 -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 1FC0121F8FFD for ; Mon, 18 Mar 2013 10:21:07 -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 r2IHL6iS000896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Mar 2013 18:21:06 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2IHL6ae002284; Mon, 18 Mar 2013 18:21:06 +0100 (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 r2IHL29n002655; Mon, 18 Mar 2013 18:21:06 +0100 Message-ID: <51474CD9.9010105@gmail.com> Date: Mon, 18 Mar 2013 18:20:25 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <5147312A.2070102@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:21:18 -0000 Le 18/03/2013 17:36, Ted Lemon a écrit : > On Mar 18, 2013, at 12:31 PM, Jong-Hyouk Lee > wrote: >> Just you need to be clear. Making what to be WG items? If you >> asking "reviewing of the standardized documents (related to IP) by >> other SDO to be WG items here", definitely no! >> >> We could review and give some comments or revision requests to >> other SDO when we would find something wrong there. Otherwise, why >> do we officially study and do review for other SDO here without >> official requests from them? > > What I was agreeing to was surveying documents produced by other > SDOs to see if they relate to the proposed work, and of course > liaising with the other SDOs about the work that's done in its, if > its winds up being chartered. Ok, so that may make into something like: "Opportunities exist to develop liaisons with these SDOs. This group will survey these SDO's documents to identify how it relates to this group's work." (we'd have no specific work item, like a draft and a timeline commitment, which seems fine like that). Alex Alex > > > From buddenbergr@gmail.com Mon Mar 18 10:30:57 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D482021F9011 for ; Mon, 18 Mar 2013 10:30:57 -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 4LPU00t8mLNX for ; Mon, 18 Mar 2013 10:30:49 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 87B8621F901A for ; Mon, 18 Mar 2013 10:30:42 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id rr4so6591004pbb.27 for ; Mon, 18 Mar 2013 10:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=FFfxI5nx7O9g2ij9GtFj/1o1/odQBytNpeiTEBc8/+M=; b=QuutYY/1WipLm/YvsJSWj1zIfaKQf5xIhgPB80zqWunXR92a+sAWvVkt/j7hfuMouq 7WAQTHZTQ2fpODfZaAZSFol3LnssxoI9l52BF0myvwLJGfBad6npnr7BIlP9ADQUR+eN igRsh1NdobgCKCRwstNyJXjKYmF0mpRjVG/nyYauZkNnwEtncGXBjUiK9JYeq0o/lspH NLDdNi4jbLTqWOU7WrXnC5ZILoFR9cEDwaaL2GdEnH8RSkHt6NSbAtOiDKp/0APoWxun bLXdO2Ya1Eb6mJ6wPojDoTnnewo9pZcIhJRO66oAloMwcORpnwLtgqHibIfhjhc6Vgkj 4y7Q== X-Received: by 10.66.156.102 with SMTP id wd6mr11712363pab.9.1363627842366; Mon, 18 Mar 2013 10:30:42 -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 ESMTPS id xs10sm8967550pac.8.2013.03.18.10.30.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Mar 2013 10:30:41 -0700 (PDT) Message-ID: <1363627839.1813.461.camel@localhost> From: Rex Buddenberg To: "Velt, R. (Ronald) in 't" Date: Mon, 18 Mar 2013 09:30:39 -0800 In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , Kevin Lahey , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:30:57 -0000 Gee, I didn't think I'd have to defend this one. Warning: this is a longer message, trying to roll up several questions you folks are asking. I contributed the 'instrumented ambulance' example to Alex's set of use cases, so let me expand it a bit. Ronald, you're right -- there should be a LAN (actually a good case for about three LANs) in an ambulance. End systems such as casualty vital signs monitors, radionav receivers, voice handsets for both the EMT and the driver, etc, should be attached to the LAN. Systems engineering sanity: keep them modularly separated from the radio issues. Next up the food chain is a router. Nothing unusual about it, except that it has more ports than the el cheapo one you have in your residence;-). Of course we need a radio network to get from the mobile platform to anywhere else and there are several possibilities. Since the ambulance operation can be considered 'mission critical', high availability is a driving factor. And since radio is much more iffy than wireline, and the ambulance can be expected to travel in and out of various footprints in its travails ... you want more than one link to the wired internet. - at least in the US, the most likely single link will be a cellphone one -- the emergency services and Congress are off in the direction of LTE over 700Mhz spectrum. - in rural areas, wider coverage is necessary so at least some ambulances may have satellite comms links. - at least some in [its] started with vehicle-vehicle daisy chains. - it's plausible, in urban and suburban areas, to exploit the WiFi access point density. If we find one house in each city block with a public-accessible AP, we'd probably have pretty solid coverage. Close cousin to the v2v above except it's handoffs instead. Ronald, does this answer your question? There's an economic premium with keeping the equipment in the back of the ambulance identical to that in the ER/ICU. And never do with radio what you can do with wire (e.g. LAN in your question). Multi-homed hosts make no scale sense to me. The ambulance use case illustrates some related requirements. Since [its] does not seem to have defined its scope yet, you can't pooh-pooh these as out of scope ... at least not yet;-) - security. End-to-end authenticity and confidentiality are required. This is an application design issue (layer 6/7 and operating system). In the ambulance case, at least within the US, we have the law (HIPPA) on the same side of the issue. - manageability. This is also an app design issue; need SNMP agents in end systems. (the reason here, to be fair, has nothing to do with radio but with the high availability needs). - multicast. A lot of emergency services data is multicast in nature (and the bandwidth-limited radio links are, after all, shared media, giving us multicast payoff exactly where we need it). Emergency services (and military) in general have much higher proportion of data that is multicast in nature than an all-civilian setting. But all-civilian settings do need to be multicast-receive friendly (weather warnings, for example). Radio characteristics. We can't re-engineer the media -- God did that, and as near as I can tell from Genesis, on the First Day. It's four orders of magnitude less capacious than wireline and its four orders of magnitude noisier than wireline. So we have to accommodate. Thus my previous comments about transport protocols: - consider the case of the ambulance transporting a casualty from a rural area (suggesting satcom channel) to a suburban area where the hospital is located (suggesting terrestrial radio-WAN of some sort). Propagation time for the 4G cellular link will be in 10s of msec; propagation time for the satcom link will be in 100s of msec. Is it reasonable to expect that packets will never arrive out of order? Or that we can jigger the underlying infrastructure so that doesn't happen ... without infringing on a bunch of other desiderata? - IEEE 802.16 (at least) has a layer 2 NAK-retransmit algorithm. This would also cause packets to arrive in scrambled order ... over a single link. I picked these observations because they will cause out-of-order arrival, whether or not you have multiple-radio-hop daisy chains (which I would expect to exacerbate). The robustness exemplified by TCP has been soft-pedaled as the internet migrated to lots more fiber optic, but it's all back with radio. Topology. Vehicle-to-vehicle daisy chains appear to present the most volatile topology situations. So I suspect that if we get that part right (and [MANET] has that issue within its scope) then we probably have a super-solution to the rest (rapid handoffs to fixed internet, for example). (Org comment: if topology is the only issue in [its] scope, then some of the critics here are right -- [its] has nothing to do.) On Mon, 2013-03-18 at 10:29 +0000, Velt, R. (Ronald) in 't wrote: > Hi, > > >-----Original Message----- > >From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > >Wesley Eddy > >Sent: maandag 18 maart 2013 2:08 > >To: Kevin Lahey > >Cc: its@ietf.org > >Subject: Re: [its] simultaneous use of multiple radios or not > > > >On 3/13/2013 8:21 PM, Kevin Lahey wrote: > >> On Wed, 13 Mar 2013 10:06:34 -0800 > >> Rex Buddenberg wrote: > >> > >>> The basic design of IP (and especially TCP) accommodates. TCP is > >>> designed to deal with packets that arrive out of order, which is > >>> likely if you have diverse routes. > >> > >> Careful -- TCP is actually very sensitive to reordering. Fast > >> retransmission will be triggered after a small number of duplicate > >> ACKs, which are triggered when a packet arrives out of order (or is > >> lost). Some stacks can recognize repeated reorderings and relax this > >> rule, at the cost of lower performance. > >> > >> The multipath schemes with which I'm familiar try hard to steer all > >> packets in a flow to the same link. > >> > > > > > >I agree that for normal TCP, multipath routing that causes reordering is a really > >bad idea. > > > >Recently, Multipath TCP, (MPTCP) was developed which handles the use of > >multiple links in the transport layer, and avoids the issues that normal TCP > >would have. > > > >MPTCP can utilize multiple L3 paths simultaneously: > >http://tools.ietf.org/html/rfc6824 > > > >This requires the end-host to have multiple addresses visible to it, which could > >be a design constraint on the way the mobile network is setup. > > Right. Can I ask what model is being assumed here? Is this entity with > multiple radio interfaces supposed to be a router or a multi-homed > host? I tend to think it is the former, with hosts residing on some > in-vehicle (ethernet or CAN-bus based) link attached to it. If that's > the case, one would have to perform some special tricks to make the > hosts see multiple source addresses. > > Ronald in 't Velt > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From Ted.Lemon@nominum.com Mon Mar 18 10:32: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 B19B221F9043 for ; Mon, 18 Mar 2013 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nRM6QNTeteFT for ; Mon, 18 Mar 2013 10:32:43 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id CF83821F9055 for ; Mon, 18 Mar 2013 10:32:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUUdPr9ddb7ly1fJp1w8pMOKF7ZZjeRZ8@postini.com; Mon, 18 Mar 2013 10:32:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C1A171B8E1D for ; Mon, 18 Mar 2013 10:32:31 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BB1E5190043; Mon, 18 Mar 2013 10:32:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 10:32:31 -0700 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [its] Should we have WG items that are reviews of vehicular SDO documents? Thread-Index: AQHOI/YcYGgF1Z66RU6MDZvkNP8vE5isGu6AgAAMQICAAANgAA== Date: Mon, 18 Mar 2013 17:32:30 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775112AFD@mbx-01.win.nominum.com> References: <5147312A.2070102@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775112626@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775112871@mbx-01.win.nominum.com> <51474CD9.9010105@gmail.com> In-Reply-To: <51474CD9.9010105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jong-Hyouk Lee , "its@ietf.org" Subject: Re: [its] Should we have WG items that are reviews of vehicular SDO documents? X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:32:51 -0000 On Mar 18, 2013, at 1:20 PM, Alexandru Petrescu wrote: > Ok, so that may make into something like: "Opportunities exist to > develop liaisons with these SDOs. This group will survey these SDO's > documents to identify how it relates to this group's work." >=20 > (we'd have no specific work item, like a draft and a timeline > commitment, which seems fine like that). Works for me. From sratliff@cisco.com Mon Mar 18 11:46:44 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 5549521F8FF9 for ; Mon, 18 Mar 2013 11:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dL6qS7RrZBen for ; Mon, 18 Mar 2013 11:46:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DFF0C21F8FEE for ; Mon, 18 Mar 2013 11:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7932; q=dns/txt; s=iport; t=1363632395; x=1364841995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eDMSlOmOWEqz8I2pAmA8QM63yp9nlXqTH91hulLH6QY=; b=QJJ6erGuhl61KZnbmyYCr06P4tTtcYiHID0jD2inla5ubHWkHAit+kca oKXDST0n7e1mOTGPqB4U93OXH8E0i269Rna/wwcb7Cu9GmaDq2XJX4Ypf J6nBVS6C96Xyf/Jmjkl/CQ6XGUhjGPza9lxAuf5+62nATRzuzfiV7dZmc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAZgR1GtJV2a/2dsb2JhbAA9BsUdgVYWdIIkAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQchBgsUCQgCBA4FCBOHZwMJBgy4LQ2JW4xMgRMGDHECJgsHBoJZYQOTGIFmgn+KSYUagwqBagkXHg X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="185768005" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 18 Mar 2013 18:46:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2IIkYUr008445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 18:46:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 13:46:33 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [its] simultaneous use of multiple radios or not Thread-Index: AQHOIpEORy6UKKf66UmImupIa4KuTpiq+KgAgACc74CAAHW2gIAAFTMA Date: Mon, 18 Mar 2013 18:46:32 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1005DAD6@xmb-aln-x03.cisco.com> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> In-Reply-To: <1363627839.1813.461.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <57ED739CAA91C544B997371155D3FD93@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy , Kevin Lahey , "Velt, R. \(Ronald\) in 't" , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:46:44 -0000 Rex,=20 Excellent discussion. I agree with you 100%.=20 Regards, Stan On Mar 18, 2013, at 1:30 PM, Rex Buddenberg wrote: > Gee, I didn't think I'd have to defend this one. Warning: this is a > longer message, trying to roll up several questions you folks are > asking. >=20 > I contributed the 'instrumented ambulance' example to Alex's set of use > cases, so let me expand it a bit. =20 >=20 > Ronald, you're right -- there should be a LAN (actually a good case for > about three LANs) in an ambulance. End systems such as casualty vital > signs monitors, radionav receivers, voice handsets for both the EMT and > the driver, etc, should be attached to the LAN. Systems engineering > sanity: keep them modularly separated from the radio issues. =20 >=20 > Next up the food chain is a router. Nothing unusual about it, except > that it has more ports than the el cheapo one you have in your > residence;-). =20 >=20 > Of course we need a radio network to get from the mobile platform to > anywhere else and there are several possibilities. Since the ambulance > operation can be considered 'mission critical', high availability is a > driving factor. And since radio is much more iffy than wireline, and > the ambulance can be expected to travel in and out of various footprints > in its travails ... you want more than one link to the wired internet. =20 > - at least in the US, the most likely single link will be a cellphone > one -- the emergency services and Congress are off in the direction of > LTE over 700Mhz spectrum. =20 > - in rural areas, wider coverage is necessary so at least some > ambulances may have satellite comms links. > - at least some in [its] started with vehicle-vehicle daisy chains. =20 > - it's plausible, in urban and suburban areas, to exploit the WiFi > access point density. If we find one house in each city block with a > public-accessible AP, we'd probably have pretty solid coverage. Close > cousin to the v2v above except it's handoffs instead. =20 >=20 > Ronald, does this answer your question? There's an economic premium > with keeping the equipment in the back of the ambulance identical to > that in the ER/ICU. And never do with radio what you can do with wire > (e.g. LAN in your question). Multi-homed hosts make no scale sense to > me. >=20 >=20 > The ambulance use case illustrates some related requirements. Since > [its] does not seem to have defined its scope yet, you can't pooh-pooh > these as out of scope ... at least not yet;-) =20 > - security. End-to-end authenticity and confidentiality are required. > This is an application design issue (layer 6/7 and operating system). > In the ambulance case, at least within the US, we have the law (HIPPA) > on the same side of the issue. =20 > - manageability. This is also an app design issue; need SNMP agents in > end systems. (the reason here, to be fair, has nothing to do with radio > but with the high availability needs). =20 > - multicast. A lot of emergency services data is multicast in nature > (and the bandwidth-limited radio links are, after all, shared media, > giving us multicast payoff exactly where we need it). Emergency > services (and military) in general have much higher proportion of data > that is multicast in nature than an all-civilian setting. But > all-civilian settings do need to be multicast-receive friendly (weather > warnings, for example).=20 >=20 > Radio characteristics. We can't re-engineer the media -- God did that, > and as near as I can tell from Genesis, on the First Day. It's four > orders of magnitude less capacious than wireline and its four orders of > magnitude noisier than wireline. So we have to accommodate. Thus my > previous comments about transport protocols: > - consider the case of the ambulance transporting a casualty from a > rural area (suggesting satcom channel) to a suburban area where the > hospital is located (suggesting terrestrial radio-WAN of some sort). > Propagation time for the 4G cellular link will be in 10s of msec; > propagation time for the satcom link will be in 100s of msec. Is it > reasonable to expect that packets will never arrive out of order? Or > that we can jigger the underlying infrastructure so that doesn't > happen ... without infringing on a bunch of other desiderata? > - IEEE 802.16 (at least) has a layer 2 NAK-retransmit algorithm. This > would also cause packets to arrive in scrambled order ... over a single > link. > I picked these observations because they will cause out-of-order > arrival, whether or not you have multiple-radio-hop daisy chains (which > I would expect to exacerbate). The robustness exemplified by TCP has > been soft-pedaled as the internet migrated to lots more fiber optic, but > it's all back with radio. =20 >=20 > Topology. Vehicle-to-vehicle daisy chains appear to present the most > volatile topology situations. So I suspect that if we get that part > right (and [MANET] has that issue within its scope) then we probably > have a super-solution to the rest (rapid handoffs to fixed internet, for > example). (Org comment: if topology is the only issue in [its] scope, > then some of the critics here are right -- [its] has nothing to do.) >=20 >=20 >=20 >=20 >=20 > On Mon, 2013-03-18 at 10:29 +0000, Velt, R. (Ronald) in 't wrote: >> Hi, >>=20 >>> -----Original Message----- >>> From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of >>> Wesley Eddy >>> Sent: maandag 18 maart 2013 2:08 >>> To: Kevin Lahey >>> Cc: its@ietf.org >>> Subject: Re: [its] simultaneous use of multiple radios or not >>>=20 >>> On 3/13/2013 8:21 PM, Kevin Lahey wrote: >>>> On Wed, 13 Mar 2013 10:06:34 -0800 >>>> Rex Buddenberg wrote: >>>>=20 >>>>> The basic design of IP (and especially TCP) accommodates. TCP is >>>>> designed to deal with packets that arrive out of order, which is >>>>> likely if you have diverse routes. >>>>=20 >>>> Careful -- TCP is actually very sensitive to reordering. Fast >>>> retransmission will be triggered after a small number of duplicate >>>> ACKs, which are triggered when a packet arrives out of order (or is >>>> lost). Some stacks can recognize repeated reorderings and relax this >>>> rule, at the cost of lower performance. >>>>=20 >>>> The multipath schemes with which I'm familiar try hard to steer all >>>> packets in a flow to the same link. >>>>=20 >>>=20 >>>=20 >>> I agree that for normal TCP, multipath routing that causes reordering i= s a really >>> bad idea. >>>=20 >>> Recently, Multipath TCP, (MPTCP) was developed which handles the use of >>> multiple links in the transport layer, and avoids the issues that norma= l TCP >>> would have. >>>=20 >>> MPTCP can utilize multiple L3 paths simultaneously: >>> http://tools.ietf.org/html/rfc6824 >>>=20 >>> This requires the end-host to have multiple addresses visible to it, wh= ich could >>> be a design constraint on the way the mobile network is setup. >>=20 >> Right. Can I ask what model is being assumed here? Is this entity with >> multiple radio interfaces supposed to be a router or a multi-homed >> host? I tend to think it is the former, with hosts residing on some >> in-vehicle (ethernet or CAN-bus based) link attached to it. If that's >> the case, one would have to perform some special tricks to make the >> hosts see multiple source addresses.=20 >>=20 >> Ronald in 't Velt >> This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer >>=20 >> _______________________________________________ >> its mailing list >> its@ietf.org >> https://www.ietf.org/mailman/listinfo/its >=20 >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Tue Mar 19 10:07: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 53B0421F8FC7 for ; Tue, 19 Mar 2013 10:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Q1LuhekWQH+T for ; Tue, 19 Mar 2013 10:07:11 -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 90C9A21F8FC5 for ; Tue, 19 Mar 2013 10:07:10 -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 r2JH79Is011685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Mar 2013 18:07:09 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2JH79Zt027032 for ; Tue, 19 Mar 2013 18:07:09 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2JH71wZ027611 for ; Tue, 19 Mar 2013 18:07:09 +0100 Message-ID: <51489B0E.6030203@gmail.com> Date: Tue, 19 Mar 2013 18:06:22 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: its@ietf.org References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> In-Reply-To: <1363627839.1813.461.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:07:12 -0000 I read the email. Yes, the ambulance scenario comes from you first - the instrumented part, and from some EU project participants (the part of ambulance-makes-way-thru-traffic). I agree with many points described which are excellent network design guidance. If I can modify the Charter proposal accordingly - I will be more than happy, I just need to know how. I am trying to figure out whether the use of multiple interfaces is just guidance, or whether there is some specific Item to work on for multiple radios. Or that the concept of multiple radios and wirelines is already there deeply entrenched in the essence of IP addressing and routing. Guidance is some text in the Charter proposal that describes in a compressed way what you described below. Would one offer such 3-line text to add in the Charter proposal? I just put this: "Each moving vehicle may use disjoint and heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively)." On another hand, an Item is typically a Working Group document (WG item) to which effort could be committed. For example, we may have an Item document which contains Scenarios and Requirements text. This has a time tag associated - deliver this Item by that Month of Year. Do you think we may have an Item about the use of multiple interfaces? Do you think there would be people ready to put effort in authoring, presenting such document? I am interested in all that discussion about multiple interfaces. That said, please see some replies below. Le 18/03/2013 18:30, Rex Buddenberg a écrit : > Gee, I didn't think I'd have to defend this one. Warning: this is a > longer message, trying to roll up several questions you folks are > asking. > > I contributed the 'instrumented ambulance' example to Alex's set of > use cases, so let me expand it a bit. > > Ronald, you're right -- there should be a LAN (actually a good case > for about three LANs) in an ambulance. End systems such as casualty > vital signs monitors, radionav receivers, voice handsets for both the > EMT and the driver, etc, should be attached to the LAN. Systems > engineering sanity: keep them modularly separated from the radio > issues. > > Next up the food chain is a router. Nothing unusual about it, > except that it has more ports than the el cheapo one you have in > your residence;-). > > Of course we need a radio network to get from the mobile platform to > anywhere else and there are several possibilities. Since the > ambulance operation can be considered 'mission critical', high > availability is a driving factor. And since radio is much more iffy > than wireline, and the ambulance can be expected to travel in and out > of various footprints in its travails ... you want more than one link > to the wired internet. - at least in the US, the most likely single > link will be a cellphone one -- the emergency services and Congress > are off in the direction of LTE over 700Mhz spectrum. - in rural > areas, wider coverage is necessary so at least some ambulances may > have satellite comms links. - at least some in [its] started with > vehicle-vehicle daisy chains. - it's plausible, in urban and suburban > areas, to exploit the WiFi access point density. If we find one > house in each city block with a public-accessible AP, we'd probably > have pretty solid coverage. Close cousin to the v2v above except > it's handoffs instead. > > Ronald, does this answer your question? There's an economic premium > with keeping the equipment in the back of the ambulance identical to > that in the ER/ICU. And never do with radio what you can do with > wire (e.g. LAN in your question). Multi-homed hosts make no scale > sense to me. > > > The ambulance use case illustrates some related requirements. Since > [its] does not seem to have defined its scope yet, you can't > pooh-pooh these as out of scope ... at least not yet;-) - security. > End-to-end authenticity and confidentiality are required. This is an > application design issue (layer 6/7 and operating system). In the > ambulance case, at least within the US, we have the law (HIPPA) on > the same side of the issue. - manageability. This is also an app > design issue; need SNMP agents in end systems. (the reason here, to > be fair, has nothing to do with radio but with the high availability > needs). - multicast. A lot of emergency services data is multicast > in nature (and the bandwidth-limited radio links are, after all, > shared media, giving us multicast payoff exactly where we need it). > Emergency services (and military) in general have much higher > proportion of data that is multicast in nature than an all-civilian > setting. But all-civilian settings do need to be multicast-receive > friendly (weather warnings, for example). > > Radio characteristics. We can't re-engineer the media -- God did > that, and as near as I can tell from Genesis, on the First Day. It's > four orders of magnitude less capacious than wireline and its four > orders of magnitude noisier than wireline. So we have to > accommodate. Thus my previous comments about transport protocols: - > consider the case of the ambulance transporting a casualty from a > rural area (suggesting satcom channel) to a suburban area where the > hospital is located (suggesting terrestrial radio-WAN of some sort). > Propagation time for the 4G cellular link will be in 10s of msec; > propagation time for the satcom link will be in 100s of msec. Is it > reasonable to expect that packets will never arrive out of order? > Or that we can jigger the underlying infrastructure so that doesn't > happen ... without infringing on a bunch of other desiderata? - IEEE > 802.16 (at least) has a layer 2 NAK-retransmit algorithm. This would > also cause packets to arrive in scrambled order ... over a single > link. I picked these observations because they will cause > out-of-order arrival, whether or not you have multiple-radio-hop > daisy chains (which I would expect to exacerbate). The robustness > exemplified by TCP has been soft-pedaled as the internet migrated to > lots more fiber optic, but it's all back with radio. > > Topology. Vehicle-to-vehicle daisy chains appear to present the > most volatile topology situations. So I suspect that if we get that > part right (and [MANET] has that issue within its scope) then we > probably have a super-solution to the rest (rapid handoffs to fixed > internet, for example). (Org comment: if topology is the only issue > in [its] scope, then some of the critics here are right -- [its] has > nothing to do.) No, topology is not the only issue here. We used topology as a distinction to dissociate between n-hop and 1-hop protocols. That may lead to scenarios pertinent to MANET/RoLL vehicular protocols distinct from scenarios pertinent to direct Vehicle-to-Vehicle communications. For example, we may have an Item which says that we require MANET and/or RoLL to deliver a n-hop routing protocol for V2V2V n-subnet topology - that translates in a pure MANET/RoLL discussion. And another Item which analyzes how to do 1-hop routing with IPv6 1-hop protocols. This is a pure non-MANET discussion. But this deserves its separate thread. I see beneficial to keep separate threads for: multiple interfaces discussion, 1-hop routing discussion and n-hop routing discussion. This is all open for discussion. Alex > > > > > > On Mon, 2013-03-18 at 10:29 +0000, Velt, R. (Ronald) in 't wrote: >> Hi, >> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Wesley Eddy Sent: >>> maandag 18 maart 2013 2:08 To: Kevin Lahey Cc: its@ietf.org >>> Subject: Re: [its] simultaneous use of multiple radios or not >>> >>> On 3/13/2013 8:21 PM, Kevin Lahey wrote: >>>> On Wed, 13 Mar 2013 10:06:34 -0800 Rex Buddenberg >>>> wrote: >>>> >>>>> The basic design of IP (and especially TCP) accommodates. >>>>> TCP is designed to deal with packets that arrive out of >>>>> order, which is likely if you have diverse routes. >>>> >>>> Careful -- TCP is actually very sensitive to reordering. Fast >>>> retransmission will be triggered after a small number of >>>> duplicate ACKs, which are triggered when a packet arrives out >>>> of order (or is lost). Some stacks can recognize repeated >>>> reorderings and relax this rule, at the cost of lower >>>> performance. >>>> >>>> The multipath schemes with which I'm familiar try hard to steer >>>> all packets in a flow to the same link. >>>> >>> >>> >>> I agree that for normal TCP, multipath routing that causes >>> reordering is a really bad idea. >>> >>> Recently, Multipath TCP, (MPTCP) was developed which handles the >>> use of multiple links in the transport layer, and avoids the >>> issues that normal TCP would have. >>> >>> MPTCP can utilize multiple L3 paths simultaneously: >>> http://tools.ietf.org/html/rfc6824 >>> >>> This requires the end-host to have multiple addresses visible to >>> it, which could be a design constraint on the way the mobile >>> network is setup. >> >> Right. Can I ask what model is being assumed here? Is this entity >> with multiple radio interfaces supposed to be a router or a >> multi-homed host? I tend to think it is the former, with hosts >> residing on some in-vehicle (ethernet or CAN-bus based) link >> attached to it. If that's the case, one would have to perform some >> special tricks to make the hosts see multiple source addresses. >> >> Ronald in 't Velt This e-mail and its contents are subject to the >> DISCLAIMER at http://www.tno.nl/emaildisclaimer >> >> _______________________________________________ its mailing 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 Tue Mar 19 10:16: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 92F3121F8FC5 for ; Tue, 19 Mar 2013 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.17 X-Spam-Level: X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 FXCR4reCpb18 for ; Tue, 19 Mar 2013 10:16:45 -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 5304A21F8F85 for ; Tue, 19 Mar 2013 10:16:45 -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 r2JHGhNo015208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Mar 2013 18:16:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2JHGhsE029346; Tue, 19 Mar 2013 18:16:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2JHGbEN025358; Tue, 19 Mar 2013 18:16:43 +0100 Message-ID: <51489D4E.9010100@gmail.com> Date: Tue, 19 Mar 2013 18:15:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 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: Rex Buddenberg , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:16:46 -0000 Le 13/03/2013 18:40, Ivancic, William D. (GRC-RHN0) a écrit : > This is more of what I was getting at. I was pretty active in mext, > monami6 YEs, I agree. But Monami6 had a very specific problem - use multiple addresses as CoAs (and not just one). It was a very specific and focused work. If we do something about multiple interfaces here, I am trying to identify what could be that very specific and focused work. What protocol should be extended? Once I understand that, I think it's easy to synthesize out the generic text to put in the Charter proposal. > and a few other mobile-ip related groups working mobile networking. > Some of the first code I used working the Cisco allowed you to use > multiple egress interfaces, but only one at a time. If the preferred > link when down, the next best (as pre configured) link would be used. > If I had 5 egress interfaces with 5 different radio systems, I could > use any of these, but only one at a time. I might have wired, wifi, > 4G, UHF with priority in that order. Note, they all may be provided > by different service providers. > > My question was do you want to be able to simultaneously use multiple > link? If so, the problems becomes very interesting. It also may be > one wants specific traffic to use specific links. Something along the lines of Mobile IPv6 Flow Mobility? Use Mobile IPv6 messages to assign application flows to interfaces or to CoAs? > Buy the way, I am currently working on spacesuit communications. > Spacesuits are mini-spacecraft with full life support and such. They > really are an intelligent vehicle, but probably less intelligent than > a car. There is a current concept for the next generation to have > two radios, a low-rate highly reliable radio and a wifi-type radio > with large bandwidth. Weather or no they would both be used > simultaneously is an open question. Obviously, high-rate, > high-resolution video would not be permitted over the UHF low-rate > link. Will - thank you. The spacesuit is a relevant use-case. I can see interesting spacesuit-to-spacesuit needs of communication. But, we already have two use-cases in the Charter proposal: ambulance coupled to automating driving, and smart-city. Do you think we should add spacesuit use-case? In the Charter proposal? Or commit to contribute to a draft about usecases and Scenarios? Alex > > Multi-homed from IETF 67 in 2006. Slides 5 and 11 > > "Multi-Homed Mobile Networks," 67th IETF, nemo and monami working > groups, November 9-10, 2006 San Diego, California ( Powerpoint ) file > size 679,424 bytes > > http://roland.grc.nasa.gov/~ivancic/papers_presentations/2006/IETF67nemo-mon > > ami6-final.ppt > > Will > > > > > From Ronald.intVelt@tno.nl Tue Mar 19 10:32:26 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86FA21F8DAC for ; Tue, 19 Mar 2013 10:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 DzRpI1Bd8J12 for ; Tue, 19 Mar 2013 10:32:25 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2146E21F8DAB for ; Tue, 19 Mar 2013 10:32:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,872,1355094000"; d="scan'208";a="5711297" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 19 Mar 2013 18:32:22 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.241]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 18:32:22 +0100 From: "Velt, R. (Ronald) in 't" To: Rex Buddenberg Thread-Topic: [its] simultaneous use of multiple radios or not Thread-Index: AQHOIpECZsGRtlT+UkuqisTpeEBU1JiqlBMAgACq3eCAAGfHgIABlE0g Date: Tue, 19 Mar 2013 17:32:21 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307A65C877@EXC-MBX03.tsn.tno.nl> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> In-Reply-To: <1363627839.1813.461.camel@localhost> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Cc: Wesley Eddy , Kevin Lahey , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:32:26 -0000 UmV4LCAgYWxsLA0KDQooaW4tbGluZSkNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogUmV4IEJ1ZGRlbmJlcmcgW21haWx0bzpidWRkZW5iZXJnckBnbWFpbC5jb21dDQo+U2Vu dDogbWFhbmRhZyAxOCBtYWFydCAyMDEzIDE4OjMxDQo+VG86IFZlbHQsIFIuIChSb25hbGQpIGlu ICd0DQo+Q2M6IFdlc2xleSBFZGR5OyBLZXZpbiBMYWhleTsgaXRzQGlldGYub3JnDQo+U3ViamVj dDogUmU6IFtpdHNdIHNpbXVsdGFuZW91cyB1c2Ugb2YgbXVsdGlwbGUgcmFkaW9zIG9yIG5vdA0K Pg0KPkdlZSwgSSBkaWRuJ3QgdGhpbmsgSSdkIGhhdmUgdG8gZGVmZW5kIHRoaXMgb25lLiAgV2Fy bmluZzogdGhpcyBpcyBhIGxvbmdlcg0KPm1lc3NhZ2UsIHRyeWluZyB0byByb2xsIHVwIHNldmVy YWwgcXVlc3Rpb25zIHlvdSBmb2xrcyBhcmUgYXNraW5nLg0KPg0KPkkgY29udHJpYnV0ZWQgdGhl ICdpbnN0cnVtZW50ZWQgYW1idWxhbmNlJyBleGFtcGxlIHRvIEFsZXgncyBzZXQgb2YgdXNlDQo+ Y2FzZXMsIHNvIGxldCBtZSBleHBhbmQgaXQgYSBiaXQuDQo+DQo+Um9uYWxkLCB5b3UncmUgcmln aHQgLS0gdGhlcmUgc2hvdWxkIGJlIGEgTEFOIChhY3R1YWxseSBhIGdvb2QgY2FzZSBmb3IgYWJv dXQNCj50aHJlZSBMQU5zKSBpbiBhbiBhbWJ1bGFuY2UuIA0KDQpJIGRpZCBub3QgaGF2ZSB5b3Vy IGFtYnVsYW5jZSBpbiBtaW5kLiBUbyBtZSwgSVRTIGlzIG1vcmUgYWJvdXQgaW1wcm92aW5nIHRy YWZmaWMgc2FmZXR5IGFuZCB0cmFmZmljIGVmZmljaWVuY3kgYnkgbWVhbnMgb2YgZGF0YSBjb21t dW5pY2F0aW9ucyBhbW9uZyB2ZWhpY2xlcyBhbmQgYmV0d2VlbiB2ZWhpY2xlcyBhbmQgcm9hZHNp ZGUgaW5mcmFzdHJ1Y3R1cmUuIFZpZXdlZCB0aGF0IHdheSwgYW4gaW50ZXJlc3RpbmcgZmVhdHVy ZSBmb3IgYW4gYW1idWxhbmNlIHdvdWxkIGl0cyBhYmlsdHkgdG8gYWxlcnQgb3RoZXIgcm9hZCB1 c2VycyB0aGF0IGl0IGlzIGNvbWluZyB0aHJvdWdoIGJlZm9yZSBpdHMgYXVkaWJsZSAvIHZpc2li bGUgc2lnbmFscyBjYW4gYmUgaGVhcmQgLyBzZWVuLiANCg0KPHNuaXA+DQoNCj4NCj5Sb25hbGQs IGRvZXMgdGhpcyBhbnN3ZXIgeW91ciBxdWVzdGlvbj8gIA0KDQpFcm0uLi4gSSB3YXMgbWVyZWx5 IHJlYWN0aW5nIHRvIFdlcyBFZGR5J3MgbWVudGlvbiBvZiBNUFRDUC4gSXQgaXNuJ3Qgb2J2aW91 cyB0byBtZSBob3cgTVBUQ1AgY291bGQgZXhwbG9pdCB0aGUgYXZhaWxhYmlsaXR5IG9mIG11bHRp cGxlIHJhZGlvIHBhdGhzLCBpZiB0aGUgaW50ZXJmYWNlcyB0byB0aG9zZSByYWRpb3MgZXhpc3Qg b24gdGhlIHJvdXRlciBhcyBvcHBvc2VkIHRvIHRoZSBNUFRDUC1jYXBhYmxlIGhvc3QuIEkgYW0g YXdhcmUgb2YgZHJhZnQtd3ItbXB0Y3Atc2luZ2xlLWhvbWVkLTA0LiBXaGF0IGlzIHByb3Bvc2Vk IHRoZXJlIGlzIHdoYXQgSSB3b3VsZCBjYXRlZ29yaXplIHVuZGVyICJzcGVjaWFsIHRyaWNrcyIu IA0KDQo8c25pcD4NCg0KUm9uYWxkDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBz dWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0dHA6Ly93d3cudG5vLm5sL2VtYWlsZGlzY2xh aW1lcgo= From buddenbergr@gmail.com Tue Mar 19 10:38:31 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4950621F8D45 for ; Tue, 19 Mar 2013 10:38:31 -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 TTBrmHOw5ltb for ; Tue, 19 Mar 2013 10:38:30 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id C14CF21F8C72 for ; Tue, 19 Mar 2013 10:38:30 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so613687pbc.5 for ; Tue, 19 Mar 2013 10:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=/qpTO15Rit7sFrTm4PkVIa1pkSqP77QFc7DozSYSziI=; b=pqXYxhRQgwpDTjwe4lu5EXZqvXHJePi6XUFANhQUuPLUcaeU4JUV3UdNieCX93sWK9 RlNLCquK4gMfRXBpZO14Jqsu6xyWSmutyZXcK9PoIDUbObRL3/WcfDuyN6LujrOC4TAT 7bNzxy83CDOIU7mV38ERqu7FY+m/kr4Dh013CJxStqPM8muklMLJn3KFHcGc9ZtHQ7/O PwG9LHPeA9xmGI74O7TrGUlIAupm4lB2WgFsDP4cc2+vNz3h3xG+U4UyhLg6YPKnFE8K 82zvOB4JUDA5gL+/lII/m1JCpgiBJATPQ2uszawky2A2sZXBPPIyWS2c2mzBSn1DpY29 hn0g== X-Received: by 10.68.252.134 with SMTP id zs6mr4443828pbc.66.1363714710544; Tue, 19 Mar 2013 10:38:30 -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 ESMTPS id y13sm25062247pbv.0.2013.03.19.10.38.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Mar 2013 10:38:29 -0700 (PDT) Message-ID: <1363714707.1813.565.camel@localhost> From: Rex Buddenberg To: Alexandru Petrescu Date: Tue, 19 Mar 2013 09:38:27 -0800 In-Reply-To: <51489B0E.6030203@gmail.com> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:38:31 -0000 Alex, On Tue, 2013-03-19 at 18:06 +0100, Alexandru Petrescu wrote: > trying to figure out whether the use of multiple interfaces is just > guidance, or whether there is some specific Item to work on for > multiple > radios. The number of alternate routes is driven by the level of availability required. The more nines, the more interfaces. That's a requirements analysis and systems design issue, not a standards one. The standards issue is essentially a negative one -- don't do something that would inhibit. (requiring in-order packet delivery at layer 3 would probably do that). From buddenbergr@gmail.com Tue Mar 19 10:48: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 BCA0F21F8DCF for ; Tue, 19 Mar 2013 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 9VrrAKeNAVNK for ; Tue, 19 Mar 2013 10:48:39 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1461221F8E13 for ; Tue, 19 Mar 2013 10:48:39 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id 3so266269pdj.0 for ; Tue, 19 Mar 2013 10:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=TlrCn4vIHH9g03PQEa6vo8FeMwrGCx+09bGxSSRIrLU=; b=iAjn1wAE6Xew/AJPeB3dR42EbwkM0QO1zIv2xbxAeNanfnSc46SzoTNhJ6vnO8yLuO OndCOKcNc52QzdZLgpPtALiSMrk+kf56kYRgoancQcbFPK77h5LWShsYE/VJtNCdXrls YhfdLlXv3Wb7jJVwyuDx12WFQumfKndI6Cf3Aci6ZJqwg3pwau96pLMreHUTpN0hrKub 93QmzmNXnK5PJrHtEqY3peraSi8vbqy3gICxbsmvJJRgsyPP2Wtp2OlkimNV65K0zr+s CLoe3RKqgYXpyCG9sKYVW33bPRCAPwUQnswROiMhaQmpqVq8975RuwH/0WUVb0RXRhGi tZVg== X-Received: by 10.68.212.135 with SMTP id nk7mr4410493pbc.120.1363715318796; Tue, 19 Mar 2013 10:48:38 -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 ESMTPS id xz5sm25071549pbb.25.2013.03.19.10.48.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Mar 2013 10:48:37 -0700 (PDT) Message-ID: <1363715315.1813.569.camel@localhost> From: Rex Buddenberg To: "Velt, R. (Ronald) in 't" Date: Tue, 19 Mar 2013 09:48:35 -0800 In-Reply-To: <72FB622921C13746AD6349E70A8D9F307A65C877@EXC-MBX03.tsn.tno.nl> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <72FB622921C13746AD6349E70A8D9F307A65C877@EXC-MBX03.tsn.tno.nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Wesley Eddy , Kevin Lahey , "its@ietf.org" Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:48:40 -0000 On Tue, 2013-03-19 at 17:32 +0000, Velt, R. (Ronald) in 't wrote: > ITS is more about improving traffic safety and traffic efficiency by > means of data communications among vehicles and between vehicles and > roadside infrastructure. Viewed that way, an interesting feature for > an ambulance would its abilty to alert other road users that it is > coming through before its audible / visible signals can be heard / > seen. I get to the same internetwork design using this (entirely legit) variant of the use case. 'Traffic efficiency' would include things like optimum routing and traffic light control, which require highly available comms from the platform through the terrestrial internet. Security requirements are similar -- authenticity of the data is critical (you should shudder to consider spoofed traffic data implications). In internet-speak, same infrastructure, different app. From mcr@sandelman.ca Tue Mar 19 12:31: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 932F121F88A2 for ; Tue, 19 Mar 2013 12:31:47 -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.000, 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 Wwz4CCsSVaSm for ; Tue, 19 Mar 2013 12:31:47 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9AF21F87AB for ; Tue, 19 Mar 2013 12:31:47 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A66020168 for ; Tue, 19 Mar 2013 15:39:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1287563860; Tue, 19 Mar 2013 15:31:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0501A63827 for ; Tue, 19 Mar 2013 15:31:24 -0400 (EDT) From: Michael Richardson To: its@ietf.org In-Reply-To: <1363714707.1813.565.camel@localhost> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 19:31:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> The number of alternate routes is driven by the level of Rex> availability required. The more nines, the more interfaces. Rex> That's a requirements analysis and systems design issue, not a Rex> standards one. Rex> The standards issue is essentially a negative one -- don't do Rex> something that would inhibit. (requiring in-order packet Rex> delivery at layer 3 would probably do that). Can we go back a bit to what is driving the need for so much data that multiple radios are called for? Would these radios be visible as seperate L3 interfaces?=20 I'm asking because there are a number of candidate routing protocols which would only use one interface for a given flow. Many feel that that might be a bug in the specification. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUUi9C4qHRg3pndX9AQLOuAP/TCbhzG3UNEULnYb5WkX13obPqAvtPG// 4MVGNjhmjmfI86DZejtLMlrWvaIowkNB/SzsAVfUQj1A0EdPPNrXnDpQlnmoPDtf Mv84EgMFNRdgPBL8bGD8ipIkb8MZm28BDYkQFhCVOZAEvL8CVkoWavBYoXcmhBPW OfYSDrixdnc= =Vylj -----END PGP SIGNATURE----- --=-=-=-- From buddenbergr@gmail.com Tue Mar 19 13:47: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 CC14521F8C48 for ; Tue, 19 Mar 2013 13:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 qkTWkhMZojeI for ; Tue, 19 Mar 2013 13:47:29 -0700 (PDT) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 333F321F8BF4 for ; Tue, 19 Mar 2013 13:47:29 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id z20so531169dae.31 for ; Tue, 19 Mar 2013 13:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=kq9YFwNBMjUjCsd5DenqEFzV3ea43fv1c2f1CmuIUiU=; b=WXmjpU7NGe6Z48zR4Ile+uM05+8AqSscEWI5SYlTu/ANneIRrK7UorNvm+s3pshjxZ OrPh6Dk9e04xVFIhSKopHMqvdI62bBUAaETQPSDmGdwGZiQCaNppHoRjB5LTfGQ0pjif L5XtAYjsf3y0s/9YuAZb+nXTHBZ1vtc1TlO7Qt/3XJtVTvMtGltYP/IkRDq0X61LVPLk kH6gHDqxsrXTyqgca1hZa51jw4OQwAx8E/jdIWdUVKeVCJhQxsd08z6VrK8kadbbSmum 4XxLBvv8vFa+gxN3xJPEvMEiScNMe3bp1fEdGFM0UpPOB6G72T85IeDIiI6DlOBUtEW/ A9ug== X-Received: by 10.68.237.100 with SMTP id vb4mr5190871pbc.202.1363726046946; Tue, 19 Mar 2013 13:47:26 -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 ESMTPS id tm1sm25509609pbc.11.2013.03.19.13.47.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Mar 2013 13:47:25 -0700 (PDT) Message-ID: <1363726043.1813.645.camel@localhost> From: Rex Buddenberg To: Michael Richardson Date: Tue, 19 Mar 2013 12:47:23 -0800 In-Reply-To: <31549.1363721484@sandelman.ca> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:47:29 -0000 Michael, Here's the academic. The first question to be addressed is 'what is the availability requirement?' Availability is defined as up time / total time and is usually expressed as the 'number of nines'. For instance, 99.99% availability pencils out to around 15 minutes of tolerable downtime in a calendar quarter. Since it's unlikely that you'll get 99.99% availability out of a single radio-WAN (read interface to the router), you need altroutes. The knee-jerk is to improve the number of 9s in a particular link. .... but this is radio guys! The second question is, once you've considered how much availability is required, how to get it? There are three principles of high availability engineering: - elimination of single points of failure. In comms systems, this principle usually means altroutes and backup power*. - reliable crossover. In multiply-threaded systems, the crossover switch itself can become a single point of failure. - prompt detection of failures as they occur. Or, in SNMP-speak, fault management. A user may never see a failure, but somebody needs to in order to direct maintenance (or in the case of radio-WANs, fill in coverage holes). The first principle is a provisioning principle, it's technology-choice independent. As an example, it may mean stashing an emergency generator in your garage for periods when grid power fails. *in practice, once you exceed 2 nines of Ao, you have to dual-thread the network because nobody can fix equipment that fast. The second principle is at the heart of the questions you're asking. First, it's moot if there are no altroutes. In the internet, the basic design of IP (RFC791, connectionless, stateless) meets this need. Routers do reliable crossover all day, every day. Anything that reintroduces state at layer 3 (or tries to do the crossover elsewhere, such as layer 2 bridges) tends to defeat the purpose. (for internet history types, Paul Beran was right). The third principle is best exemplified by a failure scenario I observed last summer: a city's emergency services (LMR) network failed because one of its three towers failed. The tower failed because an air conditioner in the hut at the base of the tower failed, the comms gear overheated and quit working. It took hours for the city to triage the failure, plus a couple more hours for the HVAC repairman to actually fix the problem -- all system downtime. Most of the Ao problem is not a standards one. The first principle is provisioning, the third is instrumenting (you could also read that as provisioning). I'd contend that neither need standards that we don't already have, but they do need follow-through and thorough implementation (a 'best practices' issue?). I'd also contend that the second principle is one met in the internet, provided we don't do stupid things (which include QoS controls that compromise the connectionless state of IP). > > > > Would these radios be visible as seperate L3 interfaces? > > > > Yes. Otherwise you wouldn't meet the second principle. > > I'm asking because there are a number of candidate routing protocols > > which would only use one interface for a given flow. Many feel that > > that might be a bug in the specification. > > I'd consider anything that chokes off perfectly usable altroutes as a bug. (At layer 2, the spanning tree algorithm does precisely that -- don't use it in high Ao situations). On Tue, 2013-03-19 at 15:31 -0400, Michael Richardson wrote: > >>>>> "Rex" == Rex Buddenberg writes: > Rex> The number of alternate routes is driven by the level of > Rex> availability required. The more nines, the more interfaces. > Rex> That's a requirements analysis and systems design issue, not a > Rex> standards one. > > Rex> The standards issue is essentially a negative one -- don't do > Rex> something that would inhibit. (requiring in-order packet > Rex> delivery at layer 3 would probably do that). > > Can we go back a bit to what is driving the need for so much data that > multiple radios are called for? > > Would these radios be visible as seperate L3 interfaces? > > I'm asking because there are a number of candidate routing protocols > which would only use one interface for a given flow. Many feel that > that might be a bug in the specification. > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From mcr@sandelman.ca Wed Mar 20 10:22: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 DE19121F8FD3 for ; Wed, 20 Mar 2013 10:22:17 -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.000, 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 Rczw8SEjj+ED for ; Wed, 20 Mar 2013 10:22:17 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id D362621F8DE9 for ; Wed, 20 Mar 2013 10:22:16 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 10FF42016D; Wed, 20 Mar 2013 13:30:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D3CE963860; Wed, 20 Mar 2013 13:22:07 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C395763827; Wed, 20 Mar 2013 13:22:07 -0400 (EDT) From: Michael Richardson To: Rex Buddenberg In-Reply-To: <1363726043.1813.645.camel@localhost> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> <1363726043.1813.645.camel@localhost> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:22:18 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> The third principle is best exemplified by a failure scenario I Rex> observed last summer: a city's emergency services (LMR) network Rex> failed because one of its three towers failed. The tower Rex> failed because an air conditioner in the hut at the base of the Rex> tower failed, the comms gear overheated and quit working. It Rex> took hours for the city to triage the failure, plus a couple Rex> more hours for the HVAC repairman to actually fix the problem Rex> -- all system downtime. So, why did it take hours to triage the failure? My *bet* is that the failure wasn't visible at layer-3, so it couldn't be seen. Rex> Most of the Ao problem is not a standards one. The first Rex> principle is provisioning, the third is instrumenting (you Rex> could also read that as provisioning). I'd contend that Rex> neither need standards that we don't already have, but they do Rex> need follow-through and thorough implementation (a 'best Rex> practices' issue?). I'd also contend that the second principle Rex> is one met in the internet, provided we don't do stupid things Rex> (which include QoS controls that compromise the connectionless Rex> state of IP). >> > > Would these radios be visible as seperate L3 interfaces? Rex> Yes. Otherwise you wouldn't meet the second principle. Good, we agree. >> > I'm asking because there are a number of candidate routing >> protocols > which would only use one interface for a given flow. >> Many feel that > that might be a bug in the specification. Rex> I'd consider anything that chokes off perfectly usable Rex> altroutes as a bug. (At layer 2, the spanning tree algorithm Rex> does precisely that -- don't use it in high Ao situations). So, many of the routing protocols would give you the alternate route as soon as one can see the primary has failed, but they will not, for a single flow (for various definitions of flow and different protocols), send packets out both radios, giving you increased bandwidth. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUUnwP4qHRg3pndX9AQI81QQAnk3mR4zKf5TlGHVhiCi40AGvaCtwq7ff bIA5Qr9XtnyeAIBQzQ5rVvkK1CgjWbFMo0ggyRsZAU6VxHJd+3wFMfJzp3XJ/qTg PuTAoy7Bl1XzekjjHwXDqO1O1ysA6HQH0JuNDPMswznHVhlj3HtyU5rd8A1wxvFJ Av276dj1FXI= =DhBe -----END PGP SIGNATURE----- --=-=-=-- From buddenbergr@gmail.com Wed Mar 20 10:53: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 5848721F8613 for ; Wed, 20 Mar 2013 10:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 EcrOEqWtCR5r for ; Wed, 20 Mar 2013 10:53:50 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id DBB6421F8600 for ; Wed, 20 Mar 2013 10:53:46 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so704909pdi.21 for ; Wed, 20 Mar 2013 10:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=rQP9TazSNx/VuEVG1O8gxvihT80VgL2WVZryp4uU4Yw=; b=FJhE0it6QjBybAk7Qdlg+kbcDxze3GV1lZlHtnIfcj5cdw86IPWNrw7KrBrln8LLFe 15psUY6GgaBZHb8GIzY1tG4qLFmM7g/0syxh6ZgosdIkPz5zQsJRNa3d5d8nROAbZI4r iERyRrbDkGCRCHo68Ba36XQoWqLVWOY4chIK5uw0NPn4eLqJ9nCYyKfIa0PRHr3TGkBp /epwrVr2KKR6nn7a3zNtq1s5ep5mVn1PzFiITgDhtHObRBYpoBDnUHM6IwIZArfXQtjE ZJ99a2lkC7XyP9c06kqWOr7HUS6rJ0UXPEVLOvmlAjldku9V28dbEQvFrZdImqh/G+y0 wJ4g== X-Received: by 10.66.13.74 with SMTP id f10mr10453197pac.146.1363802026622; Wed, 20 Mar 2013 10:53:46 -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 ESMTPS id ij15sm3070269pac.4.2013.03.20.10.53.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Mar 2013 10:53:45 -0700 (PDT) Message-ID: <1363802023.7964.80.camel@localhost> From: Rex Buddenberg To: Michael Richardson Date: Wed, 20 Mar 2013 10:53:43 -0700 In-Reply-To: <30590.1363800127@sandelman.ca> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> <1363726043.1813.645.camel@localhost> <30590.1363800127@sandelman.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:53:51 -0000 Two issues in here: in line... On Wed, 2013-03-20 at 13:22 -0400, Michael Richardson wrote: > >>>>> "Rex" == Rex Buddenberg writes: > Rex> The third principle is best exemplified by a failure scenario I > Rex> observed last summer: a city's emergency services (LMR) network > Rex> failed because one of its three towers failed. The tower > Rex> failed because an air conditioner in the hut at the base of the > Rex> tower failed, the comms gear overheated and quit working. It > Rex> took hours for the city to triage the failure, plus a couple > Rex> more hours for the HVAC repairman to actually fix the problem > Rex> -- all system downtime. > > So, why did it take hours to triage the failure? > My *bet* is that the failure wasn't visible at layer-3, so it couldn't > be seen. First issue. The failure was not visible at _any_ layer. There was NO fault monitoring system in place (other than, perhaps, some vendor proprietary stuff for the comms gear itself). The solution that should suggest itself to you is to instrument everything in the hut, a/c included, with SNMP agents, with an SNMP console at the dispatcher (PSAP in public-safety-ese) > > Rex> Most of the Ao problem is not a standards one. The first > Rex> principle is provisioning, the third is instrumenting (you > Rex> could also read that as provisioning). I'd contend that > Rex> neither need standards that we don't already have, but they do > Rex> need follow-through and thorough implementation (a 'best > Rex> practices' issue?). I'd also contend that the second principle > Rex> is one met in the internet, provided we don't do stupid things > Rex> (which include QoS controls that compromise the connectionless > Rex> state of IP). > > >> > > Would these radios be visible as seperate L3 interfaces? > > Rex> Yes. Otherwise you wouldn't meet the second principle. > > Good, we agree. > > > >> > I'm asking because there are a number of candidate routing > >> protocols > which would only use one interface for a given flow. > >> Many feel that > that might be a bug in the specification. > > Rex> I'd consider anything that chokes off perfectly usable > Rex> altroutes as a bug. (At layer 2, the spanning tree algorithm > Rex> does precisely that -- don't use it in high Ao situations). > > So, many of the routing protocols would give you the alternate route as > soon as one can see the primary has failed, but they will not, for a > single flow (for various definitions of flow and different protocols), > send packets out both radios, giving you increased bandwidth. > Second issue. From a high availability point of view, if an alternate route exists in the routing table, that should meet the need ... whether or not it is in use. The outstanding question, though, is how does the router know that the primary route has failed? Traditionally by sensing congestion -- buffer overflow. This 'how' mechanism sticks capacity and fault issues together -- it can't distinguish the two. I think it may be easy to get too cute. One of my students a few years ago, put an 802.16 transceiver on a boat, then sailed it away from it's opposite number set up on the beach. As the boat got offshore, it would disappear into the trough, breaking the link for several seconds (enough time for the .16 MAC to close the layer 2 connection). When the boat reappeared out of the trough, the pair would re-establish a layer 2 connection from scratch. The traces that the student brought me clearly showed the handshakes and dropouts. The question that this trial should raise to you is at what point would a router decide to kick in an altroute (and then kick it back out)? If the router is simply able to point traffic to any operating interface that has buffer space to accept it, then the issue is moot. From mcr@sandelman.ca Thu Mar 21 07:16:42 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73B21F9061 for ; Thu, 21 Mar 2013 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 GU6uGCiyT--c for ; Thu, 21 Mar 2013 07:16:41 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 94C5621F9062 for ; Thu, 21 Mar 2013 07:16:41 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C40A42016F; Thu, 21 Mar 2013 10:25:09 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 009BF63860; Thu, 21 Mar 2013 10:16:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E3EFF63827; Thu, 21 Mar 2013 10:16:32 -0400 (EDT) From: Michael Richardson To: Rex Buddenberg In-Reply-To: <1363802023.7964.80.camel@localhost> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> <1363726043.1813.645.camel@localhost> <30590.1363800127@sandelman.ca> <1363802023.7964.80.camel@localhost> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:16:42 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> Second issue. From a high availability point of view, if an alter= nate Rex> route exists in the routing table, that should meet the need Rex> ... whether=20 Rex> or not it is in use. The outstanding question, though, is how Rex> does the=20 So, I'm trying to distinguish the case where packets of the same microflow arrive uninterrupted (this is usually the goal of internet routing). There is another form of uptime where a new TCP connection would succeed, but it might involve a new set of prefixes, and a new route. Rex> The question that this trial should raise to you is at what point Rex> would a router decide to kick in an altroute (and then kick it back Rex> out)?=20=20 Rex> If the router is simply able to point traffic to any operating Rex> interface that has buffer space to accept it, then the issue is mo= ot.=20=20 There are bufferbloat (latency and jitter) issues with a naive approach here, but it may well be the right answer. Was the .16 system doing security, or just beacon/station-attachment. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUUsWQIqHRg3pndX9AQLwHAQA7H8m7IrPW0RRap5+0KKRiagF7EFZt87f rQWazvaMCpIG8ImLLrDSm2KF9UIYAGm4Q1bdU8qqCD+IjdqNI1OhvPxyAdnMHg6e F44GZwgqOnw1iKe6zLU/5Yc4qcxoSP4F0SCQ7+AIgAmGyOKEMUqSReYFqGsS+SeC IZc1VcslKiQ= =vFOQ -----END PGP SIGNATURE----- --=-=-=-- From buddenbergr@gmail.com Thu Mar 21 09:03: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 F352621F9165 for ; Thu, 21 Mar 2013 09:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 e7kbGhjTBuQi for ; Thu, 21 Mar 2013 09:03:20 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C721F9167 for ; Thu, 21 Mar 2013 09:03:20 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id y10so1154653pdj.27 for ; Thu, 21 Mar 2013 09:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=PgHEwI+iZFrj4MH88Q7rCc56/z//0vwhhrSO9z+EewA=; b=m8rK4FDw9eW7FtnPWityZ6atTj3jukzx0asap5WI1lVaVuD97xw9DrRPnR2hrsktjU /E6n3MH0C9KKyR0Z0GP72Anht4E/68Uz36MeiZDyWcQg5dlaW6G+51DhvrCCcgqvU9Xs D7ImkDCvFhcCE5RWQWiCxlWNZYbxAf/4ATLEZTRtmZZt5Ik0ee3Ckdaj22SR/UB2k83y mDWJQgSndXw+B4NTzvAinAnRrDgBttAuTPvY23+tf0s10e/CVKzQ93nIVxo4AYLtmeCd /rLyVs6ZsodaPwlkIIqNFGdaLuhMvYBag3sSupewAw49rJ49zX/DbHwH+RnYVhzFJIVA fKHQ== X-Received: by 10.66.175.73 with SMTP id by9mr3050432pac.191.1363881800087; Thu, 21 Mar 2013 09:03:20 -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 ESMTPS id is1sm6572431pbc.15.2013.03.21.09.03.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Mar 2013 09:03:19 -0700 (PDT) Message-ID: <1363881797.7964.109.camel@localhost> From: Rex Buddenberg To: Michael Richardson Date: Thu, 21 Mar 2013 09:03:17 -0700 In-Reply-To: <19187.1363875392@sandelman.ca> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> <1363726043.1813.645.camel@localhost> <30590.1363800127@sandelman.ca> <1363802023.7964.80.camel@localhost> <19187.1363875392@sandelman.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:03:21 -0000 in line On Thu, 2013-03-21 at 10:16 -0400, Michael Richardson wrote: > >>>>> "Rex" == Rex Buddenberg writes: > Rex> Second issue. From a high availability point of view, if an alternate > Rex> route exists in the routing table, that should meet the need > Rex> ... whether > Rex> or not it is in use. The outstanding question, though, is how > Rex> does the > > So, I'm trying to distinguish the case where packets of the same > microflow arrive uninterrupted (this is usually the goal of internet > routing). um... what do you mean by microflow? One TCP session, perhaps? If a vehicle is moving down the highway and shifting from one router to another, but it's still the same awful youTube download, is that a microflow? By diverse routes. > > There is another form of uptime where a new TCP connection would > succeed, but it might involve a new set of prefixes, and a new route. > > Rex> The question that this trial should raise to you is at what point > Rex> would a router decide to kick in an altroute (and then kick it back > Rex> out)? > Rex> If the router is simply able to point traffic to any operating > Rex> interface that has buffer space to accept it, then the issue is moot. > There are bufferbloat (latency and jitter) issues with a naive approach > here, but it may well be the right answer. One of the hardwon lessons in systems engineering (numerous backside scars): Never discuss QoS issues before you 1) understand the reach-to-mobile issues and 2) do the Ao homework. The internet, by default, maximizes the qos parameter of bandwidth efficiency and trades off the qos parameters of latency, jitter, interactivity to get it. Any attempts to use QoS controls to change this usually have unforeseen side effects that are usually all bad. TANSTAFL. > > Was the .16 system doing security, or just beacon/station-attachment. > The experiment was a simple how-far-does-it-go one. But the obvious is that when the link was up, it would haul packets. None of the non-default 802.16 security measures (e.g. keypair exchange) were turned on. From mcr@sandelman.ca Thu Mar 21 09:41:26 2013 Return-Path: X-Original-To: its@ietfa.amsl.com Delivered-To: its@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC88921F8E5E for ; Thu, 21 Mar 2013 09:41:26 -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.000, 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 doc2IJGHbq0H for ; Thu, 21 Mar 2013 09:41:26 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DBEEE21F8E3D for ; Thu, 21 Mar 2013 09:41:22 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A3C482016D; Thu, 21 Mar 2013 12:49:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6FCD463860; Thu, 21 Mar 2013 12:41:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6179A63827; Thu, 21 Mar 2013 12:41:14 -0400 (EDT) From: Michael Richardson To: Rex Buddenberg In-Reply-To: <1363881797.7964.109.camel@localhost> References: <1363197994.1813.348.camel@localhost> <20130313172112.671bcf40@temprokkaku> <514668DC.1030901@mti-systems.com> <72FB622921C13746AD6349E70A8D9F307A65A11E@EXC-MBX03.tsn.tno.nl> <1363627839.1813.461.camel@localhost> <51489B0E.6030203@gmail.com> <1363714707.1813.565.camel@localhost> <31549.1363721484@sandelman.ca> <1363726043.1813.645.camel@localhost> <30590.1363800127@sandelman.ca> <1363802023.7964.80.camel@localhost> <19187.1363875392@sandelman.ca> <1363881797.7964.109.camel@localhost> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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: its@ietf.org Subject: Re: [its] simultaneous use of multiple radios or not X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 16:41:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Rex" =3D=3D Rex Buddenberg writes: Rex> Second issue. From a high availability point of view, if an Rex> alternate route exists in the routing table, that should meet Rex> the need ... whether or not it is in use. The outstanding Rex> question, though, is how does the >> So, I'm trying to distinguish the case where packets of the same >> microflow arrive uninterrupted (this is usually the goal of >> internet routing). Rex> um... what do you mean by microflow? One TCP session, Rex> perhaps? That's an example of a microflow, yes.=20 Also includes a SIP, RTP, DNS request/reply, etc. Rex> If a vehicle is moving down the highway and shifting from one Rex> router to another, but it's still the same awful youTube Rex> download, is that a microflow? By diverse routes. Well.... some video downloaders actually notice TCP session failure, implement happy eyeballs, and will restart a TCP connection, so it's a bad example. My point is that if initiating a new TCP session when the old one fails succeeds, that may well resiliant enough for some application. That's why I'm asking what the use case is here. >> Was the .16 system doing security, or just >> beacon/station-attachment. Rex> The experiment was a simple how-far-does-it-go one. But the Rex> obvious is that when the link was up, it would haul packets. Rex> None of the non-default 802.16 security measures (e.g. keypair Rex> exchange) were turned on. okay, so this was just attachment/beacons work, not concern with trying to rekey each time. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUUs4KoqHRg3pndX9AQJ/AAP/QkAjm549qSznSkwZwGf0QdVYuCcdxEO+ gjlcZiXhukvzU70021hp5yEpnFyG3t3pLN/9ypYqQunHmFoWhbWt73z60U6AamUy q2qCvPDqyh4rtZ/ohWtV5LhrVmGrD4IKucjgeET5nwJwpdDzhqHBsy6EnUzgilR9 Gv41XVeaGns= =r8Gd -----END PGP SIGNATURE----- --=-=-=-- From alexandru.petrescu@gmail.com Fri Mar 29 04:04: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 572F021F9323 for ; Fri, 29 Mar 2013 04:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[AWL=0.248, 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 2cWIN6XmFCUc for ; Fri, 29 Mar 2013 04:04:54 -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 A362821F92D5 for ; Fri, 29 Mar 2013 04:04:50 -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 r2TB4hC2012707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 29 Mar 2013 12:04:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r2TB4hDb028116 for ; Fri, 29 Mar 2013 12:04:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r2TB4XGS021520 for ; Fri, 29 Mar 2013 12:04:43 +0100 Message-ID: <51557508.5050802@gmail.com> Date: Fri, 29 Mar 2013 12:03:36 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: multipart/mixed; boundary="------------010203030107080600020407" Subject: [its] Updated proposal of Charter ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 11:04:55 -0000 This is a multi-part message in MIME format. --------------010203030107080600020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Discussions happened briefly in private about this Charter proposal. See attached for the new version. Most notably - it now mentions the URL of a web page http://www.lara.prd.fr/ietf-its cotnains documents presented at earlier meetings at IETF. - reflects a little bit better the potential work with respect to MANET/RoLL: write first requirements, then identify gaps, then if new work is needed, otherwise do work in conjunction with the group which 'owns' the existing protocol. I agree it is still a relatively large text. Comments welcome. Alex --------------010203030107080600020407 Content-Type: text/plain; charset=windows-1252; name="its-8.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="its-8.txt" Intelligent Transportation Systems at IETF Draft Charter Proposal March 26th, 2013 http://ietf.org/mailman/listinfo/its Intelligent Transportation Systems (its) ---------------------------------------- Current Status: Informal Chairs: TBD TBD Assigned Area Director: TBD () Mailing list Address: its@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/its Archive: http://www.ietf.org/mail-archive/web/its/current/maillist.html Additional web page http://www.lara.prd.fr/ietf-its Draft Charter Proposal: Context ------- Intelligent Transportation Systems (ITS) are composed of interconnected systems of machines; vehicles, mobile devices and fixed embedded devices (actuators and sensors). These machines communicate with fixed access points which are are deployed along terrestrial roads (e.g. Road-Side Units), and along shores of water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless communications to equipment deployed in mobile vehicles (e.g. On-Board Units), in a secure manner. The entire system may be connected to the Internet; in certain cases the vehicles are disconnected from the Internet yet are inter-connected to each another, in an ad-hoc manner. Each moving vehicle may use disjoint and heterogeneous radio systems (e.g. a vehicle employs two or more different radios which may be used simultaneously, or alternatively). Communication security requirements are of paramount importance in the context of vehicular communications. Using IP should not introduce new risks, especially when safety-specific applications are involved. For example, inter-vehicular communication systems for crash avoidance should be secured (safety of humans is at stake); as another practical example, within the vehicle, introducing IP communications to an otherwise non-IP rearview camera should not allow for attacker IP devices to DoS the display, or turn the volume to a sudden high. Certain security requirements may be about generic IP communications security, whereas others may be specific to vehicular communications. Due to the mobile nature of the system, several problems exist with respect to IP addressing and route establishment such that IP communications can be realized. In the case of 1-hop Vehicle-to-Vehicle communications (V2V), without infrastructure, there is a problem in identifying which subnets and addresses are used on the link between two vehicles; also there is a problem in deciding how one vehicle learns the prefix deployed in a vehicle in close vicinity. In the case of n-hop V2V2V communications there is a need of identification which address configuration and dynamic routing protocol should be employed. In the case of Vehicle-to-Infrastructure (V2I) communications, there is a problem in propagating the prefix contained in a vehicle to the routers of the infrastructures without destabilizing the Internet routing (a typical IP network is using mostly IP addresses topologically valid at a single point, and relatively stable routing system). One particular use case is under the form of an instrumented ambulance. The ambulance is connected to the Internet and offers wireless and wired access to a large number of individual equipments deployed in-vehicle. The ambulance may move through a traffic jam and signal its presence to nearby vehicles with visual means and also with communication packets. Automatic driving through traffic jams involves wireless communications between vehicles. Constant links between vehicles constitute good support for establishing IP communications. An IP device in one vehicle may signal its actual speed to another IP device in the vehicle nearby. The smart-city use case is also important for networking country- and world-wide transports. The use case should lead to development of requirements and services for transports within cities, or countries, making them smart. The ITS technologies may use techniques from MANET and from RoLL adapted to this smart-city use case. One may need to consider ETSI IPv6 over GeoNetworking, and also add OLSRv2 as used in community networks. A hybrid routing protocol could be used. Spacesuit: the IP network structure deployed inside a vehicle should be suitable for deployment in a spacesuit as well. It is considered that several existing IETF protocols could and should be reused in the communication scenarios described above. For the V2V2V scenarios - the protocols OLSR, AODV and RPL should be considered. For the IP addressing and mobility aspects of in-vehicle subnetworks, single-subnet V2V, and single-subnet V2I, the following protocols should be considered: IPv6, Mobile IPv6, ND, DHCPv6, PMIPv6. Several Standards Development Organizations outside IETF work towards developing protocols for vehicular communications. In some cases IP protocols are used for transport, in other cases IP protocols are modified for purposes particular to vehicular communications. The group ISO TC204 describes ITS station architecture, IPv6 networking and security, and optimizations. The group ETSI ITS describes IPv6 for networking in vehicles. IEEE TGp, AUTOSAR and IPSO describe other aspects of vehicular communications. When possible, liaisons will be established with these organizations. This group will survey these SDO's documents to identify how it relates to this group's work. Potential new work items ------------------------ The following potential work items exist: Scenarios and requirements for vehicular communications will be developed which introduce at IETF the terms V2V, V2I, V2R and intra-vehicular paradigms. Define various possible scenarios for IP vehicular communications and identify requirements that are essential to support the defined scenarios. Practices and gap analysis for IP vehicular communications: document practices for the deployment of existing IP protocols and identify any limitation of the existing IP protocols to fulfill the scenarios and requirements for IP vehicular communications. If limitations are identified as part of the above deliverable, specify extensions to the existing protocols - these extensions should be performed in association with the group which originated the design of that particular protocol, or that is actively maintaining that protocol at this time. If entirely new protocols are necessary to reduce the gap identified, then re-charter. One particular practice to document is the IP addressing architecture within a vehicle, between vehicles, and between vehicle and infrastructure: the preferred address auto-configuration methods, the requirements for address stability and scope of visibility (in-vehicle, to vehicles nearby, to infrastructure, to Internet, etc.) A problem statement draft should be written which documents the problem which is a real-world problem, points precisely to the protocols which may break, and may easily lead to a solution that can be designed in a straightforward manner. Supplementary work items ------------------------ Infrastructure-less 1-hop route exchanges between vehicles, or between vehicles and road-side units which are disconnected from the infrastructure. A widely-used link-scoped IP protocol should be reused for prefix exchanges between vehicles in close vicinity; a single subnet is used between such vehicles, which are otherwise disconnected from the infrastructure. IEEE 802.11p is a link layer technology specific to vehicular communications, and which may be used for IP for ITS. In certain places this link layer technology is named "G5". Several trials of using IP directly over 802.11p links (without intermediate layers) have been performed in laboratory environments. A vehicle may have a multiplicity of interfaces, and a multiplicity of addresses outside and inside the vehicle, at the same time, for different purposes. For the use of IPv6 addresses inside a vehicle it is necessary the addressing schemes which couled be employed, and which address auto-configuration mechanism(s) (or a combination thereof) should be employed such that to be inline with the in-vehicle application requirements scenarios. For outside the vehicle, the use of IPv6 addresses in a subnet formed by the egress interfaces of the vehicles, in a 1-hop ad-hoc manner, is considered. For the fixed network deployed outside the vehicle - the use of Proxy Mobile IPv6 protocol on the fixed mobility management entities may prove advantageous to offer mobility to a moving network deployed in a vehicle. For the security inside the vehicular on-board network, requirements specific to vehicular communications should be formulated. For the security on the link between two vehicles, a secure Neighbor Discovery mechanism should be used. Milestones: Mar 2013 - Meet in Orlando done Jul 2013 - Meet in Berlin Jul 2013 - Present drafts "Scenarios and Requirements for IP in Intelligent Transportation Systems", and Gap Analysis Jul 2013 - Present drafts on Route Exchange between vehicles Jul 2013 - Present MANET landscape for V2V2V Nov 2013 - Present status from ISO Nov 2013 - Present gap analysis and requirements Mar 2014 - Present problem statement Jul 2014 - Present solution drafts Nov 2014 - Present solution drafts --------------010203030107080600020407-- From alison@she-devel.com Fri Mar 29 19:33: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 4D99221F8E6E for ; Fri, 29 Mar 2013 19:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HayXVhMRG0Hk for ; Fri, 29 Mar 2013 19:33:18 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2021F8E6D for ; Fri, 29 Mar 2013 19:33:15 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so885389lab.22 for ; Fri, 29 Mar 2013 19:33:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=s8upi+yQcsUV+MRkOxIuVapaRD+GWOh/QbFZkZj8E2Y=; b=C8eW/DkfeKsVZvfd8+NboPywuWVOK4Z64oabExH+Hfc+j5FPMBcjNfItg9b8kJxbaW BZpe1kAuOnZcuJQU48XY1NhVQoSk5QsdQ1vBH0oJj4JliofzzNlNYqnrMrVyxKxDl04b 8qmC0ZFhlEn67X7lVDFrtmywvZ5019GVDemyjb/R9k5++EC/Sq+iLDaYy96I3KIernlp RjzRmiiB21/srIoz5rWQq4IWbrxqMrlyBSC/N8YrIIiE5ir2Q5qBgFj1VFRmm5w2IAPq 8FJXFfEeq2jzHEa6GKA9zw7+1Dq0NpAKWDB+N7n3wZpuPl2JWdg/nO0GjIoKb2bO8cJ9 GCCw== MIME-Version: 1.0 X-Received: by 10.112.85.68 with SMTP id f4mr2250275lbz.29.1364610794231; Fri, 29 Mar 2013 19:33:14 -0700 (PDT) Received: by 10.112.82.163 with HTTP; Fri, 29 Mar 2013 19:33:14 -0700 (PDT) Date: Fri, 29 Mar 2013 19:33:14 -0700 Message-ID: From: Alison Chaiken To: its@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnZlyHKORIpSie3dptsQ06z27UFZV7POJiYNYa65YQrq0lo7XnWXHWdg08lmb9Gptu9W8YI Subject: [its] "Hangout" about automotive Linux networking on Tuesday 4/2 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, 30 Mar 2013 02:33:19 -0000 On Tuesday 4/2 at 10 AM PDT (GMT-7), Savari Networks CEO Ravi Puvvala and I will present a Google+ Hangout on the topic "Embedded Linux Takes on the Hard Problems of Automotive," which is about 802.11p, DSRC/IEEE1609 and automotive intranet based on standards like FlexRay, EthernetAV, CAN etc. Here are the details: https://plus.google.com/u/0/events/cqj3grb8sm4tgsugjjvdc01e8mc I'm not sure if you can attend without having a gmail address; if not, I apologize. Actually I apologize in general as the Hangout is my manglement's idea. Here are slides whose first half I will run through quickly: http://she-devel.com/Chaiken_ELC_2013.pdf Video of previous presentation by Ravi: https://www.youtube.com/watch?v=uDqn3WwR_jI&feature=youtu.be Ravi's previous slides: http://files.meetup.com/2623882/savari-v2x-svaosm-sep2012.pdf Please, if you are so inclined, show up and tell us we're all wrong! We hope to have lots of questions and comments throughout the talk, as a live event is worthless otherwise. -- Alison Chaiken alison@she-devel.com 650-279-5600 http://{she-devel.com, exerciseforthereader.org} Access is more important than ownership. -- Joe Gebbia, AirBnB From alexandru.petrescu@gmail.com Sat Mar 30 06:53: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 6C93A21F87F5 for ; Sat, 30 Mar 2013 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 XPzZisWAULsC for ; Sat, 30 Mar 2013 06:53:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7720721F87D2 for ; Sat, 30 Mar 2013 06:53:18 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7B0369401F7 for ; Sat, 30 Mar 2013 14:53:12 +0100 (CET) Message-ID: <5156EE43.9070102@gmail.com> Date: Sat, 30 Mar 2013 14:53:07 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 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 X-Antivirus: avast! (VPS 130330-0, 30/03/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [its] V2V2I aspects (was: "Hangout" about automotive Linux networking on Tuesday 4/2) 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, 30 Mar 2013 13:53:21 -0000 Thanks for having posted this invitation here. I have looked at the slides http://she-devel.com/Chaiken_ELC_2013.pdf and in particular slide 17 "Vehicles are networks of networks" shows a scenario of vehicle-to-bus-to-infrastructure communications. This is pertinent to some Internet Drafts that have been discussed by IETF participants. Alex Le 30/03/2013 03:33, Alison Chaiken a écrit : > On Tuesday 4/2 at 10 AM PDT (GMT-7), Savari Networks CEO Ravi Puvvala > and I will present a Google+ Hangout on the topic "Embedded Linux > Takes on the Hard Problems of Automotive," which is about 802.11p, > DSRC/IEEE1609 and automotive intranet based on standards like FlexRay, > EthernetAV, CAN etc. Here are the details: > > https://plus.google.com/u/0/events/cqj3grb8sm4tgsugjjvdc01e8mc > > I'm not sure if you can attend without having a gmail address; if not, > I apologize. Actually I apologize in general as the Hangout is my > manglement's idea. > > Here are slides whose first half I will run through quickly: > http://she-devel.com/Chaiken_ELC_2013.pdf > > Video of previous presentation by Ravi: > https://www.youtube.com/watch?v=uDqn3WwR_jI&feature=youtu.be > > Ravi's previous slides: > http://files.meetup.com/2623882/savari-v2x-svaosm-sep2012.pdf > > Please, if you are so inclined, show up and tell us we're all wrong! > We hope to have lots of questions and comments throughout the talk, > as a live event is worthless otherwise. >