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

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Jul 2012 19:04:30 +0200

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.

Subject: New Version Notification for draft-petrescu-its-scenarios-reqs-01.txt
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 13 Jul 2012 10:01:02 -0700

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

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 13 Jul 2012 10:35:12 -0700

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

Scenario 2 outlines a solution, but not a problem.

On Fri, 2012-07-13 at 19:04 +0200, Alexandru Petrescu wrote:
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 14 Jul 2012 11:11:21 +0200

Hi Alex,

I skimmed through the draft, I support all information, don't have
what to add so far. It will help us direct our works in ITS,

thanking you,
Abdussalam
==========

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 16 Jul 2012 08:55:39 -0500

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.

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

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

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

   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.

   o  R10.  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.)

On Jul 13, 2012, at 1:04 PM, Alexandru Petrescu wrote:

Thanks in advance,

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: July 13, 2012 1:01:02 PM EDT
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-petrescu-its-scenarios-reqs-01.txt

Abstract:

The IETF Secretariat

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Jul 2012 11:45:22 +0200

Rex,

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Jul 2012 17:12:52 +0200

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

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

>> Per our recent discussions, we submitted a new draft about
>> scenarios and requirements for IP in ITS:
>>
>> I would like to request feedback about the scenarios and
>> requirements described in this draft.
>>
>> Thanks in advance,
>>
>> *From: *"[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>> *Date: *July 13, 2012 1:01:02 PM
>> EDT *To: *"[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>> *Cc: *"[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>> *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
>>
>>
>> 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
>> [email-masked] <mailto:[email-masked]>
> ****************************** William D. Ivancic Phone 216-433-3494
> Fax 216-433-8705 Networking Lab 216-433-2620 Mobile 440-503-4892

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 19 Jul 2012 13:20:35 -0500

On Jul 19, 2012, at 11:12 AM, Alexandru Petrescu wrote:

Wil,

.......

Yes an vehicle communication center's name.  Think about how your smart phone works.  The phone number is really a label that gets bound to a local attachment point. It is not a address.  It is globally reachable because of directory mapping.

Alex,

Give this book  a read. It is a very difficult read, but well worth the effort.

Read the whole book, but feel free to jump to Chapter 9 "Multi-homing,Multicast, and Mobility" section "Mobility in IP and Cellular Networks" to get a feel for how the phone system evolved from the phone number being a location dependent point of attachment address to a cell phone number being  location independent node address  to eventually becoming more or less an application name.

"Patterns in Network Architecture - A Return to Fundamentals" by John Day.

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 25 Jul 2012 17:14:01 +0100

Hi Alex,

Regarding on Section 3 Scenarios, I would classify them with following
categories.

Scenarios 1, 3 might be the necessities of vehicle communications

Scenarios 2 describes high wireless accesses availability on current network
environment

Scenario 4 - it might be one of requirements. 

Scenario 5 - it sounds somewhat generic problem to me where every node to
have Internet connection is facing.

...

My opinion is would we need to specify them focused on necessities of
vehicular communications?

Those would be much better to understand requirements followed.

Regards,

Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Friday, July 13, 2012 6:05 PM
To: [email-masked]
Subject: [its] New draft on scenarios and requirements for IP in ITS

Thanks in advance,

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Jul 2012 18:45:51 +0200

Seil,

Thank you for the message.

I agree mainly with your points.  I find it useful to the future reader
if the scenarios where grouped in classes: necessities of vehicle
communications, high bandwidth availability, and other generica problems.

This may also to separate the requirements which are more specific to
vehicular communications, rather than generic fixed communications.

Is this what you mean?

Do you think a modification of the draft should be done?

Alex

Le 25/07/2012 18:14, Seil Jeon a écrit :
> Hi Alex,
>
>
> Regarding on Section 3 Scenarios, I would classify them with
> following categories.
>
> Scenarios 2 describes high wireless accesses availability on current
> network environment
>
> Scenario 5 - it sounds somewhat generic problem to me where every
> node to have Internet connection is facing.
>
> ...
>
> My opinion is would we need to specify them focused on necessities
> of vehicular communications?
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Friday, July 13, 2012 6:05 PM To: [email-masked] Subject: [its] New
> draft on scenarios and requirements for IP in ITS
>
> Per our recent discussions, we submitted a new draft about scenarios
> and requirements for IP in ITS:
>

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 27 Jul 2012 11:24:54 +0100

Hi Alex,

My point was that if you intend to present "Scenarios" for intelligent
transport system, I believe the contents need to show "Vision" when the ITS
technologies we're trying to achieve are well applied.

Current scenarios somewhat seem to get lost focus in the perspective of
"Scenarios".

First, we need to show the "Vision" obviously what we're achieving in ITS.
Of course, this job is always difficult :|

However, if this vision is clear in our mind first, we would become to know
how other works should be done specifically I believe.

Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Thursday, July 26, 2012 5:46 PM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [its] New draft on scenarios and requirements for IP in ITS

Seil,

I agree mainly with your points.  I find it useful to the future reader if
the scenarios where grouped in classes: necessities of vehicle
communications, high bandwidth availability, and other generica problems.

Is this what you mean?

Alex

Le 25/07/2012 18:14, Seil Jeon a écrit :
> Scenario 5 - it sounds somewhat generic problem to me where every node 
> to have Internet connection is facing.
>
> ...
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Jul 2012 13:05:59 +0200

So what would be the 1-phrase vision of IP and ITS?

In the future all vehicles will be connected to the Internet.

or maybe

In the future all vehicles will be connected among themselves.

or otherwise

In the first phases small islands of vehicular networks will be forming
and as more and more islands join and grow a whole new network will appear.

Other 1-phrase vision would one propose?

Alex

Le 27/07/2012 12:24, Seil Jeon a écrit :
>
> Hi Alex,
>
> My point was that if you intend to present "Scenarios" for
> intelligent transport system, I believe the contents need to show
> "Vision" when the ITS technologies we're trying to achieve are well
> applied.
>
> Current scenarios somewhat seem to get lost focus in the perspective
> of "Scenarios".
>
> First, we need to show the "Vision" obviously what we're achieving in
> ITS. Of course, this job is always difficult :|
>
> However, if this vision is clear in our mind first, we would become
> to know how other works should be done specifically I believe.
>
>
>
> Seil
>
>
> Thursday, July 26, 2012 5:46 PM To: Seil Jeon Cc: [email-masked]
> I agree mainly with your points.  I find it useful to the future
> reader if the scenarios where grouped in classes: necessities of
> vehicle communications, high bandwidth availability, and other
> generica problems.
>
> This may also to separate the requirements which are more specific
> to vehicular communications, rather than generic fixed
> communications.
>
> Is this what you mean?
>
>> Scenarios 2 describes high wireless accesses availability on
>> current network environment
>>
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Friday, July 13, 2012 6:05 PM To: [email-masked] Subject: [its]
>> New draft on scenarios and requirements for IP in ITS
>>
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>

---

From: "Seil Jeon" <[email-masked]>
Date: Mon, 30 Jul 2012 03:19:34 +0100

Hi Alex,

Sorry for my late responding due to my travel.

Please see inline.

Regards,

Seil

On Fri, 27 Jul 2012 13:05:59 +0200
> In the future all vehicles will be connected among 

Yes, but that should be presented at Introduction I think, 
if omitted.

"Vision" I mentioned needs to be somewhat specific.

> Other 1-phrase vision would one propose?

I have two suggestions.

First, we add sub-sections, presenting specific topics 
considering Georgios's comment like traffic road safety, 
traffic efficiency/management, etc.. in "Scenarios". Then, 
we describe each sub-section in detail, that must be 
"Vision" ITS BoF wants to do.

Second, current sub-section related to vehicle-to-x (3.1, 
3.2, 3.3, 3.4, 3.5) should be composed as independent 
Section with "Vehicle communication style" (title name 
needs to be revised accordingly) because various vehicle 
coms. style can be considered to support even same 
scenario. Namely, vehicle coms. style does not subordinate 
to specific scenario all the time.

I hope this comment helps you.

>> Subject: Re: [its] New draft on scenarios and 
>>requirements for IP in
>> ITS
>>
>> Seil,
>>