[PATCH net-next v1 1/3] gtp: refactor to support flow-based gtp encap and decap

Pablo Neira Ayuso pablo at netfilter.org
Wed Aug 2 12:52:58 UTC 2017

On Mon, Jul 31, 2017 at 09:21:36AM +0200, Andreas Schultz wrote:
> Hi Jiannan,
> ----- On Jul 13, 2017, at 2:44 AM, Jiannan Ouyang ouyangj at fb.com wrote:
> [...]
> > -static int gtp_rx(struct pdp_ctx *pctx, struct sk_buff *skb,
> > -			unsigned int hdrlen, unsigned int role)
> > +static int gtp_rx(struct gtp_dev *gtp, struct sk_buff *skb,
> > +		  unsigned int hdrlen, struct sock *sk,
> > +		  struct metadata_dst *tun_dst)
> Some time ago, there was an extensive discussion about the relation
> of PDP context and network devices. You are basically reverting one
> of the changes that was made in that context. I think it is wrong to
> couple GTP devices and PDP context the way you do here (there are
> people that disagree, though).
> The GTP network device of one of two structures owning the PDP context,
> the other is the GTP socket. GTP network devices and GTP sockets should
> be strictly separated.
> The GTP network device owns the IP given to the MS, handles mapping
> IP's into GTP tunnels (peer GSN + TEIDs) and hands the resulting GTP 
> packets of to the GTP socket for sending. The GTP socket decaps the GTP
> packet, find the right context and based on information therein passes
> it to the GTP network device.
> By separating is that way, you can have MS with overlapping or colliding
> IP's on the same GTP socket as long as they belong to different GTP network
> devices.
> We had a length discussion about whether the above scenario makes sense.
> I'm not sure if we reached a final verdict, but the 3GPP specifications
> clearly permit such a setup.

We need a netlink interface to retrieve GTP information accordingly,
this includes a top-level APN object to represent what you need. That
would allow to accomodate all usecases.

More information about the osmocom-net-gprs mailing list