On 4 March 2018 at 19:58, Yang, Yi <yi.y.y...@intel.com> wrote:
> On Sun, Mar 04, 2018 at 07:40:49PM -0800, Joe Stringer wrote:
>> On 4 March 2018 at 18:48, Yang, Yi <yi.y.y...@intel.com> wrote:
>> > On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
>> >> ?On 2 March 2018 at 04:32, Yi Yang <yi.y.y...@intel.com> wrote:
>> >> > + goto err;
>> >> > + }
>> >> > + } else {
>> >> > + /* tnl->gtpu_msgtype can identify if it is GTP-U message,
>> >> > + * miniflow_extract won't parse it if tnl->gtpu_msgtype
>> >> > + * isn't equal to GTPU_MSGTYPE_GPDU.
>> >> > + */
>> >> > + packet->packet_type = htonl(PT_UNKNOWN);
>> >>
>> >> This is where the limits of my GTP understanding will show, I was
>> >> under the impression that GTP-U provides encapsulation for user
>> >> traffic, so would commonly encapsulate IPv4/IPv6 inside. Whereas for
>> >> GTP-C, it's signalling traffic so would not have such inner headers -
>> >> it's supposed to be handled by a GTP implementation. Why is it
>> >> important to be able to decapsulate GTP-C? Furthermore, what's
>> >> ensuring that we don't end up spitting inner GTP-C packet data onto
>> >> the wire without headers post-translation?
>> >>
>> > GTP-C is for control path, so I don't think it makes sense for OVS to
>> > handle this, in addition GTP-C used different UDP port from GTP-U's, so
>> > we must have different tunnel ports to handle them respectively.
>>
>> Re: GTP-C in OVS, I'm inclined to agree that it doesn't make sense to
>> be in OVS. There's a lot of complexity there and existing FOSS
>> projects already attempt to support this, such as those under Osmocom.
>>
>> The thing I was trying to highlight with the above comment is that
>> this function appears to be attempting to handle both GTP-U and GTP-C,
>> but if it doesn't make sense for OVS to handle it then I'm not sure
>> why this code attempts to do so. I don't think that expecting people
>> to just send the right kind of traffic on the designated ports (eg,
>> GTP-U on the GTP-U port) is enough, these paths need to be resilient
>> to unexpected input. Perhaps it's enough to restrict installation of
>> flows with pop GTP actions based on presence of the appropriate GTP
>> msgtype in the flow key.
>
> GTP-U has two kinds of message types, normal GTP-U PDU and signaling
> messages, so we have to handle signaling messages here, it isn't GTP-C,
> http://www.3gpp.org/ftp/Specs/archive/29_series/29.281/29281-f10.zip
> has detailed description.
I see, thanks for the reference.
> By the way, Feng said the existing GTP kernel implementation also didn't
> implement GTP-C and didn't handle other optional flag bits.
Ah, okay. The thing I was thinking of was the way to configure a GTP
socket to forward signalling traffic to a userspace process for
handling:
https://www.kernel.org/doc/Documentation/networking/gtp.txt
>>
>> > I don't know if Jiannan has implemented GTP-C support in kernel data
>> > path, we can add GTP-C support if it is really needed, but I think it is
>> > a nice-to-have thing.
>>
>> I believe there is some kind of implementation already in the kernel,
>> but you'd have to take a look to see whether its design fits with what
>> you're trying to do.
>>
>> Cheers,
>> Joe
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
