Project

General

Profile

Actions

Feature #6103

open

move from 1:1 relationship of UDP socket and net-device to a N:M relationship

Added by laforge 7 months ago. Updated 5 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
-
Start date:
07/20/2023
Due date:
% Done:

0%

Spec Reference:

Description

As it was only recently discovered, there appears to be a conceptual constraint in the kernel GTP module.

The original module was developed for a very simplistic use case, where there is a 1:1 mapping between UDP sockets and gtp net-devices. This works fine for a GGSN/P-GW that implements one APN.

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).

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.
  • 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.

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.


Related issues

Related to OsmoGGSN (former OpenGGSN) - Bug #6106: OsmoGGSN attempts to use the same GTP-U socket for all APNs with gtpu-mode kernel-gtpNew07/21/2023

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)