Re: [manet] [its] Scenarios, potential topics...

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 03 July 2012 07:59 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFBD21F87B9; Tue, 3 Jul 2012 00:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level:
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+D3cxPVxZjH; Tue, 3 Jul 2012 00:59:25 -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 3863A21F87B4; Tue, 3 Jul 2012 00:59:25 -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 q637xTGE019845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jul 2012 09:59:30 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q637xT72025705; Tue, 3 Jul 2012 09:59: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 q637xQbO005408; Tue, 3 Jul 2012 09:59:29 +0200
Message-ID: <4FF2A65E.2080000@gmail.com>
Date: Tue, 03 Jul 2012 09:59:26 +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: Abdussalam Baryun <abdussalambaryun@gmail.com>
References: <CADnDZ89NgkfhvvJTaS_89+Bub+95pKrFZPYHhXzcQT1KBqEcmg@mail.gmail.com>
In-Reply-To: <CADnDZ89NgkfhvvJTaS_89+Bub+95pKrFZPYHhXzcQT1KBqEcmg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: manet <manet@ietf.org>, its@ietf.org
Subject: Re: [manet] [its] Scenarios, potential topics...
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 07:59:27 -0000

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