Subject: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems"

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 8 Jul 2016 02:33:16 +0900

Hi all,
I have posted a new its I-D:
- Title
   Survey on IP-based Vehicular Networking for Intelligent Transportation
Systems

- File

https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00

- Abstract
   This document surveys the IP-based vehicular networks, which are
   considered a key component of Intelligent Transportation Systems
   (ITS).  The main topics of vehicular networking are vehicle-to-
   vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure-
   to-vehicle (I2V) networking.  Vehicular networks deal with some
   critical aspects, such as IP address autoconfiguration, routing,
   handover, and mobility management.  This document summarizes and
   analyzes the previous research activities that use IPv4 or IPv6 for
   vehicular networking"

In this draft, we show the survey on IP-based Vehicular Networking
for Intelligent Transportation Systems.
This draft will be a good foundation to figure out the state-of-the-art
schemes for IP-based vehicular networking, so we can use it for
"ITS General Problem Area" that is one of work items in our its group:
https://trac.tools.ietf.org/wg/its/trac/

It will be great for you to take a look at this I-D and give us comments or
suggestions.

Thanks.

Best Regards,
Paul
-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: José Santa Lozano <[email-masked]>
Date: Fri, 8 Jul 2016 10:55:19 +0200

Dear Paul,

Thanks for the work. Please consider the next comments and suggestions of papers to add:

1- I think it would be interesting to also include a section about security. Even though you have added a small note at the end of the document, I think that probably some works in the area could arise. From our side we propose the next paper to add:

Pedro J. Fernández, José Santa, Fernando Bernal, Antonio F. Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016.

In this paper we evaluate the usage of IPSec in vehicular (to infrastructure) communications.

2- In the same line I think the document lacks in more evaluation deployment works in the scientific literature. For sure, some of the currently included papers include evaluations, but I think a concrete section or an update with paper of this line would be beneficial to people to understand the feasibility of IPv6 in vehicular communications. From our side we propose the next one:

José Santa, Pedro J. Fernández, Fernando Pereñiguez, Antonio F. Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p and IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous Computing, in press these days, 2016.

In this paper we present the work carried out in frames of the FOTsis project to deploy real IPv6 vehicle-to-infrastructure networks around Europe, together with the main evaluations performed.

3- In the document there is a lack in mentioning the synergy between currently standardized architecture at ISO/ETSI and the usage of IPv6. However, IEEE WAVE has been cited multitude of times. Our next paper could help to improve this needed part of the document, which could be probably added in the mobility management section:

José Santa, Fernando Pereñiguez-García, Fernando Bernal, Pedro J. Fernández, Rafael Marín-López, Antonio F. Skarmeta. A Framework for Supporting Network Continuity in Vehicular IPv6 Communications. IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17-34, doi: 10.1109/MITS.2013.2274876, 2014.

In this work we present an architecture that complements the ETSI/ISO communication architecture by using IPv6 (IETF) technologies.

4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but we have also tested the possibility of also sending ETSI CAM/DENM messages over this platform by using UDP. This approach could be interesting for the IETF ITS group. I am not completely sure about the place to add this contribution, but in this case I doubt about the need to create a new section, given that I am not sure if there are many other works in this line.

José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio F. Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in Vehicular Communications. Transportation Research Part C: Emerging Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.

In this work we provide an implementation of the ETSI messaging algorithm over our IPv6-o-11p basis.

Please, let me know if you need further text, depending on the interest you find in my previous suggestions.

Regards,

-- 
José Santa Lozano
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta

> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong <[email-masked]> escribió:
> 
> Hi all,
>    Survey on IP-based Vehicular Networking for Intelligent Transportation Systems 
> 
> - File
> It will be great for you to take a look at this I-D and give us comments or suggestions.
> 
> Thanks.
> 
> Best Regards,
> Paul
> -- 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jul 2016 14:21:57 +0200

Hello José,

Thank you for the message.  There are many aspects you said that need to
be considered.  Let me reply to just one now.

