Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Performance Evaluation of GTP-U and SRv6 Stateless Translation

53 views

Published on

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.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Performance Evaluation of GTP-U and SRv6 Stateless Translation

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. Measurement methodology • Our measurement method is based on RFC 2544, but slightly different from the original RFC method
  14. 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. 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. 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. 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. 18. Backup slides
  19. 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. 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. 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. 22. Packet structures for measurement
  23. 23. PDF of latency under heavy condition

×