Date:   Sun, 27 Feb 2022 10:12:54 +0100
From:   Jonas Bonn <jonas@...rbonn.se>
To:     Harald Welte <laforge@...monks.org>
Cc:     Wojciech Drewek <wojciech.drewek@...el.com>,
        netdev@...r.kernel.org, dsahern@...il.com,
        stephen@...workplumber.org
Subject: 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:
>> On 11/02/2022 19:29, Wojciech Drewek wrote:
>>> 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.
> 
>> 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.
> 
>> 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
> 

Powered by blists - more mailing lists