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:[email protected]]
Sent: Tuesday, July 18, 2017 6:39 AM
To: Yang, Yi Y <[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
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
