Jan, yes, we have patch to parse GTP-u as L7 protocol and implemented corresponding match fields. This needn't any extra prerequisite, the parser just parse the GTP-u header in UDP packet if its UDP destination port is 2152.
Here is our change against struct flow. diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h index 91966df..8078fa5 100644 --- a/include/openvswitch/flow.h +++ b/include/openvswitch/flow.h @@ -152,6 +152,10 @@ struct flow { ovs_be32 igmp_group_ip4; /* IGMP group IPv4 address. * Keep last for BUILD_ASSERT_DECL below. */ ovs_be32 pad3; /* Pad to 64 bits. */ + + /* L5 (64-bit aligned) */ + union fields l5_fields; }; BUILD_ASSERT_DECL(sizeof(struct flow) % sizeof(uint64_t) == 0); BUILD_ASSERT_DECL(sizeof(struct flow_tnl) % sizeof(uint64_t) == 0); union fields l5_fields is defined as below /* L5 information used in flow key. */ struct gtp_u_mf { uint8_t gtp_flag; uint8_t gtp_msgtype; ovs_be32 gtp_teid; ovs_be32 ip_dst_in_gtp_u; ovs_be32 ip_src_in_gtp_u; uint8_t ip_proto_in_gtp_u; ovs_be16 tp_src_in_gtp_u; ovs_be16 tp_dst_in_gtp_u; }; -----Original Message----- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Tuesday, July 18, 2017 6:39 AM To: Yang, Yi Y <yi.y.y...@intel.com>; Amar Padmanabhan <amarpadmanab...@fb.com>; Joe Stringer <j...@ovn.org>; Wieger IJntema <wieger.ijntema....@gmail.com> Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso <pa...@netfilter.org>; Harald Welte <lafo...@gnumonks.org> Subject: RE: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath 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.y...@intel.com] > Sent: Monday, 17 July, 2017 11:18 > To: Jan Scheurich <jan.scheur...@ericsson.com>; Amar Padmanabhan > <amarpadmanab...@fb.com>; Joe Stringer <j...@ovn.org>; Wieger IJntema > <wieger.ijntema....@gmail.com> > Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso > <pa...@netfilter.org>; Harald Welte <lafo...@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-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich > Sent: Monday, July 17, 2017 4:24 PM > To: Amar Padmanabhan <amarpadmanab...@fb.com>; Joe Stringer > <j...@ovn.org>; Wieger IJntema <wieger.ijntema....@gmail.com> > Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso > <pa...@netfilter.org>; Harald Welte <lafo...@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-boun...@openvswitch.org > > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Amar > > Padmanabhan > > Sent: Friday, 14 July, 2017 19:23 > > To: Joe Stringer <j...@ovn.org>; Wieger IJntema > > <wieger.ijntema....@gmail.com> > > Cc: ovs dev <d...@openvswitch.org>; Harald Welte > > <lafo...@gnumonks.org>; Pablo Neira Ayuso <pa...@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" <j...@ovn.org> wrote: > > > > On 14 July 2017 at 04:53, Wieger IJntema <wieger.ijntema....@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 > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev