o R0. Support of multiple interfaces: The vehicle (= not restricted to the MR physically) should support several interfaces towards the infrastructure. And at least one internal to the vehicle.

o R1. IP addressing within each vehicle for Sub-networks su= pport: Mobile router support several sub-networks hosting stakeholder netwo= rks,
o R2. IP addressing on the interface between vehicles. (May or may not= be globally reachable) o R3. Globally Reachable from Internet: (This may be a globally reacha= ble address, or perhaps something else.) o R4. Quality of Service: One stakeholder may request for a minimum bandwidth for its applications. QoS should ensure those minimums are taken into accounts. o R5. Broadcasted Alerts support: For example, Along the highway, the = MR may receive alerts about accident through 802.11p or some other mechanism= . o R6. Store, Carry and Forward: Improve communication efficiency by delaying transfer of information. o R7. Efficient inter-vehicular routing: For Example, may take advanta= ge of geographic information (not restricted to geonetworking). o R8. Security: MR must prevent routing of packets between sub networks and ensure protection of those data within the vehicle. o R9. Continuity of ongoing sessions: it is desirable that ongoing sessions between one device within the vehicle and one device in the Internet is maintained ongoing during vehicle movements, and upon handovers between heterogeneous access points. o R10. Reachability at permanent home addresses: it is desirab= le that each device connected inside a vehicle to be reachable at a permanent fixed address, for all other IP devices deployed in the Internet. (I think R3 takes care of this.)=

Then = I gave up and did not write that requirement.

This is open for discu= ssion.

Alex,

Give thi= s book a read. It is a very difficult read, but well worth the effort= .

Read the whole book, but feel free to jum= p to Chapter 9 "Multi-homing,Multicast, and Mobility" section "Mobility in = IP and Cellular Networks" to get a feel for how the phone system evolved fr= om the phone number being a location dependent point of attachment address = to a cell phone number being location independent node address = to eventually becoming more or less an application name.

"Patterns in Network Architecture - A Return to Fundamentals" by Joh= n Day.

