Subject: Re: [ipwave] Summary of 6man review of draft-ietf-ipwave-ipv6-over-80211ocb-22

From: Russ Housley <[email-masked]>
Date: Fri, 1 Jun 2018 07:52:56 -0400

> On Jun 1, 2018, at 12:51 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi all,
>   I had requested the 6man WG to review draft-ietf-ipwave-ipv6-over-80211ocb-22 after the WGLC here as per the ipwave charter. The request resulted in several comments and some of them are major and, in my opinion, require significant changes to the draft to address. 
> 
> The thread starts with this email
> 
> https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html <https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html>
> 
> and the further emails in this thread can be found at
> 
> https://mailarchive.ietf.org/arch/browse/ipv6/?q=80211ocb-22 <https://mailarchive.ietf.org/arch/browse/ipv6/?q=80211ocb-22>
> 
> One of the proposals that emerged there was that this document can be discussed at the 6man WG meeting in Montreal to identify potential ways forward. I’d rather not wait till the Montreal meeting if we can make progress on this document before then. I think we should start discussing the issues raised on the ipwave mailing list and come up with a plan to address them. In my mind the major issues that were raised are
> 
> * Lack of specification of how ND will work on these links (the underlying assumption of the commenters is that standard ND would not work)
> * Multicast support (or the lack of it) and how it will be addressed - e.g. should we specify an NBMA oriented ND procedure?
> * Not enough basic background information about 802.11OCB
> 
> Comments and potential solutions are greatly appreciated.

I know that there are several people that have done implementations.  Please share with us what you did for neighbor discovery (ND).  My hope is that there is something that we can add to the document based on your implementation experience.

It is obvious that ND techniques that would be acceptable while the vehicle is parked in a garage would not be acceptable while the same vehicle is a speed on the highway.  The later is clearly the hard case.

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Jun 2018 17:52:26 +0200

Hi,

Sorry for late reply.

Le 01/06/2018 à 13:52, Russ Housley a écrit :
> 
>> On Jun 1, 2018, at 12:51 AM, Suresh Krishnan 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>   I had requested the 6man WG to review 
>> draft-ietf-ipwave-ipv6-over-80211ocb-22 after the WGLC here as per the 
>> ipwave charter. The request resulted in several comments and some of 
>> them are major and, in my opinion, require significant changes to the 
>> draft to address.
>>
>> https://www.ietf.org/mail-archive/web/ipv6/current/msg30065.html
>>
>> https://mailarchive.ietf.org/arch/browse/ipv6/?q=80211ocb-22
>> *
>> *
>> One of the proposals that emerged there was that this document can be 
>> discussed at the 6man WG meeting in Montreal to identify potential 
>> ways forward. I’d rather not wait till the Montreal meeting if we can 
>> make progress on this document before then. I think we should start 
>> discussing the issues raised on the ipwave mailing list and come up 
>> with a plan to address them. In my mind the major issues that were 
>> raised are
>>
>> * Lack of specification of how ND will work on these links (the 
>> underlying assumption of the commenters is that standard ND would not 
>> work)
>> * Multicast support (or the lack of it) and how it will be addressed - 
>> e.g. should we specify an NBMA oriented ND procedure?
> I know that there are several people that have done implementations. 
>   Please share with us what you did for neighbor discovery (ND).  My 
> hope is that there is something that we can add to the document based on 
> your implementation experience.

The ND protocol is very important in vehicle communications.  In 
particular, in the zone outside of the car, the ND protocol is very 
important (also inside the car).

In the zone outside the car, there are two typical ways to employ ND.

In the first way, the ND protocol is used without much modifications. 
This is when the car connects to a fixed road-side unit.  The RSU sends 
a Router Advertisement, and NAs, to the car.  And the car configures an 
address on its egress interface, and connects to the Internet.  This has 
been trialled in the lab, and now there are a few RSUs deployed in that 
way - on some roads.

In this 'first way', there are very simple tweaks necessary in the ND 
space.  One tweak that is absolutely necessary is that the RSU 
absolutely must send some presence messages for the cars to detect its 
presence.  One must remember the RSUs on 802.11 OCB do not send any IEEE 
'Beacon' which are otherwise very normal in 802.11 not-OCB.  Absent 
these Beacons it is hard for a vehicle to detect the presence of RSUs 
and decide to connect to it.

The interoperability problem in this 'first way' is to decide _which_ 
message the RSU to send out periodically, and the car to check _that_ 
particular message.  There are very many candidates, contrary to 
expectations, and deployments do many distinct incompatible things. 
Examples noticed in practice are: TSA (Time Stamp Advertisemt), IPv6 
Router Advertisement, 802.21 message, Europe's CAM message, and probably 
more.  Each one of these is different, yet one little cheap car can not 
implement _all_ of them in order to sense presence.

The IPv4 problem of this 'first way' is that in IPv4 there are not many 
platforms that implement IPv4 Router Advertisement.  And if we want to 
do IPv4 deployment similar to IPv6 deployment then we would have 
preferred to use IPv6 RAs (that all routers do) _and_ IPv4 RA.

These are the ND problems with this 'first way'.

In one of my implementations we have solved it like this: use IPv6 RA to 
detect presence in IPv6 (not CAM, not 802.21, not TSA) and use IPv4 RA 
to detect presence in IPv4.

In another implementation on which I work right now the European CAM 
message is mandatory for some reason.  It may be possible that we will 
use this CAM message (instead of IPv6 RA) to detect presence, but I am 
not very sure at this time.

Another necessary aspect for ND in this 'first way' is that the RSU 
sends RAs very frequently.  This is a parameter to set in a 
configuration file.  This parameter _is_ specified in RFCs, there is 
nothing new.  One RA must be sent every 10ms or so.  Calculations have 
been performed to evaluate that number, starting from emission power 
parameter, and vehicle speed.  When put in practice, these parameters 
(10ms) do prove successful.

