The GPRS Tunneling Protocol User Plane (GTP-U) has long been deployed for GSM, UMTS and 4G LTE. Now for 5G, IPv6 Segment Routing (SRv6) has been proposed as an alternative user plane protocol to GTP-U in both 3GPP and IETF. SRv6 based on source routing has many advantages: stateless traffic steering, network programming and so on. Despite the advantages, it is hard to expect to replace GTP-U by SRv6 all at once, even in a 5G deployment because of a lot of dependencies between 3GPP nodes. Therefore, stateless translation and co- existence with GTP-U have been proposed in IETF. However there are no suitable measurement platform and performance evaluation results between GTP-U and SRv6. In particular, it is hard to measure latency on commercial traffic generators when a receiving packet type is different from a sending packet type. In this paper, we focus on the performance evaluation between GTP-U and SRv6 stateless translation. We designed an SRv6 measurement platform using a programmable switch, and measured GTP-U and SRv6 functions with pre-defined scenarios on a local environment. Well-known performance metrics, such as throughput and packets per second (PPS), are measured by the traffic generator while the latency at the functions was measured using telemetry on our SRv6 platform. In our evaluation, we cannot find the abrupt performance drop of well-known metrics at SRv6 stateless translation. Moreover, the latency of SRv6 stateless translation is similar to GTP-U and their performance degradation is negligible. Through the evaluation results, it is obvious that the SRv6 stateless translation is acceptable to the 5G user plane.

1. Performance Evaluation of GTP-U
and SRv6 Stateless Translation
Toyota Motor Corp.1),APRESIA Systems,Ltd.2), Cisco Systems3), SoftBank Corp.4)
Chunghan Lee1), Kentaro Ebisawa1), Hitoshi Kuwata2),
Miya Kohno3), Satoru Matsushima4)
Oct.25.2019
International Workshop High-Precision Networks Operations and
Control, Segment Routing and Service Function Chaining
(HiPNet+SR/SFC 2019)

2. Introduction
• Segment routing IPv6 (SRv6)
• Encode the path in each packet
SRv6 based on source routing has many advantages: stateless
traffic steering, state reduction, network
programming and so on

3. Why the translation is required? – (1)
• The data plane of mobile
network has multiple stacking
headers
• Stacking multiple small IDs to
fulfill requirements of reliability,
VPNs, etc.,
• After network failure,
the efficient network path
would not be selected
due to the state of stacking
headers
IPv6 as user
PDN protocol
GTPv1U as
mobile user-
plane protocol
L3 VPN for
mobile core
and back-haul
L2 VPN for
virtual networks
LSP for high quality
and reliability

4. Why the translation is required? – (2)
• Consolidate all layer headers into one single IPv6 layer
*Exist in Segment Routing Extension Header (SRH)
572bits
IPv6 DA (128 bits)
IPv6 SA (128 bits)
Segment-ID [0]* (128 bits)
Segment-ID [1]* (128 bits)
512bits

5. What is GTP-U and SRv6 Stateless
Translation?
• All identifiers of a GTP-U tunnel (IPv4 info. and TEID) can be
embedded as an argument of a Segment ID (SID)

6. Current state of translation method
• The method (SRv6 for Mobile UserPlane) for co-existing GTP-U
has been proposed in IETF
• https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-05
However, there are no suitable measurement platform and
performance evaluation results between GTP-U and SRv6

7. Research goal
• Evaluate the quantitative performance of stateless translation
between GTP-U and SRv6
• Clarify the possibility of co-existence of GTP-U and SRv6

8. How to measure stateless translation?
1. There are no implementations of translation functions and,
unnecessary L2 and L3 functions are involved to the SRv6
2. We cannot measure the latency on a commercial traffic
generator when packet types are changed by the functions
➞ Design and implement GTP-U and SRv6 stateless translation
functions with the minimum H/W resource
➞ Inject nanosecond timestamp as telemetry to measure
the latency at the SRv6 functions

9. Approach
• Focus on the pure performance evaluation of SRv6 functions
on programmable switch on a local environment
• Measurement on traffic generator
• Well-known performance metrics, such as throughput, packet loss and packets
per second (PPS)
• Measurement on programmable switch
• Latency at the SR functions using telemetry

10. Why programmable switch is used?
• The programmable switch is desirable for the measurement
platform
Programmable
switch (Tofino)
VPP (fd.io) Linux Kernel
Throughput
J J
(Depend on CPU cores)
L
Latency
J J
(Depend on VPP graph nodes)
L

