Hello David -
The ability for a gNB to connect to multiple CNs is already supported by
the 3GPP Multi Operator Core Network (MOCN) feature.
Using SRv6 may remove the GTP header but then you have to find somewhere
else to carry the application metadata found in the GTP header. Here,
you are assuming the GTP metadata can be squeezed into less than 128
bits of a SID. As noted in 29892, this may limit future extensibility to
support more UP features (which is maybe why the 29892 study concluded
to not standardise a SRv6 user plane protocol without GTP-U).
Eliminating UDP? Well, there are lots of potential reasons for operators
wanting to keep UDP (e.g. for traversing firewalls and NATs, for load
balancing, etc) but that is a different discussion.
/bill
On 2025-08-06 12:14 p.m., David Lake wrote:
Bill
RFC 9433 details how the RAN portions can be encoded in SRv6 SIDs.
There was also a hackathon at IETF 122 where BGP support was added for
the new NLRIs. GoBGP v 3.36 has full support for SRv6-MUP in this mode.
In both these cases, GTP is retained on N3 but I believe that it could
be interesting to see how N3 could move to a pure SRv6 implementation
and remove GTP in it’s entirety.
At present, the domain of a gNB is limited to the scope of the GTP.
Having a gNB support multiple PLMNs, each mapped to a different SRv6
SID or even within a QCI to different SIDs without having to deal with
GTP could have great applicability to wholesale networks (those that
support MVNOs). Removing SRv6 would also remove the UDP + GTP header
in each packet.
David
*From: *DanVoyer <[email protected]>
*Date: *Wednesday, 6 August 2025 at 15:11
*To: *Bill Gage <[email protected]>
*Cc: *[email protected] <[email protected]>
*Subject: *[DMM] Re: SRv6 replacement of GTP-U for 6G - Planned proposal
for a 3GPP study
Hi Bill,
One of the values for SRv6, compared to GTP, is it's stateless. But, the
goal for Marcus is open a study at 3GPP to come up with a comparable
analysis for U-GTP and SRv6.
On your point for RAN-related information, I'll invite you to read the
document TR. 29.892 section 6.2
*6.2.2*: Details how SRv6 can be applied within 5GC, including protocol
adaptation to the N3/N9/N6 interfaces and mapping from GTP attributes
(e.g., QFI, TEID) to SIDs.
Thanks,
Dan
On Thu, Jul 31, 2025 at 12:03 PM Bill Gage <[email protected]
<mailto:[email protected]>> wrote:
Hello Markus -
I'm a bit confused by your proposal.
As indicated in the slide set, slides 1-7, SRv6 makes sense as a TE
replacement for MPLS in the user plane. But I don't see how SRv6 (at
least in its current form) provides value as a replacement for GTP-U.
In addition to the PDU (IP packet) being transported, GTP-U includes a
header that contains RAN-related information fields such as end point
identifier (for mapping to a radio bearer), sequence numbers, QoS
information, etc.
What value is SRv6 bringing to this capability?
/bill
On 2025-07-21 12:33 p.m., [email protected]
<mailto:[email protected]> wrote:
> Dear DMM and SRv6ops community,
>
> I would like to draw your attention to an activity that we want
to bring
> to 3GPP to investigate for 6G. It is about the replacement of
GTP-U by
> SRv6 for mobile user plane. This should be of particular interest
to all
> operators/vendors already using/implementing SRv6 or planning its
> introduction.
>
> The last three slides in the slide set at https://
datatracker.ietf.org/ <https://datatracker.ietf.org/>
> meeting/123/materials/slides-123-srv6ops-21-advancing-deutsche-
telekoms-
> traffic-engineering-for-srv6-01 <https://datatracker.ietf.org/
<https://datatracker.ietf.org/>
> meeting/123/materials/slides-123-srv6ops-21-advancing-deutsche-
telekoms-
> traffic-engineering-for-srv6-01> provide more information about our
> motivation and will be presented by me tomorrow during srv6ops
session.
>
> Please read them, attend tomorrow's SRv6ops session or contact me or
> Maria if you are interested.
>
> We are particularly interested in expanding our round of
supporters in
> 3GPP, getting an assessment from you that you may have already
done on
> this topic and studying with you if 3GPP agrees.
>
> Br
>
> Markus
>
_______________________________________________
dmm mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected] <mailto:dmm-
[email protected]>
_______________________________________________
dmm mailing list -- [email protected]
To unsubscribe send an email to [email protected]