In the 'second way', the ND is used also outside the car, but this time 
it is used to connect from one vehicle to another nearby.

In this 'second way', one vehicle sends an IPv6 Router Advertisement to 
another vehicle on same channel and nearby.

Here, the ND protocol needs much more tweaks than simple parameters. 
One important new thing is a prefix that must be put in this RA.  Of 
course, RAs already has prefixes, but the prefix I am writing about is 
different: it is not the prefix on the link, but the prefix(es) present 
inside the car.  So one car informs another car about its own inner 
prefixes.

Among those two 'ways', I believe we only need to document the 'first' 
way in the IPv6-over-OCB.  The doubt I have is that we already did 
document it, and then we removed it somehow.  I can try again soon.

> It is obvious that ND techniques that would be acceptable while the 
> vehicle is parked in a garage would not be acceptable while the same 
> vehicle is a speed on the highway.  The later is clearly the hard case.

I fully agree.  In this distinction (fast vs slow) I think we can leave 
out the 'fast' way from the IPv6-over-OCB.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Jun 2018 18:11:50 +0200

There was some question about broadcast vs unicast vs multicast in 
vehicular communications.

Typically, extremely many people call 'vehicular communications' to be 
the cars that 'broadcast' messages around, containing positions, and 
make local decisions about who is where, such as to avoid accidents.

Despite the ultra-importance of accident avoiding, this view is still a 
too narrow view of 'vehicular communications'.  Where is the Internet in 
this 'vehicular communications'?

There are other views of vehicular communications which are encompassing 
much more than just accident avoidance.

One of these views is the following:

The use of IP unicast in vehicle-to-vehicle communications is the following:

               top-antenna                       top-antenna
                   |		                    |		
   front-antenna--CAR1--rear-atenna  front-antenna--CAR2--rear-atenna

In this view, CARs 'broadcast' CAMs on a particular 5.9GHz channel on 
their top antennas, but use IP between rear-antenna and front-antenna. 
They are on distinct interfaces than top antenna, different 5.9GHz 
channel than from top antenna, but on same 5.9GHz channel between front 
of a car and rear of another car.  Channel mgmt is performed by somebody.

So one has an IP subnet between CAR1 rear-antenna and CAR2 front-antenna.

On this IP subnet the ND protocol works.

The way it works is like on an Ethernet in the Enterprise network: use 
the IPv6 'unicast' and 'multicast' concept of IPv6 MLD.

The ND problem in this space is the exchange of prefixes.  We have 
solved it with software and a draft.

The 'multicast' problem in this space is the following: a PC inside a 
car needs to send a convoy 'maintenance' message to each other similar 
PC in each other car in a convoy (not to the Routers in the cars, but to 
the PCs in charge of automated driving).  Is MLD sufficient to establish 
the multicast tree?  Which multicast address to use?  This is my 
'multicast' problem right now.

To summarize: yes, we do use unicast messages between cars in convoy: we 
ping unicast, ssh between PCs of distinct cars in convoy, etc.  We do 
not like 'broadcast' even though 1000 people request for CAM.  We can 
send these CAMs, they are 'broadcast', we do not like it, we can write a 
howto make CAMs with cheap open source, and it all ends there until 
someone at ETSI agrees CAM is wrong.  I am afraid that will take so much 
time to change people's minds...

For multicast: I need to understand whether IP multicast in a 
multi-subnet IP network formed in a convoy can be implemented simply 
with MLD or some other protocol is needed, and whether that is open source.

Alex

---

From: Tony Li <[email-masked]>
Date: Sun, 10 Jun 2018 15:34:49 -0700

Alex,

> The IPv4 problem of this 'first way' is that in IPv4 there are not many platforms that implement IPv4 Router Advertisement.  And if we want to do IPv4 deployment similar to IPv6 deployment then we would have preferred to use IPv6 RAs (that all routers do) _and_ IPv4 RA.

For IPv4 router based deployments this is a solved problem through the use of DHCP. The client requests an address and is provided one, along with router information. There is no good reason not to use this mechanism in any router based OCB subnet.

For ad-hoc OCB subnets, it makes sense to use IPv4 link local addressing. There are already well-documented mechanisms for this that ensure that nodes avoid address collisions. I know of no reason not to make use of this.

I also see no reason not to use the analogous mechanisms in IPv6.

> 
> Here, the ND protocol needs much more tweaks than simple parameters. One important new thing is a prefix that must be put in this RA.  Of course, RAs already has prefixes, but the prefix I am writing about is different: it is not the prefix on the link, but the prefix(es) present inside the car.  So one car informs another car about its own inner prefixes.

Using ND as a routing protocol has been discussed many times. It is not advisable. It does not prefix collisions nor multi-hop scenarios.  If we want a routing protocol, we should use a routing protocol.

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 10 Jun 2018 15:43:04 -0700

> Despite the ultra-importance of accident avoiding, this view is still a too narrow view of 'vehicular communications'.  Where is the Internet in this 'vehicular communications’?

The Internet is largely irrelevant. If we simply enable IP connectivity, then we have an infrastructure to enable any application. Internet access falls out for free.

> In this view, CARs 'broadcast' CAMs on a particular 5.9GHz channel on their top antennas, but use IP between rear-antenna and front-antenna. They are on distinct interfaces than top antenna, different 5.9GHz channel than from top antenna, but on same 5.9GHz channel between front of a car and rear of another car.  Channel mgmt is performed by somebody.

I’ll avoid the question of who the ‘somebody’ is and point out that you’ve then posited the creation of four separate IP subnets here: 
1) top-antennas
2) front of Car1
3) between the two Cars
4) rear of Car2

