This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Andreas Schultz aschultz at tpip.netHi Jiannan, ----- 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: 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