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  |
|
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  |
|
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 #1824542 is a reply to message #1824541] |
Fri, 17 April 2020 08:07 |
|
Hi Gabor,
thanks for your review, it is much appreciated.
Gábor Szalai wrote on Fri, 17 April 2020 09:36As 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.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 04:55:24 GMT 2024
Powered by FUDForum. Page generated in 0.01932 seconds |
] 
Search
Help
Register
Login
Home
