Segment Routing IPv6 for mobile user-plane PoCs
draft-camarillo-dmm-srv6-mobile-pocs-01

Abstract

This document describes the ongoing proof of concepts of [I-D.ietf-dmm-srv6-mobile-uplane] and their progress.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 25, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. M-CORD C3PO
• 3.1. PoC phases
• 3.2. Activity report
• 3.2.1. Phase 1
• 4. Open Air Interface
• 4.1. PoC phases
• 4.1.1. Phase 1: Mobile Core Migration from IPv4-GTP to SRv6
• 4.2. Activity report
• 5. Contributors
• 6. Informative References
• Authors' Addresses

1. Introduction

The [I-D.ietf-dmm-srv6-mobile-uplane] proposes SRv6 as userplane protocol for mobile networks. As part of this work we have decided to create a series of PoCs with the objective to prove the viability and feasibility of such proposal.

For this reason we have two ongoing PoCs using M-CORD C3PO and OAI, that are progressing towards a full implementation of the mechanisms described in such I-D.

This I-D contains a formal definition of the PoCs and will summarize it's findings. Anyone interested in participating in the ongoing PoCs or propose new ones is welcome to join us.

2. Terminology

This document adopts the terminology of [I-D.ietf-dmm-srv6-mobile-uplane].

This document uses the terms N3, N6 and N9 interfaces, as well as UPF and gNB as refered to in [TS.23501].

3. M-CORD C3PO

M-CORD <https://www.opennetworking.org/m-cord/> is an open-source project from ONF focused on building a cloud-native virtualized and dissagregated RAN and EPC.

As part of the M-CORD project, the C3PO component is part of the NGIC (Next Generation Infrastructure Core) <https://gerrit.opencord.org/#/admin/projects/ngic>.

The scope of this PoC is to extend the C3PO component to support natively SRv6 on the N6 and N9 interfaces and have SRv6-supported UPFs.

3.1. PoC phases

This PoC is divided in several phases:

1. SRv6 in transport network with no impact to EPC
2. SRv6 native in N6 interface (GiLAN) with SRv6 transport network
3. SRv6 native in N6 and N9 interfaces with N3 interworking mechanisms

3.2. Activity report

Phase 1 has been completed. Ongoing development of phase 2.

3.2.1. Phase 1

We used FD.io VPP <https://fd.io/technology/> to simulate an SRv6 transport network with three SRv6 routers in the N9 interface simulating a transport network.

As part of this transport network, we run two simulations:

In the first simulation we steered the IPv4/GTP traffic into an SR policy that encapsulated the packet with an SRv6 header containing two SIDs.

In the second simulation we steered the IPv4/GTP traffic into an SR policy that removed the IPv4/GTP headers and placed the GTP header information (i.e. TEID) into an SRv6 SID. The last SID of the SR policy corresponds to an End.M.GTP4.E function, that decapsulates SRv6 traffic restoring the IPv4/GTP header. The objective of the second simulation is to show the IPv4/GTP interworking mechanism via an uplink classifier behaving as SR-GW, as defined in Section 6.4 of [I-D.ietf-dmm-srv6-mobile-uplane] .

After Phase 1, we concluded that SRv6 as mobility transport network works fine, with an expected MTU overhead due to the original PDU encapsulation. The IPv4/GTP interworking mechanism in the scope of phase 1 is also fully functional. This mechanism will be further tested as the POC progresses and a native SRv6-based UPF is developed.

4. Open Air Interface

Open Air Interface (OAI) is an open-source software <http://www.openairinterface.org/?page_id=2762> that implements the 3GPP stack. OAI is composed of two major projects: OAI-RAN and OAI-CN.

• OAI-RAN implements the 4G LTE and 5G Radio Access Network. Both the gNB as well as the UE are implemented.
• OAI-Core Network implements the 4G LTE Evolved Packet Core (EPC) and 5G Core Network.

The scope of this PoC is to extend the OAI-RAN and OAI-CN components to support natively SRv6 on the N3 and N9 interfaces, and have SRv6-supported gNBs and UPFs.

4.1. PoC phases

The primary goal of this POC is to show SRv6 as a data plane replacement for GTP on both N3 and N9 interfaces. The POC also aims to demonstrate a smooth migration path during deployment and transition period from IPv4-GTP and IPv6-GTP to an end to end SRv6 data plane.

The PoC functions within the existing OAI model. OAI currently doesn't provide support for S5/S8 interface. The implementation instead provides an integrated SGW and PGW S/PGW module and therefore there is no GTP tunnel between these two entities. This limitation has an impact on the POC strategy and its implementation phases.

This PoC is divided into several phases:

1.-

