kernel GTP-U support dev roadmap
aschultz at tpip.net
Sat Apr 22 14:36:57 UTC 2017
----- On Apr 21, 2017, at 9:18 PM, Jiannan Ouyang ouyangj at fb.com wrote:
> Hi Harald,
> On 4/20/17, 3:21 PM, "Harald Welte" <hwelte at 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:
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
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.
More information about the osmocom-net-gprs