Le 08/07/2016 à 10:55, José Santa Lozano a écrit :
[...]
> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p,
> but we have also tested the possibility of also sending ETSI
> *CAM/DENM* messages over this platform by using UDP. This approach
> could be interesting for the IETF ITS group. I am not completely sure
> about the place to add this contribution, but in this case I doubt
> about the need to create a new section, given that I am not sure if
> there are many other works in this line.
>
> José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio F.
> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services
>  in Vehicular Communications. Transportation Research Part C:
> Emerging Technologies, vol. 2014, pp. 98-120, doi:
> http://dx.doi.org/10.1016/j.trc.2014.05.006, 2014.
>
> Please, let me know if you need further text, depending on the
> interest you find in my previous suggestions.

The freely-avaliable paper is very important.  It is probably the
best example mentioning CAM being transported as payload
of IPv6 over 802.11p.  Literally it says:
> CAM and DENM messages are exchanged between MR [MobileRouter] and AR
> [AccessRouter] using UDP datagrams that are destined to the
> well-known IPv6 multicast address referring to all the nodes present
> on the local network segment (ff02::1). The use of this transport is
> based on the fact that there is no sense in using a
> connection-oriented transport since vehicles enter sporadically in
> an AR communication range.

It is a highly desirable behaviour exposing application-layer working
together with a network layer over a link layer.

Do you happen to have a packet dump available for this operation? 
(ideally in monitor mode).  See more packet dumps in 802.11-OCB context 
at 
http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files

What is the maximum size of a UDP packet thus sent?  (other reports 
mention a max for CAM message of 102 bytes; others 300 bytes; they all 
fit within 802.11-OCB definition of max MTU 1500 bytes, but I want to 
make sure; also do you know at what size will 802.11OCB start to 
fragment - this can be seen in the wireshark monitor mode, 802.11 Data 
header, Flags "More Fragments"?)

What is the src MAC address used?  Because there may be a privacy worry 
of listeners along roads identifying which car uses which Organizational 
Unique Identifier.

What is the dst MAC address used?  The MAC address 33-33-0-0-0-0-1 is 
expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and 
"01-80-C2-".  There is a need to decide which one of these to use, or 
maybe request a new one.

This will help writing a single "IPv6-over-802.11-OCB" document which is 
the first goal in this group.

Alex

>
> Regards,
>
> -- José Santa Lozano Dept. Ingeniería de la Información y las
> Comunicaciones Facultad de Informática Universidad de Murcia 30100
> Murcia, Spain Telf: +34-868-888771 / +34-868-884455 Fax:
> +34-868-884151 Web: http://ants.inf.um.es/~josesanta
>
>
>
>> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong
>> <[email-masked] <mailto:[email-masked]>> escribió:
>>
>> Hi all, I have posted a new its I-D: - Title Survey on IP-based
>> Vehicular Networking for Intelligent Transportation Systems
>>
>> - File
>>
- Abstract
>> vehicle (V2V), vehicle-to-infrastructure (V2I), and
>> infrastructure- to-vehicle (I2V) networking.  Vehicular networks
>> deal with some critical aspects, such as IP address
>> autoconfiguration, routing, handover, and mobility management. This
>> document summarizes and analyzes the previous research activities
>> that use IPv4 or IPv6 for vehicular networking"
>>
>>  for Intelligent Transportation Systems. This draft will be a good
>>  foundation to figure out the state-of-the-art schemes for IP-based
>>  vehicular networking, so we can use it for "ITS General Problem
>> Area" that is one of work items in our its group:
>> Best Regards, Paul -- =========================== Mr. Jaehoon
>> (Paul) Jeong, Ph.D. Assistant Professor Department of Software
>> Sungkyunkwan University Office: +82-31-299-4957 Email:
>> [email-masked], [email-masked] Personal Homepage:
>> http://iotlab.skku.edu/people-jaehoon-jeong.php
>> _______________________________________________ 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: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 12 Jul 2016 01:48:36 +0900

Hi Jose,
Thanks for your good comments and suggestions.

My answers are inline below:

On Fri, Jul 8, 2016 at 5:55 PM, José Santa Lozano <[email-masked]> wrote:

