Hi Jiannan, On Thu, Apr 20, 2017 at 09:08:31PM +0000, Jiannan Ouyang wrote: There is no "roadmap" from my point of view, as I (and the sysmocom team) currently have no customer requirements/requests/projects on this. As sysmocom is not a group of volunteers doing things in their spare time but a team of paid engineers, we can primarily work only on those topics where there are customer requirements. For Pablo (another co-author of the module) it is the same. I'm very happy to do project based work around the kernel GTP module, in whatever direction, just as long as it is about generally useful features while within relevant specifications and architecturally fits the code and the Linux kernel stack. For Andreas and his employer Travelping the situation is quite different. As far as I understand they do have customer projects/requirements that drive the development. But I can of course not speak for him, and he can comment on this himself. If you can work on it, by all means do so. I think particularly the IPv6 support (both on the user payload (inner IP) as well as the outer transport IP is much appreciated by everyone. It may make sense to coordinate with Andreas, to make sure there's not too many merge conflicts between his work and yours. -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

Hi Jiannan, ----- On Apr 21, 2017, at 9:18 PM, Jiannan Ouyang ouyangj(a)fb.com 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. I don't have road map. As Harald already mentioned, we are mostly driven by customer demand. The current functionality in the kernel module is sufficient for their current needs. There are a few things that I have added in my spare time like the multi APN support or GTP over IPv6. These things can be found at: https://github.com/RoadRunnr/net-next/commits/master/drivers/net/gtp.c 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. 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). We (Travelping) have not yet reached a final decision on how to deal with the above problems. So, for the moment we are use what is there and concentrate on adding other major missing pieces of functionality that our customer have requested to our OpenSource GGSN/PGW implementation. The current focus there is one the Gx and Gy interfaces with the monitoring, charging, traffic redirection and QoS functions. Other future projects in the 3GPP space include a SGW implementation and eventually a MME (although this might be restricted to the functions required for NB-IoT). All of this is of course is driven by customer demand and might and can be changed when the demand changes. Regards Andreas