BGP Signaling for Mobile User Plane

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 8 September 2022.¶

Copyright Notice

Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Background

5G [_3GPP-23.501] 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 [I-D.zzhang-dmm-5g-distributed-upf].¶

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 [I-D.mhkk-dmm-srv6mup-architecture] 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 [I-D.zzhang-dmm-5g-distributed-upf], [I-D.mhkk-dmm-srv6mup-architecture], and [I-D.mpmz-dmm-mup-safi].¶

2. Analysis of SRv6 specific aspects of [I-D.mpmz-dmm-mup-safi]

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].¶

 "The Discovery Direct route is generated by the MUP PE when a routing
 instance accommodates a Direct type MUP Segment, e.g., N6 interface or
 routes on DN side in 3GPP 5G specific case.  It generates the
 Discovery Direct Route per each routing instance for the MUP Segment."

 "The Discovery Interwork route is generated by the MUP GW when a
 routing instance accommodates an Interwork type MUP Segment, e.g., N3
 interfaces or routes on RAN side in 3GPP 5G specific case.  It
 generates route per each N3RAN IP prefix and stores the route in the
 routing instance of N3RAN.  The IP prefix MAY include a gNodeB
 address which is connecting to the MUP GW."

3. Optional Type 3 Session Transform (ST3) 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.¶

4. Specifications

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=MUP EC   | Sub-Type=TBD  |  Reserved=0                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Reserved=0   |          GTP PW Label                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       + 5 - Type 3 Session Transform (ST3) route;

     +-----------------------------------+
     |           RD  (8 octets)          |
     +-----------------------------------+
     |      Prefix Length (1 octet)      |
     +-----------------------------------+
     |         Prefix (variable)         |
     +-----------------------------------+
     | Architecture specific (variable)  |
     +-----------------------------------+

     +-----------------------------------+
     |          QFI (1 octet)            |
     +-----------------------------------+
     |       AN TEID (4 octets)          |
     +-----------------------------------+
     |     AN Address Length (1 octet)   |
     +-----------------------------------+
     |     AN  Address (variable)        |
     +-----------------------------------+
     |      UPF TEID (4 octets)          |
     +-----------------------------------+
     |     UPF Address Length (1 octet)  |
     +-----------------------------------+
     |     UPF Address (variable)        |
     +-----------------------------------+

5. Security Considerations

To be provided.¶

6. IANA Considerations

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

Authors' Addresses