> -----Original Message-----
> From: Cliff Spradlin <csprad...@waymo.com>
> Sent: Tuesday, July 31, 2018 3:19
> To: Andriy Kohut <andr...@mellanox.com>
> Cc: linuxptp-devel@lists.sourceforge.net; Mykola Zhuravel
> <myk...@mellanox.com>; Amit Nishry <am...@mellanox.com>
> Subject: Re: [Linuxptp-devel] [PATCH 0/4] RAW UDPv4 transport to support
> PTP on VLAN interfaces
> 
> On Mon, Jul 30, 2018 at 7:45 AM Andriy Kohut <andr...@mellanox.com>
> wrote:
> > The new transport however is intended for a different configuration model
> - VLAN
> > aware bridges with many interfaces and the VLAN devices on top of the
> bridge.
> 
> OK, thanks for elaborating. Let's see if I understand: the problem is
> that you would need to allocate a dedicated IP address for each
> connected interface for UDP-based PTP to work. Is that right?
> 
> It looks like you've spent a lot of time implementing this. Could you
> talk about other possible solutions you considered, and why this one
> is the best?

The main goal of this series it to have one L3 VLAN interface and multiple L2 
ports in the VLAN (we have tested this on the switch with 64 ports).
Port can be a member of different VLANs - we want to have single IP address for 
the VLAN domain,
i.e. PTP packets should be send with the same IP address from all the VLAN 
member ports.

We could use UDP socket on the L3 VLAN interface, but which L2 port a packet 
will egress in that case?
How do we know which L2 ports some packet had ingressed before it came to the 
L3 interface?

Use of Linux VLANs (i.e. eth1.500) and PTP4L UDPv4 transport requires unique IP 
address per interface.

+-----------------+  +-----------------+
|     eth0.500    |  |     eth0.300    |
| (192.168.500.1) |  | (192.168.300.1) |
+-----------------+  +-----------------+
+--------------------------------------+
|                 eth0                 |
+--------------------------------------+


+-----------------+  +-----------------+
|     eth0.500    |  |     eth1.300    |
| (192.168.501.1) |  | (192.168.301.1) |
+-----------------+  +-----------------+
+--------------------------------------+
|                 eth1                 |
+--------------------------------------+


+-----------------+
|     eth2.500    |
| (192.168.502.1) |
+-----------------+
+--------------------------------------+
|                 eth2                 |
+--------------------------------------+

Assigning the same IP address (e.g. to eth1.500 and eth2.500) will break the 
Linux network stack.
So to reach the goal we came up with the new transport.
It uses VLAN aware bridge (as we want to have the _same_ IP address for the 
VLAN domain).

+-----------------+  +-----------------+
|     br0.500     |  |     br0.300     |
| (192.168.500.1) |  | (192.168.300.1) |
+-----------------+  +-----------------+
+--------------------------------------+
|                                      |
|                 br0                  |
|                                      |
+--------------------------------------+
+----------+  +----------+  +----------+
|   eth0   |  |   eth1   |  |   eth2   |
+----------+  +----------+  +----------+


We thought about using Linux namespaces also, but PTP4L does not support them.
Our solution was much easier to implement.

For each VLAN on the interface we open the PACKET socket on the physical 
interface (eth1).
Then BPF filter with modified VLAN is attached to the respective socket.
Because the whole packet should be constructed manually, we have an issue with 
the ARP - delay requests/responses should be unicast in hybrid E2E mode.
For that we save the IP address of the peer (slave or master) on receive and 
use it to send the unicast message.

> Could you use L2 PTP (ptp4l option "network_transport L2") instead so
> that you don't have to assign IP addresses?

It may be an option for small networks.
However, UDP is more versatile as one can use P2P or E2E mode according to 
their needs.
Moreover, there is E2E hybrid mode which significantly reduces multicast load 
in large scale environments.

Thanks,
Andriy
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to