> The way it works is like on an Ethernet in the Enterprise network: use the IPv6 'unicast' and 'multicast' concept of IPv6 MLD.
> 
> The ND problem in this space is the exchange of prefixes.  We have solved it with software and a draft.
> 
> The 'multicast' problem in this space is the following: a PC inside a car needs to send a convoy 'maintenance' message to each other similar PC in each other car in a convoy (not to the Routers in the cars, but to the PCs in charge of automated driving).  Is MLD sufficient to establish the multicast tree?  Which multicast address to use?  This is my 'multicast' problem right now.

Given that you’ve chosen to model this as four separate subnets, the obvious approach would be to employ existing multicast routing protocols. This then becomes a trivial topology.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jun 2018 11:45:50 +0200

Le 11/06/2018 à 00:34, Tony Li a écrit :
> 
> Alex,
> 
> 
>> The IPv4 problem of this 'first way' is that in IPv4 there are not
>> many platforms that implement IPv4 Router Advertisement.  And if we
>> want to do IPv4 deployment similar to IPv6 deployment then we would
>> have preferred to use IPv6 RAs (that all routers do) _and_ IPv4
>> RA.
> 
> 
> For IPv4 router based deployments this is a solved problem through
> the use of DHCP. The client requests an address and is provided one,
> along with router information. There is no good reason not to use
> this mechanism in any router based OCB subnet.

Whereas I agree in IPv4 the use of the DHCP protocol is very useful, it 
can not be used to detect the presence of RSUs.

The IP-OBU can not keep sending DHCP requests and wait for replies from 
candidate RSUs.  Because the wait time is the time that people will feel 
as too long and will complain about it.

Another reason why it can not be this way in IPv4 (DHCP) is the 
following: in IPv6 the logic is reversed: the IP-OBU listens to RAs 
(without requesting them).  The RAs are 'beaconed' very frequently by 
the RSU.  It is hard to do things in one way in IPv6 and in another way 
in IPv4.  It is too much work for the programmer, and hard to debug by 
other programmers.

The way to do it in IPv4 that is very much like IPv6 is to use IPv4 
Router Advertisements RFC1256.

As a reminder, the goal of these messages sent by RSU is for the IP-OBU 
to be able to measure their signal strength, and less the read the 
values specified by the RFC.  The useful value is found in the Radiotap 
Header (signal strength).  These messages just have to be 'beaconed' 
periodically by the RSU.

> For ad-hoc OCB subnets, it makes sense to use IPv4 link local
> addressing. There are already well-documented mechanisms for this
> that ensure that nodes avoid address collisions. I know of no reason
> not to make use of this.

I agree: use IPv4 link-local addresses in IPv4 in OCB mode.

The IPv6 ND question is the following: is it appropriate for IP-OBU to 
rely on IPv6 RAs to sense the presence of IP-RSU?  My answer is yes.

It is more appropriate than beaconing TSAs, 802.21 messages or IEEE WSAs.

If it were me I would put that in the draft IPv6-over-OCB right away.

> I also see no reason not to use the analogous mechanisms in IPv6.

I agree, we should use link-local addresses for communication between 
IP-OBU and IP-RSU, at least until it gets GUAs or ULAs.

For IP-OBU to IP-OBU communications also the link local addresses can be 
used.  But in that case (IP-OBU to IP-OBU) it is not clear if ever will 
there be a GUA or ULA set of interfaces.  PRobably these ULAs or GUAs 
are not needed there.

>> Here, the ND protocol needs much more tweaks than simple
>> parameters. One important new thing is a prefix that must be put in
>> this RA.  Of course, RAs already has prefixes, but the prefix I am
>> writing about is different: it is not the prefix on the link, but
>> the prefix(es) present inside the car.  So one car informs another
>> car about its own inner prefixes.
> 
> 
> Using ND as a routing protocol has been discussed many times. It is
> not advisable.

Well, I strongly recommend it.

> It does not prefix collisions nor multi-hop scenarios.

I think no routing protocol identifies prefix collisions.

I think ND exchanging prefixes works very well in scenarios of convoy of 
3 vehicles.  Generally speaking, in linear structures like trains of 
wagons, or convoys: ND exchanging prefixes works very well.

> If we want a routing protocol, we should use a routing protocol.

I dont think we want a routing protocol in a convoy.

Routing protocols implement very complicated algorithms like Yen, 
Bellman-Ford, or others, which are not really necessary in such stable 
structures such as convoys.  It's too big of a hammer if I can say so.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jun 2018 12:48:58 +0200

Le 11/06/2018 à 00:43, Tony Li a écrit :
> 
> 
>> Despite the ultra-importance of accident avoiding, this view is still 
>> a too narrow view of 'vehicular communications'.  Where is the 
>> Internet in this 'vehicular communications’?
> 
> 
> The Internet is largely irrelevant. If we simply enable IP connectivity, 
> then we have an infrastructure to enable any application. Internet 
> access falls out for free.

I agree.

But if there is no default router then there is no Internet.  No CAM 
messaging provides a default route.  A Router Advertisement does.

>>                     top-antenna                                       
>> top-antenna
>> channel than from top antenna, but on same 5.9GHz channel between 
>> front of a car and rear of another car.  Channel mgmt is performed by 
>> somebody.
> 
> 
> I’ll avoid the question of who the ‘somebody’ is

In the first demonstration that somebody is a human, probably me.  I 
will allocate initially fixed channels between the three cars.  When 
that works, we will look at about how to automate it.  I dont think it 
is difficult and it will be a pleasure to come up with an algorithm.

> and point out that 
> you’ve then posited the creation of four separate IP subnets here:
> 1) top-antennas

The top-antenna may make an IP subnet with the RSU, yes.

> 2) front of Car1

front of Car1 and rear of Car2 form a single IP subnet.

> 3) between the two Cars

The IP subnet between two Cars is the same IP subnet as the IP subnet of 
the rear antenna of Car1 and the IP subnet of Car2.

There is just one IP subnet between Car1 and Car2, and the members of 
that subnet are the front-antenna of Car1 and rear-antenna of Car2.

