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

Jan Scheurich jan.scheurich at ericsson.com
Mon Jul 17 22:39:29 UTC 2017 

Yi, so what you are saying is that for the third use case (GTP-u processing w/o terminating UDP transport tunnel) you have patched OVS to parse GTP-u as L7 protocol and implemented corresponding match fields?

There is no Ethertype defined for GTP-u as it is only specified for UDP transport. Supporting GTP-u as new packet type in OVS would require to implement support for new packet type namespace OFPHTN_UDP_TCP_PORT (code point 3). So it's a bit more work than for a new packet type in namespace OFPHTN_ETHERTYPE, but certainly doable.

The same GTP-u fields could be used as L7 fields (flow prerequisites udp, tp_dst_port= 2152) and directly for new packet type (OFPHTN_UDP_TCP_PORT,2125). Only in the latter case a decap() action could be used to remove the GTP-u encapsulation. In the former case, processing would be limited to matching and GTP-u header modification.

BR, Jan

> -----Original Message-----
> From: Yang, Yi Y [mailto:yi.y.yang at intel.com]
> Sent: Monday, 17 July, 2017 11:18
> To: Jan Scheurich <jan.scheurich at ericsson.com>; 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
> 
> 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