> 1- I think it would be interesting to also include a section about
> *security*. Even though you have added a small note at the end of the
> document, I think that probably some works in the area could arise. From
> our side we propose the next paper to add:
>
> Pedro J. Fernández, José Santa, Fernando Bernal, Antonio F.
> Skarmeta. Securing Vehicular IPv6 Communications. IEEE Transactions on
> Dependable and Secure Computing, vol. 13, no. 1, pp. 46-58, 2016.
>

 => We authors are planning to add more papers (including your paper) for
security and privacy to the next revision.

>
> 2- In the same line I think the document lacks in more *evaluation
> deployment* works in the scientific literature. For sure, some of the
> currently included papers include evaluations, but I think a concrete
> section or an update with paper of this line would be beneficial to people
> to understand the feasibility of IPv6 in vehicular communications. From our
> side we propose the next one:
>
> José Santa, Pedro J. Fernández, Fernando Pereñiguez, Antonio F.
> Skarmeta. Deployment of Vehicular Networks in Highways Using 802.11p and
> IPv6 Technologies. International Journal of Ad Hoc and Ubiquitous
> Computing, in press these days, 2016.
>
> In this paper we present the work carried out in frames of the FOTsis
> project to deploy real IPv6 vehicle-to-infrastructure networks around
> Europe, together with the main evaluations performed.
>

 => Sure. I agree that the evaluation for deployment is important.
      After reviewing your paper, we will consider to include your above
paper into the next revision.

>
> 3- In the document there is a lack in mentioning the synergy between
> currently standardized architecture at *ISO/ETSI and the usage of IPv6*.
> However, IEEE WAVE has been cited multitude of times. Our next paper could
> help to improve this needed part of the document, which could be probably
> added in the mobility management section:
>
> José Santa, Fernando Pereñiguez-García, Fernando Bernal, Pedro J.
> Fernández, Rafael Marín-López, Antonio F. Skarmeta. A Framework for
> Supporting Network Continuity in Vehicular IPv6 Communications.
> IEEE Intelligent Transportation Systems Magazine, vol. 6, no. 4, pp. 17-34,
> doi: 10.1109/MITS.2013.2274876, 2014.
>
>  =>   After reviewing your paper, we will also consider to include this
paper in the next revision.

> In this work we present an architecture that complements the ETSI/ISO
> communication architecture by using IPv6 (IETF) technologies.
>
 => It seems like this work will be able to broaden the vehicular network
architecture along with IEEE WAVE Standards.

>
> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but we
> have also tested the possibility of also sending ETSI *CAM/DENM* messages
> over this platform by using UDP. This approach could be interesting for the
> IETF ITS group. I am not completely sure about the place to add this
> contribution, but in this case I doubt about the need to create a new
> section, given that I am not sure if there are many other works in this
> line.
>
> Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in
> Vehicular Communications. Transportation Research Part C:
>  => After reviewing the above paper, we will consider to include this
paper to the next revision.

> you find in my previous suggestions.

 =>  Through the review of all of your papers, I will ask you further text
if needed.

       Thanks.

       Best Regards,
       Paul

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 12 Jul 2016 08:18:03 +0200

Dear Alexandre,

According to the information we have of our tests, these are the values you request:

- The size of the UDP packet finally created is 36 bytes (UDP header+ UDP payload). This is quite far from the theoretical 1500 bytes usually taken as MTU, so we did not experience fragmentation. Ir our case, the CAM messages created were quite simple for testing purposes. The fields considered are detailed in the paper.

- The source MAC address of the final frames was the MAC of the MR or the AR. Hence, yes, it is a privacy weakness, but this paper was not focused on security.

- The destination MAC used we think it was the one used for IPv6 multicasting, so 33:33… (we are searching for the dump files)

Regards,

-- 
José Santa Lozano
Dept. Ingeniería de la Información y las Comunicaciones
Facultad de Informática
Universidad de Murcia
30100 Murcia, Spain
Telf: +34-868-888771 / +34-868-884455
Fax: +34-868-884151
Web: http://ants.inf.um.es/~josesanta <http://ants.inf.um.es/~josesanta>

