Cellular Network Infrastructure » Core Network (CN) » OsmoGGSN (former OpenGGSN) » Linux Kernel GTP-U

Hi Harald,

laforge wrote:

However, any non-trivial deployment will likely need support for multiple APNs. An APN is something like a label that identifies an external IP network (can be a private network or public internert).

I would suggest to make the GTP driver APN-aware by extending the existing API. Define a default APN for backwards compatibility, so any new PDP context which does not specify APN will use the default APN. Then, extend the netlink interface to add/delete/update an APN and specify what UDP port is used for such APN and allow to attach one UDP socket to APN to identify the traffic. That is n APNs will be attached to one GTP device.

Currently, AFAICT, the only way to achieve this is to create one UDP socket for each APN, as there's a 1:1 mapping to net-devices. While this may be acceptable in a lab network, this doesn't really match the "production" use cases of many real-world networks. The reason is:

• you usually only have very limited IP addresses that are routed (and advertised) in the IPX/GRX towards other cellular operators
• 3GPP protocols do not support the use of non-standard port numbers, i.e. there can only be one GTP socket per IP address.

From a 3GPP point of view, any GSN can implement any number of APN even on a single IP address.

So what would be needed to support those setups would be to de-couple the enabling of GTP kernel driver on a udp socket from the creating a gtp net-device operations. Having those two separate means you can do something like

• have a single UDP socket and enable the kernel GTP driver
• create any number of gtp net-devices (one for each APN you want to support), possibly use them in separate netns/vrf/... as you want.

I believe one device for n APNs model should fine to cope with these requirements. The GTP device implements tx path, the PDP context database determines what GTP tunnel is selected for the traffic from/to MS.

• each tunnel that is created by userspace (GTP_CMD_NEWPDP) then indicates
  • to which UDP socket it belongs
  • to which net-device it belongs

AFAICT, we already have gtp_tunnel_set_ifidx in libgtpnl, which then puts the GTPA_LINK, attribute into the GTP_CMD_NEWPDP), so no change is required there.

Yes. net-device is already specified by the GTPA_LINK attribute. Only UDP socket (or explicit APN label as I suggest) is missing.

I like the idea of adding the APN concept, it might allow to attach more properties to an APN, instead of using the UDP port/socket to identify this.

AFAICT, we already have gtp_tunnel_set_ifidx in libgtpnl, which then puts the GTPA_LINK, attribute into the GTP_CMD_NEWPDP), so no change is required there.

I just don't see any method by which we could create net-devices independent of a upd socket. It seems both are intertwined in the gtm_dev_newlink/RTM_NEWLINK, which currently supports

• attaching the GTP driver to a pre-existing UDP socket
• creating a new UDP socket for a GTP driver

pablo, am I understanding the code correctly? I'm looking for feedback to make sure we have a common understanding of the current situation, and then possibly as a second step to see how we could change it and what kind of effort that might be.

I think this can be address incrementally, yes.

We have to decide if we would like to make kernel aware of APN or not, or simply use the UDP port to identify the socket. I would prefer this driver is APN aware because this allows to attaching for properties to this object in the future, this allows for accesing such properties via pdp->apn, if that is ever needed.

The other possibility is to make kernel APN agnostic, but then it will be harder to predict how users will be using these APIs, and IMO that might make things more complicated as we move on to extend this driver.