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