> El 11 jul 2016, a las 14:21, Alexandre Petrescu <[email-masked]> escribió:
> 
> Hello José,
> 
>> http://dx.doi.org/10.1016/j.trc.2014.05.006 <http://dx.doi.org/10.1016/j.trc.2014.05.006>, 2014.
>> 
> Do you happen to have a packet dump available for this operation? (ideally in monitor mode).  See more packet dumps in 802.11-OCB context at http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files <http://www.itsforge.net/index.php/forum/cv-dsrc-message-parser/44-test-files>
> 
> What is the maximum size of a UDP packet thus sent?  (other reports mention a max for CAM message of 102 bytes; others 300 bytes; they all fit within 802.11-OCB definition of max MTU 1500 bytes, but I want to make sure; also do you know at what size will 802.11OCB start to fragment - this can be seen in the wireshark monitor mode, 802.11 Data header, Flags "More Fragments"?)
> 
> What is the src MAC address used?  Because there may be a privacy worry of listeners along roads identifying which car uses which Organizational Unique Identifier.
> 
> What is the dst MAC address used?  The MAC address 33-33-0-0-0-0-1 is expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and "01-80-C2-".  There is a need to decide which one of these to use, or maybe request a new one.
> 
> This will help writing a single "IPv6-over-802.11-OCB" document which is the first goal in this group.
> 
> Alex
> 
>> 
>> Regards,
>> 
>> +34-868-884151 Web: http://ants.inf.um.es/~josesanta <http://ants.inf.um.es/~josesanta>
>> 
>> 
>> 
>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> escribió:
>>> 
>> [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 12 Jul 2016 19:06:19 +0200

Dick,

Probably our system did not pass any interop test, but this was not the purpose of the research. Our intention was to implement and test a proof of concept, and we are not pursuing a final system to be put in the market. I simply noticed that this work could be of interest for the group. Having said that, if this imply that I should rephrase the usage of “ETSI CAM/DENM”, I do not have any problem. We used packets that could not be totally compliant.

Regards,

> El 12 jul 2016, a las 9:14, Dick Roy <[email-masked]> escribió:
> 
> Jose,
>  
> Perhaps you could explain in a bit more detail what you mean by “also sending ETSI CAM/DENM messages over this platform by using UDP”. As per previous postings, this is a very involved procedure if you intend it to be compliant to “current thinking”, and I am pretty sure you are not thinking along those lines.
>  
> RR
>  
> From: José Santa Lozano [mailto:[email-masked]] 
> Sent: Friday, July 8, 2016 1:55 AM
> To: Mr. Jaehoon Paul Jeong
> Cc: [email-masked]
> Subject: Re: [its] A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems"
>  
> Dear Paul,
> 
> José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio F. Skarmeta. Experimental Evaluation of CAM and DENM Messaging Services in Vehicular Communications. Transportation Research Part C: Emerging Technologies, vol. 2014, pp. 98-120, doi: http://dx.doi.org/10.1016/j.trc.2014.05.006 <http://dx.doi.org/10.1016/j.trc.2014.05.006>, 2014.
>  
> El 7 jul 2016, a las 19:33, Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]>> escribió:
> 
> Hi all,
>    https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00 <https://tools.ietf.org/html/draft-jeong-its-vehicular-networking-survey-00>
> 
> - Abstract

---

From: José Santa Lozano <[email-masked]>
Date: Tue, 12 Jul 2016 19:26:20 +0200

Please, see in line.

