Re: [5gangip] IPv6 GTP-C/GTP-U

[Tom Herbert <[e-mail]>]

On Thu, Jan 25, 2018 at 7:40 AM, Alexandre Petrescu
<[e-mail]> wrote:
>
>
> Le 25/01/2018 à 12:36, [e-mail] a écrit :
>>
>> Hi Alex and Charlie,
>> what came to my mind was to ask authors of draft
>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-08, Joe and Mark,
>> whether they would agree to also include 3GPP protocol GTP (description and
>> issues) in that a draft … what do you think?
>
>
> I find the idea pertinent.
>
> I looked at the intarea-tunnels draft.
>
> I think they list common characteristics of Internet tunnels, but they stop
> short from describing a particular tunnel in detail.  Rather, they refer to
> RFCs.
>
> The draft intarea-tunnels does talk about design issues in UDP
> encapsulation, issues which are pertinent to GTP, e,g, checksums,
> fragmentation, etc.
>
> Maybe the intarea-tunnels could benefit from a draft that describes GTP-U.
>
Alex,

I can give a perspective from a programmer of Internet protocols point of view.

In Linux, we have a lot of kernel support for IP/IP encapsulations
(IP/IP, GRE, MPLS, etc). We also support many UDP encapsulations (GUE,
Geneve, VXLAN, GRE/UDP, MPLS/UDP, etc.). A considerable amount of
effort has been done to optimize UDP encapsulations
(https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf).
Mostly, implementation is straightforward: listen on a UDP socket,
handle checksum consistently, process encapsulation headers,
decapsulate and receive inner packet. Packet steering (ECMP), checksum
offload, and SW segmentation offload are common features. Typically,
there is a way to run an encapsulation as a simple virtual interface
(to isolate and develop datapath) with no control plane daemon and no
special hardware. Support for both IPv4 and IPv6 is expected from day
one.

GTP-U is nonconformant compared to other UDP encapsulations. Support
was added to Linux in 2016. This was IPv4 only and required a control
daemon (openggsn originally). It also lacked common accelerations of
other protocols. Last year, I worked on this to: 1) allow using GTP to
be configured as simple network interface 2) support common offloads
3) support IPv6 (v6/v4,v4/v6,v6/v6).

The last point is where I hit problems. My expectation was that
supporting IPv6 should be straightforward, changing interfaces and
protocol implementations to use IPv6 addresses. This was not the case.
The feedback was that a lot is required in the control plane and many
3GPP specs need to be read. Unfortunately, I didn't have time to
pursue this so the patch set was dropped. To date, there's no IPv6 GTP
support and several common features are lacking relative to other UDP
encapsulations.

An RFC certainly would have be helpful in this exercise, if nothing
else to normalize GTP to make it seem like just another UDP
encapsulation (which is a good property). IMO, a GTP-U draft should be
standalone protocol specification so that anyway could implement it
and compare its behavior and properties to other UDP encapsulation
defined in IETF. I don't believe there could be normative references
to 3GPP documents, and this doesn't seem like a WG item but maybe
should be an independent submission.

> Or maybe the GTP-U description could go into that intarea-tunnels draft.
>
That seems reasonable as a bullet point in the intro with the list of
other protocols. Conversely, a GTP-U draft should reference the
intarea-tunnels draft as requirements of IP tunnels. It should also
reference other RFCs on interactions between tunneling and IP
protocols (e.g. RFC2983, RFC6040, RFC4459). The outer UDP checksum
needs careful consideration if it is to be set to zero. RFC6935 and
RFC6936 describe requirements for a zero UDPv6 checksum and RFC8086
(GRE/UDP) section 6.2 is an example of how a protocol applies these
requirements.

>> Perhaps for that we could rely on existing old drafts mentioned below?
>
>
> Maybe the intarea-tunnels draft could refer to draft-casati-gtp-00 of year
> 2000. But if we suggest this to them, I am afraid they would object, because
> typically one needs all the References in a draft to be up to date before
> being able to advance that draft.
>
draft-casati-gtp-00 is very scant and nothing close to being a
specification that someone could take and implement. It would need a
lot of work to be a useful reference.

Tom