>> PC in each other car in a convoy (not to the Routers in the cars, but 
>> to the PCs in charge of automated driving).  Is MLD sufficient to 
>> establish the multicast tree?  Which multicast address to use?  This 
>> is my 'multicast' problem right now.
> 
> Given that you’ve chosen to model this as four separate subnets, the 
> obvious approach would be to employ existing multicast routing 
> protocols. This then becomes a trivial topology.

I would very much like if only one protocol were used.

I dont want _one_ protocol for IP routing, another one for multicast 
routing, and probably 3rd protocol for link-scoped multicast.

I want that protocol to be cheap open source, proven to work in this 
topology, to download and play with it right away.

PC1 must send a maintenance IP message to PC2 and PC3, as an IP 
multicast message.  I dont want PC1 to send a distinct message to each 
other PCx in the convoy because it wont scale.

           s4          s5
   IP-OBU1 --- IP-OBU2 --- IP-OBU3    sx: distinct IP subnet x
     |           |           |        PCx: Autonomous Drv. PC w/ RTMaps
     |s1         |s2         |s3      s4, s5: IPv6 over OCB, in LL mode
     |           |           |        s1, s2, s3: Ethernet
    PC1         PC2         PC3

Alex

---

From: [email-masked]
Date: Mon, 11 Jun 2018 09:03:33 -0400

Alex,

> The IP-OBU can not keep sending DHCP requests and wait for replies from candidate RSUs.  Because the wait time is the time that people will feel as too long and will complain about it.

Ok, that presumes some requirements that haven’t been shared.

Normally DHCP response is quite rapid. On a Wi-Fi network, it’s less than the association time.

> Another reason why it can not be this way in IPv4 (DHCP) is the following: in IPv6 the logic is reversed: the IP-OBU listens to RAs (without requesting them).  The RAs are 'beaconed' very frequently by the RSU.  It is hard to do things in one way in IPv6 and in another way in IPv4.  It is too much work for the programmer, and hard to debug by other programmers.

This sounds like a personal problem.  :-)

There is always DHCPv6, if you choose. 

> The way to do it in IPv4 that is very much like IPv6 is to use IPv4 Router Advertisements RFC1256.

Yes. That was widely ignored.  We can invoke it, but it will not be the obvious approach for most folks.

> The IPv6 ND question is the following: is it appropriate for IP-OBU to rely on IPv6 RAs to sense the presence of IP-RSU?  My answer is yes.

I concur. That’s what they’re there for.

> For IP-OBU to IP-OBU communications also the link local addresses can be used.  But in that case (IP-OBU to IP-OBU) it is not clear if ever will there be a GUA or ULA set of interfaces.  PRobably these ULAs or GUAs are not needed there.

I concur.  Link local alone is sufficient for ad-hoc ephemeral connections, which is what we should be assuming for the V2V case.

> 
> I think ND exchanging prefixes works very well in scenarios of convoy of 3 vehicles.  Generally speaking, in linear structures like trains of wagons, or convoys: ND exchanging prefixes works very well.

Yes, but how does it scale?  How does it deal with loops in the topology? Topological changes?

> I dont think we want a routing protocol in a convoy.

Each to their own.  I see no good alternative.

> Routing protocols implement very complicated algorithms like Yen, Bellman-Ford, or others, which are not really necessary in such stable structures such as convoys.  It's too big of a hammer if I can say so.

Actually, the better ones implement an even more complicated algorithm called Dijkstra. ;-)

If there’s one thing I know about wireless, it’s never to say ‘stable’. ;-)

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 11 Jun 2018 23:24:55 -0400

Alex,

> The IP subnet between two Cars is the same IP subnet as the IP subnet of the rear antenna of Car1 and the IP subnet of Car2.
> 
> There is just one IP subnet between Car1 and Car2, and the members of that subnet are the front-antenna of Car1 and rear-antenna of Car2.

Ok, if you choose to model things this way, then you effectively have only two subnets, one for the top antenna and one for everything else. This CAN work for some things, but will necessarily be problematic in some ways. As the convoy grows, the front antenna on the front car may not have connectivity to the back antenna on the rear car.  As such, your subnet may not be fully connected, and that’s going to cause some confusion and failures. 

I don’t recommend this approach. If it were up to me, I would make each pairing a separate subnet and enable routing.

> 
> I dont want _one_ protocol for IP routing, another one for multicast routing, and probably 3rd protocol for link-scoped multicast.

Well, sorry, the IP protocol stack decouples multicast and unicast routing. We made that call along time ago, as having their development coupled would have slowed both of them.

> 
> PC1 must send a maintenance IP message to PC2 and PC3, as an IP multicast message.  I dont want PC1 to send a distinct message to each other PCx in the convoy because it wont scale.
> 
>          s4          s5

That can work as long as the convoy is all in range of a single radio and then it is just a link layer multicast.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jun 2018 09:24:26 +0200

Le 11/06/2018 à 15:03, [email-masked] a écrit :
> Alex,
> 
>> The IP-OBU can not keep sending DHCP requests and wait for replies
>> from candidate RSUs.  Because the wait time is the time that people
>> will feel as too long and will complain about it.
> 
> 

However we express DHCP to be fast, it will always be at least the 
double of the speed of using beacons.

DHCP is a request-response, whereas the 'beaconing' mechanisms are just 
the advertisement message (just the response, if you wish).

>> (without requesting them).  The RAs are 'beaconed' very frequently
>> by the RSU.  It is hard to do things in one way in IPv6 and in
>> another way in IPv4.  It is too much work for the programmer, and
>> hard to debug by other programmers.
> 
> 

YEs, it is a personal problem.

Maybe other person has tried IPv4 and IPv6 on OCB IP-RSU.

> the obvious approach for most folks.

The issue is to choose _which_ message to use as a beacon on IP-RSU.

Should we use an IP message as 'beacon', or something else?

If we said that IPv4 RAs and IPv6 RAs are good candidates then IP is the 
right messagge for 'beacon'.

