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/.
Jiannan Ouyang ouyangj at fb.comHi Andreas,
Thanks for your detailed information. They are very helpful!
On 4/22/17, 7:36 AM, "Andreas Schultz" <aschultz at 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