24 Apr
2017
24 Apr
'17
9:15 p.m.
Hi Andreas,
Thanks for your detailed information. They are very helpful!
On 4/22/17, 7:36 AM, "Andreas Schultz" <aschultz(a)tpip.net> wrote:
No. lw-tunnel use netlink attributes to store the
tunnel destination. The
netlink attributes can then be attached to a routing entry. That way it
becomes possible to have tunneling information in the routing table or
pass them into the kernel module from another source, e.g. from a OpenFlow
rules in OpenVSwitch.
This would make it possible to use OF rules to put traffic into GTP tunnels.
The existing genl interface could be added to iproute2 with or without
libgtpnl and is completely independent from the lwt support.
My understanding is that the netlink attributes used by lw-tunnel are natually
supported by iproute2 or Openvswitch, e.g.
ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0
The genl interface is customized for libgtpnl. Having one of two interfaces should
be enough to manage GTP tunnels from userspace. Is there a reason that we prefer
one over the other? Specifically, why do we use genl instead of netlink, and why use
a customized userspace library instead of iproute2?
The last time I tried to push those change upstream
they got rejected
by Pablo. One of the reasons is that I had to change the API ever so
slightly. Still, this violates the rule that kernel API can not be
changed, never, ever.
Is the “kernel API” referring to the genl interface?
The other thing is that is has become clear that
Pablo's idea of how
the GTP implementation should work in terms of APIs is completely
different from my ideas. Pablo's (and other kernel developers) seem
to prefer a implementation where static tunnels can be configured.
That mean the kernel own's the GTP tunnels and the interfaces and
operates completely independent from the user space control interface.
The user space entity could then be restarted without loosing the
tunnels.
I believe that the user space entity should own the sockets and
tunnels and that a termination of the user space control instance
should automatically remove all existing GTP tunnels (having GTP
forwarding without the control context is IMHO not a valid state
for any of the 3GPP GTP gateways).
In my opinion, both design looks reasonable as long as one entity owns all the state,
either it’s the kernel or a user space control process. However, I believe that GTP
is just one of the many tunneling protocols supported by Linux. Thus, it should have
consistent behaviors comparing with other tunnels. Seems for most tunnels, the kernel
maintains the state and expose management interface to userspace programs; control
processes are mostly stateless.
Nevertheless, “a termination of the user space control instance should automatically
remove all existing GTP tunnels” is a valid point. I think this could be implemented in
the
exiting procedure or destructor of the control process, while carefully taking care of the
process crashing case.
Regards
Andreas
Regards,
Jiannan