Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Alternative to GTP_Tunnel_Daemon: osmo-uecups
Alternative to GTP_Tunnel_Daemon: osmo-uecups [message #1824517] Thu, 16 April 2020 18:16 Go to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

Dear TITAN community,

I've recently been pondering on how to do some half-way scalable testing of the user plane side of P-GW/GGSN. Handling the control plane (GTPv1C/GTPv2C) natively inside TITAN makes a lot of sense, but for the user plane, one often wants to simply run programs such as iperf or whatever other traffic-generating programs out there. Also, user plane testing often involves quite a bit of bandwidth/througput.

I really liked the principle of the titan.Servers.GTP_Tunnel_Daemon. Don't get me wrong, I think it's great that it was released as open source. However, the more I worked with it, the more awkward I found it. It is formally a C++ program, but then it uses almost none of the C++ features. Instead, it manually keeps relatively complex data structures, and the code is (my apologies) an example of extreme spaghetti style. I fould it pretty impossible to add any additional features. Furthermore, I found it unneccessarily complicated to first have hand-written code to go from TTCN3 abstract types to a binary encoding over a unix domain socket, and then again parse those messages by hand-written code inside the daemon.

After implementing a series of 10 or so cleanup patches against GTP_Tunnel_Daemon, I decided to give up and start from scratch based on a different (to me, more clean) architecture:


  • Use the automatic/generated JSON encoding of the abstract TTTCN3 data types for the control protcol between test suite and daemon. This avoids having to write a single line of C++ code on the TITAN side and one can control the daemon from pure TTCN3 code.
  • Use SCTP/IP as transport for the control protocol bteween test suite and daemon. This works in more scenarios such as containerized tests suites. It also allwos to more easily scale out, where a single test suite node/machine can control multiple [remote] user plane instances
  • (allow to) create a separate tun device for every GTP tunnel (PDP context, EPS bearer). This means that if you simulate 10 subscribers, every subscriber gets their own tun device. The existing daemon would have assigned all 10 end-user addresses to the same tun device, making it very hard to run standard software to generate user traffic without manual routing rules or the like.
  • (allow to) put every tun device into a separate Linux kernel network namespace. This guarantees complete network isolation, and it's impossible for traffic to be routed to the wrong tun device / tunnel or the like.


All in all, this allows you to simulate for example 100 LTE subscribers, each with one or multiple bearers, and each of them running an iperf or whatever traffic generating program.

I used Osmocom infrastructure to write the daemon, wich means it has a configurable logging system, and it has a telnet/vty (comnadn line) interface for the user to introspect state and even t manually create / remove tunnels as needed). I called this new system "osmo-uecups" (for "user equipment control/user plane separation), and it can be found at https://git.osmocom.org/osmo-uecups

It's still rather early in its testing (it started to work end-to-end just yesterday). I'm currently working on some initial PGW test suite (to become part of osmo-ttcn3-hacks.git) and will fix any bugs I find in osmo-uecups as I go along.

The only missing feature compared to the original GTP_Tunnel_Daemon (as far as I can tell) is support for IPv6 address/prefix allocation via IPv6 neighbor discovery. I plan to add this at a later point.

Feel free to reach out in case anyone is interested in using this. I'm also equally happy to receive bug reports, code review, contributions or the like.

[Updated on: Thu, 16 April 2020 18:21]

Report message to a moderator

Re: Alternative to GTP_Tunnel_Daemon: osmo-uecups [message #1824536 is a reply to message #1824517] Fri, 17 April 2020 06:07 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Harald,

thank you for sharing; this is a perfect example of software evolution going through stages of imperfection.
I don't want to become defensive, but I'm pretty sure the architectural etc. decisions at the time of conceiving the GTP Daemon
(or any other product for that matter) were or at least seemed sensible and justifiable. (For instance, JSON was not available then,
and SCTP might not have been deemed sufficiently robust and reliable).
As for spaghetti code, yes, we try add our fair share.... :-)

Best regards
Elemer
Re: Alternative to GTP_Tunnel_Daemon: osmo-uecups [message #1824540 is a reply to message #1824517] Fri, 17 April 2020 07:03 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 86
Registered: December 2015
Member
Hi Harald,

I responsible for that spaghetti. :)
I was a quick hack, which created less than a few days to provide GTP tunneling feature. Yes it is code a "little bit messy" and contains some "interesting" stuff.

I'm going to check your solution.
Re: Alternative to GTP_Tunnel_Daemon: osmo-uecups [message #1824541 is a reply to message #1824540] Fri, 17 April 2020 07:36 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 86
Registered: December 2015
Member
As i can see one feature is missing from the osmo-uecups:
The GTP-Daemon is able to handle multiple separate tunnel for one local IP address. The UE can have more GTP tunnel (1 for signaling, 1 for media, 1 for Internet) but one IP address. That is why the outgoing tunnel selection uses the local IP and optionally the remote IP, protocol, local & remote port.

There was a requirement to avoid any possible dependencies. So the GTP Daemon can be deployed and used without any 3pty code (except the libc and c++ compiler)
Re: Alternative to GTP_Tunnel_Daemon: osmo-uecups [message #1824542 is a reply to message #1824541] Fri, 17 April 2020 08:07 Go to previous message
Harald Welte is currently offline Harald WelteFriend
Messages: 128
Registered: July 2017
Location: Berlin, Germany
Senior Member

Hi Gabor,

thanks for your review, it is much appreciated.

Gábor Szalai wrote on Fri, 17 April 2020 09:36
As i can see one feature is missing from the osmo-uecups:
The GTP-Daemon is able to handle multiple separate tunnel for one local IP address. The UE can have more GTP tunnel (1 for signaling, 1 for media, 1 for Internet) but one IP address. That is why the outgoing tunnel selection uses the local IP and optionally the remote IP, protocol, local & remote port.


Ah yes, I forgot to mention that part. The "filters" are on my roadmap for osmo-uecups, but I first wanted to get basic functionality going before looking at other use cases.

Are you interested in the cleanup patches that I did on your GTP daemon befor deciding for an alternative route? I pushed the changes to https://github.com/laf0rge/titan.Servers.GTP_Tunnel_Daemon/commits/master in case you're interested.
Previous Topic:RDF-related encodings in Titan
Next Topic:IPsec over UDP
Goto Forum:
  


Current Time: Wed Jun 16 15:24:51 GMT 2021

Powered by FUDForum. Page generated in 0.01854 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top