> El 12 jul 2016, a las 8:52, Dick Roy <[email-masked]> escribió:
> 
>  
>  
> From: José Santa Lozano [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: Monday, July 11, 2016 11:18 PM
> To: Alexandre Petrescu
> Cc: [email-masked] <mailto:[email-masked]>
> Subject: Re: [its] CAM as UDP payload of IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems")
>  
> Dear Alexandre,
>  
> - The size of the UDP packet finally created is 36 bytes (UDP header+ UDP payload). 
> [RR>] FTR … UDP is a transport layer protocol, and PDUs exchanged at that layer are called segments; packets are layer 3 PDUs.

> This is quite far from the theoretical 1500 bytes usually taken as MTU,
> [RR>] For information, 1500 is the “frame” limit two layers lower (at the ethernet MAC / data link layer).  

Thanks for this clarification. I though that talking in those terms was clear for most of the participants.

> so we did not experience fragmentation. Ir our case, the CAM messages created were quite simple for testing purposes. The fields considered are detailed in the paper.
> [RR>] CAM messages generated at the CAM application will be on the order of 400 bytes (this FPDU size includes the certificates).  I have no idea how your UDP segments including a representative CAM FPDU can be 36 bytes unless they are empty. 

As said, we tried to stick to the standard available at that moment, only including the minimum information, but this was not essential for our research, as I said in my previous mail. Sorry for any inconvenience that this could cause. The packets created are detailed in the paper.

> [RR>] I do not understand.  First, I think you mean transmitter address since it’s an 802.11 frame without a source address (ToDS and FromDS are both 0); it has only a transmitter and receiver address and a BSSID (addr 3 field) which currently in 5.9GHz operations in the US and Europe is constrained to be the wildcard (i.e. broadcast) BSSID of all 1’s.  Secondly, ARs are in RSUs not OBUs, and hence do NOT tx CAMs. 

You are right, our AR did not send CAMs, but for us both units comply the same platform and they were configured to send DENM in other tests. In this case the same MAC addressing procedure is used.

> Third, the 5.9GHz CIs will be tumbling MAC addresses (and all other identifiers simultaneously but that’s another story) to preserve anonymity (at some level).  We have gone to great lengths to eliminate such weakness in the standards and products that have been and are being built.  
>  
> [RR>] I don’t understand this.  IP addresses are layer 3 addresses; MAC addresses are layer 2 addresses. What is meant by “a layer 2 address used for layer 3 addressing”?  

When a layer-3 packet is sent to a multicast address, the stack must decide the MAC address to include in the layer-2 frame.

> Either way, sending CAMs and DENMs to any MAC address other than the layer 2 broadcast address of all 1’s is not likely to be compliant going forward (check SAE J2945/1 for example). 

That is something we did not deal with.

> Hope this is helpful.
>> El 11 jul 2016, a las 14:21, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> escribió:
>>  
>> Hello José,
>> 
>>> https://trac.tools.ietf.org/wg/its/trac/ <https://trac.tools.ietf.org/wg/its/trac/>
>>> 
>>> [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]> Personal Homepage:
>>> http://iotlab.skku.edu/people-jaehoon-jeong.php <http://iotlab.skku.edu/people-jaehoon-jeong.php>

---

From: Bokor László <[email-masked]>
Date: Wed, 13 Jul 2016 17:49:51 +0200

Dear Paul and All,

besides Jose's suggestions I also would recommend an extension to section
7. (Mobility Management in Vehicular Networks). Solutions to efficiently
support mobility in HetVNets seems to be important in the future,
integrated solutions are required. Here you can find the preliminary
results of our activities in this topic:

N. Varga, L. Bokor and H. J. Fischer, "LDM-based dynamic network discovery
and selection for IPv6 mobility management optimization in C-ITS
environments," Models and Technologies for Intelligent Transportation
Systems (MT-ITS), 2015 International Conference on, Budapest, 2015, pp.
483-490.
doi: 10.1109/MTITS.2015.7223298
URL:
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7223298&isnumber=7223230

Best regards,
Laszlo

--
László BOKOR, Ph.D.
Budapest University of Technology and Economics (BME)
Department of Networked Systems and Services (HIT)
Tel: +36-1-463-2048, Fax: +36-1-463-3263
web: http://medianets.hu/staff/laszlo-bokor/

2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong <[email-masked]>:

>> 4- In all of our papers we transmit IPv6 packets over IEEE 802.11p, but
>> we have also tested the possibility of also sending ETSI *CAM/DENM*
>> messages over this platform by using UDP. This approach could be
>> interesting for the IETF ITS group. I am not completely sure about the
>> place to add this contribution, but in this case I doubt about the need to
>> create a new section, given that I am not sure if there are many other
>> works in this line.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 18:33:19 +0200

Le 12/07/2016 à 08:27, Dick Roy a écrit :
> A few points you might want to consider:
>
> 1) In Europe, currently, and I stress currently, CAM's and DENM's
> are messages that some (C2C-CC in particular) are "adamant" be sent
> using the ETSI TC ITS GeoNetworking protocol.  So when you say
> "sending CAMs", those of us involved in writing the standards and
> building the products can only interpret that as meaning using the
> "accepted protocols" in the various regions.  There are so many
> reasons NOT to use GeoNotworking, however, if you insist on doing so,
> you need to revisit the numbers you quote below. The minimum header
> is 80 bytes of mostly redundant information, and that does not
> INCLUDE any useful information, like the portion of the rather
> bloated CAM payload that actually does have useful information or
> the certificates that will be mandatory!
>
> 2) To make matters needlessly more complicated, there is a standard
> (and I believe some have actually tried to implement it:^)) that does
> describe a means for "tunneling" GeoNotworking frames in IPv6 frames.
> Talk about header bloat!!!!! And all this in a medium with a channel
> configuration that is hopelessly and needlessly outdated and
> ill-suited to the task (congestion reigns!). It's a really long sad
> story ...
>
> 3) The 1500 byte limit is a MIB parameter that can be changed (and
> should be for communications that do not involve ethernet, since only
> in ethernet is there the magical 1500 byte MTU (a leftover from the
> last century I might add).  Also, as long as the MAX_PDUsize
> parameter is less than 2309 bytes, there will be no fragmentation at
> the MAC.

Do y ou mean that the MTU size on 802.11 is 2309 bytes?

In order to put that as such in an IPv6-over-802.11-OCB document there 
would need to be a reference; lacking that I will cite this :-)