= --_000_B72E19FEA0A44C82A9D2B3047503FF74nasagov_-- From alexandru.petrescu@gmail.com Fri Jul 20 02:09:36 2012 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 798C721F8534 for ; Fri, 20 Jul 2012 02:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.074 X-Spam-Level: X-Spam-Status: No, score=-9.074 tagged_above=-999 required=5 tests=[AWL=1.175, 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 CQR5hVIirF9H for ; Fri, 20 Jul 2012 02:09:36 -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 A551A21F852E for ; Fri, 20 Jul 2012 02:09:35 -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 q6K9AT0v025141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Jul 2012 11:10:29 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6K9ATVi003464 for ; Fri, 20 Jul 2012 11:10:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6K9AS0A024865 for ; Fri, 20 Jul 2012 11:10:29 +0200 Message-ID: <50092084.6090709@gmail.com> Date: Fri, 20 Jul 2012 11:10:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] recent advancements and whether to meet in Vancouver 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, 20 Jul 2012 09:09:36 -0000 Group, In the recent weeks, a number of advancements happened here. - new University and Industry participants expressed interest in work. - a demo and its documentation were announced. - new drafts about problems, scenarios and requirements were announced. In my oppinion this qualifies for a face-to-face meeting. If interested to attend such a meeting in Vancouver, please let me know - I could ask for a room. If yes, I'd propose to meet Monday evening. Yours, Alex From karagian@cs.utwente.nl Fri Jul 20 02:14:17 2012 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 A858521F858A for ; Fri, 20 Jul 2012 02:14:17 -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 fDe34rMgHCf8 for ; Fri, 20 Jul 2012 02:14:16 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8406A21F857F for ; Fri, 20 Jul 2012 02:14:16 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 20 Jul 2012 11:15:11 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 20 Jul 2012 11:15:10 +0200 From: To: , Thread-Topic: [its] recent advancements and whether to meet in Vancouver Thread-Index: AQHNZleIGzkE0NMHpkiyJxUK35dHEJcx40tA Date: Fri, 20 Jul 2012 09:15:10 +0000 Message-ID: References: <50092084.6090709@gmail.com> In-Reply-To: <50092084.6090709@gmail.com> 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 Subject: Re: [its] recent advancements and whether to meet in Vancouver 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, 20 Jul 2012 09:14:18 -0000 Hi Alex, I think that it will be useful to have such a f2f meeting in Vancouver! Best regards, Georgios > -----Original Message----- > From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: vrijdag 20 juli 2012 11:10 > To: its@ietf.org > Subject: [its] recent advancements and whether to meet in Vancouver >=20 > Group, >=20 > In the recent weeks, a number of advancements happened here. >=20 > - new University and Industry participants expressed interest in work. > - a demo and its documentation were announced. > - new drafts about problems, scenarios and requirements were announced. >=20 > In my oppinion this qualifies for a face-to-face meeting. If interested = to > attend such a meeting in Vancouver, please let me know > - I could ask for a room. >=20 > If yes, I'd propose to meet Monday evening. >=20 > Yours, >=20 > Alex >=20 > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its From maxpassion@gmail.com Tue Jul 24 20:26:44 2012 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 58EFA21F84CD; Tue, 24 Jul 2012 20:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 AHiAXbx42i4L; Tue, 24 Jul 2012 20:26:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9721F84C9; Tue, 24 Jul 2012 20:26:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so455460obb.31 for ; Tue, 24 Jul 2012 20:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rdjQoylG7IWI5bceVq1pEN7ULm5wCG5Su23oVLuD28E=; b=UjH1XeFf8/ghNTnDNo5jZC9tAfsqZCwL3YGSsx2KxhxvSQJQY4JCsb2rijG/kh1jX3 8QQPPhl0tZH/unbhQOppX8fB3FFNgHDQNWqa591stfWWLWif6CoSMmYY3bxaqPiR3QOM bE+WTTscibcHHahykO6jzQD60nCvoVMyHMhkYEzU98qX6BHbWD4FivhdXKxwQjTVrmMD eiON9xmi3NhW3kWewH2dL0LEn/CzT7bm2+VQL6wKunGevUF/DidukSIYfBwH7+hRqgZn aYL6Pfi3LQj3HLVYyQUAe19ixV2z3x77oo+OYgrfMmwFL1JeyI5fMUye/ip+6enSFr4A Q0Wg== MIME-Version: 1.0 Received: by 10.182.95.142 with SMTP id dk14mr31667421obb.2.1343186799693; Tue, 24 Jul 2012 20:26:39 -0700 (PDT) Received: by 10.76.139.136 with HTTP; Tue, 24 Jul 2012 20:26:39 -0700 (PDT) In-Reply-To: <4FF2A65E.2080000@gmail.com> References: <4FF2A65E.2080000@gmail.com> Date: Wed, 25 Jul 2012 11:26:39 +0800 Message-ID: From: liu dapeng To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 25 Jul 2012 03:26:44 -0000 Hi Alex, Regarding v2v communication: 1. If the mobile routers have LTE link and use IPv6, then v2v communication can also rely on LTE? The precondition is that one vehicle knows the other vehicle's identity (for example, every mobile router have a domain name and can be updated dynamically). 2. Even in the above v2v case, Mobile IP could also be useful? Since mobile IP can provide a stable IP address, the mobile routers do not need to update the domain name dynamically, it can use the home address when registering in the domain system. Any comments? Thanks, Best regards, Dapeng 2012/7/3, Alexandru Petrescu : > Hi Abdussalam and thanks for the reply. > > Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >> Hi Alex and All, >> >>> Scenario : A router deployed in a moving vehicle, uses its egress >>> interface to connect to larger-area access network(s) or to other >>> vehicles. >> >> Should it use IPv6-over-LTE? > > In our context we consider indeed IPv6 over LTE, for several reasons. > The 3GPP specs about LTE seem to be very specific and detailed about the > use of IPv6. (In the past, before LTE, the earlier 3GPP specs were > mentioning IPv6 but more like an option feature.) > > However, the 3GPP specs about the use of IPv6 have some lack of > specification in the case that the UE (User Terminal) is actually a > Mobile Router. The Prefix Delegation part may be underspecified. > >> Should it use Mobile IP? > > Hmm... that is a good question and much can be said about it. I am > interested to liste others' oppinions as well. > > I think Mobile IP may be necessary but not sufficient. In the case of > direct vehicle-to-vehicle IP communications (non covered areas) Mobile > IP may not be necessary. It may be that extensions to Neighbor > Discovery and DHCP could help establish paths within local topologies. > > And, when that is done (e.g. exchange routes between two vehicles using > RA) it may become apparent that interactions between Mobile IP and this > mechanism may be necessary. > >>> Open to discussion: what are the scenarios? > > We are interested in describing the scenarios. There may exist several > possibilities. I think of the following lego-like approach: > > - scenario of MR-to-infrastrucure - use Mobile IP, Prefix Delegation. > - scenario MR-to-MR - conceive prefixes in Router Advertisements, > compare to other dynamic routing approaches. > - scenario MR-to-MR-to-Infrastructure - combine the above two. > > Another direction is classify the kinds of vehicles. I think of > something like this: > > - Internet Vehicle (has a plethora of interfaces, long- and short- > range). > - Range Extending Vehicle - extends the range of reachability. > - Leaf Vehicle - like and end-node. > > Then there are other scenario statements that could open the path to the > following: > - addressability within vehicle, ULA, VIN. > - problem of bandwidth difference between inside and outside the > vehicle. > >> What are the potential work items? What might be needed, >> if anything at all? >> >> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and ITS >> issues and in your questions directions. I will join the ITS-WG which >> I think can have relation to MANET [RFC2501]. > > Well, hmm. I am happy to hear that but let us go easy about this. > > "ITS" at IETF is currently just an informal effort. Its future may be > ambitious but right now it's not a WG. To do that, we'd need to make a > BoF first (Birds-of-a-Feather) and ask others' oppinion about way forward= . > > Secod, RFC2501 and ad-hoc routing are just one possibility to continue > working on this. Some people may express positive technical feedback > about MANET and others less so. > >> IMO that vehicle routers communications depend on both their >> communication protocols and the used-network for such communication >> (my answer of both Q1 and Q2). In particular, to answer Q2, IMHO >> there is no doubt that Mobile IP [RFC6275] is needed for the router's >> if the communication is through the Internet's domain(s), but if it >> is through Ad-hoc networks' domain(s) it MAY not be used. > > I tend to agree that Mobile IP may not be needed between vehicles which > communicate directly without infrastructure. Then one wonders _what_ is > needed? > >> The Internet is an infrastructure network and Ad-hoc networks are >> infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree with >> the WG answers, and will read more into the WG inputs regarding these >> issues. > > (see above note about this "WG" acronym which ITS is not currently) > >> I will schedule to participate/prepare I-D in the future for ITS >> scenarios. I am preparing an I-D on DSRv2 routing which is a MANET >> routing protocol that fits the use-case of ITS and VANET as well. > > I am interested to work on scenario/reqs drafts for ITS. > > About "DSRv2" - is it still about Routing Headers? > > I am interested to hear others' oppinions as well. > > Yours, > > Alex > >> >> Regards >> >> Abdussalam Baryun University of Glamorgan, UK >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> >> From: Alexandru Petrescu To: its >> at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >> Scenarios, potential topics... >> ------------------------------------------------------------------------= -------- >> >> >> >> >> > Welcome to the ITS list at IETF, an informal discussion. >> >> Earlier at IETF discussions related to vehicular communications >> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >> few), drafts were published [*]. At times people expressed interest >> to meet f2f. Now there is this email list. >> >> Participants are solicited to work on the topic of using IP in >> Intelligent Transportation Systems. The term ITS is a placeholder >> that, in my oppinion, is generic enough to cover many aspects of >> vehicular communications; vehicles may be wheeled, watered, flown. >> Ambulance, fire engine, coastal ship are particular examples. >> >> Scenario : A router deployed in a moving vehicle, uses its egress >> interface to connect to larger-area access network(s) or to other >> vehicles. Should it use IPv6-over-LTE? Should it use Mobile IP? >> >> Example potential work items: - Reqs for IPv6 in vehicular networks >> - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - ULA and >> IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 over 802.11p >> (IPv6-over-foo). - open. >> >> I am told about other vehicular drafts and discussions, that I have >> not cited, existed and still exist (about e.g. ecall). I am >> interested to learn about all the vehicular activities at IETF. >> >> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >> >> Open to discussion: what are the scenarios? What are the potential >> work items? What might be needed, if anything at all? >> >> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >> draft-jhlee-mext-mnpp-00.txt, October 2009. >> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. 2010. >> draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. 2010 >> draft-rosen-ecrit-ecall-04.txt, March 2010. >> draft-singh-simple-vehicle-info, July 2007. >> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >> draft-bauer-mext-aero-solspace, Sep. 2009. >> draft-bauer-mext-aero-topology, Sep. 2009. >> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >> draft-rosen-ecrit-ecall-05.txt, March 2012. >> >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 ------ Best Regards, Dapeng Liu From alexandru.petrescu@gmail.com Wed Jul 25 07:04:31 2012 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 C243921F85B4 for ; Wed, 25 Jul 2012 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.231 X-Spam-Level: X-Spam-Status: No, score=-9.231 tagged_above=-999 required=5 tests=[AWL=1.018, 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 JnmUlFa+vt+q for ; Wed, 25 Jul 2012 07:04:31 -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 D8E3F21F85CE for ; Wed, 25 Jul 2012 07:04:30 -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 q6PE4TEd002552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Jul 2012 16:04:29 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6PE4TKd026751 for ; Wed, 25 Jul 2012 16:04:29 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6PE4IdK030782 for ; Wed, 25 Jul 2012 16:04:29 +0200 Message-ID: <500FFCE2.6030800@gmail.com> Date: Wed, 25 Jul 2012 16:04:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] want to present? 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, 25 Jul 2012 14:04:31 -0000 Participants to ITS at IETF, We will meet face-to-face Monday evening, 19h30-20h30, room Plaza C. If you want to present slides please ask, Alex From alexandru.petrescu@gmail.com Wed Jul 25 07:18:16 2012 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 49DE221F85EF; Wed, 25 Jul 2012 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.264 X-Spam-Level: X-Spam-Status: No, score=-9.264 tagged_above=-999 required=5 tests=[AWL=0.985, 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 Ef24+iTC0CZU; Wed, 25 Jul 2012 07:18: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 9634421F85D1; Wed, 25 Jul 2012 07:18: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 q6PEICwV032047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2012 16:18:12 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6PEIB0O032017; Wed, 25 Jul 2012 16:18:11 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6PEI7X7004872; Wed, 25 Jul 2012 16:18:11 +0200 Message-ID: <50100020.4040708@gmail.com> Date: Wed, 25 Jul 2012 16:18:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: liu dapeng References: <4FF2A65E.2080000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 25 Jul 2012 14:18:16 -0000 Dear Dapeng, Thank you for the interest in the v2v scenario. Please see below for answers to the questions. Le 25/07/2012 05:26, liu dapeng a �crit : > Hi Alex, > > Regarding v2v communication: > > 1. If the mobile routers have LTE link and use IPv6, then v2v > communication can also rely on LTE? LTE use on a vehicle for V2V communication may be an option. We locally think currently more about the use of shorter-range links (WiFi, other) for direct communications between vehicles, without the use of LTE infrastructure. On another hand, the use of a fixed LTE base station or eNodeB to achieve communication between Mobile Routers may be feasible. Just one LTE base station, or femto cell, may be sufficient to largely improve the V2V communications based on short-range links. Even more, it may be possible to use a LTE base-station on board of vehicle, and maybe LTE Relay, on X2 interface. In this way, direct V2V communication without fixed infrastructure, and still LTE - long range, high bandwidth, may be possible. What do you think? > The precondition is that one vehicle knows the other vehicle's > identity (for example, every mobile router have a domain name and can > be updated dynamically). Right, if a MR owns a fully qualified domain name, then it may try to obtain an IP address dynamically from the LTE infrastructure, and then update its ressource record in the DNS. In this way, another MR may contact the first by identifying it with the FQDN. But here, there may be some problems about the LFNs (Local Fixed Nodes). It's the LFNs which woult typically communicate application data, not the MRs. Then I wonder how would it be possible to have a FQDN for all the LFNs, and an entry in DNS about such FQDN and the IP prefix. And how would the prefix be allocated too. What do you think? > 2. Even in the above v2v case, Mobile IP could also be useful? Since > mobile IP can provide a stable IP address, the mobile routers do not > need to update the domain name dynamically, it can use the home > address when registering in the domain system. Mobile IP could be useful, yes. And if it is used then reachability at a permanent address and session continuity are ensured, without needing to update the DNS. But in order for Mobile IP to work there would be a need for a Home Agent in the fixed infrastructure. For direct V2V communications one MR may "nest" under another MR. For their communication to work, there would be a need that one of those two MRs to be connected to the infrastructure to the HA. Also, it may be possible that even though the HA is not reachable, one MR sends a BU to another MR informing it about its prefix. This is doable. Until now we have much considered the use of RA (Router Advertisement) messages to achieve this, instead of BU. But each has its advantages. What do you think? Alex > > Any comments? > > Thanks, Best regards, Dapeng > > 2012/7/3, Alexandru Petrescu : >> Hi Abdussalam and thanks for the reply. >> >> Le 01/07/2012 19:31, Abdussalam Baryun a �crit : >>> Hi Alex and All, >>> >>>> Scenario : A router deployed in a moving vehicle, uses its >>>> egress interface to connect to larger-area access network(s) or >>>> to other vehicles. >>> >>> Should it use IPv6-over-LTE? >> >> In our context we consider indeed IPv6 over LTE, for several >> reasons. The 3GPP specs about LTE seem to be very specific and >> detailed about the use of IPv6. (In the past, before LTE, the >> earlier 3GPP specs were mentioning IPv6 but more like an option >> feature.) >> >> However, the 3GPP specs about the use of IPv6 have some lack of >> specification in the case that the UE (User Terminal) is actually >> a Mobile Router. The Prefix Delegation part may be >> underspecified. >> >>> Should it use Mobile IP? >> >> Hmm... that is a good question and much can be said about it. I >> am interested to liste others' oppinions as well. >> >> I think Mobile IP may be necessary but not sufficient. In the case >> of direct vehicle-to-vehicle IP communications (non covered areas) >> Mobile IP may not be necessary. It may be that extensions to >> Neighbor Discovery and DHCP could help establish paths within local >> topologies. >> >> And, when that is done (e.g. exchange routes between two vehicles >> using RA) it may become apparent that interactions between Mobile >> IP and this mechanism may be necessary. >> >>>> Open to discussion: what are the scenarios? >> >> We are interested in describing the scenarios. There may exist >> several possibilities. I think of the following lego-like >> approach: >> >> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >> Delegation. - scenario MR-to-MR - conceive prefixes in Router >> Advertisements, compare to other dynamic routing approaches. - >> scenario MR-to-MR-to-Infrastructure - combine the above two. >> >> Another direction is classify the kinds of vehicles. I think of >> something like this: >> >> - Internet Vehicle (has a plethora of interfaces, long- and short- >> range). - Range Extending Vehicle - extends the range of >> reachability. - Leaf Vehicle - like and end-node. >> >> Then there are other scenario statements that could open the path >> to the following: - addressability within vehicle, ULA, VIN. - >> problem of bandwidth difference between inside and outside the >> vehicle. >> >>> What are the potential work items? What might be >>> needed, if anything at all? >>> >>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and >>> ITS issues and in your questions directions. I will join the >>> ITS-WG which I think can have relation to MANET [RFC2501]. >> >> Well, hmm. I am happy to hear that but let us go easy about this. >> >> "ITS" at IETF is currently just an informal effort. Its future may >> be ambitious but right now it's not a WG. To do that, we'd need to >> make a BoF first (Birds-of-a-Feather) and ask others' oppinion >> about way forward. >> >> Secod, RFC2501 and ad-hoc routing are just one possibility to >> continue working on this. Some people may express positive >> technical feedback about MANET and others less so. >> >>> IMO that vehicle routers communications depend on both their >>> communication protocols and the used-network for such >>> communication (my answer of both Q1 and Q2). In particular, to >>> answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is >>> needed for the router's if the communication is through the >>> Internet's domain(s), but if it is through Ad-hoc networks' >>> domain(s) it MAY not be used. >> >> I tend to agree that Mobile IP may not be needed between vehicles >> which communicate directly without infrastructure. Then one >> wonders _what_ is needed? >> >>> The Internet is an infrastructure network and Ad-hoc networks >>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree >>> with the WG answers, and will read more into the WG inputs >>> regarding these issues. >> >> (see above note about this "WG" acronym which ITS is not >> currently) >> >>> I will schedule to participate/prepare I-D in the future for ITS >>> scenarios. I am preparing an I-D on DSRv2 routing which is a >>> MANET routing protocol that fits the use-case of ITS and VANET as >>> well. >> >> I am interested to work on scenario/reqs drafts for ITS. >> >> About "DSRv2" - is it still about Routing Headers? >> >> I am interested to hear others' oppinions as well. >> >> Yours, >> >> Alex >> >>> >>> Regards >>> >>> Abdussalam Baryun University of Glamorgan, UK >>> ======================================================= >>> >>> From: Alexandru Petrescu To: >>> its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>> Scenarios, potential topics... >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>> >> >>> >>> >>> Welcome to the ITS list at IETF, an informal discussion. >>> >>> Earlier at IETF discussions related to vehicular communications >>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>> few), drafts were published [*]. At times people expressed >>> interest to meet f2f. Now there is this email list. >>> >>> Participants are solicited to work on the topic of using IP in >>> Intelligent Transportation Systems. The term ITS is a >>> placeholder that, in my oppinion, is generic enough to cover many >>> aspects of vehicular communications; vehicles may be wheeled, >>> watered, flown. Ambulance, fire engine, coastal ship are >>> particular examples. >>> >>> Scenario : A router deployed in a moving vehicle, uses its >>> egress interface to connect to larger-area access network(s) or >>> to other vehicles. Should it use IPv6-over-LTE? Should it use >>> Mobile IP? >>> >>> Example potential work items: - Reqs for IPv6 in vehicular >>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - >>> ULA and IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 >>> over 802.11p (IPv6-over-foo). - open. >>> >>> I am told about other vehicular drafts and discussions, that I >>> have not cited, existed and still exist (about e.g. ecall). I >>> am interested to learn about all the vehicular activities at >>> IETF. >>> >>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>> >>> Open to discussion: what are the scenarios? What are the >>> potential work items? What might be needed, if anything at all? >>> >>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. >>> 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>> draft-singh-simple-vehicle-info, July 2007. >>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>> draft-bauer-mext-aero-solspace, Sep. 2009. >>> draft-bauer-mext-aero-topology, Sep. 2009. >>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>> >>> >> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >> > > From seiljeon@av.it.pt Wed Jul 25 09:19:03 2012 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 6000A21F86D0 for ; Wed, 25 Jul 2012 09:19:03 -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 5ubrCqIcFWvr for ; Wed, 25 Jul 2012 09:19:02 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C921F86CF for ; Wed, 25 Jul 2012 09:19:01 -0700 (PDT) Received: from [192.168.21.32] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65569035; Wed, 25 Jul 2012 17:14:00 +0100 From: "Seil Jeon" To: "'Alexandru Petrescu'" References: <5000551E.9000800@gmail.com> In-Reply-To: <5000551E.9000800@gmail.com> Date: Wed, 25 Jul 2012 17:14:01 +0100 Message-ID: <000c01cd6a80$8115a550$8340eff0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9yEKjmsKSOjOZNCYEpfBUzNfuGZhZZ7Xw Content-Language: ko Cc: its@ietf.org Subject: Re: [its] New draft on scenarios and requirements for IP in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:19:03 -0000 Hi Alex, Regarding on Section 3 Scenarios, I would classify them with following categories. Scenarios 1, 3 might be the necessities of vehicle communications Scenarios 2 describes high wireless accesses availability on current network environment Scenario 4 - it might be one of requirements. Scenario 5 - it sounds somewhat generic problem to me where every node to have Internet connection is facing. ... My opinion is would we need to specify them focused on necessities of vehicular communications? Those would be much better to understand requirements followed. Regards, Seil -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Friday, July 13, 2012 6:05 PM To: its@ietf.org Subject: [its] New draft on scenarios and requirements for IP in ITS Participants to ITS informal effort at IETF, Per our recent discussions, we submitted a new draft about scenarios and requirements for IP in ITS: draft-petrescu-its-scenarios-reqs-01.txt I would like to request feedback about the scenarios and requirements described in this draft. Thanks in advance, Alex and on behalf of co-authors. From maxpassion@gmail.com Thu Jul 26 00:25:15 2012 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 9F30221F84CE; Thu, 26 Jul 2012 00:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 wVE6NJ3+dqfq; Thu, 26 Jul 2012 00:25:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4182621F84C5; Thu, 26 Jul 2012 00:25:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2594680obb.31 for ; Thu, 26 Jul 2012 00:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4d75gvEQyiFGBwyHoGLl9Ufc04cLERaigC9GLdcLAK0=; b=skufv8KREOfrrQZ5wcnBOXOvGQGdMvXXfn8zQ7cNtLeZWEB7YZizle164kU4WZH9oA TDL7L17LX4URnTwWX5oBuMhCN5U+mBkzgfrXXJ5JLfn4yN8Pj0Sk9mVN12zy8R7atuU+ Bal5c0mw9vLO0vHnJ0+kQLzNCuec/KciL+4HmIVGRinXlymWeUzF4y2aKMRUBxv70BLI IQAJWUFqOSrd33u08zUBIu2gE4cmVKRt1ZCoV4dFIpWIQXTvvsR8AjxBkiqZvShGFr+C Lzql5L8K48CIbzw03BRwlW2fr8SbOI83+G+Mjykmflmkry1geu7qP8/1k52frhXxZnaw d/MA== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr39529336oeg.37.1343287513597; Thu, 26 Jul 2012 00:25:13 -0700 (PDT) Received: by 10.76.139.136 with HTTP; Thu, 26 Jul 2012 00:25:13 -0700 (PDT) In-Reply-To: <50100020.4040708@gmail.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> Date: Thu, 26 Jul 2012 15:25:13 +0800 Message-ID: From: liu dapeng To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 26 Jul 2012 07:25:15 -0000 Hi Alex, Please see my reply inline. 2012/7/25, Alexandru Petrescu : > Dear Dapeng, > > Thank you for the interest in the v2v scenario. Please see below for > answers to the questions. > > Le 25/07/2012 05:26, liu dapeng a =E9crit : >> Hi Alex, >> >> Regarding v2v communication: >> >> 1. If the mobile routers have LTE link and use IPv6, then v2v >> communication can also rely on LTE? > > LTE use on a vehicle for V2V communication may be an option. We locally > think currently more about the use of shorter-range links (WiFi, other) > for direct communications between vehicles, without the use of LTE > infrastructure. [Dapeng] May I ask what is the use case scenario of this V2V communication? Whether the transmission range of Wi-Fi is enough for this use case? > On another hand, the use of a fixed LTE base station or eNodeB to > achieve communication between Mobile Routers may be feasible. Just one > LTE base station, or femto cell, may be sufficient to largely improve > the V2V communications based on short-range links. > > Even more, it may be possible to use a LTE base-station on board of > vehicle, and maybe LTE Relay, on X2 interface. In this way, direct V2V > communication without fixed infrastructure, and still LTE - long range, > high bandwidth, may be possible. > > What do you think? [Dapeng] LTE D2D maybe relevant to this topic? >> The precondition is that one vehicle knows the other vehicle's >> identity (for example, every mobile router have a domain name and can >> be updated dynamically). > > Right, if a MR owns a fully qualified domain name, then it may try to > obtain an IP address dynamically from the LTE infrastructure, and then > update its ressource record in the DNS. In this way, another MR may > contact the first by identifying it with the FQDN. > > But here, there may be some problems about the LFNs (Local Fixed Nodes). > It's the LFNs which woult typically communicate application data, not > the MRs. Then I wonder how would it be possible to have a FQDN for all > the LFNs, and an entry in DNS about such FQDN and the IP prefix. And > how would the prefix be allocated too. [Dapeng] How about using NEMO in the MR? If that is the case, the LFNs will be the mobile node and only the LFN that need to communicate with another vehicle need to have a FQDN. The user can get the FQDN by registering the service to the the ITS operator. > What do you think? > >> 2. Even in the above v2v case, Mobile IP could also be useful? Since >> mobile IP can provide a stable IP address, the mobile routers do not >> need to update the domain name dynamically, it can use the home >> address when registering in the domain system. > > Mobile IP could be useful, yes. And if it is used then reachability at > a permanent address and session continuity are ensured, without needing > to update the DNS. But in order for Mobile IP to work there would be a > need for a Home Agent in the fixed infrastructure. > > For direct V2V communications one MR may "nest" under another MR. For > their communication to work, there would be a need that one of those two > MRs to be connected to the infrastructure to the HA. > > Also, it may be possible that even though the HA is not reachable, one > MR sends a BU to another MR informing it about its prefix. This is > doable. Until now we have much considered the use of RA (Router > Advertisement) messages to achieve this, instead of BU. But each has > its advantages. [Dapeng] If use RA, that will limit the V2V communication to only adjacent vehicle? Thanks, Best Regards, Dapeng > What do you think? > > Alex > >> >> Any comments? >> >> Thanks, Best regards, Dapeng >> >> 2012/7/3, Alexandru Petrescu : >>> Hi Abdussalam and thanks for the reply. >>> >>> Le 01/07/2012 19:31, Abdussalam Baryun a =E9crit : >>>> Hi Alex and All, >>>> >>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>> egress interface to connect to larger-area access network(s) or >>>>> to other vehicles. >>>> >>>> Should it use IPv6-over-LTE? >>> >>> In our context we consider indeed IPv6 over LTE, for several >>> reasons. The 3GPP specs about LTE seem to be very specific and >>> detailed about the use of IPv6. (In the past, before LTE, the >>> earlier 3GPP specs were mentioning IPv6 but more like an option >>> feature.) >>> >>> However, the 3GPP specs about the use of IPv6 have some lack of >>> specification in the case that the UE (User Terminal) is actually >>> a Mobile Router. The Prefix Delegation part may be >>> underspecified. >>> >>>> Should it use Mobile IP? >>> >>> Hmm... that is a good question and much can be said about it. I >>> am interested to liste others' oppinions as well. >>> >>> I think Mobile IP may be necessary but not sufficient. In the case >>> of direct vehicle-to-vehicle IP communications (non covered areas) >>> Mobile IP may not be necessary. It may be that extensions to >>> Neighbor Discovery and DHCP could help establish paths within local >>> topologies. >>> >>> And, when that is done (e.g. exchange routes between two vehicles >>> using RA) it may become apparent that interactions between Mobile >>> IP and this mechanism may be necessary. >>> >>>>> Open to discussion: what are the scenarios? >>> >>> We are interested in describing the scenarios. There may exist >>> several possibilities. I think of the following lego-like >>> approach: >>> >>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >>> Delegation. - scenario MR-to-MR - conceive prefixes in Router >>> Advertisements, compare to other dynamic routing approaches. - >>> scenario MR-to-MR-to-Infrastructure - combine the above two. >>> >>> Another direction is classify the kinds of vehicles. I think of >>> something like this: >>> >>> - Internet Vehicle (has a plethora of interfaces, long- and short- >>> range). - Range Extending Vehicle - extends the range of >>> reachability. - Leaf Vehicle - like and end-node. >>> >>> Then there are other scenario statements that could open the path >>> to the following: - addressability within vehicle, ULA, VIN. - >>> problem of bandwidth difference between inside and outside the >>> vehicle. >>> >>>> What are the potential work items? What might be >>>> needed, if anything at all? >>>> >>>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) and >>>> ITS issues and in your questions directions. I will join the >>>> ITS-WG which I think can have relation to MANET [RFC2501]. >>> >>> Well, hmm. I am happy to hear that but let us go easy about this. >>> >>> "ITS" at IETF is currently just an informal effort. Its future may >>> be ambitious but right now it's not a WG. To do that, we'd need to >>> make a BoF first (Birds-of-a-Feather) and ask others' oppinion >>> about way forward. >>> >>> Secod, RFC2501 and ad-hoc routing are just one possibility to >>> continue working on this. Some people may express positive >>> technical feedback about MANET and others less so. >>> >>>> IMO that vehicle routers communications depend on both their >>>> communication protocols and the used-network for such >>>> communication (my answer of both Q1 and Q2). In particular, to >>>> answer Q2, IMHO there is no doubt that Mobile IP [RFC6275] is >>>> needed for the router's if the communication is through the >>>> Internet's domain(s), but if it is through Ad-hoc networks' >>>> domain(s) it MAY not be used. >>> >>> I tend to agree that Mobile IP may not be needed between vehicles >>> which communicate directly without infrastructure. Then one >>> wonders _what_ is needed? >>> >>>> The Internet is an infrastructure network and Ad-hoc networks >>>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I agree >>>> with the WG answers, and will read more into the WG inputs >>>> regarding these issues. >>> >>> (see above note about this "WG" acronym which ITS is not >>> currently) >>> >>>> I will schedule to participate/prepare I-D in the future for ITS >>>> scenarios. I am preparing an I-D on DSRv2 routing which is a >>>> MANET routing protocol that fits the use-case of ITS and VANET as >>>> well. >>> >>> I am interested to work on scenario/reqs drafts for ITS. >>> >>> About "DSRv2" - is it still about Routing Headers? >>> >>> I am interested to hear others' oppinions as well. >>> >>> Yours, >>> >>> Alex >>> >>>> >>>> Regards >>>> >>>> Abdussalam Baryun University of Glamorgan, UK >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>>> >>>> From: Alexandru Petrescu To: >>>> its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 Sub: [its] >>>> Scenarios, potential topics... >>>> ----------------------------------------------------------------------= ---------- >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> > Welcome to the ITS list at IETF, an informal discussion. >>>> >>>> Earlier at IETF discussions related to vehicular communications >>>> happened in several groups (MEXT, AUTOCONF, 6MAN, to name but a >>>> few), drafts were published [*]. At times people expressed >>>> interest to meet f2f. Now there is this email list. >>>> >>>> Participants are solicited to work on the topic of using IP in >>>> Intelligent Transportation Systems. The term ITS is a >>>> placeholder that, in my oppinion, is generic enough to cover many >>>> aspects of vehicular communications; vehicles may be wheeled, >>>> watered, flown. Ambulance, fire engine, coastal ship are >>>> particular examples. >>>> >>>> Scenario : A router deployed in a moving vehicle, uses its >>>> egress interface to connect to larger-area access network(s) or >>>> to other vehicles. Should it use IPv6-over-LTE? Should it use >>>> Mobile IP? >>>> >>>> Example potential work items: - Reqs for IPv6 in vehicular >>>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 addressing - >>>> ULA and IPv6 for vehicles - IPv6 multicast - ISO TC204 - IPv6 >>>> over 802.11p (IPv6-over-foo). - open. >>>> >>>> I am told about other vehicular drafts and discussions, that I >>>> have not cited, existed and still exist (about e.g. ecall). I >>>> am interested to learn about all the vehicular activities at >>>> IETF. >>>> >>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>> >>>> Open to discussion: what are the scenarios? What are the >>>> potential work items? What might be needed, if anything at all? >>>> >>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. 2010. >>>> draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, Nov. >>>> 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>>> draft-singh-simple-vehicle-info, July 2007. >>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>>> draft-bauer-mext-aero-solspace, Sep. 2009. >>>> draft-bauer-mext-aero-topology, Sep. 2009. >>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>> >>>> >>> >>> >>> >>> _______________________________________________ manet mailing list >>> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >>> >> >> > > > --=20 ------ Best Regards, Dapeng Liu From alexandru.petrescu@gmail.com Thu Jul 26 09:37:31 2012 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 A875021F85DF; Thu, 26 Jul 2012 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.323 X-Spam-Level: X-Spam-Status: No, score=-9.323 tagged_above=-999 required=5 tests=[AWL=0.926, 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 Rsi8T0hK+6YS; Thu, 26 Jul 2012 09:37:30 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 64D1621F85D8; Thu, 26 Jul 2012 09:37:29 -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 q6QGbOla016040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 18:37:24 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QGbOlT020060; Thu, 26 Jul 2012 18:37:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QGbK8G000336; Thu, 26 Jul 2012 18:37:24 +0200 Message-ID: <50117240.10902@gmail.com> Date: Thu, 26 Jul 2012 18:37:20 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: liu dapeng References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: manet , its@ietf.org, Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 26 Jul 2012 16:37:31 -0000 Hi Dapeng, Le 26/07/2012 09:25, liu dapeng a �crit : > Hi Alex, Please see my reply inline. > > 2012/7/25, Alexandru Petrescu : >> Dear Dapeng, >> >> Thank you for the interest in the v2v scenario. Please see below >> for answers to the questions. >> >> Le 25/07/2012 05:26, liu dapeng a �crit : >>> Hi Alex, >>> >>> Regarding v2v communication: >>> >>> 1. If the mobile routers have LTE link and use IPv6, then v2v >>> communication can also rely on LTE? >> >> LTE use on a vehicle for V2V communication may be an option. We >> locally think currently more about the use of shorter-range links >> (WiFi, other) for direct communications between vehicles, without >> the use of LTE infrastructure. > > [Dapeng] May I ask what is the use case scenario of this V2V > communication? Well you may and there are many scenarios that we considered in the past, as part of work with various partners specialized in particular scenarios. V2V concepts for public transportation scenarios are described in section 3.3 of draft-petrescu-its-scenarios-reqs-01. A fixed incident scene scenario for V2V is described in section 3 of draft-petrescu-autoconf-ra-based-routing-02. Peer-to-peer applications described in section 4.2 of draft-ietf-mext-nemo-ro-automotive-req-02. An advertising vehicle scenario is one where a 'billboard' vehicle runs along the highway and distributes not only visual ads but also wireless Internet. This is to be used in many kinds of convoys like... Generic use of V2V is described in section 3.3 of draft-petrescu-its-scenarios-reqs-01.txt. CALM describes some V2V scenarios as well. Is there some particular scenario that deserves more interest from your side? > Whether the transmission range of Wi-Fi is enough for this use case? Indeed in some use cases the WiFi transmission range (unlicensed spectrum, around 50meter range at a certain power level) may be enough. For example, at an incident scene this is largely enough. On another hand, vehicles in a convoy, or wifi billboard vehicle, may need more than 50m, otherwise one is tempted to approach more for better reception. In these cases maybe LTE may be necessary, or other forms of longer-range wireless links, maybe with forms of 802.11p. >> On another hand, the use of a fixed LTE base station or eNodeB to >> achieve communication between Mobile Routers may be feasible. >> Just one LTE base station, or femto cell, may be sufficient to >> largely improve the V2V communications based on short-range links. >> >> Even more, it may be possible to use a LTE base-station on board of >> vehicle, and maybe LTE Relay, on X2 interface. In this way, direct >> V2V communication without fixed infrastructure, and still LTE - >> long range, high bandwidth, may be possible. >> >> What do you think? > > [Dapeng] LTE D2D maybe relevant to this topic? LTE D2D would stand for "Device-to-Device"? I am not aware of this term, please explain. (I am aware of an effort at ETSI called "GW-to-GW" communications which may approach much to these V2V terms). >>> The precondition is that one vehicle knows the other vehicle's >>> identity (for example, every mobile router have a domain name >>> and can be updated dynamically). >> >> Right, if a MR owns a fully qualified domain name, then it may try >> to obtain an IP address dynamically from the LTE infrastructure, >> and then update its ressource record in the DNS. In this way, >> another MR may contact the first by identifying it with the FQDN. >> >> But here, there may be some problems about the LFNs (Local Fixed >> Nodes). It's the LFNs which woult typically communicate >> application data, not the MRs. Then I wonder how would it be >> possible to have a FQDN for all the LFNs, and an entry in DNS about >> such FQDN and the IP prefix. And how would the prefix be allocated >> too. > > [Dapeng] How about using NEMO in the MR? If that is the case, the > LFNs will be the mobile node and only the LFN that need to > communicate with another vehicle need to have a FQDN. The user can > get the FQDN by registering the service to the the ITS operator. Sounds reasonable. However, running NEMO Mobile IP on MR would mean that LFN is not running anything mobility-related and that MR does all mobility management on its behalf. In this sense, such a scenario would mean that MR updates the DNS with an entire set of addresses (a prefix). For example, instead of updating it with mr.example.com - 1::1, it would update it with example.com - 1::/64, if that is at all possible. In this way, whenever some LFN asks to talk to LFN.example.com then the IP address would be within that prefix. I am not sure I am not saying stupid DNS things, I stand correced. I need to better understand a DNS part of the picture in this ITS effort, please, and others help clarify it. Yours, Alex > >> What do you think? >> >>> 2. Even in the above v2v case, Mobile IP could also be useful? >>> Since mobile IP can provide a stable IP address, the mobile >>> routers do not need to update the domain name dynamically, it >>> can use the home address when registering in the domain system. >> >> Mobile IP could be useful, yes. And if it is used then >> reachability at a permanent address and session continuity are >> ensured, without needing to update the DNS. But in order for >> Mobile IP to work there would be a need for a Home Agent in the >> fixed infrastructure. >> >> For direct V2V communications one MR may "nest" under another MR. >> For their communication to work, there would be a need that one of >> those two MRs to be connected to the infrastructure to the HA. >> >> Also, it may be possible that even though the HA is not reachable, >> one MR sends a BU to another MR informing it about its prefix. This >> is doable. Until now we have much considered the use of RA (Router >> Advertisement) messages to achieve this, instead of BU. But each >> has its advantages. > > [Dapeng] If use RA, that will limit the V2V communication to only > adjacent vehicle? > > Thanks, Best Regards, Dapeng > >> What do you think? >> >> Alex >> >>> >>> Any comments? >>> >>> Thanks, Best regards, Dapeng >>> >>> 2012/7/3, Alexandru Petrescu : >>>> Hi Abdussalam and thanks for the reply. >>>> >>>> Le 01/07/2012 19:31, Abdussalam Baryun a �crit : >>>>> Hi Alex and All, >>>>> >>>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>>> egress interface to connect to larger-area access >>>>>> network(s) or to other vehicles. >>>>> >>>>> Should it use IPv6-over-LTE? >>>> >>>> In our context we consider indeed IPv6 over LTE, for several >>>> reasons. The 3GPP specs about LTE seem to be very specific and >>>> detailed about the use of IPv6. (In the past, before LTE, the >>>> earlier 3GPP specs were mentioning IPv6 but more like an >>>> option feature.) >>>> >>>> However, the 3GPP specs about the use of IPv6 have some lack of >>>> specification in the case that the UE (User Terminal) is >>>> actually a Mobile Router. The Prefix Delegation part may be >>>> underspecified. >>>> >>>>> Should it use Mobile IP? >>>> >>>> Hmm... that is a good question and much can be said about it. I >>>> am interested to liste others' oppinions as well. >>>> >>>> I think Mobile IP may be necessary but not sufficient. In the >>>> case of direct vehicle-to-vehicle IP communications (non >>>> covered areas) Mobile IP may not be necessary. It may be that >>>> extensions to Neighbor Discovery and DHCP could help establish >>>> paths within local topologies. >>>> >>>> And, when that is done (e.g. exchange routes between two >>>> vehicles using RA) it may become apparent that interactions >>>> between Mobile IP and this mechanism may be necessary. >>>> >>>>>> Open to discussion: what are the scenarios? >>>> >>>> We are interested in describing the scenarios. There may exist >>>> several possibilities. I think of the following lego-like >>>> approach: >>>> >>>> - scenario of MR-to-infrastrucure - use Mobile IP, Prefix >>>> Delegation. - scenario MR-to-MR - conceive prefixes in Router >>>> Advertisements, compare to other dynamic routing approaches. - >>>> scenario MR-to-MR-to-Infrastructure - combine the above two. >>>> >>>> Another direction is classify the kinds of vehicles. I think >>>> of something like this: >>>> >>>> - Internet Vehicle (has a plethora of interfaces, long- and >>>> short- range). - Range Extending Vehicle - extends the range of >>>> reachability. - Leaf Vehicle - like and end-node. >>>> >>>> Then there are other scenario statements that could open the >>>> path to the following: - addressability within vehicle, ULA, >>>> VIN. - problem of bandwidth difference between inside and >>>> outside the vehicle. >>>> >>>>> What are the potential work items? What might be >>>>> needed, if anything at all? >>>>> >>>>> I am interested to work on Vehicle Ad-hoc NETwork (VANET) >>>>> and ITS issues and in your questions directions. I will join >>>>> the ITS-WG which I think can have relation to MANET >>>>> [RFC2501]. >>>> >>>> Well, hmm. I am happy to hear that but let us go easy about >>>> this. >>>> >>>> "ITS" at IETF is currently just an informal effort. Its >>>> future may be ambitious but right now it's not a WG. To do >>>> that, we'd need to make a BoF first (Birds-of-a-Feather) and >>>> ask others' oppinion about way forward. >>>> >>>> Secod, RFC2501 and ad-hoc routing are just one possibility to >>>> continue working on this. Some people may express positive >>>> technical feedback about MANET and others less so. >>>> >>>>> IMO that vehicle routers communications depend on both their >>>>> communication protocols and the used-network for such >>>>> communication (my answer of both Q1 and Q2). In particular, >>>>> to answer Q2, IMHO there is no doubt that Mobile IP >>>>> [RFC6275] is needed for the router's if the communication is >>>>> through the Internet's domain(s), but if it is through >>>>> Ad-hoc networks' domain(s) it MAY not be used. >>>> >>>> I tend to agree that Mobile IP may not be needed between >>>> vehicles which communicate directly without infrastructure. >>>> Then one wonders _what_ is needed? >>>> >>>>> The Internet is an infrastructure network and Ad-hoc networks >>>>> are infrastructure-less networks. Regarding Q3, Q4 and Q5 I >>>>> agree with the WG answers, and will read more into the WG >>>>> inputs regarding these issues. >>>> >>>> (see above note about this "WG" acronym which ITS is not >>>> currently) >>>> >>>>> I will schedule to participate/prepare I-D in the future for >>>>> ITS scenarios. I am preparing an I-D on DSRv2 routing which >>>>> is a MANET routing protocol that fits the use-case of ITS >>>>> and VANET as well. >>>> >>>> I am interested to work on scenario/reqs drafts for ITS. >>>> >>>> About "DSRv2" - is it still about Routing Headers? >>>> >>>> I am interested to hear others' oppinions as well. >>>> >>>> Yours, >>>> >>>> Alex >>>> >>>>> >>>>> Regards >>>>> >>>>> Abdussalam Baryun University of Glamorgan, UK >>>>> ======================================================= >>>>> >>>>> From: Alexandru Petrescu >>>>> To: its at ietf.org Date: Fri, 16 Mar 2012 13:38:49 +0100 >>>>> Sub: [its] Scenarios, potential topics... >>>>> -------------------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>>> >> >>>>> >>>>> Welcome to the ITS list at IETF, an informal discussion. >>>>> >>>>> Earlier at IETF discussions related to vehicular >>>>> communications happened in several groups (MEXT, AUTOCONF, >>>>> 6MAN, to name but a few), drafts were published [*]. At >>>>> times people expressed interest to meet f2f. Now there is >>>>> this email list. >>>>> >>>>> Participants are solicited to work on the topic of using IP >>>>> in Intelligent Transportation Systems. The term ITS is a >>>>> placeholder that, in my oppinion, is generic enough to cover >>>>> many aspects of vehicular communications; vehicles may be >>>>> wheeled, watered, flown. Ambulance, fire engine, coastal >>>>> ship are particular examples. >>>>> >>>>> Scenario : A router deployed in a moving vehicle, uses its >>>>> egress interface to connect to larger-area access network(s) >>>>> or to other vehicles. Should it use IPv6-over-LTE? Should >>>>> it use Mobile IP? >>>>> >>>>> Example potential work items: - Reqs for IPv6 in vehicular >>>>> networks - V2V with RA - V2R(oadside) - VIN and IPv6 >>>>> addressing - ULA and IPv6 for vehicles - IPv6 multicast - >>>>> ISO TC204 - IPv6 over 802.11p (IPv6-over-foo). - open. >>>>> >>>>> I am told about other vehicular drafts and discussions, that >>>>> I have not cited, existed and still exist (about e.g. >>>>> ecall). I am interested to learn about all the vehicular >>>>> activities at IETF. >>>>> >>>>> Relevant std works: IEEE 802.11p, 802.22, ETSI ITS, ISO. >>>>> >>>>> Open to discussion: what are the scenarios? What are the >>>>> potential work items? What might be needed, if anything at >>>>> all? >>>>> >>>>> Alex [*] draft-ietf-mext-nemo-ro-automotive-req-02 >>>>> draft-jhlee-mext-mnpp-00.txt, October 2009. >>>>> draft-ietf-mext-nemo-ro-automotive-req-02, Jan. 2009. >>>>> draft-karagiannis-traffic-safety-requirements-02.txt, Feb. >>>>> 2010. draft-wakikawa-roll-invehicle-reqs-00.txt, May 2008. >>>>> draft-petrescu-autoconf-ra-based-routing-01.txt, Feb. 2011. >>>>> draft-petrescu-mip4-tuntype-change-00.txt, March 2011. >>>>> draft-uehara-dtnrg-decentralized-probe-message-00.txt, Nov. >>>>> 2010. draft-uehara-dtnrg-decentralized-probe-transport-00, >>>>> Nov. 2010 draft-rosen-ecrit-ecall-04.txt, March 2010. >>>>> draft-singh-simple-vehicle-info, July 2007. >>>>> draft-sijeon-mext-nemo-pmip6-00, Oct. 2010. >>>>> draft-bauer-mext-aero-solspace, Sep. 2009. >>>>> draft-bauer-mext-aero-topology, Sep. 2009. >>>>> draft-bernardos-mext-aero-nemo-ro-sol-analysis, Nov. 2008. >>>>> draft-rosen-ecrit-ecall-05.txt, March 2012. >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ manet mailing >>>> list manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> >> >> >> > > From alexandru.petrescu@gmail.com Thu Jul 26 09:45:58 2012 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 5A94721F861B for ; Thu, 26 Jul 2012 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.35 X-Spam-Level: X-Spam-Status: No, score=-9.35 tagged_above=-999 required=5 tests=[AWL=0.899, 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 m6TYncq1CDvd for ; Thu, 26 Jul 2012 09:45:57 -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 7A2FD21F8619 for ; Thu, 26 Jul 2012 09:45: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 q6QGjtMn018066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 18:45:55 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6QGjsa7021501; Thu, 26 Jul 2012 18:45:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6QGjo8i026648; Thu, 26 Jul 2012 18:45:54 +0200 Message-ID: <5011743F.6090708@gmail.com> Date: Thu, 26 Jul 2012 18:45:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Seil Jeon References: <5000551E.9000800@gmail.com> <000c01cd6a80$8115a550$8340eff0$@av.it.pt> In-Reply-To: <000c01cd6a80$8115a550$8340eff0$@av.it.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] New draft on scenarios and requirements for IP in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:45:58 -0000 Seil, Thank you for the message. I agree mainly with your points. I find it useful to the future reader if the scenarios where grouped in classes: necessities of vehicle communications, high bandwidth availability, and other generica problems. This may also to separate the requirements which are more specific to vehicular communications, rather than generic fixed communications. Is this what you mean? Do you think a modification of the draft should be done? Alex Le 25/07/2012 18:14, Seil Jeon a �crit : > Hi Alex, > > > Regarding on Section 3 Scenarios, I would classify them with > following categories. > > Scenarios 1, 3 might be the necessities of vehicle communications > > Scenarios 2 describes high wireless accesses availability on current > network environment > > Scenario 4 - it might be one of requirements. > > Scenario 5 - it sounds somewhat generic problem to me where every > node to have Internet connection is facing. > > ... > > My opinion is would we need to specify them focused on necessities > of vehicular communications? > > Those would be much better to understand requirements followed. > > > Regards, > > Seil > > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Friday, July 13, 2012 6:05 PM To: its@ietf.org Subject: [its] New > draft on scenarios and requirements for IP in ITS > > Participants to ITS informal effort at IETF, > > Per our recent discussions, we submitted a new draft about scenarios > and requirements for IP in ITS: > > draft-petrescu-its-scenarios-reqs-01.txt > > I would like to request feedback about the scenarios and > requirements described in this draft. > > Thanks in advance, > > Alex and on behalf of co-authors. > > > From budden@nps.edu Thu Jul 26 10:12:59 2012 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 7F16121F8670 for ; Thu, 26 Jul 2012 10:12:59 -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 JnZ3JwnnY4EE for ; Thu, 26 Jul 2012 10:12:58 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33C21F866B for ; Thu, 26 Jul 2012 10:12:58 -0700 (PDT) X-ASG-Debug-ID: 1343322774-036c92049440a400001-m4RtKs Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id 6amhIaGhgdyKCTfA; Thu, 26 Jul 2012 10:12:54 -0700 (PDT) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jul 2012 10:12:53 -0700 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [manet] [its] Scenarios, potential topics... To: Alexandru Petrescu In-Reply-To: <50117240.10902@gmail.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 26 Jul 2012 10:12:00 -0700 Message-ID: <1343322720.981.666.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1343322774 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.103822 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: manet , its@ietf.org, liu dapeng , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 26 Jul 2012 17:12:59 -0000 On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: > > Is there some particular scenario that deserves more interest from > your > side? > > > Whether the transmission range of Wi-Fi is enough for this use case? > > Indeed in some use cases the WiFi transmission range (unlicensed > spectrum, around 50meter range at a certain power level) may be > enough. > For example, at an incident scene this is largely enough. Liu Dapeng, The classical use case, in my mind, is the instrumented ambulance*. The casualty inside may have several end systems (sensors) attached. Further, the ambulance will have end system nav receiver (to report position) and the EMT may need several services, VOIP being an obvious one. The topology for such is a LAN within the ambulance and a router with one or more outside interfaces. Reaching to a neighboring vehicle (e.g. with WiFi) is clearly not enough. The router needs to get to the rest of the internet in order to get the data to the hospital emergency room. So the first thought is an LTE or IEEE 802.16 network segment for the radio-WAN. There's nothing wrong with more than one hop, so including a WiFi interface on the router is OK too. (Indeed with the balkanization of the cellphone system, at least in US, multiple 4G cellphone interfaces is likely to be needed). From sratliff@cisco.com Thu Jul 26 11:22:30 2012 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 DAEE721F861F; Thu, 26 Jul 2012 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 jtH-ZN6sQbwS; Thu, 26 Jul 2012 11:22:30 -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 2C25421F8623; Thu, 26 Jul 2012 11:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2135; q=dns/txt; s=iport; t=1343326950; x=1344536550; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7dkrGO47WYkVkOBES2sCYFPba7QSO69U1FoyzmakyR0=; b=CE31W632IWE2tKRBAcLvRXIURHt315U9xsxDttTxoIGPu9EOg/ZjcV/+ PVOLNAvYzG7iXKqBMlFF0VecovtNiy3z6OAKIgva94KC5UcaPyhslDNvP n0pllzq0Ft15kiAYD4IyXW9zZ/WZZT27SrcYMFRb1Hy9oXY7PMuyjerDZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJKJEVCtJV2d/2dsb2JhbABFuTmBB4IgAQEBAwEBAQEPASc0CwULAgEIDgoeECcLJQIEDgUih2UGC5tzoEYEi08bhXlgA5VIjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,660,1336348800"; d="scan'208";a="102690250" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jul 2012 18:22:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6QIMTo8024757 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jul 2012 18:22:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 13:22:29 -0500 From: "Stan Ratliff (sratliff)" To: Rex Buddenberg Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsAA= Date: Thu, 26 Jul 2012 18:22:28 +0000 Message-ID: References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> In-Reply-To: <1343322720.981.666.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.005 x-tm-as-result: No--33.827800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <17B5F65E7430E74AA434261AC6C8121F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandru Petrescu , manet , "" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 26 Jul 2012 18:22:31 -0000 Rex, On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: > On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>=20 >> Is there some particular scenario that deserves more interest from >> your >> side? >>=20 >>> Whether the transmission range of Wi-Fi is enough for this use case? >>=20 >> Indeed in some use cases the WiFi transmission range (unlicensed >> spectrum, around 50meter range at a certain power level) may be >> enough. >> For example, at an incident scene this is largely enough.=20 >=20 > Liu Dapeng, >=20 > The classical use case, in my mind, is the instrumented ambulance*. The > casualty inside may have several end systems (sensors) attached. > Further, the ambulance will have end system nav receiver (to report > position) and the EMT may need several services, VOIP being an obvious > one. >=20 > The topology for such is a LAN within the ambulance and a router with > one or more outside interfaces. Reaching to a neighboring vehicle (e.g. > with WiFi) is clearly not enough. The router needs to get to the rest > of the internet in order to get the data to the hospital emergency room. > So the first thought is an LTE or IEEE 802.16 network segment for the > radio-WAN. There's nothing wrong with more than one hop, so including a > WiFi interface on the router is OK too. (Indeed with the balkanization > of the cellphone system, at least in US, multiple 4G cellphone > interfaces is likely to be needed). >=20 FWIW, I think you've hit the nail on the head here. The WiFi connection to = a neighboring vehicle might help, in cases where (1) the ambulance attendan= ts want to do something like a VoIP call to the people in the neighboring v= ehicle, or (2) if said neighboring vehicle has Internet connectivity and ca= n "share" (e.g. 802.16, or LTE, or maybe even a satellite modem). But havin= g WiFi to a neighboring vehicle is, in and of itself, not necessarily a goo= d thing.=20 Regards, Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From seiljeon@av.it.pt Fri Jul 27 03:24:54 2012 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 69B0C21F8613 for ; Fri, 27 Jul 2012 03:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CIq48LQLs6W8 for ; Fri, 27 Jul 2012 03:24:53 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3A01421F8503 for ; Fri, 27 Jul 2012 03:24:53 -0700 (PDT) Received: from [193.136.93.23] (account seiljeon@av.it.pt HELO ATNoGSeil) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 65598335; Fri, 27 Jul 2012 11:24:52 +0100 From: "Seil Jeon" To: "'Alexandru Petrescu'" References: <5000551E.9000800@gmail.com> <000c01cd6a80$8115a550$8340eff0$@av.it.pt> <5011743F.6090708@gmail.com> In-Reply-To: <5011743F.6090708@gmail.com> Date: Fri, 27 Jul 2012 11:24:54 +0100 Message-ID: <001701cd6be2$1077ccc0$31676640$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9yEKjmsKSOjOZNCYEpfBUzNfuGQFAu0iYAaPTH8yYRQihsA== Content-Language: ko Cc: its@ietf.org Subject: Re: [its] New draft on scenarios and requirements for IP in ITS X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 10:24:54 -0000 Hi Alex, My point was that if you intend to present "Scenarios" for intelligent transport system, I believe the contents need to show "Vision" when the = ITS technologies we're trying to achieve are well applied. Current scenarios somewhat seem to get lost focus in the perspective of "Scenarios". First, we need to show the "Vision" obviously what we're achieving in = ITS. Of course, this job is always difficult :| However, if this vision is clear in our mind first, we would become to = know how other works should be done specifically I believe. Seil -----Original Message----- From: its-bounces@ietf.org [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, July 26, 2012 5:46 PM To: Seil Jeon Cc: its@ietf.org Subject: Re: [its] New draft on scenarios and requirements for IP in ITS Seil, Thank you for the message. I agree mainly with your points. I find it useful to the future reader = if the scenarios where grouped in classes: necessities of vehicle communications, high bandwidth availability, and other generica = problems. This may also to separate the requirements which are more specific to vehicular communications, rather than generic fixed communications. Is this what you mean? Do you think a modification of the draft should be done? Alex Le 25/07/2012 18:14, Seil Jeon a =E9crit : > Hi Alex, > > > Regarding on Section 3 Scenarios, I would classify them with following = > categories. > > Scenarios 1, 3 might be the necessities of vehicle communications > > Scenarios 2 describes high wireless accesses availability on current=20 > network environment > > Scenario 4 - it might be one of requirements. > > Scenario 5 - it sounds somewhat generic problem to me where every node = > to have Internet connection is facing. > > ... > > My opinion is would we need to specify them focused on necessities of=20 > vehicular communications? > > Those would be much better to understand requirements followed. > > > Regards, > > Seil > > > -----Original Message----- From: its-bounces@ietf.org=20 > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Friday, July 13, 2012 6:05 PM To: its@ietf.org Subject: [its] New=20 > draft on scenarios and requirements for IP in ITS > > Participants to ITS informal effort at IETF, > > Per our recent discussions, we submitted a new draft about scenarios=20 > and requirements for IP in ITS: > > draft-petrescu-its-scenarios-reqs-01.txt > > I would like to request feedback about the scenarios and requirements=20 > described in this draft. > > Thanks in advance, > > Alex and on behalf of co-authors. > > > _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its From alexandru.petrescu@gmail.com Fri Jul 27 04:06:07 2012 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 0674D21F8652 for ; Fri, 27 Jul 2012 04:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.437 X-Spam-Level: X-Spam-Status: No, score=-9.437 tagged_above=-999 required=5 tests=[AWL=0.812, 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 MRoe7JkN+908 for ; Fri, 27 Jul 2012 04:06:06 -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 1B89421F864F for ; Fri, 27 Jul 2012 04:06:05 -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 q6RB632L013942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2012 13:06:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6RB63sV029917; Fri, 27 Jul 2012 13:06:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6RB5xse018737; Fri, 27 Jul 2012 13:06:03 +0200 Message-ID: <50127617.5010502@gmail.com> Date: Fri, 27 Jul 2012 13:05:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Seil Jeon References: <5000551E.9000800@gmail.com> <000c01cd6a80$8115a550$8340eff0$@av.it.pt> <5011743F.6090708@gmail.com> <001701cd6be2$1077ccc0$31676640$@av.it.pt> In-Reply-To: <001701cd6be2$1077ccc0$31676640$@av.it.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] 1-phrase vision (was: New draft on scenarios and requirements for IP in ITS) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 11:06:07 -0000 So what would be the 1-phrase vision of IP and ITS? In the future all vehicles will be connected to the Internet. or maybe In the future all vehicles will be connected among themselves. or otherwise In the first phases small islands of vehicular networks will be forming and as more and more islands join and grow a whole new network will appear. Other 1-phrase vision would one propose? Alex Le 27/07/2012 12:24, Seil Jeon a �crit : > > Hi Alex, > > My point was that if you intend to present "Scenarios" for > intelligent transport system, I believe the contents need to show > "Vision" when the ITS technologies we're trying to achieve are well > applied. > > Current scenarios somewhat seem to get lost focus in the perspective > of "Scenarios". > > First, we need to show the "Vision" obviously what we're achieving in > ITS. Of course, this job is always difficult :| > > However, if this vision is clear in our mind first, we would become > to know how other works should be done specifically I believe. > > > > Seil > > > -----Original Message----- From: its-bounces@ietf.org > [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > Thursday, July 26, 2012 5:46 PM To: Seil Jeon Cc: its@ietf.org > Subject: Re: [its] New draft on scenarios and requirements for IP in > ITS > > Seil, > > Thank you for the message. > > I agree mainly with your points. I find it useful to the future > reader if the scenarios where grouped in classes: necessities of > vehicle communications, high bandwidth availability, and other > generica problems. > > This may also to separate the requirements which are more specific > to vehicular communications, rather than generic fixed > communications. > > Is this what you mean? > > Do you think a modification of the draft should be done? > > Alex > > Le 25/07/2012 18:14, Seil Jeon a �crit : >> Hi Alex, >> >> >> Regarding on Section 3 Scenarios, I would classify them with >> following categories. >> >> Scenarios 1, 3 might be the necessities of vehicle communications >> >> Scenarios 2 describes high wireless accesses availability on >> current network environment >> >> Scenario 4 - it might be one of requirements. >> >> Scenario 5 - it sounds somewhat generic problem to me where every >> node to have Internet connection is facing. >> >> ... >> >> My opinion is would we need to specify them focused on necessities >> of vehicular communications? >> >> Those would be much better to understand requirements followed. >> >> >> Regards, >> >> Seil >> >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, July 13, 2012 6:05 PM To: its@ietf.org Subject: [its] >> New draft on scenarios and requirements for IP in ITS >> >> Participants to ITS informal effort at IETF, >> >> Per our recent discussions, we submitted a new draft about >> scenarios and requirements for IP in ITS: >> >> draft-petrescu-its-scenarios-reqs-01.txt >> >> I would like to request feedback about the scenarios and >> requirements described in this draft. >> >> Thanks in advance, >> >> Alex and on behalf of co-authors. >> >> >> > > > _______________________________________________ its mailing list > its@ietf.org https://www.ietf.org/mailman/listinfo/its > > > From alexandru.petrescu@gmail.com Fri Jul 27 05:38:45 2012 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 B4C3921F84FE; Fri, 27 Jul 2012 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.458 X-Spam-Level: X-Spam-Status: No, score=-9.458 tagged_above=-999 required=5 tests=[AWL=0.791, 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 YHYa-WxKt2LC; Fri, 27 Jul 2012 05:38:45 -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 CB5CD21F84E1; Fri, 27 Jul 2012 05:38:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6RCce5H015590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2012 14:38:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6RCcdcw025631; Fri, 27 Jul 2012 14:38:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6RCcaaU021812; Fri, 27 Jul 2012 14:38:39 +0200 Message-ID: <50128BCC.7070002@gmail.com> Date: Fri, 27 Jul 2012 14:38:36 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 27 Jul 2012 12:38:45 -0000 Le 26/07/2012 20:22, Stan Ratliff (sratliff) a �crit : > Rex, > > On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: > >> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>> >>> Is there some particular scenario that deserves more interest >>> from your side? >>> >>>> Whether the transmission range of Wi-Fi is enough for this use >>>> case? >>> >>> Indeed in some use cases the WiFi transmission range (unlicensed >>> spectrum, around 50meter range at a certain power level) may be >>> enough. For example, at an incident scene this is largely >>> enough. >> >> Liu Dapeng, >> >> The classical use case, in my mind, is the instrumented >> ambulance*. The casualty inside may have several end systems >> (sensors) attached. Further, the ambulance will have end system nav >> receiver (to report position) and the EMT may need several >> services, VOIP being an obvious one. >> >> The topology for such is a LAN within the ambulance and a router >> with one or more outside interfaces. Reaching to a neighboring >> vehicle (e.g. with WiFi) is clearly not enough. The router needs >> to get to the rest of the internet in order to get the data to the >> hospital emergency room. So the first thought is an LTE or IEEE >> 802.16 network segment for the radio-WAN. There's nothing wrong >> with more than one hop, so including a WiFi interface on the >> router is OK too. (Indeed with the balkanization of the cellphone >> system, at least in US, multiple 4G cellphone interfaces is likely >> to be needed). >> > > FWIW, I think you've hit the nail on the head here. The WiFi > connection to a neighboring vehicle might help, in cases where (1) > the ambulance attendants want to do something like a VoIP call to > the people in the neighboring vehicle, or (2) if said neighboring > vehicle has Internet connectivity and can "share" (e.g. 802.16, or > LTE, or maybe even a satellite modem). But having WiFi to a > neighboring vehicle is, in and of itself, not necessarily a good > thing. WEll, I agree with the first points about potential necessity of WiFi between ambulance and a neighboring vehicle. One scenario that may be relevant is sharing information about the casualty between the two different agencies running each vehicle (say law enforcement and first aid); from an eHealth perspective this would mean to share data like chemical substance history to medicals trying to identify what happened, or between insurance company and the medical to have first hand proof about accident conditions and reimbursement. And more. I also agree about one vehicle offering Internet connection to nearby vehicle (a case named sometimes V2V2I). But I do not understand well why you're saying that having WiFi to a neighboring WiFi (not for Internet access, not for data sharing like ambulance-police) is not necessarily a good thing. What do you have in mind about it not being a good thing? Alex > > Regards, Stan > > > >> _______________________________________________ manet mailing list >> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > > From sratliff@cisco.com Fri Jul 27 08:10:21 2012 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 A575921F84F3; Fri, 27 Jul 2012 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Lm2071bUuKLv; Fri, 27 Jul 2012 08:10:20 -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 AA2CE21F84DC; Fri, 27 Jul 2012 08:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3984; q=dns/txt; s=iport; t=1343401820; x=1344611420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HX5RRTzuvaA5WxWV8A6mrBdvQ4NVgACaGBoYkbcqtmY=; b=AZCD0kPwhDc4RzxA13c2ZfHoXHSpdYm6Kpd5r5zt3oGArLCmLtSW5c3W PVzNBRyItnLpS7EXP850DOUpXSKJNbgVP/tzByIRK0WEpcpXe0IZvXYQF ObZlC05EFXyQn1sWu0mDwcaSr9eAbKYVlL5D5+6nEBqWVyfRB1su3nVsh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKuElCtJXG9/2dsb2JhbAA7Crk8gQeCIAEBAQMBAQEBDwFbCwULAgEIGC4nCyUCBA4FIodlBguaA6BYBItQEAuFeWADiBiNMI4ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106031203" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2012 15:10:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6RFAKs8005985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 15:10:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 10:10:19 -0500 From: "Stan Ratliff (sratliff)" To: Alexandru Petrescu Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsACAATJBAIAAKmAA Date: Fri, 27 Jul 2012 15:10:18 +0000 Message-ID: <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> In-Reply-To: <50128BCC.7070002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--35.642200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <903AD7FCED12BA44A9004EE3A2A13E51@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 27 Jul 2012 15:10:21 -0000 On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: > Le 26/07/2012 20:22, Stan Ratliff (sratliff) a =E9crit : >> Rex, >>=20 >> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>=20 >>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>=20 >>>> Is there some particular scenario that deserves more interest >>>> from your side? >>>>=20 >>>>> Whether the transmission range of Wi-Fi is enough for this use >>>>> case? >>>>=20 >>>> Indeed in some use cases the WiFi transmission range (unlicensed >>>> spectrum, around 50meter range at a certain power level) may be >>>> enough. For example, at an incident scene this is largely >>>> enough. >>>=20 >>> Liu Dapeng, >>>=20 >>> The classical use case, in my mind, is the instrumented >>> ambulance*. The casualty inside may have several end systems >>> (sensors) attached. Further, the ambulance will have end system nav >>> receiver (to report position) and the EMT may need several >>> services, VOIP being an obvious one. >>>=20 >>> The topology for such is a LAN within the ambulance and a router >>> with one or more outside interfaces. Reaching to a neighboring >>> vehicle (e.g. with WiFi) is clearly not enough. The router needs >>> to get to the rest of the internet in order to get the data to the >>> hospital emergency room. So the first thought is an LTE or IEEE >>> 802.16 network segment for the radio-WAN. There's nothing wrong >>> with more than one hop, so including a WiFi interface on the >>> router is OK too. (Indeed with the balkanization of the cellphone >>> system, at least in US, multiple 4G cellphone interfaces is likely >>> to be needed). >>>=20 >>=20 >> FWIW, I think you've hit the nail on the head here. The WiFi >> connection to a neighboring vehicle might help, in cases where (1) >> the ambulance attendants want to do something like a VoIP call to >> the people in the neighboring vehicle, or (2) if said neighboring >> vehicle has Internet connectivity and can "share" (e.g. 802.16, or >> LTE, or maybe even a satellite modem). But having WiFi to a >> neighboring vehicle is, in and of itself, not necessarily a good >> thing. >=20 > WEll, I agree with the first points about potential necessity of WiFi > between ambulance and a neighboring vehicle. >=20 > One scenario that may be relevant is sharing information about the > casualty between the two different agencies running each vehicle (say > law enforcement and first aid); from an eHealth perspective this would > mean to share data like chemical substance history to medicals trying to > identify what happened, or between insurance company and the medical to > have first hand proof about accident conditions and reimbursement. And > more. >=20 > I also agree about one vehicle offering Internet connection to nearby > vehicle (a case named sometimes V2V2I). >=20 > But I do not understand well why you're saying that having WiFi to a > neighboring WiFi (not for Internet access, not for data sharing like > ambulance-police) is not necessarily a good thing. What do you have in > mind about it not being a good thing? Again, let's consider the ambulance case. I've got a small subnet of device= s in that ambulance, behind an on-board router. Let's also assume a scenari= o where *all* of my traffic needs are back to the hospital (via the Interne= t). From the ambulance, I have WiFi connectivity to, say, a neighboring pol= ice vehicle. But that police vehicle either doesn't have a router installed= , or it doesn't have Internet connectivity. All I'm saying is that in that = case, a WiFi connection from the ambulance to the police vehicle doesn't he= lp a whole lot. Regards, Stan >=20 > Alex >=20 >>=20 >> Regards, Stan >>=20 >>=20 >>=20 >>> _______________________________________________ manet mailing list >>> manet@ietf.org https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >=20 >=20 From alexandru.petrescu@gmail.com Fri Jul 27 08:18:03 2012 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 86FDD21F8770; Fri, 27 Jul 2012 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.478 X-Spam-Level: X-Spam-Status: No, score=-9.478 tagged_above=-999 required=5 tests=[AWL=0.771, 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 aZxSVmsPt15W; Fri, 27 Jul 2012 08:18:02 -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 36C1321F8766; Fri, 27 Jul 2012 08:18:02 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q6RFHwvU022270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Jul 2012 17:17:58 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q6RFHw4A018836; Fri, 27 Jul 2012 17:17:58 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q6RFHs0c030140; Fri, 27 Jul 2012 17:17:58 +0200 Message-ID: <5012B123.2040605@gmail.com> Date: Fri, 27 Jul 2012 17:17:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> In-Reply-To: <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 27 Jul 2012 15:18:03 -0000 Le 27/07/2012 17:10, Stan Ratliff (sratliff) a �crit : > > On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: > >> Le 26/07/2012 20:22, Stan Ratliff (sratliff) a �crit : >>> Rex, >>> >>> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>> >>>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>> >>>>> Is there some particular scenario that deserves more interest >>>>> from your side? >>>>> >>>>>> Whether the transmission range of Wi-Fi is enough for this >>>>>> use case? >>>>> >>>>> Indeed in some use cases the WiFi transmission range >>>>> (unlicensed spectrum, around 50meter range at a certain >>>>> power level) may be enough. For example, at an incident scene >>>>> this is largely enough. >>>> >>>> Liu Dapeng, >>>> >>>> The classical use case, in my mind, is the instrumented >>>> ambulance*. The casualty inside may have several end systems >>>> (sensors) attached. Further, the ambulance will have end >>>> system nav receiver (to report position) and the EMT may need >>>> several services, VOIP being an obvious one. >>>> >>>> The topology for such is a LAN within the ambulance and a >>>> router with one or more outside interfaces. Reaching to a >>>> neighboring vehicle (e.g. with WiFi) is clearly not enough. The >>>> router needs to get to the rest of the internet in order to get >>>> the data to the hospital emergency room. So the first thought >>>> is an LTE or IEEE 802.16 network segment for the radio-WAN. >>>> There's nothing wrong with more than one hop, so including a >>>> WiFi interface on the router is OK too. (Indeed with the >>>> balkanization of the cellphone system, at least in US, multiple >>>> 4G cellphone interfaces is likely to be needed). >>>> >>> >>> FWIW, I think you've hit the nail on the head here. The WiFi >>> connection to a neighboring vehicle might help, in cases where >>> (1) the ambulance attendants want to do something like a VoIP >>> call to the people in the neighboring vehicle, or (2) if said >>> neighboring vehicle has Internet connectivity and can "share" >>> (e.g. 802.16, or LTE, or maybe even a satellite modem). But >>> having WiFi to a neighboring vehicle is, in and of itself, not >>> necessarily a good thing. >> >> WEll, I agree with the first points about potential necessity of >> WiFi between ambulance and a neighboring vehicle. >> >> One scenario that may be relevant is sharing information about the >> casualty between the two different agencies running each vehicle >> (say law enforcement and first aid); from an eHealth perspective >> this would mean to share data like chemical substance history to >> medicals trying to identify what happened, or between insurance >> company and the medical to have first hand proof about accident >> conditions and reimbursement. And more. >> >> I also agree about one vehicle offering Internet connection to >> nearby vehicle (a case named sometimes V2V2I). >> >> But I do not understand well why you're saying that having WiFi to >> a neighboring WiFi (not for Internet access, not for data sharing >> like ambulance-police) is not necessarily a good thing. What do >> you have in mind about it not being a good thing? > > Again, let's consider the ambulance case. I've got a small subnet of > devices in that ambulance, behind an on-board router. Let's also > assume a scenario where *all* of my traffic needs are back to the > hospital (via the Internet). From the ambulance, I have WiFi > connectivity to, say, a neighboring police vehicle. But that police > vehicle either doesn't have a router installed, or it doesn't have > Internet connectivity. All I'm saying is that in that case, a WiFi > connection from the ambulance to the police vehicle doesn't help a > whole lot. Well, now I understand what you mean by a non-Internet WiFi access being a bad thing. It is a temptation to connect to and then a disillusion that there is no Internet on it. This is a good problem that deserves being explored. I think the V2V without Internet may still be needed. There may exist a mechanism where one vehicle's MR detects the presence of the other vehicle's MR and understands whether this latter may offer Internet access or not. This distinctor may be the presence of a default route capability in the RA (or DHCP). The presence/absence of default router capability in the heard WiFi is what may help decide to follow/not follow the path of connecting to that WiFi and avoid being deceived. But I agree this risk of deceit by the presence of a non-Internet WiFi is something not good, and we could look at it. Or maybe you see some other solution to this? Alex > > Regards, Stan > > > >> >> Alex >> >>> >>> Regards, Stan >>> >>> >>> >>>> _______________________________________________ manet mailing >>>> list manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> >> >> > > > From sratliff@cisco.com Fri Jul 27 08:26:14 2012 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 D967621F87CC; Fri, 27 Jul 2012 08:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 FSfxurOb8Doq; Fri, 27 Jul 2012 08:26:14 -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 E921C21F87C8; Fri, 27 Jul 2012 08:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=6188; q=dns/txt; s=iport; t=1343402774; x=1344612374; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=22LwjAWfdxflN/uyPZKqw5pJDqv5X24mgvwp5LLR6y8=; b=ID1JlAFVm62lnI/DHlyBfV0p5CxLu1qqjwCnPKXGTSWpUQkv4BYhfwUM 1ET3aAyL0fZn4Y0bLiKMpNLhiqNOPBaInCBLw/o1ere3owyLebie4szEA 4cUbz/1J8FLcKvEv22Bw4ZfC8+zxKGOEuNN4by4gD8oWmT0OsFVIalqKi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMuxElCtJV2a/2dsb2JhbAA7Crk8gQeCIAEBAQMBAQEBDwFbCwULAgEIGC4nCyUCBA4FGweHZQYLmg2gVASLUBALhXlgA4gYjTCOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,667,1336348800"; d="scan'208";a="106005324" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jul 2012 15:26:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6RFQDZO030397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jul 2012 15:26:13 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.20]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 10:26:13 -0500 From: "Stan Ratliff (sratliff)" To: Alexandru Petrescu Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: AQHNa0z+KdD0i/G5YkiHpPL3hkc7R5c8IMEAgAATsACAATJBAIAAKmAAgAACJICAAAJPgA== Date: Fri, 27 Jul 2012 15:26:12 +0000 Message-ID: <320F7BE1-B4E7-4F2E-A271-162D8627144B@cisco.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> <50117240.10902@gmail.com> <1343322720.981.666.camel@localhost.localdomain> <50128BCC.7070002@gmail.com> <278C867E-6600-432C-9871-8C83A58EB696@cisco.com> <5012B123.2040605@gmail.com> In-Reply-To: <5012B123.2040605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19066.004 x-tm-as-result: No--35.186100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6A0C1D6607CDD34CBA56FD1EBA9E3BD0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rex Buddenberg , manet , "" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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, 27 Jul 2012 15:26:15 -0000 On Jul 27, 2012, at 11:17 AM, Alexandru Petrescu wrote: > Le 27/07/2012 17:10, Stan Ratliff (sratliff) a =E9crit : >>=20 >> On Jul 27, 2012, at 8:38 AM, Alexandru Petrescu wrote: >>=20 >>> Le 26/07/2012 20:22, Stan Ratliff (sratliff) a =E9crit : >>>> Rex, >>>>=20 >>>> On Jul 26, 2012, at 1:12 PM, Rex Buddenberg wrote: >>>>=20 >>>>> On Thu, 2012-07-26 at 18:37 +0200, Alexandru Petrescu wrote: >>>>>>=20 >>>>>> Is there some particular scenario that deserves more interest >>>>>> from your side? >>>>>>=20 >>>>>>> Whether the transmission range of Wi-Fi is enough for this >>>>>>> use case? >>>>>>=20 >>>>>> Indeed in some use cases the WiFi transmission range >>>>>> (unlicensed spectrum, around 50meter range at a certain >>>>>> power level) may be enough. For example, at an incident scene >>>>>> this is largely enough. >>>>>=20 >>>>> Liu Dapeng, >>>>>=20 >>>>> The classical use case, in my mind, is the instrumented >>>>> ambulance*. The casualty inside may have several end systems >>>>> (sensors) attached. Further, the ambulance will have end >>>>> system nav receiver (to report position) and the EMT may need >>>>> several services, VOIP being an obvious one. >>>>>=20 >>>>> The topology for such is a LAN within the ambulance and a >>>>> router with one or more outside interfaces. Reaching to a >>>>> neighboring vehicle (e.g. with WiFi) is clearly not enough. The >>>>> router needs to get to the rest of the internet in order to get >>>>> the data to the hospital emergency room. So the first thought >>>>> is an LTE or IEEE 802.16 network segment for the radio-WAN. >>>>> There's nothing wrong with more than one hop, so including a >>>>> WiFi interface on the router is OK too. (Indeed with the >>>>> balkanization of the cellphone system, at least in US, multiple >>>>> 4G cellphone interfaces is likely to be needed). >>>>>=20 >>>>=20 >>>> FWIW, I think you've hit the nail on the head here. The WiFi >>>> connection to a neighboring vehicle might help, in cases where >>>> (1) the ambulance attendants want to do something like a VoIP >>>> call to the people in the neighboring vehicle, or (2) if said >>>> neighboring vehicle has Internet connectivity and can "share" >>>> (e.g. 802.16, or LTE, or maybe even a satellite modem). But >>>> having WiFi to a neighboring vehicle is, in and of itself, not >>>> necessarily a good thing. >>>=20 >>> WEll, I agree with the first points about potential necessity of >>> WiFi between ambulance and a neighboring vehicle. >>>=20 >>> One scenario that may be relevant is sharing information about the >>> casualty between the two different agencies running each vehicle >>> (say law enforcement and first aid); from an eHealth perspective >>> this would mean to share data like chemical substance history to >>> medicals trying to identify what happened, or between insurance >>> company and the medical to have first hand proof about accident >>> conditions and reimbursement. And more. >>>=20 >>> I also agree about one vehicle offering Internet connection to >>> nearby vehicle (a case named sometimes V2V2I). >>>=20 >>> But I do not understand well why you're saying that having WiFi to >>> a neighboring WiFi (not for Internet access, not for data sharing >>> like ambulance-police) is not necessarily a good thing. What do >>> you have in mind about it not being a good thing? >>=20 >> Again, let's consider the ambulance case. I've got a small subnet of >> devices in that ambulance, behind an on-board router. Let's also >> assume a scenario where *all* of my traffic needs are back to the >> hospital (via the Internet). From the ambulance, I have WiFi >> connectivity to, say, a neighboring police vehicle. But that police >> vehicle either doesn't have a router installed, or it doesn't have >> Internet connectivity. All I'm saying is that in that case, a WiFi >> connection from the ambulance to the police vehicle doesn't help a >> whole lot. >=20 > Well, now I understand what you mean by a non-Internet WiFi access being > a bad thing. It is a temptation to connect to and then a disillusion > that there is no Internet on it. >=20 > This is a good problem that deserves being explored. >=20 > I think the V2V without Internet may still be needed. There may exist a > mechanism where one vehicle's MR detects the presence of the other > vehicle's MR and understands whether this latter may offer Internet > access or not. This distinctor may be the presence of a default route > capability in the RA (or DHCP). The presence/absence of default router > capability in the heard WiFi is what may help decide to follow/not > follow the path of connecting to that WiFi and avoid being deceived. Oh yes, I absolutely agree that the WiFi connection *could* be a useful thi= ng - it just depends on what you are trying to do. >=20 > But I agree this risk of deceit by the presence of a non-Internet WiFi > is something not good, and we could look at it. >=20 > Or maybe you see some other solution to this? I don't know that it deceitful, it's just a scenario that could happen. As = far as a solution goes, I think it's something that should be discussed, bu= t from what I've seen, one way to address it is with multiple links in the = ambulance. As was mentioned earlier in this thread - if the ambulance has a= n LTE connection to the Internet, then things work. In the case where the a= mbulance's WiFi happens to find an Internet-accessible hotspot to connect t= o, then there are a couple of paths back to the hospital - the question fro= m the ambulance router perspective is "what's the best link?". But yes, I s= ee this as an area for discussion/exploration and potential work.=20 Regards, Stan >=20 > Alex >=20 >=20 >>=20 >> Regards, Stan >>=20 >>=20 >>=20 >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Regards, Stan >>>>=20 >>>>=20 >>>>=20 >>>>> _______________________________________________ manet mailing >>>>> list manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 From karagian@cs.utwente.nl Sun Jul 29 16:34:14 2012 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 8A3D511E8072 for ; Sun, 29 Jul 2012 16:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_50=0.001, 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 cIhNjkcwtNsj for ; Sun, 29 Jul 2012 16:34:13 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC48E21F8625 for ; Sun, 29 Jul 2012 16:34:12 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 30 Jul 2012 01:34:09 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.41]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Mon, 30 Jul 2012 01:34:09 +0200 From: To: , Thread-Topic: comments on the draft on ITS scenarios and requirements Thread-Index: AQHNbeKm/kiHMVf4NEK1QmFMDd0dkQ== Date: Sun, 29 Jul 2012 23:34:08 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.114.255.126] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [its] comments on the draft on ITS scenarios and requirements 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, 29 Jul 2012 23:34:14 -0000 Hi Alex, I think that draft-petrescu-its-scenarios-reqs-01.txt is introducing some = vehicular networking scenarios, but for the sake of completeness it will be= probably beneficiary to mention all possible types of scenarios and use ca= ses.=20 The vehicular networking applications can be classified in Traffic (or Acti= ve) road safety, traffic efficiency & management and Infotainment applicati= ons. Many documents are describing these applications, see references at t= he bottom of this email! Traffic (or Active) road safety applications are those that are primarily e= mployed to decrease the probability of traffic accidents and the loss of li= fe of the occupants of vehicles. The active road safety applications can b= e grouped in Driving assistance-Co-operative awareness and Driving assistan= ce Road Hazard Warning applications. Traffic efficiency and management applications: focus on improving the vehi= cle traffic flow, traffic coordination and traffic assistance and provide u= pdated local information, maps and in general, messages of relevance bounde= d in space and/or time. Speed management and Co-operative navigation are tw= o typical groups of this type of applications. Infotainment applications: All other type of applications are Infotainment = applications. These applications can be divided in two main classes: Co-ope= rative local services and Global Internet services According to several standardization bodies, like ETSI ITS and CALM, only t= he Infotainment applications and some of the Traffic efficiency application= s make use of the IP based protocol stack. Therefore, below, I will briefly describe the main Traffic efficiency and I= nfotainment applications mentioned in the ETSI ITS specification (ETSI TR 1= 02 638), see the reference at the bottom of this email, that could make use= of the IP based protocol stack.=20 In addition to that I would like to mention that a division of the requirem= ents might be useful. This division could be, see also e.g., ETSI TR 102 63= 8: =3D> Radio communication capabilities, such as (1) single hop radio communi= cation range, (2) used radio frequency channels, (3) available bandwidth an= d bit transfer rate, (4) robustness of the radio communication channel, (5)= level of compensation for radio signal propagation difficulties by e.g., u= sing road side units. =3D> Network communication capabilities, such as (1) mode of dissemination:= unicasting, broadcasting, multicasting, geocasting (broadcasting capabilit= y that is valid only within a specified area), (2) data aggregation, (3) co= ngestion control, (4) message priority, (5) management means for channel an= d connectivity realization, (6) support of IPv6 or IPv4 addressing, (7) mob= ility management associated with changes of point of attachment to the Inte= rnet. =3D> Vehicle absolute positioning capabilities, such as (1) Global Navigati= on Satellite System (GNSS), e.g., Global Positioning System (GPS), (2) Comb= ined positioning capabilities, e.g., combined GNSS with information provide= d by a local geographical map. =3D> Other vehicle capabilities, such as (1) vehicle interfaces for sensor = and radar, (2) vehicle navigation capabilities. Vehicle communication secur= ity capabilities, such as (1) respect of privacy and anonymity, (2) integri= ty and confidentiality, (3) resistance to external security attacks, (4) au= thenticity of received data, (5) data and system integrity. Below, I am briefly describing the main Traffic efficiency and Infotainment= applications mentioned in the ETSI ITS specification (ETSI TR 102 638), se= e the reference at the bottom of this email, that could make use of the IP = based protocol stack.=20 Traffic efficiency & management -------------------------------------------- Traffic efficiency & management applications are focusing on improving the = vehicle traffic flow, traffic coordination and traffic assistance. Furtherm= ore, traffic efficiency & management applications are focusing on providing= updated local information, maps and in general messages of relevance limit= ed in space and/or time. The traffic efficiency & management applications c= an be grouped in Speed management and Co-operative navigation. a) Speed management This type of applications is used to assist the driver to manage the speed = of his/her vehicle in order to make the driving smoother and avoid unnecess= ary stopping. This application type can be applied in the following use cas= es: =3D> Regulatory/contextual speed limit notification: in this use case, a ro= ad side units broadcasts at a given frequency the current traffic speed lim= its, e.g., regulatory and contextual. =3D> Green light optimal speed advisory: in this use case a road side unit= broadcasts information regarding the traffic lights timing data associated= to the traffic light state. A vehicle that receives this information it ca= n use the traffic lights data and its own current speed to estimate an opti= mal speed advise such that the vehicle could reach the intersection under g= reen light. =20 b) Co-operative navigation This type of applications is used to increase the traffic efficiency by man= aging the navigation of vehicles through the cooperation between vehicles a= nd through the cooperation between vehicles and road side units. This appli= cation type can be applied in the following use cases: =3D> Traffic information and recommended itinerary: in this use case, a roa= d side unit broadcasts periodically to inform approaching vehicles about tr= affic abnormal conditions and provides advices to avoid a traffic jam. Thes= e advices may include map and route information. =20 =3D> Enhanced route guidance and navigation: in this use case, a road side = unit can communicate with vehicles that would want to use Internet connecti= vity in order to download optimized itinerary according to personalized req= uirements. This interaction may also include route guidance and navigation = information. =20 =3D> Limited access warning and detour notification: in this use case, a ro= ad side unit informs approaching vehicles about some road limited access. T= he approaching vehicles may be queried about security access control relate= d information. The vehicles that are not being authorized to access the res= tricted area are being guided to follow another way.=20 =20 =3D> In-vehicle signing: in this use case, road side units are broadcasting= information associated with traffic signs to the drivers of the approachin= g vehicles. =20 =3D> Electronic toll collect: in this use case, a road side unit queries ap= proaching vehicles about security access control related information. Vehic= les that have the necessary access rights are allowed to access the road ne= twork part, after electronic toll collect.=20 =20 =3D> Co-operative adaptive cruise control (it is recommended that this use = case should not use the Internet based protocol stack): in this use case, v= ehicles are cooperating with each other and, if possible with road side uni= ts, to obtain the necessary lead vehicle dynamics information and general t= raffic ahead, such as acceleration and head distance, in order to enhance t= he performance of the current Adaptive Cruise Control (ACC) systems. =20 =3D> Co-operative vehicle-highway automatic system (platoon) (it is recomme= nded that this use case should not use the Internet based protocol stack): = in this use case, vehicles are cooperating with each other and, if possible= with road side units, to obtain the necessary lead vehicle dynamics inform= ation and general traffic ahead in order to enhance the C-ACC (Co-operative= ACC) features, such that a series of vehicles could drive and operate safe= ly and smoothly as a platoon on a highway or a specific lane. =20 Infotainment Applications ----------------------------------- a) Co-operative local services This type of applications is focusing on infotainment that can be obtained = from locally based services. This application type can be applied in the fo= llowing use cases: =3D> Point of interest notification: in this use case, a road side unit inf= orms on a periodical way the approaching vehicles about the presence of loc= ally based services, such as restaurants, and points of interest. =20 =3D> ITS (Intelligent Transport System) local electronic commerce: in this = use case, a road side unit informs vehicles that they might have the capabi= lity to process a local payment for service (e.g., parking) reservation or = some other local purchasing. =20 =3D> Media downloading: in this use case, a road side unit can provide mult= imedia to approaching vehicles using either the internet network or locally= . The downloading can be conditioned by a commercial transaction, when digi= tal rights are required for the downloading action. =20 b) Global Internet services This type of applications is focusing on infotainment that can be obtained = from global internet services. This application type is grouped in Communit= ies services and ITS station life cycle: b.1) Communities services This global internet service application group is including insurance and f= inancial services, fleet management and parking zone management. This appli= cation type can be applied in the following use cases: =3D> Insurance and financial services: in this use case, a road side unit p= rovides the capability to approaching vehicles the pay as you drive service= s, where an on-demand and real time interaction can be supported using fina= ncial and insurance coverage service provider. This can be enabled using, i= n addition to the vehicle to vehicle network, also the Internet network. =20 =3D> Fleet management: in this use case, a road side unit can use Internet = access and provide and collect fleet management data from approaching vehic= les, through the exchanges between vehicles and road side units.=20 =20 b.2) ITS station life cycle This type of applications is focusing on infotainment, where vehicles can d= ownload software and data provisioning and updates. This application type c= an be applied in the following use case: =3D> Vehicle software/data provisioning and update: in this use case, a roa= d side unit is able to insure the software and data exchange between vehicl= es and a relevant software provisioning center. The exchanged information c= an be used for provisioning or for updating installed software and/or data. =20 Below a list with documents that provide more detail on vehicular networkin= g scenarios and use cases and possible issues that need to be solved! ETSI TR 102 638, =93Intelligent Transport System (ITS); Vehicular Communica= tions; Basic Set of Applications; Definition, ETSI specification TR 102 638= , v.1.1.1, June 2009. Car to Car Communication Consortium, =93Car to Car Communication Consortium= Manifesto: Overview of the C2C-CC System=94, C2C-CC, version 1.1, 2007. =20 Intellidrive project, =93Vehicle safety applications=94, ITS Joint program = Office, USDOT, 2008, pp. 1-15. IST Safespot project, =93Use cases, functional specifications and safety ma= rgin applications for the SAFESPOT Project=94, Safespot IST-4-026963-IP del= iverable D8.4.4, 2008, pp 1 =96 54. IST PreDrive C2X project, =93Detailed description of selected use cases and= corresponding technical requirements=94, PreDrive C2X deliverable 4.1. IST CVIS project, =93Use cases and system requirements=94, CVIS IST-4-02729= 3-IP deliverable 2.2, v. 1.0, 2006, pp 1- 256. R. Bishop, =93A Survey of Intelligent Vehicle Applications Worldwide=94, in= Proc. of IEEE Intelligent Vehicles Symposium, pp. 25-30, 2000. A. R. Girard, J. Borges de Sousa, J. K. Hedrick, =93An Overview of Emerging= Results in Networked Multi-Vehicle Systems=94, in Proc. of 40th IEEE Confe= rence on Decision and Control, USA, pp. 1485-1490, 2001. S. Tsugawa, =93Inter-Vehicle Communications and their Applications to Intel= ligent Vehicles: an Overview=94, in Proc. of IEEE Intelligent Vehicles Symp= osium, pp. 564-569, 2002.=20 J. Luo, J.-P. Hubaux, =93A survey of research in inter-vehicle communicatio= ns, in Embedded Security in Cars=94, in Journal of Computer Science, Embedd= ed Security in Cars Securing Current and Future Automotive IT Applications,= Springer-Verlag, pp. 111-122, 2006. J.Chennikara-Varghese, W. Chen, O. Altintas and S. Cai, =93Survey of Routin= g Protocols for Inter-Vehicle Communications,=94 in Proc. of Vehicle-to-Veh= icle Communications (V2VCOM) Workshop 2006, in conjunction with MobiQuitous= 2006, pp. 1-5, July 2006. Fan Li, Yu Wang, =93Routing in Vehicular Ad Hoc Networks: A Survey=94, in I= EEE Vehicular Technology Magazine, pp. 12-22, June 2007. M. L. Sichitiu, M. Kihl, =93Inter-Vehicle Communication Systems: A Survey= =94, in IEEE Communications Surveys & Tutorials, Vol. 10, Issue 2, 2nd Quar= ter, pp. 88 =96 105, 2008. Y. Toor, P. M=FChlethaler, A. Laouiti, A. de la Fortelle, =93Vehicle Ad Hoc= Networks: Applications and Related Technical Issues=94, in IEEE Communicat= ions Surveys & Tutorials, Vol. 10, Issue 3, 3rd Quarter 2008. H. Hartenstein, K. P. Laberteaux, =93A Tutorial Survey on Vehicular Ad Hoc = Networks=94, in IEEE Communications Magazine, Vol. 46, Issue 6, pp. 164-171= , June 2008. T. L. Willke, P. Tientrakool, N. F. Maxemchuk, =93A Survey of inter-Vehicle= Communication Protocols and Their Applications=94, IEEE Communications Sur= veys & Tutorials, Vol 11, Issue 2, 2nd Quarter, pp. 3-20, 2009.=20 P. Papadimitratos, A. de La Fortelle, K. Evenssen, R. Brignolo and S. Cosen= za, =93Vehicular Communication Systems: Enabling Technologies, Applications= , and Future Outlook on Intelligent Transportation,=94 in IEEE Communicatio= ns Magazine, Vol. 47, Issue 11, pp. 84-95, November 2009. G. Karagiannis, O. Altintas, E. Ekici, G.J., Heijenk, B. Jarupan, K. Lin, T= . Weil, (2011) =93Vehicular networking: A survey and tutorial on requiremen= ts, architectures, challenges, standards and solutions=94, IEEE Communicat= ions Surveys & Tutorials, 13 (4). pp. 584-616. ISSN 1553-877X, 2011=20 Best regards, Georgios ________________________________________ Van: its-bounces@ietf.org [its-bounces@ietf.org] namens Alexandru Petrescu = [alexandru.petrescu@gmail.com] Verzonden: vrijdag 13 juli 2012 19:04 Aan: its@ietf.org Onderwerp: [its] New draft on scenarios and requirements for IP in ITS Participants to ITS informal effort at IETF, Per our recent discussions, we submitted a new draft about scenarios and requirements for IP in ITS: draft-petrescu-its-scenarios-reqs-01.txt I would like to request feedback about the scenarios and requirements described in this draft. Thanks in advance, Alex and on behalf of co-authors.= From seiljeon@av.it.pt Sun Jul 29 19:19:36 2012 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 A37D321F8455 for ; Sun, 29 Jul 2012 19:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViO0MPwQEXbO for ; Sun, 29 Jul 2012 19:19:36 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6645211E8088 for ; Sun, 29 Jul 2012 19:19:35 -0700 (PDT) Received: from [216.123.55.167] (account seiljeon@av.it.pt) by av.it.pt (CommuniGate Pro WEBUSER 5.4.2) with HTTP id 65631702; Mon, 30 Jul 2012 03:19:34 +0100 From: "Seil Jeon" To: "Alexandru Petrescu" X-Mailer: CommuniGate Pro WebUser v5.4.2 Date: Mon, 30 Jul 2012 03:19:34 +0100 Message-ID: In-Reply-To: <50127617.5010502@gmail.com> References: <5000551E.9000800@gmail.com> <000c01cd6a80$8115a550$8340eff0$@av.it.pt> <5011743F.6090708@gmail.com> <001701cd6be2$1077ccc0$31676640$@av.it.pt> <50127617.5010502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit Cc: its@ietf.org Subject: Re: [its] 1-phrase vision (was: New draft on scenarios and requirements for IP in ITS) X-BeenThere: its@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Intelligent Transportation Systems discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 02:19:36 -0000 Hi Alex, Sorry for my late responding due to my travel. Please see inline. Regards, Seil On Fri, 27 Jul 2012 13:05:59 +0200 Alexandru Petrescu wrote: > So what would be the 1-phrase vision of IP and ITS? > > In the future all vehicles will be connected to the >Internet. > > or maybe > > In the future all vehicles will be connected among >themselves. > Yes, but that should be presented at Introduction I think, if omitted. "Vision" I mentioned needs to be somewhat specific. > or otherwise > > In the first phases small islands of vehicular networks >will be forming > and as more and more islands join and grow a whole new >network will appear. > > Other 1-phrase vision would one propose? I have two suggestions. First, we add sub-sections, presenting specific topics considering Georgios's comment like traffic road safety, traffic efficiency/management, etc.. in "Scenarios". Then, we describe each sub-section in detail, that must be "Vision" ITS BoF wants to do. Second, current sub-section related to vehicle-to-x (3.1, 3.2, 3.3, 3.4, 3.5) should be composed as independent Section with "Vehicle communication style" (title name needs to be revised accordingly) because various vehicle coms. style can be considered to support even same scenario. Namely, vehicle coms. style does not subordinate to specific scenario all the time. I hope this comment helps you. > > Alex > > Le 27/07/2012 12:24, Seil Jeon a �crit : >> >> Hi Alex, >> >> My point was that if you intend to present "Scenarios" >>for >> intelligent transport system, I believe the contents >>need to show >> "Vision" when the ITS technologies we're trying to >>achieve are well >> applied. >> >> Current scenarios somewhat seem to get lost focus in the >>perspective >> of "Scenarios". >> >> First, we need to show the "Vision" obviously what we're >>achieving in >> ITS. Of course, this job is always difficult :| >> >> However, if this vision is clear in our mind first, we >>would become >> to know how other works should be done specifically I >>believe. >> >> >> >> Seil >> >> >> -----Original Message----- From: its-bounces@ietf.org >> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>Petrescu Sent: >> Thursday, July 26, 2012 5:46 PM To: Seil Jeon Cc: >>its@ietf.org >> Subject: Re: [its] New draft on scenarios and >>requirements for IP in >> ITS >> >> Seil, >> >> Thank you for the message. >> >> I agree mainly with your points. I find it useful to >>the future >> reader if the scenarios where grouped in classes: >>necessities of >> vehicle communications, high bandwidth availability, and >>other >> generica problems. >> >> This may also to separate the requirements which are >>more specific >> to vehicular communications, rather than generic fixed >> communications. >> >> Is this what you mean? >> >> Do you think a modification of the draft should be done? >> >> Alex >> >> Le 25/07/2012 18:14, Seil Jeon a �crit : >>> Hi Alex, >>> >>> >>> Regarding on Section 3 Scenarios, I would classify them >>>with >>> following categories. >>> >>> Scenarios 1, 3 might be the necessities of vehicle >>>communications >>> >>> Scenarios 2 describes high wireless accesses >>>availability on >>> current network environment >>> >>> Scenario 4 - it might be one of requirements. >>> >>> Scenario 5 - it sounds somewhat generic problem to me >>>where every >>> node to have Internet connection is facing. >>> >>> ... >>> >>> My opinion is would we need to specify them focused on >>>necessities >>> of vehicular communications? >>> >>> Those would be much better to understand requirements >>>followed. >>> >>> >>> Regards, >>> >>> Seil >>> >>> >>> -----Original Message----- From: its-bounces@ietf.org >>> [mailto:its-bounces@ietf.org] On Behalf Of Alexandru >>>Petrescu >>> Sent: Friday, July 13, 2012 6:05 PM To: its@ietf.org >>>Subject: [its] >>> New draft on scenarios and requirements for IP in ITS >>> >>> Participants to ITS informal effort at IETF, >>> >>> Per our recent discussions, we submitted a new draft >>>about >>> scenarios and requirements for IP in ITS: >>> >>> draft-petrescu-its-scenarios-reqs-01.txt >>> >>> I would like to request feedback about the scenarios and >>> requirements described in this draft. >>> >>> Thanks in advance, >>> >>> Alex and on behalf of co-authors. >>> >>> >>> >> >> >> _______________________________________________ its >>mailing 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 Mon Jul 30 08:45:13 2012 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 C5BA121F843E for ; Mon, 30 Jul 2012 08:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 cn5GU88hhRSH for ; Mon, 30 Jul 2012 08:45:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1352B21F843A for ; Mon, 30 Jul 2012 08:45:12 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3350968wgb.13 for ; Mon, 30 Jul 2012 08:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=9mGou9ZD/2bQzWgu0caGCvJpn12yd8EggSAXo/4N3+g=; b=fAc+tiMXcz0RsUlQ2jLqZNpyeSxVTwiRzTzcICNZf3Mj4JNbUs8B9lmMJxq4CwQCZ0 PkzQKEbLSnOKjfvFZ9Tp0eoTe7ktZWDuVWQdhDMuGDmDppPw2PoWF5OEWfVQMcxeyP+s iUbQjUMLaVQqVqhek/kbkECr+N1aZIkWZPtqGkGyJfCOeHdZ9xeBXJvIn4fZSayturuR JPNHCCLV2StuDAV35lZTVnNIdzxNCzNBT6zsGWy4wkGhViePUuKDl+KcWM+r8dU1KthZ dpnJ9XgmUZfmZjo2fQ4U1giRW35w55Fu8BLLYV72mETxIuNBVMprlcH+uY7HV9q27hAO qglA== Received: by 10.216.132.135 with SMTP id o7mr5482782wei.6.1343663111905; Mon, 30 Jul 2012 08:45:11 -0700 (PDT) Received: from [130.129.19.174] (dhcp-13ae.meeting.ietf.org. [130.129.19.174]) by mx.google.com with ESMTPS id b7sm25049849wiz.9.2012.07.30.08.45.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 08:45:11 -0700 (PDT) Message-ID: <5016ABFE.9060203@gmail.com> Date: Mon, 30 Jul 2012 08:45:02 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [its] bar BoF meet today 19h30-20h30 room Plaza C, 2nd floor 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, 30 Jul 2012 15:45:13 -0000 ITS participants, We hold a bar BoF today: 19h30-20h30 Vancouver, Pacific time room Plaza C, 2nd floor The agenda is still under preparation. I will present briefly draft-petrescu-its-scenarios-reqs-01.txt. Georgios will show slides as well. If you want to show slides please ask. A webex invitation will be sent out soon. The room has tables distributed in a U-shaped manner, for maybe 20-30 people. See you there, Alex From alexandru.petrescu@gmail.com Mon Jul 30 09:00:24 2012 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 8D24B21F8630 for ; Mon, 30 Jul 2012 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 VB4OHWZmir56 for ; Mon, 30 Jul 2012 09:00:23 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3A21F8604 for ; Mon, 30 Jul 2012 09:00:23 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so1511984wib.13 for ; Mon, 30 Jul 2012 09:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Qjp/Ql7QY2VC1dl/qCiyjxBTfpVGGcGN1e++emFISQs=; b=qC14cQfq6ugdjwa6pTuKv31ZWV1FjIZWyWOeXrWEb5l56Q5HY0BzWaOqRT3yqY6vQg QcNdU5qRGjmSJJzrMPTKvLvUXrbxpIKKWVEzov1IHzWIN/0YEbNoWOMdef/HD+n3h8o1 nf4CI5p+6iT3PKZ1bsbSmspNIjLH/zxAtdADD5UxC+nsfoDVkqVHRKpq0bDxA/tDjgMN sXIozTEvR/Y5JlAQLoDLblAbLPj6f5iSttriy0GlcgT0moZBIv//Wdk7cFxJmy5R1t2Q pyxIpq9fKldEfRPphb+/gTgMMueAHJxNHdsao6mfmqUdZTgAard0MuNYYXp/myjgN9Pm W/Rw== Received: by 10.180.86.226 with SMTP id s2mr27659346wiz.9.1343664022636; Mon, 30 Jul 2012 09:00:22 -0700 (PDT) Received: from [130.129.19.174] (dhcp-13ae.meeting.ietf.org. [130.129.19.174]) by mx.google.com with ESMTPS id l6sm1491142wiz.4.2012.07.30.09.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 09:00:21 -0700 (PDT) Message-ID: <5016AF8E.5010509@gmail.com> Date: Mon, 30 Jul 2012 09:00:14 -0700 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [its] invitation in English 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, 30 Jul 2012 16:00:24 -0000 The webex invitation is in French, but all you need is click the url and use the password itsietf https://cea-list.webex.com/cea-list/j.php?ED=219289702&UID=0&PW=NOGFmZmI1MzA2&RT=NyM0 Do not hesitate to ask if it doesnt work. Copy the list. Yours, Alex --------------------------------------------------------------------- Bonjour , Alexandru PETRESCU vous invite � participer � cette r�union en ligne. Sujet : bar BoF ITS at IETF Vancouver Date : lundi 30 juillet 2012 Heure : 19:15, Heure d'�t� du Pacifique (San Francisco, GMT-07:00) Num�ro de la r�union : 707 259 126 Mot de passe de la r�union : itsietf ------------------------------------------------------- Pour participer � la r�union en ligne (Maintenant depuis vos appareils mobiles !) ------------------------------------------------------- 1. Allez sur le site https://cea-list.webex.com/cea-list/j.php?ED=219289702&UID=0&PW=NOGFmZmI1MzA2&RT=NyM0 2. Si demand�, entrez votre nom et votre adresse email. 3. Si un mot de passe est exig�, entrez le mot de passe de r�union : itsietf 4. Cliquez sur "Participer". Pour afficher les autres fuseaux horaires ou langues disponibles, cliquez sur le lien : https://cea-list.webex.com/cea-list/j.php?ED=219289702&UID=0&PW=NOGFmZmI1MzA2&ORT=NyM0 ------------------------------------------------------- Pour participer uniquement � la t�l�conf�rence ------------------------------------------------------- Afficher num�ros internationaux : https://webexap.arkadin.com/GlobalNum.aspx?TollNum=172283003&TollNumCC=1&TollFreeNum=805103003&TollFreeNumCC=1&ParticipantCode=26174894 Participant Pin Code : 261 748 94 ------------------------------------------------------- Pour obtenir de l'aide ------------------------------------------------------- 1. Allez sur le site https://cea-list.webex.com/cea-list/mc 2. Dans la barre de navigation, � gauche, cliquez sur Assistance. Vous pouvez me contacter au : alexandru.petrescu@cea.fr Pour ajouter cette r�union � votre programme de calendrier (par exemple dans Microsoft Outlook), cliquez sur ce lien : https://cea-list.webex.com/cea-list/j.php?ED=219289702&UID=0&ICS=MI&LD=7&RD=7&ST=1&SHA2=xd-ZtUtFGPHVKL3F5v3yIAWmhqjDuG4fv3LhnwhCrIc=&RT=NyM0 Pour lire des fichiers rich media UCF (Universal Communications Format), vous devez disposer de lecteurs compatibles. V�rifiez que votre ordinateur poss�de les lecteurs ad�quats en acc�dant � https://cea-list.webex.com/cea-list/systemdiagnosis.php. REMARQUE IMPORTANTE : Ce service WebEx comprend une fonctionnalit� qui permet l'enregistrement de l'audio, des documents et de tous mat�riels �chang�s ou visualis�s pendant une session. En prenant part � cette session, vous consentez � ces enregistrements. Si vous ne consentez pas � ces enregistrements, discutez-en avec l'organisateur de la r�union avant le d�but de l'enregistrement ou ne rejoignez pas la session. Veuillez prendre note que de tels enregistrements peuvent �tre communiqu�s en cas de litiges. From reller@cococorp.com Mon Jul 30 10:19:43 2012 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 7846411E8133; Mon, 30 Jul 2012 10:19: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 1F2bUTfmiwHh; Mon, 30 Jul 2012 10:19:43 -0700 (PDT) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by ietfa.amsl.com (Postfix) with ESMTP id D2AD111E8130; Mon, 30 Jul 2012 10:19:42 -0700 (PDT) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub06.exchhosting.com (192.168.11.102) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 10:19:41 -0700 Received: from EXMBX13.exchhosting.com ([fe80::b856:bbe8:8b31:4946]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Mon, 30 Jul 2012 10:19:40 -0700 From: "A. Riley Eller" To: Alexandru Petrescu , liu dapeng Date: Mon, 30 Jul 2012 10:19:37 -0700 Thread-Topic: [manet] [its] Scenarios, potential topics... Thread-Index: Ac1qcFoz+xyXwOxsSdyoLN0cNH/MfQEBr1Xw Message-ID: <3D05610F3AC2E047AACAA68F63DF908D379D28E2EC@EXMBX13.exchhosting.com> References: <4FF2A65E.2080000@gmail.com> <50100020.4040708@gmail.com> In-Reply-To: <50100020.4040708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 30 Jul 2012 10:28:15 -0700 Cc: manet , "its@ietf.org" , Abdussalam Baryun Subject: Re: [its] [manet] Scenarios, potential topics... 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: