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

[Yang, Yi Y]

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 t

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

[Jan Scheurich]

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

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

[Yang, Yi Y]

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 pro

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

[Jan Scheurich]

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

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

[Amar Padmanabhan]

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"  wrote:

On 14 July 2017 at 04:53, Wieger IJntema  
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

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

[Joe Stringer]

On 14 July 2017 at 04:53, Wieger IJntema  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

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

[Joe Stringer]

On 13 July 2017 at 18:38, Jiannan Ouyang  wrote:
> Hi Joe,
>
>> It's neat to see new tunnel implementations being introduced, and also
>> quite cool that it doesn't require significant code changes to OVS to
>> make this happen. Thanks for looking into this :-)
>
> Thanks :)
>
>> I mentioned on the netdev thread that we should work towards using the
>> rtnetlink interface for using the latest kernel devices, eventually
>> everything should switch over to that configuration path.
>>·
>> Do you expect that users will upgrade to the latest kernel to get GTP
>> support? This is certainly the easier method from a
>> development/support perspective. If this is the case, then I don't
>> think we should need many (if any?) changes to the datapath/ directory
>> in OVS. In this case patch #1 could be replaced with a little bit of
>> extra code that pipes the device configuration through
>> lib/dpif-netlink-rtnl.[ch].
>
> I agree with your suggestion.
>
> For code deployment, let's assume uses will upgrade to the latest kernel.
> Nowadays, does OVS tend to have a duplicated tunnel implementation? I noticed
> there are some duplicated tunnel implementation for OVS datapath and the
> "upstream" implementation. What's the plan here?

The code in the OVS tree helps to backport functionality to older
kernels. For example, we currently allow building the OVS tree version
of the module against kernel 3.10, but this kernel didn't have support
for geneve tunnels. So, the compat code provides this functionality
for those older kernels. Depending on the kernel version, how isolated
the feature is, and how important that feature is to users, we may
attempt to provide an implementation of a particular feature in the
OVS tree so that users can use this module with whichever kernel they
like, or we may just request that users upgrade their kernel to get
the newer functionality. Typically the implementation in the OVS tree
is based on the latest code that is available in the Linux tree at the
time that the feature is introduced. Ideally the code directly under
ovs/datapath/ is identical to upstream linux/net/openvswitch/ code,
then the ovs/datapath/compat fleshes out all of the APIs necessary to
build and use that functionality on the older kernel.

It's always easier to ask users to upgrade and not provide an
implementation in the OVS tree - it's a lot of work to support a
backport. That's the background of my question.

For what it's worth, there's some examples about the features
supported on various platforms in Documentation/faq/releases.rst, and
it would be good if your patch could update this as well.

>> I have a broad question with this overall model - Does it assume that
>> the OpenFlow controller is responsible for handling the GTP-C traffic?
>> Then it just programs OVS to match on that GTP-C traffic and forward
>> to the controller? Subsequently, whatever PDP contexts and so on that
>> the controller's GTP-C implementation needs to create, it just sets up
>> equivalent flows for this purpose?
>
> What you said are right, except that the patches are about GTP-U (userplane
> GTP). We expect the OpenFlow controller to handle GTP-U traffics and create
> flows for each PDP context.

OK, so I think this is coming back to me. The kernel implementation
will split out the GTP-C traffic and send it to an independent socket,
where your GTP daemon can process the messages. So, the GTP-C traffic
never hits OVS userspace. Does that sound right?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Wieger IJntema]

>
> 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?

Kind regards, Wieger IJntema
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Jiannan Ouyang]

Hi Joe,

> It's neat to see new tunnel implementations being introduced, and also
> quite cool that it doesn't require significant code changes to OVS to
> make this happen. Thanks for looking into this :-)

Thanks :)

> I mentioned on the netdev thread that we should work towards using the
> rtnetlink interface for using the latest kernel devices, eventually
> everything should switch over to that configuration path.
>·
> Do you expect that users will upgrade to the latest kernel to get GTP
> support? This is certainly the easier method from a
> development/support perspective. If this is the case, then I don't
> think we should need many (if any?) changes to the datapath/ directory
> in OVS. In this case patch #1 could be replaced with a little bit of
> extra code that pipes the device configuration through
> lib/dpif-netlink-rtnl.[ch].

I agree with your suggestion.

For code deployment, let's assume uses will upgrade to the latest kernel.
Nowadays, does OVS tend to have a duplicated tunnel implementation? I noticed
there are some duplicated tunnel implementation for OVS datapath and the
"upstream" implementation. What's the plan here?

> I have a broad question with this overall model - Does it assume that
> the OpenFlow controller is responsible for handling the GTP-C traffic?
> Then it just programs OVS to match on that GTP-C traffic and forward
> to the controller? Subsequently, whatever PDP contexts and so on that
> the controller's GTP-C implementation needs to create, it just sets up
> equivalent flows for this purpose?

What you said are right, except that the patches are about GTP-U (userplane
GTP). We expect the OpenFlow controller to handle GTP-U traffics and create
flows for each PDP context.

Thanks
-Jiannan

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 12 July 2017 at 17:45, Jiannan Ouyang  wrote:
> This patch series depends on the Linux net-next patch set
> [PATCH net-next] Flow Based GTP Tunneling
>
> With flow based GTP tunneling supported in the upstream datapath, we can
> create a gtp vport associated with a flow based GTP net_device. This
> allows us to program GTP tunnels via ovs-vsctl.
>
> Example:
>
> 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"
>
> ovs-ofctl add-flow br0 \
> "in_port=LOCAL,actions=set_tunnel:888, \
> set_field:192.168.60.141->tun_dst,2"
>
> arp -s 10.1.1.122 02:00:00:00:00:00

It's neat to see new tunnel implementations being introduced, and also
quite cool that it doesn't require significant code changes to OVS to
make this happen. Thanks for looking into this :-)

I mentioned on the netdev thread that we should work towards using the
rtnetlink interface for using the latest kernel devices, eventually
everything should switch over to that configuration path.

Do you expect that users will upgrade to the latest kernel to get GTP
support? This is certainly the easier method from a
development/support perspective. If this is the case, then I don't
think we should need many (if any?) changes to the datapath/ directory
in OVS. In this case patch #1 could be replaced with a little bit of
extra code that pipes the device configuration through
lib/dpif-netlink-rtnl.[ch].

I have a broad question with this overall model - Does it assume that
the OpenFlow controller is responsible for handling the GTP-C traffic?
Then it just programs OVS to match on that GTP-C traffic and forward
to the controller? Subsequently, whatever PDP contexts and so on that
the controller's GTP-C implementation needs to create, it just sets up
equivalent flows for this purpose?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev