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

Patch:

gtp: properly parse extension headers

is provided here:

https://git.kernel.org/pub/scm/linux/kernel/git/pablo/gtp.git/log/

There is one question to be addressed though:

TS 29.060 in 5.2.1 General format of the GTP-U Extension Header says:

"Bits 7 and 8 of the Next Extension Header Type have the following meaning: ...

1 0 Comprehension of this extension header is required by the Endpoint Receiver but not by an Intermediate Node.
1 1 Comprehension of this header type is required by recipient (either Endpoint Receiver or Intermediate Node)"

From reading the supported GTP-U extension headers in the TS, it seems this extension headers are informative (no immediate action seems to be required).

At a later stage in the GTP development, once there is a userspace program requiring this information provided by the GTP extension headers, a netlink event to userspace including the information that is provided should be sufficient. I don't seem to find any immediate
action to be performed as specified by the TS for this extension headers that require comprehension.

I think the patch I am attaching should be sufficient by now to allow Linux GTP to work with other existing non-Linux GTP implementations, this simply strips off the GTP extension header when decapsulating the packet from RX path, no informative netlink event is delivered by now.

I am also attaching what I have used to test it, it is a hack from TX path, it should help to add GTP extension support in the future, if ever needed. Note gtp->len field counts for SN, N and E field: TS 29.060: "The Sequence Number, the N-PDU Number or any Extension headers shall be considered to be part of the payload, i.e. included in the length count".

pablo wrote in #note-1:

There is one question to be addressed though:

TS 29.060 in 5.2.1 General format of the GTP-U Extension Header says:

"Bits 7 and 8 of the Next Extension Header Type have the following meaning: ...

1 0 Comprehension of this extension header is required by the Endpoint Receiver but not by an Intermediate Node.
1 1 Comprehension of this header type is required by recipient (either Endpoint Receiver or Intermediate Node)"

From reading the supported GTP-U extension headers in the TS, it seems this extension headers are informative (no immediate action seems to be required).

I think the primary use is in 5G to diferentiate QoS at this level. So one would likely expect an UPF to classify packets in different queues based on parameters in the extension header.

At a later stage in the GTP development, once there is a userspace program requiring this information provided by the GTP extension headers, a netlink event to userspace including the information that is provided should be sufficient.

I don't think this is a very likely use case. GTP-U packets are many (up to gigabits for each subscriber in 5G), and the whole point of the kernel GTP driver is to avoid involving userspace on every packet. It's more likely that somebody would want to add actions like marking a packet (for later QoS treatment, ...) based on contents of the extension header (specifically the "PDU session container"). That kind of processing should certainly all work inside the kernel. Sending one netlink event to userspace for each incoming packet with such an extension header would quickly overflow the netlink system, and at the time userspace processes the notification it is too late to impact the processing of that specific packet anyway.

But I agree that for the current task it is sufficient to simply skip it.

osmith can you work on related TTCN-3 tests? Feel free to create a separate issue. I think the easiest way would be to send related GTPv1U packets with extension header[s] from TTCN3 to osmo-ggsn and expect them to pass like normal GTP without exthdr in both the userspace and kernel-gtp cases. Thanks!