N3 via SRv6 GW VNFs and no impact on 3GPP control plane.

1.1.-

Mobile Core Migration from IPv4-GTP to SRv6

1.2.-

Mixed IPv4-GTP/IPv6-GTP Mobile Core Over SRv6

2.-

N3 via SRv6 eNB and S/PGW integrated modules and no impact on 3GPP control plane.

2.1.-

Mobile Core Migration from IPv4-GTP to SRv6

2.2.-

Mixed IPv4-GTP/IPv6-GTP Mobile Core Over SRv6

3.-

N3 via SRv6 support of ID-LOC architecture

Important notes:

-

The above phases and solution strategy can easily be extended to the N9 interface. However, although the N9 interface is well within the scope of this PoC, the effort required to changes the OAI code base to support S5/S8 and separate SGW and PGW modules will push the project well beyond the timeline of this PoC and as such are not currently part of the PoC.

-

Support for service programming, TE, QoS, entropy, and other enhanced features are also within the scope of this PoC, but will also fall beyond the time line of this project and are not currently considered in this PoC.

-

The above items can be pulled back into the project based on demand and assistance from others.

4.1.1. Phase 1: Mobile Core Migration from IPv4-GTP to SRv6

Phase one of this POC focuses on demonstrating a smooth migration path from the existing mobile core networks with IPv4 GTP based user plane to SRv6 user plane with absolutely no impact on 3GPP control plane. The idea is to employ SRv6 gateways between mobile core equipment such as eNB, SGW, and PGW, intercept GTP traffic, and carry UE's payload through SRv6 newtwork by encoding GTP information into the SIDs.

In this POC as it was mentioned earlier we use OAI open source software. OAI implements gNB as an stand alone entitiy, but bundles MME, SGW and PGW into a single package. We employ three Linux PCs in oursetup. Two of these machines run the gNB and one of the SRv6 GWs. The thrid machines employs virtualisation and instantiates two virtual machines. The second SRv6 gateway runs in one of the virtual machine while the other virtual machines executes the code for the combinged MME, SGW, PGW. The code in SRv6 gateways is based on VPP implementation in Linux Foundation. We modified this code to intercept GTP packets, extract GTP information, and encode GTP information into the SIDs. Given that today's mobile core don't deal with multiple UPFs, the resulting SRv6 haeader doesn't require any SRH to carry GTP information across the network. Therefore, in this phase, the resulting SRv6 packets are simply IPv6 packets with their DA set to SIDs. The following diagratm shows the POC configuration.

                                            +--------------------------+
                                            |                +========+|
  +--+    \|/                               |                | +---+  ||
  |UE|     |                                |                | |HSS|  ||
  +--+     |                                |                | +-+-+  ||
        +--+                                |                |   |    ||
        |                                   |                | +-+-+  ||
      +-+                                   |                | |MME|  ||
      |                                     |                | +---+  ||
      |                    GTP<->SID        |  GTP<->SID     |        ||
  +---+---+   +-----+      +--------+       | +========+     |+------+||
  | USRP  |   |     |      |        |       | |        |     ||      |||
  |(Ettus +---+ gNB +-GTP--+ SRGW-1 +--SRv6-|-+ SRGW-2 +-GTP-|+ SPGW |||
  | B210) | ^ |     |      |        |       | |        |     ||      |||
  +-------+ | +-----+      +--------+       | +========+     |+--+---+||
            |                               |   VM-1         |   |    ||
           USB                              |                |   |    ||
                                            |                +========+|
                                            |               VM-2 |     |
                                            |                    |     |
                                            +--------------------|-----+
                                                                 |
                                                                 |
                                                                 DN

             

POC Configuration

In this implementation, the SRGW at one end extracts relavant GTP informaton(SA, DA, TEID) from GTP and encodes them into the lower 96 bits of SID. The SID is then copied into the DA of IPv6 header and the packet is forwarded toward the SRGW at the far end. Receiving the SRv6 packet, the far end SRGW recognises the SID as local and executes a set of functions that extracts GTP information from the SID, forms the GTP packet by adding relevant UDP and GTP headers and forward this reconstructed GTP packet to its associated mobile core node.

4.2. Activity report

Development started. Phase 1 has been completed.

5. Contributors

Chenchen Liu
Huawei Technolgies Co., Ltd.
Shenzhen, China

Email: liuchenchen1@huawei.com

Arun Rajagopal
Sprint
United States of America

Email: Arun.Rajagopal@sprint.com

Mark Bales
Sprint
United States of America

Email: Mark.Bales@sprint.com

Robert Butler
Sprint
United States of America

Email: Robert.Butler@sprint.com

6. Informative References

Authors' Addresses