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/.
Pablo Neira Ayuso pablo at netfilter.orgOn Tue, Mar 14, 2017 at 01:28:25PM +0100, Andreas Schultz wrote: > ----- On Mar 14, 2017, at 12:43 PM, pablo pablo at netfilter.org wrote: [...] > A GTP entity serves multiple local IP endpoints, It manages outgoing tunnels > by the local APN/VRF, source IP, destination IP and remote tunnel id, incoming > tunnels are managed by the local destination IP, local tunnel id and VRF/APN. > > Therefor a PDP context needs the following attributes: > > * local source/destination IP (and port - but that's for different series) > * remote destination IP > * local and remote TEID > * VRF/APN [...] > I'm not sure if this pseudo GTP entity root device fits well with > other networking concepts. And more over, I can't really see the need > for such an construct. Some sort of top-level structure that wraps all these objects is needed, and that can be a new VRF object itself. You can add a netlink interface to add/dump/delete VRFs, this VRF database would be *global* to the GSN. At VRF creation, you attach the socket and the GTP device. You can share sockets between VRFs. PDP context objects would be added to the corresponding VRF *not to the socket*, but actually this will result in inserting this PDP context into the socket hashtable and the GTP device hashtable. We need to introduce a default VRF that is assumed to always exist, and that userspace cannot remove, so things don't break backward. If no VRF is specified, then we attach things to this default VRF. Actually, look at this from a different angle: the existing driver is just supporting *one single VRF* at this moment so we just have to represent this explicitly. Breaking existing API is a no-go. This explicit VRF concept would also allow us to dump PDP contexts that belong to a given VRF, by simply indicating the VRF unique id. Jamal already requested that we extend iproute2 to have command to inspect the gtp driver we cannot escape this, we should allow standalone tools to inspect the gtp datapath as we do with other existing tunnel drivers, no matter what daemon in userspace implements the control plane. [...] > I think that the user space control instance should own the tunnels and > only use the kernel facility to manage them. When the user space instance > goes away, so should the tunnels. This doesn't allow daemon hot restart for whatever administrative reason without affecting existing traffic. The kernel owns the datapath indeed, that include tunnels. > From that perspective, I want to keep the kernel facilities to the > absolute needed minimum. If some simple abstraction that we can insert makes this whole thing more maintainable, then it makes sense to consider it. This is all about not exposing the internal layout of the representation you use for a very specific reason: The more you expose internal details to userspace, the more problems we'll have to extend things later on in the future. And don't try to be smart and say: "Hey, I already know every usecase we will have in the future" because that is not true.