But if we say that IPv6 RA is fine, whereas in IPv4 RA is not 
appropriate and DHCP is more appropriate, then the other non-IP 
candidates will look more attractive (WSA, TSA, 802.21) because they 
will always be faster than DHCP.

>> The IPv6 ND question is the following: is it appropriate for IP-OBU
>> to rely on IPv6 RAs to sense the presence of IP-RSU?  My answer is
>> yes.
> 
> 
>> For IP-OBU to IP-OBU communications also the link local addresses
>> can be used.  But in that case (IP-OBU to IP-OBU) it is not clear
>> if ever will there be a GUA or ULA set of interfaces.  PRobably
>> these ULAs or GUAs are not needed there.
> 
> 
> I concur.  Link local alone is sufficient for ad-hoc ephemeral
> connections, which is what we should be assuming for the V2V case.
> 
>> 
>> I think ND exchanging prefixes works very well in scenarios of
>> convoy of 3 vehicles.  Generally speaking, in linear structures
>> like trains of wagons, or convoys: ND exchanging prefixes works
>> very well.
> 
> 
> Yes, but how does it scale?

Yes.  However long the convoy is the route propagation will scale.  The 
speed of propagation is something like n(n-1)/2 if I remember correctly.

It scales better than repeating messages at link-layer.

But of course it depends of what one considers by 'scaling' - which factors.

> How does it deal with loops in the
> topology?

On one hand, there are no loops in a convoy: it's linear.

Second, there are some proposals to try to answer to that question.  An 
implementer reserved two bits in the 'R' field of an RA and thought 
(without writing it down) to use these fields to solve such a loop if it 
appeared. draft-pfister-moving-net-autoconf-00

> Topological changes?

I hope topological changes dont appear.  I hope once formed the convoy 
stays that way for a long time.

Convoy demonstrators strive for arbitrary position of vehicle in convoy, 
but in practice they do use lots of manual configurations and dedicated 
positions.

In the future this may become more dynamic.

>> Bellman-Ford, or others, which are not really necessary in such
>> stable structures such as convoys.  It's too big of a hammer if I
>> can say so.
> 
> 

I tend to agree, yet there is much stability in very many wireless 
deployments like WiFi access points at conference.

A convoy is maintained stable by RTMaps programs that exchange IP 
datagrams.  If the convoy de-stabilizes somehow then there are many 
other problems than just IP routing or wireless.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jun 2018 09:29:36 +0200

Le 12/06/2018 à 05:24, Tony Li a écrit :
>> The IP subnet between two Cars is the same IP subnet as the IP
>> subnet of the rear antenna of Car1 and the IP subnet of Car2.
>> 
>> There is just one IP subnet between Car1 and Car2, and the members
>> of that subnet are the front-antenna of Car1 and rear-antenna of
>> Car2.
> 
> 
> Ok, if you choose to model things this way, then you effectively have
> only two subnets, one for the top antenna and one for everything
> else.

No.  There is one subnet for the top antenna and its RSU, one subnet for 
rear antenna and one subnet for front antenna.

> This CAN work for some things, but will necessarily be
> problematic in some ways. As the convoy grows, the front antenna on
> the front car may not have connectivity to the back antenna on the
> rear car.  As such, your subnet may not be fully connected, and
> that’s going to cause some confusion and failures.

I agree with the problem you describe, but note that this is not what I 
meant.

What I meant is this: one subnet for top antenna with RSU, one subnet in 
front of car and one subnet in rear of car.

With this schema I think it is not problematic.

> 
> I don’t recommend this approach. If it were up to me, I would make
> each pairing a separate subnet and enable routing.

YEs, this is what we try to do.

> 
>> 
>> I dont want _one_ protocol for IP routing, another one for
>> multicast routing, and probably 3rd protocol for link-scoped
>> multicast.
> 
> 
> Well, sorry, the IP protocol stack decouples multicast and unicast
> routing. We made that call along time ago, as having their
> development coupled would have slowed both of them.
> 
>> 
>> multicast message.  I dont want PC1 to send a distinct message to
>> each other PCx in the convoy because it wont scale.
>> 
>> s4          s5 IP-OBU1 --- IP-OBU2 --- IP-OBU3    sx: distinct IP
>> subnet x |           |           |        PCx: Autonomous Drv. PC
>> w/ RTMaps |s1         |s2         |s3      s4, s5: IPv6 over OCB,
>> in LL mode |           |           |        s1, s2, s3: Ethernet 
>> PC1         PC2         PC3
> 
> 
> That can work as long as the convoy is all in range of a single radio
> and then it is just a link layer multicast.

 >    |           |           |        s1, s2, s3: Ethernet

In this schema there is an IP subnet in front of the car (s4) and 
another IP subnet in the rear of the car (s5).

IP routing is enabled.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jun 2018 09:34:56 +0200

[...]

> Well, sorry, the IP protocol stack decouples multicast and unicast routing. We made that call along time ago, as having their development coupled would have slowed both of them.

I can agree.

But I need somebody who has tried IPv6 multicast in an IP structure like 
this.  PC1 must send an IP datagram to an IP multicast address to which 
PC2 and PC3 are part of.

 >     |           |           |        s1, s2, s3: Ethernet

If this does not work with IPv6 multicast between laptops on a table 
then it will not work in a convoy either.

Alex

---

From: [email-masked]
Date: Tue, 12 Jun 2018 08:09:54 -0400

> But I need somebody who has tried IPv6 multicast in an IP structure like this.  PC1 must send an IP datagram to an IP multicast address to which PC2 and PC3 are part of.
> 
>>          s4          s5
> If this does not work with IPv6 multicast between laptops on a table then it will not work in a convoy either.

This should work with IP multicast right out of the box, but you will need both unicast and mcast protocols, plus mcast listeners.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jun 2018 15:54:44 +0200

> This should work with IP multicast right out of the box, but you will need both unicast and mcast protocols, plus mcast listeners.

