Subject: [ipwave] Re-Charter

From: François Simon <[email-masked]>
Date: Sat, 5 May 2018 08:50:01 -0400

IPWAVE Re-charter

Good day to all.

Here are my comments on this email:

*	As I recollect, there are a few issues in the few last weeks:

*	the problem statement draft

*	My question is again: What is IETF / IPWAVE trying to do in term of
standard?  It has been established of whatever it is, it will use the
network layer protocol 1Pv6.
*	It has been also established is that “product” will address
“vehicular” connectivity – V2V, V2I, V2X, etc.
*	Is the “problem statement” actually the “requirements” / “mobile
applications” that we are trying to achieve?  Here are examples of
application types: Safety, Mobility, entertainment, Environment, Road
Weather; etc., 
*	If this is true, then any mobile link and PHY layers, including
802.11 OCB is fair game. The application will dictate!
*	Also, if this is true, then OCB is no longer the focus.

*	the IPv6-over-OCB draft comments in 6man WG

*	Sorry, I do not know what this means.

*	the remark from Dick Roy about vehicular networks and what other SDO
really needs from IETF

*	The remarks from Dr, Roy are in general 99.9% accurate.
*	If other SDOs have needs from IETF/WAVE, then they should make their
requirement known and include them in the IPWAVE “requirements”, if
applicable.

*	A couple of liaison interests from ITU and SAE C-V2X

*	The previous comment applies here as well.

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

*	This is what I am trying to do: a top = down approach.

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

*	This now is not part of the “re-charter”.  I would caution to add
functions in the requirements without a good understanding from the IPWAVE
WG.

-        SAE J2735 standard provide in its dictionary two messages for this
purpose (at                                         least it did 2 years
ago).  The application would process the messages.

*	This is a basic principal:
*	MSG_SignalRequestMessage  (SRM): Requesting the signal controller
(via RSU) to provide right-of-way thrue the intersection.
*	MSG_SignalStatusMessage  (SSM): Is the response from the signal
controller if the request has been granted or not.

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

-        I do not know what that is, but I have a feeling this another
sort-range communication inside a vehicle (ZigBee).

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

-        Ok then.

*	Is MUTCD an ASCII protocol?

*	No
*	US Only - The Manual on Uniform Traffic Control Devices (MUTCD) is
incorporated by reference in 23 Code of Federal Regulations (CFR), Part 655,
Subpart F and shall be recognized as the national standard for all traffic
control devices installed on any street, highway, bikeway, or private road
open to public travel (see definition in Section 1A.13) in accordance with
23 U.S.C. 109(d) and 402(a).

*	US Only - The National Transportation Communications for ITS
Protocol (NTCIP) suite of standard communications protocols and data
definitions has been designed to accommodate the diverse needs of various
subsystems and user services of the National ITS Architecture. NTCIP
standards are intended to handle these needs in the following two areas: 

The first type of communications is between a management system or center
and multiple control or monitoring devices, such as a traffic control system
communicating with intersection controllers, dynamic message signs, and
control of CCTV cameras. This type is referred to as center-to-field (C2F)
communications. 

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

*	For the US, I suggest that you consult SAE J2735 standard,

Fygs

 

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Friday, May 04, 2018 4:06 AM
To: François Simon <[email-masked]>; [email-masked]
Subject: Re: [ipwave] IPWAVE Recharter Topics?

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

> 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] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

> _______________________________________________ its mailing list 