> The current thinking is that in 5.9GHz operation all packets should
> be kept below that limit to avoid fragmentation.  I happen to think
> such blanket restrictions are not good ideas.  There are scenarios in
> which fragmentation is useful, acceptable, and easily doable. I do
> not believe there are any restrictions in the latest version of
> 802.11 that prohibit fragmentation at the MAC in 5.9GHz operations in
> Europe or the US ... NPDUs/MSDUs of length > 2308 bytes can and will

2308 or 2309?

> be fragmented at the MAC unless you have a non-compliant device.

If MAC fragments and reassembles then IP does not need to, and as such 
we should write it down (in other cases it's IP who needs to fragment 
and MAC no).

Also, I would like to add that there may be some cases like RSUs sending 
lists of POIs, or to some extent multiply signed messages, that may 
require > 1500 MTU.

> 4) CAMs and DENMs are generally exchanged between MR's, not an MR and
> an AR.

I dont see why not.  ETSI CAMs are very popular so I would expect even 
my watch to send one if it so wanted to advertise its position or a very 
precise time.

The problem is that you dont have at IETF one unique message to 
advertise presence, position or time in a periodic manner.

At IETF there are periodic broadcast messages like ICMP Router 
Advertisements, OSPF Link State Advertisements, SAP Session 
Advertisements; but none of these advertises position or time.

There are messages giving the time in NTP but these are request-response 
nature, not advertisements like beacons.

There are RFCs that describe how to encode geographical coordinates, but 
they dont say which protocol to use to advertise them.

> AR's are located in RSUs, not OBUs by definition.  CAMs and
> DENMs are messages generally exchanged between OBUs.  (There are god
> reasons to also receive them at RSUs and share that information ...
> welcome to the world of Cooperative ITS! ... but that's somewhat off
> track for this discussion.) Referring to 1), the current thinking is
> that BTP will be used above GN since that's the ONLY choice (though
> you could say there is a UDP-like protocol ... just it doesn't have a
> checksum which means it's the simplest possible transport layer
> protocol that does NOTHING other than pass packets to the identified
> higher layer entity:^))
>
> 5) As for MAC addresses, generally (meaning almost always!) for CAMs
> and DENMs, the dst addr is the broadcast address (all 1's).  The tx
> addr is the MAC address of the transmitter which will likely be drawn
> from a local addr space and changed every "so often" to preserve
> anonymity.  The BSSID (addr 3 in the 802.11 data frame header) will
> be all 1's if you care. As far as choosing some other MAC address as
> mentioned below:
>
> " What is the dst MAC address used?  The MAC address 33-33-0-0-0-0-1
> is expected, but also are ff-ff-ff-ff-ff-ff, and "01-00-5E-" and
>  maybe request a new one."
>
> I think there is some confusion that needs to be cleared up, and
> perhaps this paragraph achieves that goal.

So I think there is choice to be made between all 1s and 33-33-0-0-0-0-1.

> 6) Finally, as a general point to be remembered, IEEE 802.11
> operation in 5.9GHz OCB involves NO (layer 2) networking at all. The
> phrase "IEEE 802.11 OCB network(s)" is an oxymoron, whether the
> intent is to imply layer 2 OR (especially) layer 3 networking!  When
> it is used in documents, I have no idea what it means.  IMO, the
> phrase should be replaced with something more meaningful wherever it
> occurs.

