Hi Harald and Andreas,
I’m writing to inquiry about the development roadmap of the kernel gtp module. For example, is there any plan to support the following features soon - lightweight tunnel - ipv6
The openair-cn project I’m working on is a user of the kernel gtp module. I’m happy to help improve the kernel gtp support, so it’s good to first ask about the roadmap.
Regards, -Jiannan
Hi Jiannan,
On Thu, Apr 20, 2017 at 09:08:31PM +0000, Jiannan Ouyang wrote:
I’m writing to inquiry about the development roadmap of the kernel gtp module. For example, is there any plan to support the following features soon
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.
The openair-cn project I’m working on is a user of the kernel gtp module. I’m happy to help improve the kernel gtp support, so it’s good to first ask about the roadmap.
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.
Hi Harald,
On 4/20/17, 3:21 PM, "Harald Welte" hwelte@sysmocom.de wrote:
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.
Currently, I’m investigating lightweight tunnel (lwt) support for gtp, a wishlist feature listed on your netdev talk.
Please correct me if I’m wrong: gtp.ko currently uses the genl interface to talk to libgtpnl in userspace for tunnel management. With lwt support, it is possible to manage gtp tunnels with iproute2 commands. In this case, libgtpnl may be deprecated and replaced by iproute2 in the future. Is that correct?
It may make sense to coordinate with Andreas, to make sure there's not too many merge conflicts between his work and yours.
Andreas, would you please share your plan on the gtp kernel module?
Regards, -Jiannan
Hi Jiannan,
----- On Apr 21, 2017, at 9:18 PM, Jiannan Ouyang ouyangj@fb.com wrote:
Hi Harald,
On 4/20/17, 3:21 PM, "Harald Welte" hwelte@sysmocom.de wrote:
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.
Currently, I’m investigating lightweight tunnel (lwt) support for gtp, a wishlist feature listed on your netdev talk.
Please correct me if I’m wrong: gtp.ko currently uses the genl interface to talk to libgtpnl in userspace for tunnel management. With lwt support, it is possible to manage gtp tunnels with iproute2 commands. In this case, libgtpnl may be deprecated and replaced by iproute2 in the future. Is that correct?
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.
It may make sense to coordinate with Andreas, to make sure there's not too many merge conflicts between his work and yours.
Andreas, would you please share your plan on the gtp kernel module?
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
Regards, -Jiannan
Hi Andreas,
Thanks for your detailed information. They are very helpful!
On 4/22/17, 7:36 AM, "Andreas Schultz" aschultz@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
osmocom-net-gprs@lists.osmocom.org
-
Andreas Schultz -
Harald Welte -
Jiannan Ouyang