BGP MUP over 6G UP Architecture

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 2 May 2027.¶

Copyright Notice

Copyright (c) 2026 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. Introduction

The MUP architecture [I-D.ietf-dmm-mup-architecture] transforms mobile-session information into routing information and separates segment discovery from session-specific forwarding. The BESS BGP MUP SAFI work [I-D.ietf-bess-mup-safi] specifies the corresponding BGP advertisements for a 3GPP 5G interworking model. Meanwhile, the study of the 6G user-plane evolution in 3GPP considers, potentially, distributed UPFs, i.e., Serving UPFs (S-UPFs), and Anchor UPFs (A-UPFs), along with the control-plane functions [TR.23.801]. Note that the 6G UP architecture is still under the study in 3GPP, possibly with more variations introduced and it is not yet finalized. From the IETF perspective, the DMM document [I-D.dmm-mup-evolution] discusses the potential IETF work upon integrating the proposed enhancements of the 6G UP architecture.¶

This draft proposes to integrates together wireless session mappings, wireline transport reachability, and application-function requirements at a policy-controlled MUP controller or MUP-C. The objective of the integration is to steer traffic toward an eligible data network (DN), edge data center, or AI/agent execution location without requiring the application to speak BGP. The resulting forwarding path must conform to the serving and/or anchor functions as provided by the mobile system.¶

2. Terminology and Scope

The following terms are used in this document:¶

• S-UPF means Serving UPF, A-UPF means Anchor UPF, and AF means Application Function¶

• MUP-PE means MUP-capable Provider Edge, MUP-C means MUP Controller.¶

• ISD, DSD, ST1, and ST2 mean Interwork Segment Discovery, Direct Segment Discovery, Type 1 Session-Transformed, and Type 2 Session-Transformed routes respectively.¶

Note that the 6G AF, S-UPF, A-UPF, or interfaces mentioned here are all conceptual entities which shall be explicitly defined by 3GPP [TR.23.801]. This draft focuses on informational integration framework. It does not specify a new AFI, SAFI, NLRI, 6G reference point, or PFCP extension, etc.¶

3. Proposed Architecture

As illustrated in Figure 1, the mobile management and session control system remains authoritative for UE identity, session authorization, tunnel endpoints, policy, and the required S-UPF/A-UPF chain. The AF expresses service intent, such as proximity to an AI inference cluster, permitted application destination, or latency class, through authorized service/policy functions. A transport-aware orchestrator associates that intent with routable DN or compute-service reachability and candidate MUP segments. It does not place application payloads or AI model state in BGP.¶

       +---------------------+    +------------------+
       |  Mobility/session   |<---| AF / AI service  |
       | and policy functions|    | orchestration    |
       +----------+----------+    +--------+---------+
                  | authorized binding     |
                  +------------+-----------+
                               |
                               v
                    +---------------------+
                    | MUP-C / policy      |
                    | and route selection |
                    +---------+-----------+
                     BGP MUP  |  BGP MUP
                +-------------+--------------+
                |                            |
                v                            v
   UE--RAN--[MUP-PE] ---[S-UPF/A-UPF]--- [MUP-PE]-----DN/DC
                            |          (if required)    ^
                            v                           |
                            +----------->>>-------------+
                           (authorized local breakout path)
         Interwork segment             Direct segment

As shown in the figure, MUP-PEs expose interwork segments toward access-side tunnel networks and direct segments toward DNs or data centers. A PE can be collocated with a UPF or placed beside it. The MUP-C selects an authorized binding between the mobile session and the (wireline) segments, i.e, Interwork or Direct segments, then publishes or updates session-transformed routes. The S-UPF-to-DN breakout and S-UPF-to-A-UPF-to-DN are alternatives selected by mobile policy. They are not simultaneous mandatory hops.¶

4. Service-to-Session Binding and BGP Information

The proposed innovation is a service-to-session binding at the MUP-C, established before any routing advertisement. Its local input record comprises:¶

1. the UE address/prefix and mobile-session identifier;¶

2. authorized access-side and core-side tunnel endpoints and identifiers, where applicable;¶

3. allowed S-UPF, A-UPF, DN, slice, and tenant/VRF context;¶

4. candidate transport reachability and measured path properties;¶

5. an opaque local policy identifier for application or compute-service selection.¶

The MUP-C checks that these inputs describe the same authorized session and policy scope. The policy identifier is a local orchestration state, not a new BGP MUP field.¶

In the existing 5G-oriented MUP design, MUP-PEs advertise ISD routes for access interworking and DSD routes for DN-facing segments. The MUP-C derives ST1 routes from UE prefixes and access-side GTP endpoint information for downlink reachability, and ST2 routes from core-side tunnel information to resolve uplink forwarding toward a direct segment. Route Targets control import and policy isolation. The BESS work defines these four route types under its 3gpp-5g architecture type. It does not by itself define their use for a distinct 6G native user plane. Existing Route Targets or underlying VPN reachability can express separate authorized DNs, without encoding AI placement or compute load in the ST routes.¶

