20 Apr
2017
20 Apr
'17
11:08 p.m.
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
21 Apr
21 Apr
12:21 a.m.
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.
--
- 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
9:18 p.m.
Hi Harald,
On 4/20/17, 3:21 PM, "Harald Welte" <hwelte(a)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
22 Apr
22 Apr
4:36 p.m.
Hi Jiannan,
----- On Apr 21, 2017, at 9:18 PM, Jiannan Ouyang ouyangj(a)fb.com wrote:
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
Hi Harald,
On 4/20/17, 3:21 PM, "Harald Welte" <hwelte(a)sysmocom.de> 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.
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
24 Apr
24 Apr
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
2569
days inactive
2573
days old
osmocom-net-gprs@lists.osmocom.org
4 comments
3 participants
participants (3)
-
Andreas Schultz -
Harald Welte -
Jiannan Ouyang