Subject: Re: [ipwave] IPWAVE Recharter Topics?

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 2 May 2018 11:19:31 +0200

Le 18/04/2018 à 20:39, Russ Housley a écrit :
> I saw very little excitement for rechartering the IPWAVE WG.  There were
> a small number of people want to do something, but most people felt that
> other standards bodies should tackle non-IP topics.
> 
> Are there any IP-related topics that need to be tackled?  If so, is
> there enough interest and energy among the IPWAVE WG participants to
> tackle them?

Hi Russ,

In the next few months I will be concerned about how a traffic lights
controller responds to IP queries about light status, and potentially
change status. An UDP/IP protocol may be involved, and maybe over
802.11-OCB.

In France, the protocol for traffic lights controller is DIASER. Is it
used in other country?

Alex

> 
> Russ
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 May 2018 17:22:51 -0400

> On May 2, 2018, at 5:19 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

AFNOR seems to be the source of that specification.  I do not know if it is used outside of France.

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 3 May 2018 09:11:24 +0200

> AFNOR seems to be the source of that specification.  I do not know if it is used outside of France.

What protocol is used in America to control traffic lights?

(something like: request open/close status of the 'line', request
description of each light set, give priority to Public Transportation
Bus; these keywords are my speculation from translating the AFNOR DIASER
French specification)

Alex

---

From: William Whyte <[email-masked]>
Date: Thu, 3 May 2018 08:09:48 -0400

Different locales use different mechanisms, but the standardized one is
NTCIP, National Transportation Communications for ITS Protocol. It's
SNMP-based.

Cheers,

William

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[email-masked]

---

From: François Simon <[email-masked]>
Date: Thu, 3 May 2018 11:33:32 -0400

Did I miss something?  Now we are talking about traffic signals while, I believe, we certainly do not have a solution for all the issues that was brought up in the few last week. Now, UDP/IP (assuming IPv6)  is brought-up and "it may be over 802.11 OCB"; what other choice to this point.  Did the focus has changed?

In the US, MUTCD Standard is the Manual on Uniform Traffic control Devices describes basic principles for evaluating traffic control devices for Streets and Highways.  The MUTCD, published by the Federal Highway Administration (FHWA), standardizes traffic control devices throughout the country to ensure that they mean the same to, and require the same actions by, all motorists anywhere in the country. Compliance with MUTCD standards help to promote the safe, orderly, and efficient movement of traffic. These standards are intended to obtain basic uniformity of traffic control devices, they should be followed consistently. Devices that do not conform to the MUTCD should not be used on roadways.

While some states have adopted the national MUTCD as is, others have either created a similar state-specific MUTCD or simply written a state document to enhance the national MUTCD.

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 02, 2018 5:20 AM
To: [email-masked]
Subject: Re: [ipwave] IPWAVE Recharter Topics?

Le 18/04/2018 à 20:39, Russ Housley a écrit :
> I saw very little excitement for rechartering the IPWAVE WG.  There 
> were a small number of people want to do something, but most people 
> felt that other standards bodies should tackle non-IP topics.
> 

Hi Russ,

In the next few months I will be concerned about how a traffic lights controller responds to IP queries about light status, and potentially change status. An UDP/IP protocol may be involved, and maybe over 802.11-OCB.

In France, the protocol for traffic lights controller is DIASER. Is it used in other country?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 4 May 2018 10:06:29 +0200

Hi François,

 From my part, there is no change in focus.  There are just so many
things to tackle in IP for vehicular networks, but only a few things
could be done reasonably well in manageable timescales.  My intent in
these discussions is to understand what could be immediate next steps.

Le 03/05/2018 à 17:33, François Simon a écrit :
> Did I miss something?  Now we are talking about traffic signals 
> while, I believe, we certainly do not have a solution for all the 
> issues that was brought up in the few last week.

As I recollect, there are a few issues in the few last weeks:
- the problem statement draft
- the IPv6-over-OCB draft comments in 6man WG
- the remark from Dick Roy about vehicular networks and what other SDO
   really needs from IETF
- a couple of liaison interests from ITU and SAE C-V2X

> Now, UDP/IP (assuming IPv6)  is brought-up and "it may be over 802.11
> OCB"; what other choice to this point.  Did the focus has changed?

No change in focus.

We need to identify the focus, though.  What do you think should be the 
focus?

As a side note, in a project where I work, there is interest for the car 
to signal somehow to the traffic lights controller that it wants to pass 
as a priority vehicle compared to others.