I need to know how it works.  I have the ability to some trial here, but 
if somebody already did, and has some howto, then I would be very much 
grateful.

Alex

---

From: [email-masked]
Date: Tue, 12 Jun 2018 14:25:23 -0400

> I need to know how it works.  I have the ability to some trial here, but if somebody already did, and has some howto, then I would be very much grateful.

This is unicast and mcast 101.  Almost any PD stack that has OSPF and an mcast protocol will work.  DVMRP is sufficient, if wildly antiquated.  PIM-DM would also work. There are of course more
sophisticated variants of PIM if you can find them.

Your app will need to generate IGMP Joins.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jun 2018 10:26:40 +0200

> This is unicast and mcast 101.

Unicast is fixed: we use prefix exchanges in router advertisements.

> Almost any PD stack that has OSPF and
> an mcast protocol will work. DVMRP is sufficient, if wildly antiquated.

'PD' is?

DVMRP has some open source implementation available on linux?

> PIM-DM would also work. There are of course more

PIM-DM is available as open source for linux?

> Your app will need to generate IGMP Joins.

In IPv6: the app on PC would need to do MLD REPORT to join a newly 
defined group, that we would define.

I suppose there is a socket interface to generate that MLD?

I suppose the mcast group would be with scope global.  I would need to 
define that mcast group, and give it a name.

Alex

---

From: [email-masked]
Date: Wed, 13 Jun 2018 09:15:24 -0400

Alex,

> Unicast is fixed: we use prefix exchanges in router advertisements.

That doesn’t sound quite right.  Aren’t your RAs local to the subnet? How does the information propagate to the rest of the convoy?

>> an mcast protocol will work. DVMRP is sufficient, if wildly antiquated.

Public Domain, but I should have said Open Source

> PIM-DM is available as open source for linux?

https://frrouting.org/ <https://frrouting.org/>
http://git.savannah.gnu.org/cgit/quagga.git <http://git.savannah.gnu.org/cgit/quagga.git>

> In IPv6: the app on PC would need to do MLD REPORT to join a newly defined group, that we would define.
> 

Not AFAIK, you should use a raw socket.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jun 2018 16:08:05 +0200

Le 13/06/2018 à 15:15, [email-masked] a écrit :
> That doesn’t sound quite right.  Aren’t your RAs local to the subnet? 

Yes.

> How does the information propagate to the rest of the convoy?

I agree with you, it does not propagate.  We have to find a way to 
propagate it.

At this time, an IP-OBU receives an RA from another IP-OBU.  That RA 
contains the prefix of the Ethernet of one car.  A receiving IP-OBU 
inserts an entry in the routing table containing that prefix and the 
sender's LL address.

This works ok between two cars.

In order to work with three cars, we must find a way for one IP-OBU to 
read its own routing table, realize that a new entry is present and then 
send it on an interface that is not the interface on which that prefix 
arrived.

That would propagate it.

If there is another means to propagate, then I am listening.

> https://frrouting.org/
> http://git.savannah.gnu.org/cgit/quagga.git

Thanks!

Alex

---

From: [email-masked]
Date: Wed, 13 Jun 2018 10:12:48 -0400

> On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> n order to work with three cars, we must find a way for one IP-OBU to read its own routing table, realize that a new entry is present and then send it on an interface that is not the interface on which that prefix arrived.
> 
> That would propagate it.
> 

That would be called a routing protocol.

I would suggest OSPF (or, if you’re very brave, IS-IS).

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jun 2018 16:26:45 +0200

Le 13/06/2018 à 16:12, [email-masked] a écrit :
> 
> 
>> On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>> n order to work with three cars, we must find a way for one IP-OBU to 
>> read its own routing table, realize that a new entry is present and 
>> then send it on an interface that is not the interface on which that 
>> prefix arrived.
>>
>> That would propagate it.
>>

Routing protocols like OSPF and IS-IS were designed and implemented with 
Ethernet in mind, not OCB.

Some times they dont react, some times they over-react.

Some times they are not available on embedded platforms, or significant 
work must be produced to port them.

But yes, I take the suggestion of OSPF.

Somebody else also suggested Babel and we tried it with 3 computers and 
it worked.  But we did not try multicast.  I guess Babel, which seems to 
be adapted ok for WiFi, does support multicast.

Maybe there is nothing new to standardise here.

Unless of course we can see that a convoy is something different than a 
LAN, or than a smartphone.

I will take that quagga and see how it does multicast.  If it does not 
work maybe we will try to fix it.

Maybe we will be fed up and try to start something from scratch.

Or maybe it will work right away.

Alex

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 13 Jun 2018 16:22:48 +0000

(below)

From: its [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: woensdag 13 juni 2018 16:13
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] multicast in convoy

On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

That would propagate it.

:-]

I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track protocol that works even if your IP-OBU has only one radio interface. Implementation here:

https://github.com/OLSR/OONF