11. Programmable switch as SRv6 platform
• Add the L2 forwarding function at the 1st stage (Stage(0)) for the
baseline of latency measurement
• Prepare the primitive functions at the 2nd stage (Stage(1)) for the
performance evaluation of SRv6 functions

12. Measurement with telemetry
1. The 1st timestamp is firstly recorded and the functions are matched by packet headers
2. The 1st timestamp is written into a source MAC address field by the telemetry function
3. The packet is looped back to the switch and the 2nd timestamp is newly recorded
4. The latency between the 1st and 2nd timestamp is calculated, and it is written into
the source MAC by the telemetry function

13. Measurement methodology
• Our measurement method is based on RFC 2544, but slightly
different from the original RFC method

14. Measurement scenarios
• We generate the same number of packets at each scenario
without packet loss
Light (short) Light (long) Heavy (short) Heavy (long)
Packet
size
Throughput Packet
size
Throughput Packet
size
Throughput Packet
size
Throughput
GTP-U
(100 B)
SRv6
(104 B)
100 Mbps
GTP-U
(1514 B)
SRv6
(1518 B)
100 Mbps
GTP-U
(100 B)
SRv6
(104 B)
100 Gbps
GTP-U
(1514 B)
SRv6
(1518 B)
100 Gbps
The worst
condition

15. Average values of PPS and throughput
• Achieve the same number of PPS at the functions
• No abrupt performance changes in the statistics under the scenarios
Light (short) Light (long) Heavy (short) Heavy (long)
PPS Through-
put
PPS Through-
put
PPS Through-
put
PPS Through-
put
GPU-U
(encap/
decap)
100,805 96.7 Mbps 8,127 99.7 Mbps 100,805,260 96.7 Gbps 8,127,358 99.7 Gbps
SRv6
(encap/
decap)
100,805 99.9 Mbps 8,127 99.9 Mbps 100,805,260 99.9 Gbps 8,127,358 99.9 Gbps
SRv6
(trans.)
100,805 99.9 Mbps 8,127 99.9 Mbps 100,805,260 99.9 Gbps 8,127,358 99.9 Gbps

16. Normalized latency at functions
• The baseline is avg. latency of L2 forwarding for the normalized latency
• The latency was noticeably impacted by T.M.Tmap and encap. functions
• The latency was increased when the header size of forwarding packets was
increased regardless of GTP-U and SRv6 function
The latency of SRv6 stateless translation is similar to
GTP-U and their performance degradation is negligible

17. Conclusion and future work
• Conclusion
• The performance gap among the stateless translation, GTP-U and
SRv6, is small and it is negligible under the heavy condition (100
Gbps)
• Present the possibility of the co-existence of GTP-U with SRv6
through the quantitative results
• Future work
• Evaluate various SRv6 functions on other platforms, such as VPP and
Linux Kernel
• Propose and deploy a full 5G network with suitable scenarios for co-
existing with the GTP-U

18. Backup slides

19. GTP-U/SRv6 translation for mobile network
• Mobile devices are only communicated with UPF (GTP-U) on LTE network
• Using Segment routing gateway (SRGW), the stacking headers can be embedded to
SRH and the efficient path can be selected
Embedded to SRH
<Current LTE >
<LTE + SRGW>
Stacking
packets

20. A Current Mobile Network Example
SGiEPCRAN
Access Node
(eNode-B)
GTP-U Tunnel GTP-U Tunnel
L2 Anchor Node
(Serving Gateway)
L3 Anchor Node
(Packet Data
Network Gateway)
Service
Functions
IPv4 IPv4
VLAN, etc.,
IPv4/IPv6
Data-plane
Role
Internet,
Service network
• Well fragmented to RAN, EPC and SGi. <- Redundancies lessen TCO
<- Can be scaled up but costy• Per-session tunnel creation and handling.
<- Hard to meet Apps reqs• Non-optimum data-path.

21. Target functions
• Six primitive functions for the evaluation
Functions Description Sending
packet type
Receiving
packet type
SRv6
(T.M.Tmap)
Translated to SRv6 GTP-U SRv6
SRv6
(End.M.GTP4.E)
Translated to GTP-U SRv6 GTP-U
GTP-U encap. Encapsulated as GTP-U IPv4 GTP-U
GTP-U decap. Decapsulated as IPv4 GTP-U IPv4
SRv6 encap. Encapsulated as SRv6 IPv4 SRv6
SRv6 decap. Decapsulated as IPv4 SRv6 IPv4
Stateless
translation
functions

22. Packet structures for measurement

23. PDF of latency under heavy condition