For example, in a 5G-compatible session with UE prefix 2001:db8:1::10/128, access-side GTP endpoint 2001:db8:3::10 and TEID 0x01020304, the ST1 information binds the UE prefix to its access tunnel for downlink. An ST2 route identifies the separately allocated core-side GTP tunnel endpoint and the authorized DN segment for uplink. An ISD route resolves the access endpoint; a DSD route resolves the DN segment. Note that these addresses are illustrative and imply no new route encoding.¶

5. BGP MUP Control-Plane Procedure

The following are the procedure for integrating the mobile and wireline control-plane:¶

1. The mobile control system establishes or updates the UE session, allocates tunnel state where needed, and decides whether S-UPF and A-UPF processing are required. The AF's service request is authorized through the mobile policy domain.¶

2. Eligible MUP-PEs announce ISD and DSD reachability and their SRv6 behaviors when SRv6 is deployed. A separate policy/orchestration function determines eligible transport paths and compute/DN targets.¶

3. The MUP-C validates the service-to-session binding and maps selected DN, VRF, and access reachability to applicable Route Targets and MUP segments. For a compatible 5G interworking session it derives ST1/ST2 advertisements using the BESS MUP SAFI procedures.¶

4. Receiving PEs resolve ST routes against ISD/DSD advertisements, program forwarding state, and retain the required UPF service chain. A new service location or handover triggers recomputation followed by route update/withdrawal and orderly removal of superseded forwarding state.¶

BGP provides routing-state distribution, not 3GPP session establishment or real-time application control. A future native 6G session format, if incompatible with the 3gpp-5g architecture-type encoding, requires separate BESS specification and interoperability analysis rather than overloading existing fields.¶

6. BGP MUP Data Plane over SRv6

For a GTP-U interworking example, the uplink packet starts as UE IP payload, encapsulated by the RAN in outer IP/UDP/GTP-U with a session-specific TEID. At an authorized interwork MUP-PE, processing may translate the GTP-U access transport into an SRv6 service path toward a selected DN-facing PE, optionally traversing an S-UPF or A-UPF that the session requires. At the selected direct segment, an SRv6 End.DT4/End.DT6 service behavior [RFC8986] can decapsulate into the proper tenant/VRF and forward the UE payload toward the DN. This interworking follows the applicable SRv6 mobile user-plane behaviors in [RFC9433]. It does not imply that a transit router can replace UPF policy processing.¶

For downlink, packets addressed to the UE prefix enter the DN-side MUP-PE. The resolved ST1 and ISD information determine the authorized access endpoint, TEID/QFI where applicable, and SRv6/GTP interwork behavior, so delivery can reach the serving access tunnel and then the RAN. End.MAP, as described in [RFC9433], can redirect packets between locally configured SRv6 SIDs at a transit/service node. It is not itself a mechanism for discovering mobile sessions, performing GTP accounting, or selecting AI workloads. Transport segments can be chosen according to policy, but the operator must validate MTU, encapsulation overhead, QoS preservation, and return-path symmetry where required.¶

7. Interoperability and Further Work

Items possibly requiring coordination between DMM, BESS WGs and the 3GPP SDO, along with transport/compute steering work, will include the authoritative 6G session information model, the mapping of serving and/or anchor UPF sets to MUP segments, the safe session-route scaling and aggregation, the handling of multiple compute destinations sharing a DN prefix, the security of the MUP-C northbound interface, and whether genuinely new architecture-type, NLRI, or TLV encodings are necessary. A deployment can first use existing 5G-compatible MUP interworking and out-of-band policy selection, while the 6G architecture is still evolving and the native 6G encoding is studied separately. This limits unnecessary changes to the BGP control plane.¶

8. Security Considerations

Exposing subscriber-derived session information to BGP creates privacy, denial-of-service, route-injection, and cross-tenant isolation risks. The MUP-C and its northbound inputs require authenticated, authorized and integrity-protected access. BGP adjacencies and Route Target import/export policies require operator-controlled trust boundaries. Only data needed for forwarding should be advertised; subscriber identities, raw application requests, and sensitive AI workload metadata should not be placed in BGP NLRIs or communities. Operators need route-update rate limits, withdrawal handling, state expiration, and auditability. SRv6 SIDs and behaviors must be confined to a trusted domain consistent with [RFC8754] and [RFC9433].¶

9. IANA Considerations

This document requests no IANA allocations. Any future 6G-specific BGP MUP architecture type, TLV, or route-type extension would require a separate standards-track specification and corresponding IANA review.¶

Authors' Addresses