BGP Signaling for Mobile User Plane

5G User Plane uses N4 signaling between Session Management Function (SMF) and User Plane Function (UPF), and N2 signaling between Access & Mobility Management Function (AMF) and Access Nodes (AN). A traditional UPF device is typically centrally deployed and uses GTP tunnels between itself and ANs for data traffic to/from User Equipment (UEs). The GTP tunnels are set up by the N4 and N2 signaling, and the forwarding model on a UPF is quite different from that on a typical router. UPFs can also be deployed in distributed fashion and still provide persistent IP address for UEs if needed, as described in . Some operators may desire to deploy UPFs that are implemented more like a router with BGP instead of N4 signaling. GTP tunneling can still be used or it can be partially replaced by SRv6/MPLS tunneling. It does not require any change to the 3GPP architecture, signaling and deployment model, but a controller is used to convert N4 signaling to BGP, as described in and [I-D.mpmz-dmm-mup-safi]. The above two drafts are both SRv6 specific. However, BGP signaling from the controller based on N4 signaling can be done without being SRv6 or even SR specific at all. This document specifies corresponding BGP signaling and procedures for both central and distributed deployment models with integration with wireline VPN services as described in , , and [I-D.mpmz-dmm-mup-safi].

Terminologies of 5G, or those used in [I-D.mpmz-dmm-mup-safi] and are omitted here for now. It is expected that audience of this document are familiar with them or can refer to the relevant documents.

The goal of this document is to specify encoding and procedures that work for both MPLS, SR-MPLS as well as SRv6. Therefore, we first look at the SRv6 specific aspects of [I-D.mpmz-dmm-mup-safi].

Per [I-D.mpmz-dmm-mup-safi]:

When a MUP GW receives a BGP Type 2 Session Transform (ST2) Route, which advertises the association of PDU Session TEID (on the UPF side) and a DN VPN, a corresponding Direct Route is matched to set up forwarding state on the GW so that it can decapsulate incoming GTP packets from gNB/AN and then send to the advertising MUP PE of the Direct Route using the Prefix SID in the Direct Route. The Prefix SID has an End.DT2/4/6 or End.DX2/4/6 behavior. In the non-SR case (and SR-MPLS or SRv6 as well), this route can be replaced by the “VPN-IP default route” in . The VRF table label in the route is used to send traffic by the GW to the MUP PE after GTP decapsulation.

Per [I-D.mpmz-dmm-mup-safi]:

Basically, it is a route for a gNB/AN address in the N3RAN. These routes are put into N3RAN RIB. When a MUP PE receives a BGP Type 1 Session Transform (ST1) route, the Endpoint Address in the ST1 NLRI is resolved in the N3RAN RIB, and the Prefix SRv6 SID associated with the Interwork Route, which has the End.GTP4/6.E behavior on the GW, is used send DownLink (DL) traffic from the MUP PE towards the gNB/AN via the GW. In the non-SR case (and SR-MPLS or SRv6 as well), this route can simply be replaced with a regular host route for the gNB/AN. In case of MPLS or SR-MPLS, an “IP/UDP Payload PseudoWire” label for GTP is encoded in an Extended Community so that the MUP PE can use it to send DL traffic with GTP encapsulation but w/o IP/UDP header to the GW, who will add the IP/UDP header and send the resulting GTP packet to the gNB/AN. The PW label is encoded in an EC because only the DL traffic should use the PW label and other traffic towards the gNB/AN should not. In case of SRv6, the same Prefix SID that would be attached to the Interwork Segment route can be attached to the regular gNB/AN host route that replaces the Interwork Segment route.

In [I-D.mpmz-dmm-mup-safi], the ST1 route only has the TEID and endpoint address for the gNB/AN side for DL traffic. For UpLink (UL) traffic, the ST2 route has the TEID prefix and endpoint address for the UPF side, so that the GW can determine which DN the traffic belongs to. It is quite possible that the TEID assigned by the SMF are per-session and do not fall into prefix ranges nicely. Unless the MUP controller intelligently aggregate individual per-session ST2 routes, a MUP GW that also acts as a MUP PE will receive individual per-session ST1 and ST2 routes. For that reason, an optional ST3 route is introduced to combine ST1 and ST2 routes.

A Type 3 Session Transform (ST3) route, and a GTP PW Label Extended Community are specified in this section.

The GTP PW Label Extended Community is a BGP MUP Extended Community of sub-type “GTP PW Label” (value to be assigned by IANA). The encoding is as following:

A new Route Type for BGP-MUP NLRI is added:

It is similar to the ST1 route:

For 3gpp-5g, the Architecture Specific part of the NLRI encodes the <UPF Address, UPF TEID, AN Address, AN TEID, QFI> parameters of the session that the route is for:

The route is a combination of ST1 and ST2 routes, in that: The QFI, AN TEID, and AN Address information correspond to the fields in the 3gpp-5g ST1 Route Type specific BGP-MUP NLRI:

The UPF Address info corresponds to the Endpoint fields in ST2 route:

The UPF TEID field corresponds to the TEID in the 3gpp-5g ST2 Route Type specific BGP-MUP NLRI:

The procedures are inline with those in [I-D.mpmz-dmm-mup-safi] and . Details will be added a future revision.

To be provided.

Requests to be made for the BGP encodings in . Details will be added in a future revision.