This could be achieved either by the RSU sensing the CAM beacons of a 
particular car and subsequently opening the line, or otherwise by the 
car to send an XER-CAM-over-UDP/IP to the RSU.  In this latter option, 
it is obviously IPv6-over-OCB that would be used.

Inside a car, it is already very pertinent to send 
XER-CAM-over-UDP-over-IP.  It is a good subject to write an Internet 
Draft about.

It is also pertinent to think of sending DIASER messages 
(country-specific standard) from the traffic lights controller to the 
cloud, over IPv6 over cellular link.  This, however, is not 
IPv6-over-802.11-OCB.

> In the US, MUTCD Standard is the Manual on Uniform Traffic control 
> Devices describes basic principles for evaluating traffic control 
> devices for Streets and Highways.  The MUTCD, published by the 
> Federal Highway Administration (FHWA), standardizes traffic control 
> devices throughout the country to ensure that they mean the same to, 
> and require the same actions by, all motorists anywhere in the 
> country. Compliance with MUTCD standards help to promote the safe, 
> orderly, and efficient movement of traffic. These standards are 
> intended to obtain basic uniformity of traffic control devices, they 
> should be followed consistently. Devices that do not conform to the 
> MUTCD should not be used on roadways.
> 
> While some states have adopted the national MUTCD as is, others have 
> either created a similar state-specific MUTCD or simply written a 
> state document to enhance the national MUTCD.

Is MUTCD an ASCII protocol?

A country-specific standard DIASER is an ASCII protocol.  A 
request-response message is like this: STX, C, A, ETX (meaning: start of 
text, to all traffic lights in intersection, ask the kinds of lights, 
end of text) responded by STX, C, A, E, A, G, A... ETX (there are 14 
lights, for car lane, for pedestrian lane...)  People put this ASCII 
protocol on UDP/IPv4 port number 1027.  That port number is not IANA 
reserved.  Worse, IANA reserves 1027 for some IPv6 transition mechanism. 
  That's a obviously not a desirable situation.

Alex

> 
> Fygs
> 
> -----Original Message----- From: its <[email-masked]> On
> Behalf Of Alexandre Petrescu Sent: Wednesday, May 02, 2018 5:20 AM
> To: [email-masked] Subject: Re: [ipwave] IPWAVE Recharter Topics?
> 
> 
> 
>> there enough interest and energy among the IPWAVE WG participants
>> to tackle them?
> 
> Hi Russ,
> 
> In the next few months I will be concerned about how a traffic
> lights controller responds to IP queries about light status, and
> potentially change status. An UDP/IP protocol may be involved, and
> maybe over 802.11-OCB.
> 
>> _______________________________________________ its mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>> 
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
> 
>

---

From: John Kenney <[email-masked]>
Date: Sat, 5 May 2018 07:51:28 -0700

Hi Alexandre and All:

On the topic of a vehicle requesting priority from a signal controller, you
may be aware that SAE J2735 already defines the Signal Request Message
(SRM) and Signal Status Message (SSM) for this dialogue.  SAE has
identified that SAE J2945/11 will specify the relevant application details
for how to execute such a service, though it is not yet underway.
Presumably this will be specified over WSMP (for the US), not IPv6. I don't
know what is happening for this application in Europe.

Best Regards,
John

On Fri, May 4, 2018 at 1:06 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> Did I miss something?  Now we are talking about traffic signals while, I
>> believe, we certainly do not have a solution for all the issues that was
>> brought up in the few last week.
>>
>
> to signal somehow to the traffic lights controller that it wants to pass as
> a priority vehicle compared to others.
>
> particular car and subsequently opening the line, or otherwise by the car
> to send an XER-CAM-over-UDP/IP to the RSU.  In this latter option, it is
> obviously IPv6-over-OCB that would be used.
>
> XER-CAM-over-UDP-over-IP.  It is a good subject to write an Internet Draft
> about.
>
> It is also pertinent to think of sending DIASER messages (country-specific
> standard) from the traffic lights controller to the cloud, over IPv6 over
> cellular link.  This, however, is not IPv6-over-802.11-OCB.
>
> In the US, MUTCD Standard is the Manual on Uniform Traffic control Devices
>> describes basic principles for evaluating traffic control devices for
>> Streets and Highways.  The MUTCD, published by the Federal Highway
>> Administration (FHWA), standardizes traffic control devices throughout the
>> country to ensure that they mean the same to, and require the same actions
>> by, all motorists anywhere in the country. Compliance with MUTCD standards
>> help to promote the safe, orderly, and efficient movement of traffic. These
>> standards are intended to obtain basic uniformity of traffic control
>> devices, they should be followed consistently. Devices that do not conform
>> to the MUTCD should not be used on roadways.
>>
>> either created a similar state-specific MUTCD or simply written a state
>> document to enhance the national MUTCD.
>>
>
> text, to all traffic lights in intersection, ask the kinds of lights, end
> of text) responded by STX, C, A, E, A, G, A... ETX (there are 14 lights,
> for car lane, for pedestrian lane...)  People put this ASCII protocol on
> UDP/IPv4 port number 1027.  That port number is not IANA reserved.  Worse,
> IANA reserves 1027 for some IPv6 transition mechanism.  That's a obviously
> not a desirable situation.
>
> Alex
>
>
>
>> Fygs
>>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 11 May 2018 13:30:09 +0200

