[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
>
>
>
>