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:[email protected]] > Sent: Monday, 17 July, 2017 11:18 > To: Jan Scheurich <[email protected]>; Amar Padmanabhan > <[email protected]>; Joe Stringer <[email protected]>; > Wieger IJntema <[email protected]> > Cc: ovs dev <[email protected]>; Pablo Neira Ayuso <[email protected]>; > Harald Welte <[email protected]> > 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: [email protected] > [mailto:[email protected]] On Behalf Of Jan Scheurich > Sent: Monday, July 17, 2017 4:24 PM > To: Amar Padmanabhan <[email protected]>; Joe Stringer <[email protected]>; > Wieger IJntema <[email protected]> > Cc: ovs dev <[email protected]>; Pablo Neira Ayuso <[email protected]>; > Harald Welte <[email protected]> > 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: [email protected] > > [mailto:[email protected]] On Behalf Of Amar Padmanabhan > > Sent: Friday, 14 July, 2017 19:23 > > To: Joe Stringer <[email protected]>; Wieger IJntema > > <[email protected]> > > Cc: ovs dev <[email protected]>; Harald Welte > > <[email protected]>; Pablo Neira Ayuso <[email protected]> > > 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" <[email protected]> wrote: > > > > On 14 July 2017 at 04:53, Wieger IJntema <[email protected]> > > 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 > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