Hi John,

Le 05/05/2018 à 16:51, John Kenney a écrit :
> Hi Alexandre and All:
> 
> On the topic of a vehicle requesting priority from a signal controller, 
> you may be aware that SAE J2735 already defines the Signal Request 
> Message (SRM) and Signal Status Message (SSM) for this dialogue.  SAE 
> has identified that SAE J2945/11 will specify the relevant application 
> details for how to execute such a service, though it is not yet 
> underway.  Presumably this will be specified over WSMP (for the US), not 
> IPv6. I don't know what is happening for this application in Europe.

In Europe there is also SPAT-EM and MAP messages being considered by the
ITS Technical Committee at ETSI. Maybe SRM is considered there too.

However, I do not know any traffic light controller that implements
SPAT, MAP or SRM natively - despite being standardized. The traffic
light controllers I know support DIASER natively; the brands are FARECO,
MAESTRO, and a few others.

The DIASER messages have been put on UDP on IPv4.

I doubt it makes great sense to write converters between SPAT/MAP/SRM
and DIASER(?) Rather, put DIASER clients in cars and talk over IP
directly to traffic light controllers in an end-to-end fashion.

I would need to look more to get persuaded by reasons to write such 
converters.

Alex

> 
> Best Regards,
> John
> 
> 
> On Fri, May 4, 2018 at 1:06 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi François,
> 
>         while, I believe, we certainly do not have a solution for all
>         the issues that was brought up in the few last week.
> 
> 
>     We need to identify the focus, though.  What do you think should be
>     the focus?
> 
>     As a side note, in a project where I work, there is interest for the
>     car to signal somehow to the traffic lights controller that it wants
>     to pass as a priority vehicle compared to others.
> 
>     This could be achieved either by the RSU sensing the CAM beacons of
>     a particular car and subsequently opening the line, or otherwise by
>     the car to send an XER-CAM-over-UDP/IP to the RSU.  In this latter
>     option, it is obviously IPv6-over-OCB that would be used.
> 
>     (country-specific standard) from the traffic lights controller to
>     the cloud, over IPv6 over cellular link.  This, however, is not
>     IPv6-over-802.11-OCB.
> 
>         In the US, MUTCD Standard is the Manual on Uniform Traffic
>         control Devices describes basic principles for evaluating
>         traffic control devices for Streets and Highways.  The MUTCD,
>         published by the Federal Highway Administration (FHWA),
>         standardizes traffic control devices throughout the country to
>         ensure that they mean the same to, and require the same actions
>         by, all motorists anywhere in the country. Compliance with MUTCD
>         standards help to promote the safe, orderly, and efficient
>         movement of traffic. These standards are intended to obtain
>         basic uniformity of traffic control devices, they should be
>         followed consistently. Devices that do not conform to the MUTCD
>         should not be used on roadways.
> 
>         While some states have adopted the national MUTCD as is, others
>         have either created a similar state-specific MUTCD or simply
>         written a state document to enhance the national MUTCD.
> 
> 
>     request-response message is like this: STX, C, A, ETX (meaning:
>     start of text, to all traffic lights in intersection, ask the kinds
>     of lights, end of text) responded by STX, C, A, E, A, G, A... ETX
>     (there are 14 lights, for car lane, for pedestrian lane...)  People
>     put this ASCII protocol on UDP/IPv4 port number 1027.  That port
>     number is not IANA reserved.  Worse, IANA reserves 1027 for some
>     IPv6 transition mechanism.  That's a obviously not a desirable
>     situation.
> 
>     Alex
> 
> 
> 
>         Fygs
> 
>         -----Original Message----- From: its <[email-masked]
>         <mailto:[email-masked]>> On
>         To: [email-masked] <mailto:[email-masked]> Subject: Re: [ipwave]
>         IPWAVE Recharter Topics?
> 
> 
> 
>             _______________________________________________ its mailing
>             list [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/its>
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
> -- 
> John Kenney

---

From: François Simon <[email-masked]>
Date: Fri, 11 May 2018 09:39:16 -0400

What are you trying to do? Develop a more efficient standard to meet new requirements or preserve legacy systems and "make it fit"?  This is the story of com. protocols repeating itself:

First we did have X21 Switch and X.25; ISDN came along so we developed V110 and X.31 to accommodate X21/X.25 with ISDN,  Then came ATM and Frame Relay to replace ISDN so we developed LANE to make ATM compatible with LAN, etc. etc.  My personal view is that vendor devices should not being taking into consideration!!!

Fygs

I apologize if I offended someone.

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Friday, May 11, 2018 7:30 AM
To: John Kenney <[email-masked]>
Cc: François Simon <[email-masked]>; its <[email-masked]>
Subject: Re: [ipwave] IPWAVE Recharter Topics?

Hi John,

Le 05/05/2018 à 16:51, John Kenney a écrit :
> Hi Alexandre and All:
> 
> On the topic of a vehicle requesting priority from a signal 
> controller, you may be aware that SAE J2735 already defines the Signal 
> Request Message (SRM) and Signal Status Message (SSM) for this 
> dialogue.  SAE has identified that SAE J2945/11 will specify the 
> relevant application details for how to execute such a service, though 
> it is not yet underway.  Presumably this will be specified over WSMP 
> (for the US), not IPv6. I don't know what is happening for this application in Europe.

In Europe there is also SPAT-EM and MAP messages being considered by the ITS Technical Committee at ETSI. Maybe SRM is considered there too.

However, I do not know any traffic light controller that implements SPAT, MAP or SRM natively - despite being standardized. The traffic light controllers I know support DIASER natively; the brands are FARECO, MAESTRO, and a few others.

I doubt it makes great sense to write converters between SPAT/MAP/SRM and DIASER(?) Rather, put DIASER clients in cars and talk over IP directly to traffic light controllers in an end-to-end fashion.

I would need to look more to get persuaded by reasons to write such converters.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 11:40:17 +0200

Le 11/05/2018 à 15:39, François Simon a écrit :
> What are you trying to do? Develop a more efficient standard to meet
>  new requirements or preserve legacy systems and "make it fit"?

Yes, the latter.

Because developping more efficient standards is already happening elsewhere.

> This is the story of com. protocols repeating itself:
> 
> First we did have X21 Switch and X.25; ISDN came along so we 
> developed V110 and X.31 to accommodate X21/X.25 with ISDN,  Then came
> ATM and Frame Relay to replace ISDN so we developed LANE to make ATM
> compatible with LAN, etc. etc.

I think the comparison holds to some extent.  If I recollect correctly
neither X.21 nor X.25 had IP on them, yet ISDN, ATM and FR all had it.

In our case we talk about DIASER vs SPAT.  One of them does work ok with
IP so we should use it.

> My personal view is that vendor devices should not being taking into
> consideration!!!

I can agree in a sense: equipment will implement it if demonstrating 
some great new features.

For example, if SPAT and MAP messages prove great then many hardware 
vendors will implement them natively, without converters between DIASER 
and SPAT.

Alex

> -----Original Message----- From: Alexandre Petrescu 
> <[email-masked]> Sent: Friday, May 11, 2018 7:30 AM To:
> John Kenney <[email-masked]> Cc: François Simon 
> <[email-masked]>; its <[email-masked]> Subject: Re: [ipwave] IPWAVE
> Recharter Topics?
> 
> Hi John,
> 
>> controller, you may be aware that SAE J2735 already defines the 
>> Signal Request Message (SRM) and Signal Status Message (SSM) for 
>> this dialogue.  SAE has identified that SAE J2945/11 will specify 
>> the relevant application details for how to execute such a service,
>> though it is not yet underway.  Presumably this will be specified
>> over WSMP (for the US), not IPv6. I don't know what is happening
>> for this application in Europe.
> 
> In Europe there is also SPAT-EM and MAP messages being considered by
>  the ITS Technical Committee at ETSI. Maybe SRM is considered there 
> too.
> 
> light controllers I know support DIASER natively; the brands are 
> FARECO, MAESTRO, and a few others.
> 
>> Best Regards, John
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> 
>> Hi François,
>> 
>> things to tackle in IP for vehicular networks, but only a few 
>> things could be done reasonably well in manageable timescales.  My
>>  intent in these discussions is to understand what could be 
>> immediate next steps.
>> 
>> As I recollect, there are a few issues in the few last weeks: - the
>> problem statement draft - the IPv6-over-OCB draft comments in 6man
>> WG - the remark from Dick Roy about vehicular networks and what
>> other SDO really needs from IETF - a couple of liaison interests
>> from ITU and SAE C-V2X
>> 
>> Now, UDP/IP (assuming IPv6)  is brought-up and "it may be over 
>> 802.11 OCB"; what other choice to this point.  Did the focus has 
>> changed?
>> 
>> 
>> No change in focus.
>> 
>> We need to identify the focus, though.  What do you think should
>> be the focus?
>> 
>> As a side note, in a project where I work, there is interest for 
>> the car to signal somehow to the traffic lights controller that it
>>  wants to pass as a priority vehicle compared to others.
>> 
>> This could be achieved either by the RSU sensing the CAM beacons
>> of a particular car and subsequently opening the line, or otherwise
>> by the car to send an XER-CAM-over-UDP/IP to the RSU.  In this
>> latter option, it is obviously IPv6-over-OCB that would be used.
>> 
>> XER-CAM-over-UDP-over-IP.  It is a good subject to write an 
>> Internet Draft about.
>> 
>> devices throughout the country to ensure that they mean the same
>> to, and require the same actions by, all motorists anywhere in the
>> intended to obtain basic uniformity of traffic control devices,
>> they should be followed consistently. Devices that do not conform
>> start of text, to all traffic lights in intersection, ask the
>> kinds of lights, end of text) responded by STX, C, A, E, A, G, A...
>> ETX (there are 14 lights, for car lane, for pedestrian lane...)
>> People put this ASCII protocol on UDP/IPv4 port number 1027.  That
>> port number is not IANA reserved.  Worse, IANA reserves 1027 for
>> some IPv6 transition mechanism.  That's a obviously not a
>> desirable situation.
>> 
>> Alex
>> 
>> 
>> 
>> Fygs
>> 
>> <mailto:[email-masked]>> On Behalf Of Alexandre Petrescu 
>> Sent: Wednesday, May 02, 2018 5:20 AM To: [email-masked] 
>> <mailto:[email-masked]> Subject: Re: [ipwave] IPWAVE Recharter 
>> Topics?
>> 
>> 
>> 
>> Are there any IP-related topics that need to be tackled?  If so,
>> is there enough interest and energy among the IPWAVE WG
>> participants to tackle them?
>> 
>> 
>> Hi Russ,
>> 
>> -- John Kenney Director and Principal Researcher Toyota 
>> InfoTechnology Center, USA 465 Bernardo Avenue Mountain View, CA 
>> 94043 Tel: 650-694-4160. Mobile: 650-224-6644
> 
>

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 14 May 2018 08:18:19 -0700

On Mon, 2018-05-14 at 11:40 +0200, Alexandre Petrescu wrote:
> If I recollect correctly

You're not recollecting correctly.

X.25 was a framing protocol that preceded IP by several years.  It
sorta fits at layer 2 as a framing protocol.  But it has several
connection-oriented features -- a whole raft of control knobs that
sorta made sense in a circuit-switched world.  X.25 was most certainly
used as a framing protocol for IP datagrams -- i.e. terrestrial WAN.  
     X.25 had a frame counter in it that was only 3 bits if I remember
right, so you could have only 8 frames in flight at a time.  As
wireline capacities increased, this was a fatally limiting factor. X.25
was eclipsed by Frame Relay which had all that crud stripped out.
     The amateur radio folks modified X.25 and called the mod AX.25;
used for amateur packet radio.  Several projects in the military also
tried to use X.25 framing in radio-WAN networks.  Because X.25 lacks a
MAC entirely (relies on the circuit switching environment to set up a
point-point link within which it works), none of these worked very
well. 

When I first started teaching networking, I was handed a textbook and
asked if I could use that.  There was a chapter that compared X.25 and
frame relay by listing their features.  The author concluded that since
X.25 had a longer feature list, it must be better.  Even as a rookie
prof, I managed to veto that one.