That’s for unicast. MANET multicast is a tad more complicated. SMF (RFC 6621, Experimental) is a first attempt. (Implementation here: https://www.nrl.navy.mil/itd/ncs/products/smf )

Ronald

Tony

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Jun 2018 23:21:52 -0400

Hi Alex/Tony,
  Doing a routing based solution for this is certainly possible, but the fact remains that the IPv6 over 802.11 OCB document is still missing a description of how ND works on such links. It would be great if people with implementations chime in here as Russ said, so that we can progress this draft and then open up for further improvements.

Thanks
Suresh

> On Jun 12, 2018, at 3:29 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> No.  There is one subnet for the top antenna and its RSU, one subnet for rear antenna and one subnet for front antenna.
> 
> I agree with the problem you describe, but note that this is not what I meant.
> 
> What I meant is this: one subnet for top antenna with RSU, one subnet in front of car and one subnet in rear of car.
> 
>>> in LL mode |           |           |        s1, s2, s3: Ethernet PC1         PC2         PC3
> In this schema there is an IP subnet in front of the car (s4) and another IP subnet in the rear of the car (s5).
> 
> IP routing is enabled.
> 
> Alex
>> Tony
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>

---

From: [email-masked]
Date: Wed, 13 Jun 2018 22:14:04 -0700

> On Jun 13, 2018, at 8:21 PM, Suresh Krishnan <[email-masked]> wrote:
> 

I’ll say it again: ND over OCB should operate just as over Ethernet or Wi-Fi. Folks are, of course, welcome to make local timing configuration changes, but that doesn’t affect anything fundamental.

T

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 10:51:47 +0200

> This is unicast and mcast 101.

I can agree with yout hat this is unicast one-on-one: something very 
straightforward and easy to to, that can be done just by two people.

However, for multicat it is not that 101.

Multicast 101 as deployed in the Internet is like a tree.  In the root 
and in the middle the bandwidths are very high, and at the edges the 
bandwidht is much lower.  E.g. 10Gbp/s in the root and 10Mbit/s at the edge.

However, in the case of convoy of cars, that ratio is reversed.  We have 
1Gbit/s in the car Ethernet (the edge, s1, s2, s3 in figure) but we only 
have 54Mbit/s in the OCB network between cars (the core, s4, s5).

Will multicast of Internet - PIM-DM quagga and MLD linux - work ok in 
convoy?

Alex

   Almost any PD stack that has OSPF and an mcast protocol will work. 
DVMRP is sufficient, if wildly antiquated.  PIM-DM would also work. 
There are of course more

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 10:56:35 +0200

Le 14/06/2018 à 07:14, [email-masked] a écrit :
> 
> 
>> On Jun 13, 2018, at 8:21 PM, Suresh Krishnan 
>> Doing a routing based solution for this is certainly possible, but the 
>> fact remains that the IPv6 over 802.11 OCB document is still missing a 
>> description of how ND works on such links. It would be great if people 
>> with implementations chime in here as Russ said, so that we can 
>> progress this draft and then open up for further improvements.
> 
> 
> I’ll say it again: ND over OCB should operate just as over Ethernet or 
> Wi-Fi. Folks are, of course, welcome to make local timing configuration 
> changes, but that doesn’t affect anything fundamental.

I fully agree.

There is however some messages from Lorenzo on 6MAN WG that I need to 
better understand.

He claims, by logical thinking, visibly not by trying ND on OCB, that ND 
does not work on OCB if certain conditions are unsatisfied.

That is something we could address.

_If_ we address it, then maybe it will persuade google Android team to 
modify their WiFi drivers in Android to run OCB.  If so, that would be a 
huge advantage in VRU (Virtual Road Users) demonstrators.  They just 
carry the smartphones they usually carry anyways, turn 'detectability' 
on, and thus avoid accidents.

If you know the recent self-driving car accidents between car and VRU 
then you realize how important that can be.

Until now, all the VRU demonstrators must equip people with some 
specific OCB device (not Android) before any demo can be performed.

Alex

---

From: François Simon <[email-masked]>
Date: Fri, 15 Jun 2018 08:13:51 -0400

“That would be called a routing protocol.”   Below is a sample of the list of routing protocols that are developed for ad-hoc networks (e.g.; V2V).  Extracted from “MOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK -  OVERVIEW” - 2007

“Routing Protocols for Ad-hoc Networks

Here is where the ‘madness’ starts.  Since ad-hoc is such a complex network infrastructure and also has a high profile in the Government (i.e. DoD) as well as in the commercial sectors, every standard, research, and academia organizations have their own idea and solution for a wireless ad-hoc network routing protocol (in some cases application dependent).  There are no less than 130 routing protocols, and growing, related to ad-hoc wireless network.  The routing protocol is the key factor for Ad Hoc Network. It decides directly the performance of the whole network:

Table-Driven Routing Protocols

*	Destination-Sequenced Distance-Vector (DSDV) 
*	Clusterhead Gateway Switch Routing (CGSR) 
*	The Wireless Routing Protocol (WRP) 
*	More.... 

Source-Initiated On-Demand Routing Protocols 

*	Ad Hoc On-Demand Distance Vector Routing (AODV) 
*	Dynamic Source Routing (DSR) 
*	Temporally Ordered Routing Algorithm (TORA) 
*	Associativity-Based Routing (ABR)
*	More…….

Location Information Based (Based) Routing Protocols 

*	Location Aid Routing  (LAR) 
*	Grid's Location Service Routing (GLS) 
*	More....”

Fygs

From: François Simon <[email-masked]> 
Sent: Thursday, June 14, 2018 9:28 PM
To: [email-masked]
Subject: FW: [ipwave] multicast in convoy

From: its <[email-masked] <mailto:[email-masked]> > On Behalf Of Velt, R. (Ronald) in 't
Sent: Wednesday, June 13, 2018 12:23 PM
To: [email-masked] <mailto:[email-masked]> ; Alexandre Petrescu <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] multicast in convoy

(below)

From: its [mailto:[email-masked]] On Behalf Of [email-masked] <mailto:[email-masked]> 
Sent: woensdag 13 juni 2018 16:13
To: Alexandre Petrescu <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] multicast in convoy

On Jun 13, 2018, at 10:08 AM, Alexandre Petrescu < <mailto:[email-masked]> [email-masked]> wrote:

That would propagate it.

 

:-]

Ronald

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 14:16:42 +0200

Thank you for the list.  It is very useful.

However: none of them is maintained, or available as cheap open source, 
like quagga suite is (OSPF, BGP, etc).

Alex