> [email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

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

Le 05/05/2018 à 14:50, François Simon a écrit :
>   * */As I recollect, there are a few issues in the few last weeks:/*
>       o */the problem statement draft/*
>           + My question is again: What is IETF / IPWAVE trying to do in
>             term of standard?  It has been established of whatever it
>             is, it will use the network layer protocol 1Pv6.//

It's IPv6 :-) not 1Pv6 (although I and 1 are same in latin :-)

>           + It has been also established is that “product” will address
>             “vehicular” connectivity – V2V, V2I, V2X, etc.//
>           + Is the “problem statement” actually the “requirements” /
>             “mobile applications” that we are trying to achieve?  Here
>             are examples of application types: Safety, Mobility,
>             entertainment, Environment, Road Weather; etc.,
>           + If this is true, then any mobile link and PHY layers,
>             including 802.11 OCB is fair game. The application will dictate!
>           + Also, if this is true, then OCB is no longer the focus.

Work on IPv6-over-OCB was the focus of the main work item, but now we 
advance.

>   * /*the IPv6-over-OCB draft comments in 6man WG*/
>       o Sorry, I do not know what this means.

It means this: at IETF there are several Working Groups (WG).  The 
IPWAVE is one WG.  There are other WGs such as the called '6MAN'.  The 
6MAN WG specifies IPv6 protocols.  The Area Director (AD) invited the 
participants to 6man WG to review the IPv6-over-OCB document.  They 
provided comments.  To look at that comments one may read the archives 
and maybe subscribe to the 6man WG email list ietf.org/mailman/listinfo/ipv6

>   * */the remark from Dick Roy about vehicular networks and what other
>     SDO really needs from IETF/*
>       o The remarks from Dr, Roy are in general 99.9% accurate.
>       o If other SDOs have needs from IETF/WAVE, then they should make
>         their requirement known and include them in the IPWAVE
>         “requirements”, if applicable.
> 
>   * */A couple of liaison interests from ITU and SAE C-V2X/**//*
>       o The previous comment applies here as well.//

It means this: a few liaison statements were sent from these 
organisations to the IPWAVE WG email list.  I hope you received them. 
If not, these are some pointers.  The Chairs deal with them.

Liaison Statement from ITU "Collaboration on ITS"
https://mailarchive.ietf.org/arch/msg/its/M9OxheYLs5ghlL-Uj1NxuHN10os

LS from SAE
https://mailarchive.ietf.org/arch/msg/its/l-VZ-hfUVj_O2zfxrplwFHBZ8z0

> 
>   * */We need to identify the focus, though.  What do you think should
>     be the focus?/*
> 
>       o This is what I am trying to do: a top = down approach.*//*
> 
> *//*
> 
> *//*
> 
>   * */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./*
> 
> *//*
> 
>       o This now is not part of the “re-charter”.  I would caution to
>         add functions in the requirements without a good understanding
>         from the IPWAVE WG.*//*

I can agree it to not be part of re-charter.

I would then ask _what_ is part of the re-charter?

> -SAE J2735 standard provide in its dictionary two messages for this 
>               # This is a basic principal:
>               # *MSG_SignalRequestMessage  (SRM)*: Requesting the signal
>                 controller (via RSU) to provide right-of-way thrue the
>                 intersection.
>               # *MSG_SignalStatusMessage  (SSM*): Is the response from
>                 the signal controller if the request has been granted or
>                 not.

Is SAE J2735 put on IP?  If not then it should be.  Could this be part 
of re-charter?

> -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.
> 
> -I do not know what that is, but I have a feeling this another 

ZigBee is indeed a good short-range wireless communication media useful 
in a car.  An Ethernet LAN is also short-range, but wired.  It is very 
useful in a car.

An Ethernet in a car links together many computers in a car, among 
which, notably - the 'DSRC' box with the 'LTE' box.

Many people who design in-car networks just do the 'DSRC' box, others 
just do the 'LTE' box.  Linking them together is new.

When linking the DSRC box with the LTE box one wants to send messages 
like BSM (CAM in Europe) from the DSRC box to the LTE box.  The encoding 
of these CAM messages is XER, rather than UPER.  UPER encoding is a 
compressed format which is used on 802.11-OCB because puts less bits on 
the wire.  XER encoding format puts more bits but we dont care because 
Ethernet supports it.  Converting from UPER to XER is straightforward 
with open-source libraries like asn1c.

> 
>   * */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./*
> 
> -Ok then.
> 
>   * */Is MUTCD an ASCII protocol?/*
>       o No*//*

If it is not an ASCII protocol then what is the message format of MUTCD?

>       o US Only - The Manual on Uniform Traffic Control Devices (MUTCD)
>         is incorporated by reference in 23 Code of Federal Regulations
>         (CFR), Part 655, Subpart F and shall be recognized as the
>         national standard for all traffic control devices installed on
>         any street, highway, bikeway, or private road open to public
>         travel (see definition in Section 1A.13) in accordance with 23
>         U.S.C. 109(d) and 402(a).

Hmm... MUTCD a national standard enforced on all traffic lights, that we 
dont know what is because closed spec... sounds like DIASER in France.

>       o US Only - The National Transportation Communications for ITS
>         Protocol (NTCIP) suite of standard communications protocols and
>         data definitions has been designed to accommodate the diverse
>         needs of various subsystems and user services of the National
>         ITS Architecture. NTCIP standards are intended to handle these
>         needs in the following two areas: 
> 
> The first type of communications is between a management system or 
> center and multiple control or monitoring devices, such as a traffic 
> control system communicating with intersection controllers, dynamic 
> message signs, and control of CCTV cameras. This type is referred to as 
> center-to-field (C2F) communications.
> 
>   * */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./*
>           + For the US, I suggest that you consult SAE J2735 standard,*//*

It's behind a paywall.  I cant consult it.

Alex

> *//*
> */Fygs/*
> *//*
>  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.
> 
> 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 
> 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.
> 
> A country-specific standard DIASER is an ASCII protocol.  A 
> 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.
> 
> <mailto:[email-masked]>> On Behalf
>