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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 19 July 2012 09:44 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 43FA921F8643 for <its@ietfa.amsl.com>; Thu, 19 Jul 2012 02:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.934
X-Spam-Level:
X-Spam-Status: No, score=-8.934 tagged_above=-999 required=5 tests=[AWL=1.315, 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 htqhXQWmd8eJ for <its@ietfa.amsl.com>; Thu, 19 Jul 2012 02:44:35 -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 5960E21F867F for <its@ietf.org>; Thu, 19 Jul 2012 02:44: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 q6J9jQxq032581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2012 11:45:26 +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 q6J9jQSH015827; Thu, 19 Jul 2012 11:45:26 +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 q6J9jMqB026304; Thu, 19 Jul 2012 11:45:26 +0200
Message-ID: <5007D732.7080607@gmail.com>
Date: Thu, 19 Jul 2012 11:45:22 +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: Rex Buddenberg <budden@nps.navy.mil>
References: <5000551E.9000800@gmail.com> <1342200913.981.57.camel@localhost.localdomain>
In-Reply-To: <1342200913.981.57.camel@localhost.localdomain>
Content-Type: text/plain; charset="UTF-8"; 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 09:44:36 -0000

Rex,

Le 13/07/2012 19:35, Rex Buddenberg a écrit :
> Alex,
>
> Suggest an additional scenario: voyage planning.  In this case, the
> automobile navigator needs road, weather and other information from
> external.  In addition, the navigator will need internal information
> (e.g. how full is fuel tank?).
> 	
> Increasingly, the external information is migrating to Common Alerting
> Protocol data format (an XML schema).

This is an interesting scenario.  It may indeed be formulated and added 
to the draft.

In an similar context, the electric vehicle may need to plan its 
trajectory depending on weather conditions and sometimes on the cell 
availability at nearest station.

I am not aware of Common Alerting Protocol data format.

But I need to better understand what are the implications:
- is it leading to the use of IP communications protocols?  Is http
   sufficient?  Is something more needed?
- are there implementations of CAP on IPv6?
- is this leading to enhancements of CAP?
- is this support advance further the work in this informal group?

> Scenario 2 outlines a solution, but not a problem.

ok, scenario two is:
>    Scenario 2: Because of the wide variety of available wireless
>    technologies, the vehicle should dispose of more than one wireless
>    interface towards the infrastructure.  In city center, Wi-Fi hotspots
>    may provide Internet access at crossing roads stops.  In the suburbs,
>    Internet Access may only be available with LTE or 3G.

This scenario would lead to many things.  Saying that wireless access is 
heterogeneous (several interfaces, different nature of links) means many 
things to me: use IP, use Mobile IP, always-on connections, use TCP, etc.

Do you think a better formulation would rather indicate a problem? 
(instead of a solution).  What do you mean?

Alex

> On Fri, 2012-07-13 at 19:04 +0200, 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.
>> _______________________________________________
>> its mailing list
>> its@ietf.org
>> https://www.ietf.org/mailman/listinfo/its
>
>
>
>