I will make it into a question, because we need a good title for this 
document.

Alex

>
> Hopefully, this is useful.
>
> Cheers,
>
> RR
>
>
>
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: Monday, July 11, 2016
> 5:22 AM To: [email-masked] Subject: Re: [its] CAM as UDP payload of
> IPv6 over 802.11p (was: A New I-D on "Survey on IP-based Vehicular
> Networking for Intelligent Transportation Systems")
>
> Hello José,
>
> Thank you for the message.  There are many aspects you said that need
> to be considered.  Let me reply to just one now.
>
> Le 08/07/2016 à 10:55, José Santa Lozano a écrit : [...]
>> 4- In all of our papers we transmit IPv6 packets over IEEE
>> 802.11p, but we have also tested the possibility of also sending
>> ETSI *CAM/DENM* messages over this platform by using UDP. This
>> approach could be interesting for the IETF ITS group. I am not
>> completely sure about the place to add this contribution, but in
>> this case I doubt about the need to create a new section, given
>> that I am not sure if there are many other works in this line.
>>
>> José Santa, Fernando Pereñiguez-García, Antonio Moragón, Antonio
>> F. Skarmeta. Experimental Evaluation of CAM and DENM Messaging
>> Services in Vehicular Communications. Transportation Research Part
>> C: Emerging Technologies, vol. 2014, pp. 98-120, doi:
> best example mentioning CAM being transported as payload of IPv6 over
> 802.11p.  Literally it says:
>> CAM and DENM messages are exchanged between MR [MobileRouter] and
>> AR [AccessRouter] using UDP datagrams that are destined to the
>> well-known IPv6 multicast address referring to all the nodes
>> present on the local network segment (ff02::1). The use of this
>> transport is based on the fact that there is no sense in using a
> It is a highly desirable behaviour exposing application-layer
> working together with a network layer over a link layer.
>
> (ideally in monitor mode).  See more packet dumps in 802.11-OCB
> context at
>  mention a max for CAM message of 102 bytes; others 300 bytes; they
> all fit within 802.11-OCB definition of max MTU 1500 bytes, but I
> want to make sure; also do you know at what size will 802.11OCB start
> to fragment - this can be seen in the wireshark monitor mode, 802.11
> Data header, Flags "More Fragments"?)
>
> What is the src MAC address used?  Because there may be a privacy
> worry of listeners along roads identifying which car uses which
> Organizational Unique Identifier.
>
- Abstract
>>> autoconfiguration, routing, handover, and mobility management.
>>> This document summarizes and analyzes the previous research
>>> activities that use IPv4 or IPv6 for vehicular networking"
>>>
>>> In this draft, we show the survey on IP-based Vehicular
>>> Networking for Intelligent Transportation Systems. This draft
>>> will be a good foundation to figure out the state-of-the-art
>>> "ITS General Problem Area" that is one of work items in our its
>>> group: https://trac.tools.ietf.org/wg/its/trac/
>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 19 Jul 2016 19:14:05 +0200

> I will make it into a question, because we need a good title for this 

A quick google search on definition of Network and the second definition is:

2. a group or system of interconnected people or things

802.11-ocb is a network.

I can argue that it is even a OSI Layer 2 service, but don't have the 
energy after today's meetings.