Le 15/06/2018 à 14:13, François Simon a écrit :
> /“That would be called a routing protocol.” / Below is a sample of the 
> list of routing protocols that are developed for ad-hoc networks (e.g.; 
> V2V).  Extracted from “*MOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK - 
>   OVERVIEW” - 2007***
> 
> 
>         “*/Routing Protocols for Ad-hoc Networks/*
> 
> //
> 
> /Here is where the ‘madness’ starts.  Since ad-hoc is such a complex 
> network infrastructure and also has a high profile in the Government 
> (i.e. DoD) as well as in the commercial sectors, every standard, 
> research, and academia organizations have their own idea and solution 
> for a wireless ad-hoc network routing protocol (in some cases 
> application dependent).  There are no less than 130 routing protocols, 
> and growing, related to ad-hoc wireless network.  The routing protocol 
> is the key factor for Ad Hoc Network. It decides directly the 
> performance of the whole network:/
> 
> //
> 
> */Table-Driven Routing Protocols/*
> 
>   * /Destination-Sequenced Distance-Vector (DSDV) /
>   * /Clusterhead Gateway Switch Routing (CGSR) /
>   * /The Wireless Routing Protocol (WRP) /
>   * /More.... /
> 
> */Source-Initiated On-Demand Routing Protocols /*
> 
>   * /Ad Hoc On-Demand Distance Vector Routing (AODV) /
>   * /Dynamic Source Routing (DSR) /
>   * /Temporally Ordered Routing Algorithm (TORA) /
>   * /Associativity-Based Routing (ABR)/
>   * /More……./
> 
> //
> 
> */Location Information Based (Based) Routing Protocols /*
> 
>   * /Location Aid Routing  (LAR) /
>   * /Grid's Location Service Routing (GLS) /
>   * /More....”/
> 
> Fygs
> 
> *From:* François Simon <[email-masked]>
> *Sent:* Thursday, June 14, 2018 9:28 PM
> *To:* [email-masked]
> *Subject:* FW: [ipwave] multicast in convoy
> 
> *From:* its <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Velt, R. (Ronald) in 't
> *Sent:* Wednesday, June 13, 2018 12:23 PM
> *To:* [email-masked] <mailto:[email-masked]>; Alexandre Petrescu 
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [ipwave] multicast in convoy
> 
> (below)
> 
> *From:* its [mailto:[email-masked]] *On Behalf Of [email-masked] 
> <mailto:[email-masked]>
> *Sent:* woensdag 13 juni 2018 16:13
> *To:* Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [ipwave] multicast in convoy
> 
>     n order to work with three cars, we must find a way for one IP-OBU
>     to read its own routing table, realize that a new entry is present
>     and then send it on an interface that is not the interface on which
>     that prefix arrived.
> 
>     That would propagate it.
> 
> I would suggest OLSRv2 (RFC 7181 and friends), an IETF Standards Track 
> protocol that works even if your IP-OBU has only one radio interface. 
> Implementation here:
> 
> That’s for unicast. MANET multicast is a tad more complicated. SMF (RFC 
> 6621, Experimental) is a first attempt. (Implementation here: 
> https://www.nrl.navy.mil/itd/ncs/products/smf )
> 
> Ronald
> 
> Tony
> 
> This message may contain information that is not intended for you. If 
> you are not the addressee or if this message was sent to you by mistake, 
> you are requested to inform the sender and delete the message. TNO 
> accepts no liability for the content of this e-mail, for the manner in 
> which you use it and for damage of any kind resulting from the risks 
> inherent to the electronic transmission of messages.
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Jun 2018 10:08:03 -0400

Also, ROLL's RPL (RFC6550), and it's multicast *MPL* RFC7731.
The trickle mechanism is often not associated with fast changing networks.

To the extent that changes can be detected, trickle can operate as fast
(or as slow, reducing power or bandwidth used) as needed.

OLSRv2 is also an interesting choice.

RFC6550 has an assymmetric (public key) authentication/authorization mode
that has not been interesting in LLNs, but may be very much appropriate
in this situation.

François Simon <[email-masked]> wrote:
    > “That would be called a routing protocol.” Below is a sample of the list of
    > routing protocols that are developed for ad-hoc networks (e.g.; V2V).
    > Extracted from “MOBILE AD-HOC DIGITAL COMMUNICATIONS NETWORK - OVERVIEW” -
    > 2007

    > Here is where the ‘madness’ starts. Since ad-hoc is such a complex network
    > infrastructure and also has a high profile in the Government (i.e. DoD) as
    > well as in the commercial sectors, every standard, research, and academia
    > organizations have their own idea and solution for a wireless ad-hoc network
    > routing protocol (in some cases application dependent). There are no less
    > than 130 routing protocols, and growing, related to ad-hoc wireless network.
    > The routing protocol is the key factor for Ad Hoc Network. It decides
    > directly the performance of the whole network:

    > From: its <[email-masked]> On Behalf Of Velt, R. (Ronald) in 't
    > To: [email-masked]; Alexandre Petrescu <[email-masked]>
    > Cc: [email-masked]

    > <[email-masked]> wrote:

    > That’s for unicast. MANET multicast is a tad more complicated. SMF (RFC 6621,
    > Experimental) is a first attempt. (Implementation here:

    > This message may contain information that is not intended for you. If you are
    > not the addressee or if this message was sent to you by mistake, you are
    > requested to inform the sender and delete the message. TNO accepts no
    > liability for the content of this e-mail, for the manner in which you use it
    > and for damage of any kind resulting from the risks inherent to the
    > electronic transmission of messages.

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 18:39:41 +0200

Le 15/06/2018 à 16:08, Michael Richardson a écrit :
[...]

> ----------------MESSAGE ORGINAL ci-dessous------------------
> 
> 

Are there cheap open source RPL implementations available for i386 (not 
Contiki and friends).

> OLSRv2 is also an interesting choice.

Is there cheap open source implementation available?

> that has not been interesting in LLNs, but may be very much appropriate

The vehicular network for convoy is not an LLN.  It has very strong 
Ethernet links inside each car, and some little variation outside the car.

Alex

>      > That’s for unicast. MANET multicast is a tad more complicated.. SMF (RFC 6621,