gtpu: support non-G-PDU packets and PDU Session

Updated the gtpu plugin code to support the PDU Session user plane protocol, required for 5G, as
specified in 3GPP TS 38.415 version 17.0.0. This enables some initial support of 5G gNodeB's with
the gtpu plugin.

New features:
- Basic support for the GTP-U Extension Header Flag.
Packets with one extension can now be decapsulated.
This enables basic support of the PDU Session user plane protocol (3GPP TS 38.415 version 17.0.0).
New tunnels can be created with a PDU enable flag and a 6-bit QoS Flow Identifier (QFI).
With this, encapsulated packets will have the PDU Session extension header, and the QFI set.

- Ability to forward GTP-U packets that are not handled by the plugin directly.
Only GTP-U packets with a message type of 255 (G-PDU) are handled directly.
However, 3GPP TS 29.281 defines several other message types like echo and error indication.
A new feature is added to optionally forward unknown or unsupported packets to a new IP address.
This works separately for unknown GTP-U message types, unknown TEIDs, and packets with an unknown
GTP-U header.
This allows both echo and error indications from a 5G gNodeB to be handled by a different system
outside VPP.

- Simple way to get metrics for active tunnels and on tunnel close.
In 5G session/tunnel lifetime is often short and created frequently.
The normal API becomes too slow and inaccurate when too many tunnels are created and deleted
every second.

Improvements:
- A clean ground structure to handle multiple message type in the future.
The code path for G-PDU packets is optimized for performance, representing the typical case.
Unsupported GTP-U packets enter a slow path that decodes the nature of the error.
This presents a easy hook to handle other message types in the future.

- Improved error reporting
When using traces there is more details in the tunnel descriptions.

- Updated the API with several enums.

Fixes:
- gtpu0->length field in IPv6 was computed with IPv4 header lengths in the encapsulation code.
- vec_set_len (t->rewrite, ...) size was computed with the IPv4 header size also for IPv6 tunnels.

Issues:
- This PR does not enable full support of the 3GPP specification.
In particular it only supports a single QoS/QFI flow for each tunnel.
It ignores all incoming extension header flags.

- API functions might change again when/if more support of the 3GPP TS 38.415 spec is added.

Note that I have bumped the API version to 2.1.0 as it seems to be the correct approach based on
my API changes.

Type: feature

Signed-off-by: Rune E. Jensen <runeerle@wgtwo.com>
Change-Id: I91cd2b31f2561f1b3fb1e46c4c34a5a3c71b4625

1 files changed, 2 insertions, 0 deletions

diff --git a/src/plugins/gtpu/gtpu_error.def b/src/plugins/gtpu/gtpu_error.def
index 4351529ef25..6b521c8658a 100644
--- a/src/plugins/gtpu/gtpu_error.def
+++ b/src/plugins/gtpu/gtpu_error.def
@@ -17,3 +17,5 @@ gtpu_error (NO_SUCH_TUNNEL, "no such tunnel packets")
 gtpu_error (BAD_VER, "packets with bad version in gtpu header")
 gtpu_error (BAD_FLAGS, "packets with bad flags field in gtpu header")
 gtpu_error (TOO_SMALL, "packet too small to fit a gtpu header")
+gtpu_error (UNSUPPORTED_TYPE, "packets with message type < 255 in gtpu header")
+gtpu_error (NO_ERROR_TUNNEL, "did not find an forward tunnel")