Trying to call it anything other than 'network' will just add confusion 
and I would really be interested to see one word that describes it better.

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 19 Jul 2016 12:19:49 -0700

> we should write it down (in other cases it's IP who needs to

??

IPv6 is not supposed to fragment like IPv4.  Rather, a probe is
supposed to reveal the smallest MTU along a path; then datagrams are
trimmed to size at origin

If the internetwork is probed every time -- likely in presence of
volatile routing -- I can see an awful lot of interactivity-eating
thrashing going on.  Since low latency seems to be an important
desideratum, something needs to be worked out.

Does anyone have any on-the-ground experience?

---

From: Thierry Ernst - Bis <[email-masked]>
Date: Wed, 20 Jul 2016 19:56:56 +0200

Dear all,

I would just like to take the opportunity of this discussion to « advertise » ISO 17429, a draft standard (for which I’m serving as editor), currently under ballot and developed jointly within ISO TC204 WG18 & CEN TC 278 WG16. ISO 17429 specifies a generic mechanism allowing the transmission of any ITS-related message over any type of access technology (11p and other WiFi variant, cellular, satellite, infra-red, …) using any type of networking protocol (IPv6, or V2X-dedicated protocols as specified within IEEE or ETSI) for any type of ITS exchange (point-to-point or broadcast, vehicle to other vehicles, infrastructure, Internet, nomadic devices, etc) over any type of underlying protocol stack (IPv6 or non-IP). 

This standard paves the way for more interoperability between ITS silos as currently deployed (eCall, V2X safety, connectivity, fleet management, ..).  Once adopted, this standard could be used in compliancy with both US V2X non-IP standards (IEEE), European V2X non-IP standards (ETSI) and general-purpose IETF TCP-IP based standards. 

Many forthcoming ITS use cases will require the use of IPv6 and this is why we (the ISO TC204 community which I’m serving as liaison to toward the IETF) need the IETF to work on IPv6 related issues as the ones being discussed on the IETF list so that IPv6 could be properly used for vehicular communications. 

Unfortunately I’m not able to be physically present in Berlin, but Alexandru Petrescu - acting as IETF liaison toward ISO TC204 will relay any input, discussion and material between both organizations. So, if you have a message to pass, I’m sure Alexandru will be happy to listen to any request you may have. 

Regards,
Thierry Ernst.
YoGoKo & ISO TC204 liaison toward the IETF.

> Le 12 juil. 2016 à 19:06, José Santa Lozano <[email-masked]> a écrit :
> 
> Dick,
> 
>> El 12 jul 2016, a las 9:14, Dick Roy <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Jose,
>>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 21 Jul 2016 01:00:04 +0200

Hi Bokor,
This looks an interesting paper.
I will read this paper and discuss whether to include it with my coauthors.

Thanks.

Best Regards,
Paul

On Wed, Jul 13, 2016 at 5:49 PM, Bokor László <[email-masked]> wrote:

>>  =>  Through the review of all of your papers, I will ask you further
>> text if needed.
>>
>>        Thanks.
>>
>>        Best Regards,
>>        Paul
>>
>>
>>> Regards,
>>>
>>> --
>>> José Santa Lozano

---

From: Bokor László <[email-masked]>
Date: Thu, 21 Jul 2016 13:26:38 +0200

Hi Paul,

thank you. If you have any questions or comments, please don't hesitate to
mail me.

Best regards,
Laszlo

2016-07-21 1:00 GMT+02:00 Mr. Jaehoon Paul Jeong <[email-masked]>:

>> N. Varga, L. Bokor and H. J. Fischer, "LDM-based dynamic network
>> discovery and selection for IPv6 mobility management optimization in C-ITS
>> 2016-07-11 18:48 GMT+02:00 Mr. Jaehoon Paul Jeong <[email-masked]
>> >:
>>
>>> Hi Jose,
>>>  => We authors are planning to add more papers (including your paper)
>>> for security and privacy to the next revision.
>>>
>>>>
>>>  => It seems like this work will be able to broaden the vehicular
>>> network architecture along with IEEE WAVE Standards.
>>>
>>>>