Re: [PATCH iproute2-next v3 1/2] ip: GTP support in ip link

On 27/02/2022 08:55, Harald Welte wrote:

Dear Jonas,

On Sun, Feb 27, 2022 at 07:57:02AM +0100, Jonas Bonn wrote:

quoted

On 11/02/2022 19:29, Wojciech Drewek wrote:

quoted

Support for creating GTP devices through ip link. Two arguments
can be specified by the user when adding device of the GTP type.
   - role (sgsn or ggsn) - indicates whether we are on the GGSN or SGSN

It would be really nice to modernize these names before exposing this API.

I am very skeptical about this.  The features were implemented with this use
case in mind, and as you know, they only match rather partially to the requirements
of later generation technology (4G/LTE/EPC) due to their lack of support for
dedicated bearers / TFTs.

quoted

When I added the role property to the driver, it was largely to complement
the behaviour of the OpenGGSN library, who was essentially the only user of
this module at the time.  However, even at that time the choice of name was
awkward because we were well into the 4G era so SGSN/GGSN was already
somewhat legacy terminology; today, these terms are starting to raise some
eyebrows amongst younger developers who may be well versed in 4G/5G, but for
whom 3G is somewhat ancient history.

The fact that some later generation of technology _also_ is using parts of older
generations of technology does not mean that the older terminology is in any way
superseded.  A SGSN remains a SGSN even today, likewise a GGSN.  And those network
elements are used in production, very much so even in 2022.

quoted

3GPP has a well-accepted definition of "uplink" and "downlink" which is
probably what we should be using instead.  So sgsn becomes "uplink" and ggsn
becomes "downlink", with the distinction here being whether packets are
routed by source or destination IP address.

Could you please provide a 3GPP spec reference for this?  I am working
every day in the 3GPP world for something like 15+ years now, and I
would be _seriously_ surprised if such terminology was adopted for the
use case you describe. I have not come across it so far in that way.

"uplink" and "downlink" to me
a) define a direction, and not a network element / function.
b) are very general terms which depend on the point of view.

This is why directions, in 3GPP, traditionally, are called
"mobile-originated" and "mobile-terminated".  This has an unambiguous
meaning as to which direction is used.

But in any case, here we want to name logical network elements or
functions within such elements, and not directions.

Those elements / functions have new names in each generation of mobile
technology, so you have SGSN or S-GW on the one hand side, and GGSN or
P-GW on the other side.  The P-GW has then optionally been decomposed
into the UPF and SMF.  And then you have a variety of other use cases
(interfaces) where the GTPv1U protocol was later introduced, such as the
use between eNB and S-GW.

So you cannot use S-GW and P-GW as names for the roles of the GTP tunnel
driver, as S-GW actually performs both "roles": You can think of it as
decapsulationg the traffic on the eNB-SGW interface and as encapsulating
the traffic on the SGW-PGW side.

So this may all come down sloppy usage of the terminology, but everyone 
I interact with tend to refer to the interfaces on the S-GW, I-UPF, UPF, 
etc as the uplink or downlink interface depending on whether it is 
connected to the uplink network segment or the downlink network segment. 
  That's all a bit ambiguous, as you alluded to above, until you 
consider that these directions are always relative to the UE:  the 
uplink carries traffic FROM the UE, the downlink carries traffic TO the UE.

That all maps quite nicely to the GTP module where the peer tunnel 
endpoint is determined from either the source or destination address 
depending on which direction the traffic is flowing:  either TO or FROM 
the UE.  Traffic sent on an uplink interface is destined for the UE, 
hence the destination IP determines the TEID; traffic sent out on a 
downlink interface moves away FROM the UE, so the source address 
determines the TEID.

With that, the S-GW/I-UPF has a both an uplink and a downlink GTP 
interface between which packets are forwarded.  The decision as to which 
peer TEID to send to is made based on which interface the packet is 
going out on, which of course is synonymous with the direction the 
packets are flowing in.  That's exactly what the SSGN/GGSN "mode" 
parameter decides, as well.

Anyway, I don't disagree with anything that you wrote here and I'm not 
going to push hard for a name change; I just wanted to raise the issue. 
  I realize that uplink/downlink aren't crystal clear either.  That 
said, if I'm putting together an I-UPF, then it certainly isn't more 
clear why I need an interface in "SSGN" mode rather than "downlink" mode.

And I'm sure that I've seen a one-liner or something in some 3GPP spec 
that handwavingly justifies the above usage, but of course I can't find 
it now... so I'll happily concede that this isn't a 3GPP standard, but 
rather just "common usage", at least within in my bubble.

I'm not fundamentally opposed to any renaming, but any such renaming
must have a unambiguous definition.

In the context of TS 29.060, there are a number of references to uplink
and downlink.  However, they - as far as I can tell -

* specify a direction (like the QoS Parameters like AMBR for uplink / downlink)

* are used within the context of TEIDs.  So there is an "uplink tunnel
   endpoint identifier" which is chosen by the GGSN, and which is used by
   the SGSN to send data.  So again it is used to signify a direction.

The "uplink tunnel" terminates at the "uplink interface" of the GGSN, so 
you'd want the GTP module to provide an interface in "uplink" mode.

Equally, the SGSN allocates a "downlink tunnel endpoint identifier" for 
packets terminating at the "downlink interface" (originating from the 
GGSN), so here you'd want the GTP module giving you an interface in 
"downlink" mode.

/Jonas

If we look at 3GPP TS 29.281, there are one mention of 'uplink' and
'downlink', and both are also again referring to a direction of traffic.

Regards,
	Harald