[its] Resuming the scenarios, potential topics...
Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 06 July 2012 15:28 UTC
Return-Path: <alexandru.petrescu@gmail.com>
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 7AAE521F8738 for <its@ietfa.amsl.com>; Fri, 6 Jul 2012 08:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqunzLE59oZP for <its@ietfa.amsl.com>; Fri, 6 Jul 2012 08:28:27 -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 10FCD21F8736 for <its@ietf.org>; Fri, 6 Jul 2012 08:28:26 -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 q66FShLb021378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <its@ietf.org>; Fri, 6 Jul 2012 17:28:43 +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 q66FSgCP025088 for <its@ietf.org>; Fri, 6 Jul 2012 17:28:42 +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 q66FSdIb018388 for <its@ietf.org>; Fri, 6 Jul 2012 17:28:42 +0200
Message-ID: <4FF70427.80308@gmail.com>
Date: Fri, 06 Jul 2012 17:28:39 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: its@ietf.org
References: <CADnDZ89NgkfhvvJTaS_89+Bub+95pKrFZPYHhXzcQT1KBqEcmg@mail.gmail.com> <4FF2A65E.2080000@gmail.com> <1341333653.6804.875.camel@localhost.localdomain>
In-Reply-To: <1341333653.6804.875.camel@localhost.localdomain>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [its] Resuming the scenarios, potential topics...
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Intelligent Transportation Systems discussion list." <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/its>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 15:28:28 -0000
Colleagues subscribers to ITS email list at IETF, Do you think some of the following scenarios should _not_ be worked on : - Router to modem exchange about wireless status. - DNS lookup by geo coordinates. - Multicast dissemination by geo coordinates. - V2V: mechanisms to form addresses and exchange routes directly between vehicles without help from the infrastructure. - V2V2I: mechanisms to offer Internet connectivity to one vehicle through another vehicle. - PMIP-NEMO: mechanisms to use 1-interface base-stations and moving networks. - addressing: mechanisms to form IP addresses based on vehicle- specific identifiers. - IPv6-over-802.11p: translate an 802.11p emergency message into a related IP message; form Interface Identifier based on a 802.11p MAC address. - IPv6 and ETSI ITS: make sure ETSI ITS existing documents have no bugs about IPv6. - work on Mobile IPv6 extensions about the above topics. - work on ND extensions about the above topics. - work on DHCPv6 extensions about the above topics. - work on new protocol. Yours, Alex Le 03/07/2012 18:40, Rex Buddenberg a écrit : > Alex, > > You just HAD to go and ask: > >> I am interested to hear others' oppinions as well. >> > > One of the handful of requirements differences between emergency > services and the rest of us is higher availability and survivability > needs. Skipping some analysis steps, this always boils down to >1 > route. > >>>> Scenario : A router deployed in a moving vehicle, uses its >>>> egress interface to connect to larger-area access network(s) or >>>> to other vehicles. > > So the English in the above statement is not quite right: > 'interface' MUST be plural in any practical situation: interfaces. > > > LTE is likely to be the big player for the radio-WAN, but there won't > be just one instantiation. A quick scenario: an instrumented > ambulance may have one or more LANs within the vehicle to which > several end systems are attached -- vital signs sensors, VOIP handset > for the EMT, etc. quite possibly a WiFi hotspot ... All attached to > a vehicle-mounted router. The router has interfaces to 1) wired > ethernet (for use while in the garage), 2) commercial LTE (where > coverage exists), 3) emergency services LTE (in US, this is earmarked > for 700MHz band and does not yet in fact exist), 4) WiFi -- pick up a > neighborhood hotspot, 5) satellite or other radio-WAN network for > rural areas not reachable by other means. Any sane high Ao > engineering will be picking at least two of the above. > > > Any help? > > > > On Tue, 2012-07-03 at 09:59 +0200, Alexandru Petrescu wrote: >> 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. >>> >>> <Q1>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. >> >>> <Q2>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:<Q3> 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. >> >>> <Q4> What are the potential work items? <Q5>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 <alexandru.petrescu at gmail.com> 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 > > > >
- [its] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] Scenarios, potential topics... Wesley Eddy
- Re: [its] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] Scenarios, potential topics... Stan Ratliff
- Re: [its] Scenarios, potential topics... Ivancic, William D. (GRC-RHN0)
- [its] Fwd: Re: Scenarios, potential topics... Alexandru Petrescu
- Re: [its] Scenarios, potential topics... Abdussalam Baryun
- Re: [its] Scenarios, potential topics... Abdussalam Baryun
- Re: [its] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... John Dowdell
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Rex Buddenberg
- Re: [its] Resuming the scenarios, potential topic… Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Dearlove, Christopher (UK)
- Re: [its] [manet] Scenarios, potential topics... Dearlove, Christopher (UK)
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- [its] Resuming the scenarios, potential topics... Alexandru Petrescu
- Re: [its] Resuming the scenarios, potential topic… Abdussalam Baryun
- Re: [its] refresh, url slides of last informal me… Alexandru Petrescu
- [its] Store, Carry and Forward (SCF) Technology f… Ivancic, William D. (GRC-RHN0)
- Re: [its] Store, Carry and Forward (SCF) Technolo… Abdussalam Baryun
- Re: [its] Store, Carry and Forward (SCF) Technolo… Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... liu dapeng
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... liu dapeng
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Rex Buddenberg
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... A. Riley Eller
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... A. Riley Eller
- Re: [its] [manet] Scenarios, potential topics... Rex Buddenberg
- Re: [its] [manet] Scenarios, potential topics... Okaytion
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Francisco Javier Ros Muñoz
- Re: [its] [manet] Scenarios, potential topics... A. Riley Eller
- Re: [its] [manet] Scenarios, potential topics... A. Riley Eller
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Francisco Javier Ros Muñoz
- Re: [its] [manet] Scenarios, potential topics... Stan Ratliff (sratliff)
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu
- Re: [its] [manet] Scenarios, potential topics... Alexandru Petrescu