Hello,
I am a newbie in this area so please pardon me if these are dumb or covered questions!
I am looking for a GTP stack that implements GTP-C version 2. Is this supported in open grps or is there a plan for that? If not, what stack (preferably open source) is recommended?
Thanks, Tom
Hi Tom!
On Fri, Sep 01, 2017 at 01:32:45PM -0700, Tom Herbert wrote:
I am a newbie in this area so please pardon me if these are dumb or covered questions!
no worries.
I am looking for a GTP stack that implements GTP-C version 2. Is this supported in open grps or is there a plan for that? If not, what stack (preferably open source) is recommended?
In Osmocom we only implement GTPv0 + GTPv1 for both C(ontrol) and U(ser) plane, as we so far have not been getting sufficient contributions to move beyond the 2G and 3G network element implementations nad into 4G (which is where GTPv2-C is introduced).
I'm not an expert on available GTPv2-C code out there, but I'm aware of * an Erlang implementation that's part of ergw, see https://github.com/travelping/ergw/blob/master/src/gtp_v2_c.erl they also have a separate erlang GTP library at https://github.com/travelping/gtplib
* nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/ and has also been used in OAI at https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0....
* A TTCN-3 implementation published by ETSI, primarily used for their conformance test suite - which means it is rather complete: http://forge.etsi.org/websvn/listing.php?repname=LIBS.LibGtpv2C
* another TTCN-3 implementation from Ericsson which is in the process of being released as FOSS, preview of which can be found in the osmo-ttcn3-hacks.git repository.
I guess it depends on your use case or requirements whether any of that is applicable. Maybe you can share some more background on what you have in mind?
Regards, Harald
Hi Harald,
On Fri, Sep 1, 2017 at 2:59 PM, Harald Welte laforge@gnumonks.org wrote:
Hi Tom!
On Fri, Sep 01, 2017 at 01:32:45PM -0700, Tom Herbert wrote:
I am a newbie in this area so please pardon me if these are dumb or covered questions!
no worries.
I am looking for a GTP stack that implements GTP-C version 2. Is this supported in open grps or is there a plan for that? If not, what stack (preferably open source) is recommended?
In Osmocom we only implement GTPv0 + GTPv1 for both C(ontrol) and U(ser) plane, as we so far have not been getting sufficient contributions to move beyond the 2G and 3G network element implementations nad into 4G (which is where GTPv2-C is introduced).
I'm not an expert on available GTPv2-C code out there, but I'm aware of
an Erlang implementation that's part of ergw, see https://github.com/travelping/ergw/blob/master/src/gtp_v2_c.erl they also have a separate erlang GTP library at https://github.com/travelping/gtplib
nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/ and has also been used in OAI at https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0....
I looked at that, it's pretty minimal for our purposed.
A TTCN-3 implementation published by ETSI, primarily used for their conformance test suite - which means it is rather complete: http://forge.etsi.org/websvn/listing.php?repname=LIBS.LibGtpv2C
another TTCN-3 implementation from Ericsson which is in the process of being released as FOSS, preview of which can be found in the osmo-ttcn3-hacks.git repository.
I guess it depends on your use case or requirements whether any of that is applicable. Maybe you can share some more background on what you have in mind?
My user requires GTPv2 (i.e. this is for 4G network). My interest here is really to do development on the user plane, but we need a GTP-C to at least prototype something for their network. Also, we'd like the kernel support for GTP-U (including IPv6 which I suppose is still outstanding).
Thanks, Tom
Regards, Harald --
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Tom,
On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
- nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/ and has also been used in OAI at https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0....
I looked at that, it's pretty minimal for our purposed.
Welcom to the (cellular) telecom world. Feels like the state of Linux in the mid-1990ies: Some minimal FOSS implementations exist, but most of the work still has to be done. We've been trying hard since 2008 inside Osmocom, but as indicated so far no 4G related contributions (financially or in terms of code).
My user requires GTPv2 (i.e. this is for 4G network). My interest here is really to do development on the user plane,
Are we talking about FOSS development here?
but we need a GTP-C to at least prototype something for their network.
What exactly do you want to prototype? Which of the many GTPv2-C transactions do you need? I guess if you can deal e.g. without relocation, then the complexity is quite reduced.
Also, we'd like the kernel support for GTP-U (including IPv6 which I suppose is still outstanding).
correct. We've just added user-plane IPv6 support to openggsn in userspace, v6 user plane (or even transport plane) in kernel GTP is still another area looking for contributions.
On Sat, Sep 2, 2017 at 1:29 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Tom,
On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
- nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/ and has also been used in OAI at https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0....
I looked at that, it's pretty minimal for our purposed.
Welcom to the (cellular) telecom world. Feels like the state of Linux in the mid-1990ies: Some minimal FOSS implementations exist, but most of the work still has to be done. We've been trying hard since 2008 inside Osmocom, but as indicated so far no 4G related contributions (financially or in terms of code).
My user requires GTPv2 (i.e. this is for 4G network). My interest here is really to do development on the user plane,
Are we talking about FOSS development here?
Yes.
but we need a GTP-C to at least prototype something for their network.
What exactly do you want to prototype? Which of the many GTPv2-C transactions do you need? I guess if you can deal e.g. without relocation, then the complexity is quite reduced.
I need the control plane to be able to develop the data path. The ultimate goal of our project is to an implement and ILA data path; that is use it instead of GTP-U tunneling but still have the GTP-C control plane. The support we need starts out simple, just create a data path and demonstrate the benefits (maybe as much that is in nwgtpv2). As we proceed, obviously we'll want to prototype more of the capabilities such as handover. That being said, this is just a prototype for now!
How much effort do you think it would be to implement GTPv2-C?
Also, we'd like the kernel support for GTP-U (including IPv6 which I suppose is still outstanding).
correct. We've just added user-plane IPv6 support to openggsn in userspace, v6 user plane (or even transport plane) in kernel GTP is still another area looking for contributions.
What is the difference between user plane and transport plane?
I'm looking at the GTP kernel code, it seems to be pretty straightforward to add IPv6, and the common offloads and I could look at that once I figure out a solution for using GTP-C v2.
Thanks, Tom
--
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Tom,
----- On Sep 2, 2017, at 6:51 PM, Tom Herbert tom@quantonium.net wrote:
On Sat, Sep 2, 2017 at 1:29 AM, Harald Welte laforge@gnumonks.org wrote:
Hi Tom,
On Fri, Sep 01, 2017 at 04:27:22PM -0700, Tom Herbert wrote:
- nwGTPv2c which is originally from https://sourceforge.net/projects/nwepc/ and has also been used in OAI at https://gitlab.eurecom.fr/oai/openair-cn/tree/master/SRC/GTPV2-C/nwgtpv2c-0....
I looked at that, it's pretty minimal for our purposed.
Welcom to the (cellular) telecom world. Feels like the state of Linux in the mid-1990ies: Some minimal FOSS implementations exist, but most of the work still has to be done. We've been trying hard since 2008 inside Osmocom, but as indicated so far no 4G related contributions (financially or in terms of code).
My user requires GTPv2 (i.e. this is for 4G network). My interest here is really to do development on the user plane,
Are we talking about FOSS development here?
Yes.
but we need a GTP-C to at least prototype something for their network.
What exactly do you want to prototype? Which of the many GTPv2-C transactions do you need? I guess if you can deal e.g. without relocation, then the complexity is quite reduced.
I need the control plane to be able to develop the data path. The ultimate goal of our project is to an implement and ILA data path; that is use it instead of GTP-U tunneling but still have the GTP-C control plane. The support we need starts out simple, just create a data path and demonstrate the benefits (maybe as much that is in nwgtpv2). As we proceed, obviously we'll want to prototype more of the capabilities such as handover. That being said, this is just a prototype for now!
GTPv2 control plane including GGSN/PGW handover works in erGW [1]. A more ready to run packaged solution it at [2]. It does support the kernel module for the data path and I would be willing to help with getting a GGSN/PGW up and running, and implement the IPv6 support in the control path (Erlang world).
I don't have the time right now to get into the data path implementation.
How much effort do you think it would be to implement GTPv2-C?
As always, the problems are in the details and they are not obvious from reading the specification.
Also, we'd like the kernel support for GTP-U (including IPv6 which I suppose is still outstanding).
correct. We've just added user-plane IPv6 support to openggsn in userspace, v6 user plane (or even transport plane) in kernel GTP is still another area looking for contributions.
What is the difference between user plane and transport plane?
Control plane of GTPv2, data/transport plane is GTPv1. There is no GTPv2 for the data/transport plane.
I'm looking at the GTP kernel code, it seems to be pretty straightforward to add IPv6, and the common offloads and I could look at that once I figure out a solution for using GTP-C v2.
The tricky parts might be the handling to IPv6 address delegations. But I haven't really looked at it, yet.
Regards Andreas
[1]: https://github.com/travelping/ergw [2]: https://github.com/travelping/ergw-gtp-c-node
Hi Andreas and Tom,
On Mon, Sep 04, 2017 at 11:57:22AM +0200, Andreas Schultz wrote:
correct. We've just added user-plane IPv6 support to openggsn in userspace, v6 user plane (or even transport plane) in kernel GTP is still another area looking for contributions.
What is the difference between user plane and transport plane?
Control plane of GTPv2, data/transport plane is GTPv1. There is no GTPv2 for the data/transport plane.
Sorry, this is a misunderstanding, there are two orthogonal concepts: * control plane is GTPv2-C * user plane is GTPv1-U
But then, the user plane has two layers: 1) outer (transport) layer, i.e. IP addresses of the outer IP packet 2) inner (user) layer, i.e. the IP addresses of the inner IP packet
So my comment was referring to the fact that those latter two are treated separately. Current OpenGGSN is now capable of doing IPv6 on the inner (user) IP layer, but not on the outer (transport) layer.
I'm looking at the GTP kernel code, it seems to be pretty straightforward to add IPv6, and the common offloads and I could look at that once I figure out a solution for using GTP-C v2.
The tricky parts might be the handling to IPv6 address delegations. But I haven't really looked at it, yet.
Yes, this is rather hairy, you can see my recent implementatin on OpenGGSN. It's a complete mix of modified stateless auto-configuration combined with 3GPP specific signaling in terms of PCO (protocol config options).
osmocom-net-gprs@lists.osmocom.org
-
Andreas Schultz -
Harald Welte -
Tom Herbert