[ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

Yang, Yi Y yi.y.yang at intel.com
Mon Jul 17 09:17:49 UTC 2017


Jan, for the use case you mentioned, outer IP destination of the GPT-u packet must be IP address of generic UDP tunnel port, but in the actual use case (especially for ETSI MEC use case), the destination IP of the GTP-u packet isn't ovs host node's IP, so this kind of use case needn't tunnel port, we internally have implemented GTP-u header parsing and match as application layer data.

But I do agree it is a good direction to implement tunnel port and tunnel encap & decap by using generic UDP tunnel port and generic encap & decap action.

-----Original Message-----
From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Jan Scheurich
Sent: Monday, July 17, 2017 4:24 PM
To: Amar Padmanabhan <amarpadmanabhan at fb.com>; Joe Stringer <joe at ovn.org>; Wieger IJntema <wieger.ijntema.tno at gmail.com>
Cc: ovs dev <dev at openvswitch.org>; Pablo Neira Ayuso <pablo at netfilter.org>; Harald Welte <laforge at gnumonks.org>
Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

These are indeed two different use case. The pure termination of the GTP-u tunnel can be done by adding support for a GTP-u tunnel vport, which should be straightforward now that we have support for L3 tunneling fully upstreamed in in OVS and based on the GTP tunnel support in the Linux kernel.

For more flexible use cases that match on GTP-u header fields and only conditionally decapsulate packets, we would like to have support for adding/removing the GTP-u header in the OpenFlow pipeline. This use case will be shortly be possible to implement based on the packet type-aware pipeline (PTAP) and generic encap/decap (EXT-382) infrastructure that we are currently upstreaming:
PTAP: commit 3d4b2e6eb74 and following
EXT-382: https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335642.html

For such use cases three things will have to be added on top:
1. A generic UDP tunnel vport (as already supported by the Linux kernel, I understand) to terminate the UDP transport tunnel and deliver a GTP-u packet to the PTAP OpenFlow pipeline. (There are also other interesting use cases for such a tunnel vport, e.g. MPLS over UDP.) 2. Support for GTP-u match fields in ofproto and datapaths 3. Support for generic encap and decap actions for the GTP-u packet type.

The current work on support for NSH tunnels can be seen as an example for items 2. and 3.
https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334872.html

We would be very happy to see the PTAP and encap/decap infrastructure be applied to additional use cases. 

I currently don't see a possibility to match on GTP-u headers in OVS without first terminating the UDP transport tunnel.

BR, Jan

> -----Original Message-----
> From: ovs-dev-bounces at openvswitch.org 
> [mailto:ovs-dev-bounces at openvswitch.org] On Behalf Of Amar Padmanabhan
> Sent: Friday, 14 July, 2017 19:23
> To: Joe Stringer <joe at ovn.org>; Wieger IJntema 
> <wieger.ijntema.tno at gmail.com>
> Cc: ovs dev <dev at openvswitch.org>; Harald Welte 
> <laforge at gnumonks.org>; Pablo Neira Ayuso <pablo at netfilter.org>
> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream 
> datapath
> 
> Yeah, we are looking at tunnel termination in OVS, i.e. GGSN or PGW. I 
> think what you mention Weiger is about an on-path device that also does some classification like some of the 5G proposals. I think Yi is also looking at it but that is not directly related to this patch set.
> - Amar
> 
> On 7/14/17, 10:01 AM, "Joe Stringer" <joe at ovn.org> wrote:
> 
>     On 14 July 2017 at 04:53, Wieger IJntema <wieger.ijntema.tno at gmail.com> wrote:
>     >> ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \
>     >>     ofport_request=2 type=gtp option:remote_ip=flow options:key=flow
>     >>
>     >> ovs-ofctl add-flow br0
>     >>     "in_port=2,tun_src=192.168.60.141,tun_id=123, \
>     >>     actions=set_field:02:00:00:00:00:00->eth_src, \
>     >>     set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL"
>     >
>     >
>     > I just want to be sure. But this implicates that the incomming packet is
>     > already decapusulated by the kernel and it has attached metadata like the
>     > tunnel_id etc.
>     > a nicer solution would be that you can already match on tunnel_id before it
>     > is getting encapsulated. Then you can chose later if it needa decapsulation
>     > or just forward the packet.
>     > I'm not sure if it is a possibility?
> 
>     I wonder if we're actually discussing two different use cases? I think
>     that Jiannan & co are interested in GGSN functionality, whereas if my
>     understanding serves me right what you're proposing sounds more like
>     SGSN functionality. This approach is specifically for the edge of the
>     GTP-tunnelled network so it's always wanting to perform encap/decap.
>     For this particular use case, the proposed approach has a couple of
>     nice attributes. Firstly, the tunneling follows the same model as all
>     of the existing tunneling code so it fits quite well without needing
>     to solve new problems for a new tunnel protocol type. Secondly, the
>     kernel can deal with filtering GTP-C traffic out of the stream to
>     forward to the appropriate GTP daemon, which means that OVS doesn't
>     need to be taught how to understand that traffic or forward it to
>     another program.
> 
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
dev at openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list