Re: [its] New draft on scenarios and requirements for IP in ITS

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 19 July 2012 15:12 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 16F1521F8634 for <its@ietfa.amsl.com>; Thu, 19 Jul 2012 08:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.739
X-Spam-Level:
X-Spam-Status: No, score=-8.739 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWIAM+-rOOoS for <its@ietfa.amsl.com>; Thu, 19 Jul 2012 08:12:02 -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 3455221F862B for <its@ietf.org>; Thu, 19 Jul 2012 08:12:02 -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 q6JFCrKu014408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2012 17:12:53 +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 q6JFCrPQ004910; Thu, 19 Jul 2012 17:12:53 +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 q6JFCqm8016246; Thu, 19 Jul 2012 17:12:53 +0200
Message-ID: <500823F4.7020008@gmail.com>
Date: Thu, 19 Jul 2012 17:12:52 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>
References: <5000551E.9000800@gmail.com> <D6A6FAC2-098A-41F8-ACDE-8B088B14E1DF@nasa.gov>
In-Reply-To: <D6A6FAC2-098A-41F8-ACDE-8B088B14E1DF@nasa.gov>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "its@ietf.org" <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." <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: Thu, 19 Jul 2012 15:12:04 -0000

Wil,

I tend to agree that requirements should be more generic.  But maybe not
too generic, such that to still be helpful in guiding realization of work.

Le 16/07/2012 15:55, Ivancic, William D. (GRC-RHN0) a écrit :
> Alex,
>
> I think you might want to consider writing the requirements to be a
> little more generic.  As is, at least to me, some of the requirements
>  almost specify a solution.  This is a always a bit difficult as you
> may have a solution in mind, but others may have a different solution
> that may be better.  If the requirements are more generic to the
> problem rather than specifying a solution, you allow a broader
> solution space. I tired some modifications below.
>
> Also, I moved R3 before R0-2.
>
> 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.

I agree, sounds better than the original R0 which was too short.

>
> o  R1.  IP addressing within each vehicle for Sub-networks support:
> Mobile router support several sub-networks hosting stakeholder
> networks,

Yes.

> o  R2.  IP addressing on the interface between vehicles. (May or may
> not be globally reachable)

Yes, I agree.

> o  R3.  Globally Reachable from Internet: (This may be a globally
> reachable address, or perhaps something else.)

That something else - an identifier?  (like a skype id?)  a NAI?

> 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
> advantage 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.
>
> oR10.  Reachability at permanent home addresses: it is desirable 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.)

Certainly when globally routable addresses are assigned to devices 
within a vehicle then reachability is assured, and in this sense R3 
would be suifficient.

However, permanent reachability, would mean that _stable_ addresses are 
assigned within vehicles, which wouldn't change when attaching to 
different parts of Internet following mobility events.

If there is some solution that is prohibited by the formulation of this 
requirement then I would be ready to change it.

Also, I thought to write a requirement that the addresses within a 
vehicle to change at each handover (3g - wifi, for example) and to still 
have a sort of reachability, but not reachability at permanent addresses.

Then I gave up and did not write that requirement.

This is open for discussion.

Alex

>
>
>
>
>
> On Jul 13, 2012, at 1:04 PM, Alexandru Petrescu wrote:
>
>> 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: *"internet-drafts@ietf.org
>> <mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org
>> <mailto:internet-drafts@ietf.org>> *Date: *July 13, 2012 1:01:02 PM
>> EDT *To: *"alexandru.petrescu@cea.fr
>> <mailto:alexandru.petrescu@cea.fr>" <alexandru.petrescu@cea.fr
>> <mailto:alexandru.petrescu@cea.fr>> *Cc: *"michael.boc@cea.fr
>> <mailto:michael.boc@cea.fr>" <michael.boc@cea.fr
>> <mailto:michael.boc@cea.fr>>, "witold.klaudel@renault.com
>> <mailto:witold.klaudel@renault.com>" <witold.klaudel@renault.com
>> <mailto:witold.klaudel@renault.com>>, "christophe.janneteau@cea.fr
>> <mailto:christophe.janneteau@cea.fr>" <christophe.janneteau@cea.fr
>> <mailto:christophe.janneteau@cea.fr>> *Subject: **New Version
>> Notification for draft-petrescu-its-scenarios-reqs-01.txt*
>>
>>
>>
>> A new version of I-D, draft-petrescu-its-scenarios-reqs-01.txt has
>> been successfully submitted by Alexandru Petrescu and posted to
>> the IETF repository.
>>
>> Filename:draft-petrescu-its-scenarios-reqs Revision:01
>> Title:Scenarios and Requirements for IP in Intelligent
>> Transportation Systems Creation date:2012-07-13 WG ID:Individual
>> Submission Number of pages: 12 URL:
>> http://www.ietf.org/internet-drafts/draft-petrescu-its-scenarios-reqs-01.txt
>>
>>
Status: http://datatracker.ietf.org/doc/draft-petrescu-its-scenarios-reqs
>> Htmlized:
>> http://tools.ietf.org/html/draft-petrescu-its-scenarios-reqs-01
>> Diff:
>> http://tools.ietf.org/rfcdiff?url2=draft-petrescu-its-scenarios-reqs-01
>>
>>
>>
Abstract:
>> This draft describes scenarios of vehicular communications that
>> are considered pertinent to Intelligent Transportation Systems.  In
>> these scenarios, the necessity of using IP networking technologies
>> and protocols is exposed.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________ its mailing list
>> its@ietf.org <mailto:its@ietf.org>
>> https://www.ietf.org/mailman/listinfo/its
>
> ****************************** William D. Ivancic Phone 216-433-3494
> Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>