Why the Mobile User Plane Is the Way It Is

Why the Mobile User Plane Is the Way It Is SoftBank

Japan satoru.matsushima@g.softbank.co.jp

The Mobile User Plane (MUP) architecture transforms session information from a mobile service system into routing information, so that ordinary routing nodes can take on the roles of user plane anchors and intermediate points. The architecture document that defines MUP is a normative text: it defines concepts, route types, and resolution procedures, but it does not explain why they are the way they are. This companion reader supplies that "why", outside the normative text. The technical content follows one worked example end to end, with concrete prefixes, SIDs, and tunnel endpoint identifiers, and follows the architecture document throughout. The explanations are organized around a small set of shapes that recur in the design: places deliberately left undecided, meaning that arises only when two pieces of information meet, and a strict separation between a name and the thing it points at. The Introduction gives these shapes a name borrowed from Zen, once, and then lets them do their work quietly. This document is not normative. It defines no protocol and no encoding.

Introduction This document is a companion reader to the SRv6 MUP (Mobile User Plane) architecture. Before anything else, however, there is one thing to settle: how to read it. Read MUP as Zen. This is not, of course, a claim that the designers of MUP designed it by reference to Zen. It is, rather, the observation that if you follow MUP's design decisions one by one, the same shapes keep appearing — shapes that Zen has, for a very long time, put into words. Treat this as a declaration of a discipline of reading, offered to the reader. The shapes that appear are, for example, these. Not deciding is itself a design decision. The architecture does not decide whether a segment is on the access side (). An ST2 route does not carry the prefixes of its destinations (). The architecture document itself carries no encoding (). None of these is an "undecided" point or an omission: each is a place deliberately left empty, for the sake of the freedom that not deciding opens up. What Zen calls emptiness (ku) does not mean that something is missing; it points, instead, to the margin that lets a thing do its work. Meaning is not in things; it arises when they meet. An ST route, on its own, cannot forward anything, because it carries no SID. A segment advertisement (a DSD or ISD route), on its own, does not say which session it concerns. Only when the two meet inside a MUP PE and are resolved does the meaning of a forwarding action arise for the first time. Meaning does not reside in individual things; it stands up in the relations between them. On the Zen side, this structure has long been called dependent origination (). A name is only a finger pointing at a thing. A SID is not a segment (Sections and ). A label is not a role (). A finger points at the moon, but the finger is not the moon. Get caught up in the name, and you mistake the thing itself. Many of the misunderstandings of MUP are born of exactly that mistake. Clinging to what is fixed makes the path longer. A user plane tied to an anchor takes the long way around even to a nearby server (). Each time one fixation is removed, the path becomes freer. In the end, that is what this document writes about, again and again. Tools are not made; they are borrowed. Using BGP for distribution is a choice to restrain the appetite for a new mechanism and to ride on what already exists (). Say only what needs to be said, and leave the rest elsewhere. The division of labour between documents is made of the same attitude. And the final chapter takes the form of a mondo, a question-and-answer dialogue (). A mondo is not a device for adding doctrine. It is a form for watching misunderstandings come undone. At the head of each chapter, a single line states that chapter's thread of reading. The technical content of every chapter is, as before, built from the text of the architecture document, draft-ietf-dmm-mup-architecture , and from examples with concrete values. Zen is a layer of reading laid over that. The boundary between what the text asserts and what belongs to the reading is recorded in the author's checking notes at the end of each chapter. Now, to — and first, to what we are tied to.

Why the User Plane Is a Problem

A fixed exit makes for a detour.

The way to read this companion is as declared in the Preface (preface.md): read MUP as Zen. The main document, draft-ietf-dmm-mup-architecture, defines the concepts of MUP, the types of its routes, and the procedures for resolving them, as a normative text — but it does not write about why things are the way they are. In a normative document, justification and background are not the job of the main text. This companion exists to put that "why" outside the normative text. The job of is to establish the starting point: what shape the mobile user plane has today, and where, in that shape, the problems lie. This is explained as structure, not as criticism.

The Current Shape: Tunnels and an Anchor Reduce the 5G user plane, roughly, and it has the following shape.

A packet from a terminal (UE) is placed, at the base station (gNB), into a tunnel called GTP-U.
The far end of the tunnel is a node called the UPF. The UPF behaves as the anchor of the session, and the IP address of the terminal has its meaning relative to the UPF.
Beyond the UPF, ordinary IP routing carries the packet out to a data network (DN).

For as long as the session lasts, packets pass through this anchor. Even when the terminal moves and its base station changes, re-establishing the tunnel preserves the property that "the exit is the same UPF." Session continuity holds because of this shape. As a mechanism for handling mobility, the model of GTP and an anchor is well made. The problem is what gets fixed in exchange for those virtues. The following sections take what is fixed apart into three pieces.

Problem 1: Concentration on the Anchor, and the Long Way Around That the anchor is fixed means that the path of the traffic is determined not by where the destination is, but by where the anchor is. Suppose a server sits right next to the terminal, but the UPF that anchors that session is far away. The packet is then carried once to the distant UPF and only then comes back. The more use cases arise that want processing done nearby — edge computing being the obvious one — the more conspicuous this detour becomes. RFC 7333 , which sets out the requirements for Distributed Mobility Management (DMM), raises precisely this point in its first requirement (REQ1). In substance, it says that a mobility solution must make it possible to avoid the situation in which traffic is forced to traverse a single mobility anchor located far from the optimal route. The Introduction of the main document, draft-ietf-dmm-mup-architecture, quotes this requirement because MUP is designed as an answer to this problem. Distribute the anchor — that is, create an exit nearby, per session or per service. The direction itself was already known. The difficulty is in the mechanism by which it is to be achieved.

Problem 2: The Separation of the Tunnel Layer and the Forwarding Layer The second problem concerns how paths are decided. To the transport network, a packet travelling inside a GTP tunnel is nothing more than "one flow from the gNB to the UPF." Whatever the inner destination may be, the routing of the transport network sees only the two endpoints of the tunnel. The choice of path is determined by the positions of the tunnel endpoints, and the destination and requirements of the inner flow do not enter into the transport network's decisions. Put differently, two layers are being optimised separately.

The mobile layer manages sessions and tunnels. But it has no flexibility over the actual path.
The transport layer has the power to compute paths. But it knows nothing about sessions.

As long as this separation stands, judgements about the path of an individual session — "this session to the nearby server," "this session through another exit" — arise naturally in neither layer. What is available is adjustment at the granularity of moving a tunnel endpoint or rearranging the placement of UPFs.

Problem 3: Inflexible Paths, and Intermediate Functions Fixed in Place The third problem follows from Sections and .

Because the exit (the anchor) is fixed in association with the session, it is hard to re-choose the exit in response to where the traffic is going or to the state of the network.
The intermediate functions a packet passes through — the various kinds of processing borne by the UPF — are likewise fixed onto the path. Moving the place where processing happens becomes a change to the configuration of the network.

In short, the current shape is stable for the purpose of "keeping sessions continuous," but rigid for the purpose of "recomposing the path as occasion demands." This rigidity is not a matter of good or bad implementation; it is a property of the model itself — of tunnels and an anchor. That is why this chapter treats it as a matter of the structure of the model, and not as a criticism of GTP.

So What Is Needed? Turn the three problems over, and what is needed comes into view.

Avoid concentration on an anchor, and be able to deliver each session to a nearby exit ().
Let the facts of a session enter into the decisions of the transport layer. That is, rather than sessions and routing being optimised separately, let the path be assembled from the information of the session ().
Let paths be unfixed, so that they can be exchanged later, and chosen place by place ().

The core idea of MUP lies in the second of these. Transform session information into routing information. Take the facts of the mobile side — the two ends of a session, the address of a UE — transcribe them into a form the routing world can handle (a route), and distribute them to general-purpose PEs, and the path assembles itself by the ordinary machinery of routing. A node need not be a dedicated anchor in order to serve as the exit for a session. Doing this, of course, raises new problems. A step comes to stand between the facts of a session and the behaviour of forwarding (), the role of a segment can no longer be fixed (), and tools for distribution, together with a division of labour between documents, become necessary (). The remaining chapters of this companion explain what is gained in exchange for those costs. But first, it is quicker to watch the thing move. In the next chapter, we stop talking about definitions and follow a single example — one terminal only — from beginning to end, with concrete address values.

Walking Through the Core Idea with a Single Example

The finger is not the moon.

We do not start from definitions. First, we follow a single example, involving just one terminal, from beginning to end -- and we follow it with actual addresses, not symbols. What we want the reader to take away from this chapter is not memorized terminology. It is the following single flow:

Session information is born -> it becomes routing information (an ST route) -> it is matched against segment information distributed by a separate path and resolved -> as a result, a SID and a forwarding behavior are decided -> a packet flows

MUP is hard to follow because this flow is not a straight line from start to finish. The session information, the destination of a packet, and the SID actually placed on the packet each come from a different source. In this chapter, we deliberately postpone the explanation of why, and first show the way these pieces appear separately and merge along the way. Why they are separated is the job of . The example is the one in Section 7.2 of the base document (draft-ietf-dmm-mup-architecture-03): a 3GPP 5G network, with PEs on which MUP is enabled placed at the edges of an SR domain. The base document writes it with symbols such as U/u, V/v, and S1::; here, as in below, we assign concrete values to everything. The values are examples for this chapter only: documentation address ranges (203.0.113.0/24 and 198.51.100.0/24) are used for the UE and the N3 network, 2001:db8::/32 for the SIDs, and private addresses (10.10.0.0/16) for the DN. Note that in this chapter the user plane is uniformly IPv4. The address of the UE and the addresses of the servers in the DN are IPv4. That does not mean IPv6 disappears altogether: an SRv6 SID is an IPv6 address, so the SIDs alone remain IPv6. This two-layer structure -- "the user's packets are IPv4; transport inside the domain is SRv6" -- is worth distinguishing from the start, so that the two do not get mixed up later.

The Cast: One Terminal and Three PEs First, we hand over the list of values up front. Every address that appears in this chapter is in this table. Assignment of concrete values in this section

Symbol in the base document	Value in this chapter	What it is
UE address U/u	203.0.113.100 (as a route, 203.0.113.100/32)	The IPv4 address assigned to the terminal. An IPv4 UE has a single address, so the prefix is a /32
N3 network V/v	198.51.100.0/24	The GTP-U transport network on the radio (RAN) side
gNB	198.51.100.10	The N3-side address of the base station
UPF (N3 side) X/x	198.51.100.20 (treated as a /32)	The N3-side address of the UPF
DN (S1 side) E/e	10.10.1.0/24, server A is 10.10.1.10	The data network near S1
DN (S2 side) W/w	10.10.2.0/24, server B is 10.10.2.10	The data network near S2
SRv6 locator of S1	2001:db8:100::/48	All SIDs of S1 come out of this range
SRv6 locator of S2	2001:db8:200::/48	All SIDs of S2 come out of this range

The scene is as follows. There is one UE, hanging off a gNB. The data network side is split between two locations: server A is near PE S1, and server B is near PE S2. There is also a conventional UPF, hanging off PE S3. S3 does not have MUP enabled; it is an ordinary L3VPN PE. What matters here is that the UPF has not disappeared. In this example, MUP applies only to the traffic of the single session described below. The traffic of the other UEs passes through the UPF via S3, as before. MUP is not a declaration that the existing user plane will be replaced; it is a mechanism that lets the path of a specific session be assembled by routing. The PEs on which MUP is enabled are S1 and S2. These two become MUP PEs.

The cast of the worked example How to read the diagram is simple: the left side is the radio side, and the right side is the data network side. All that happens from here is that, within this diagram, "how to deliver to 203.0.113.100" and "how to deliver from 203.0.113.100" are assembled from session information.

Before Any Packet Arrives, the Segments Have Already Introduced Themselves Before we get to the story of the session, something has already been done: each MUP PE has announced, to the whole domain, the segments it hosts. A segment here is something different from a segment in SR. A MUP segment is an abstraction of a network or a service attached to a MUP PE. It is not a node, and it is not the stretch of network between PEs. It is a declaration: "beyond this PE, there is a network or service of this kind." The introductions of S1 and S2, with concrete values, are as follows. S1 -- the radio side (Interwork Segment)

It advertises, with an Interwork Segment Discovery (ISD) route, that it hosts the N3 network 198.51.100.0/24. This is the ISD route for V/v in the base document.
Along with it, it attaches the SRv6 SID 2001:db8:100:1::, which is S1:: in the base document's notation. We take its behavior to be End.M.GTP4.E, that is, "convert a received SRv6 packet into a GTP-U packet (IPv4 transport) and send it out toward the radio side" (in this chapter, the GTP-U transport is fixed to IPv4).

S1 and S2 -- the data network side (Direct Segment)

Both advertise their own N6DN as a Direct Segment (a Direct Segment Discovery, or DSD, route). The identifier that refers to this segment is D1.
S1 attaches the SID 2001:db8:100:2:: (S1:1:: in the base document), and S2 attaches the SID 2001:db8:200:2:: (S2:: in the base document). The behavior of both is End.DT4, that is, "remove the encapsulation and look the destination up again in the routing instance of that segment (in this case, the N6DN)."

Note also the pattern in the SID values. Both of S1's SIDs lie within the locator 2001:db8:100::/48, and the trailing part (:1:: or :2::) distinguishes the behavior. For S2's End.DT4, only the locator changes, to 2001:db8:200::/48, and the part expressing the behavior is the same :2:: as S1's. "Which PE, and which behavior" is expressed in the shape of the address itself. At this point, hold on to just one distinction, which will matter later. A SID is not the segment itself. A SID identifies a forwarding behavior executed by the MUP PE that hosts the segment. That is why, for one and the same Direct Segment D1, there are separate SIDs for S1 (2001:db8:100:2::) and for S2 (2001:db8:200:2::). A segment is "what is out there"; a SID is "what to have this PE do in order to deliver there." At this point, the RIB of, say, S2 conceptually contains information like the following (the display format is a pseudo-display for purposes of explanation).

RIB of S2, before any session arrives ISD 198.51.100.0/24, from S1: SID 2001:db8:100:1:: (End.M.GTP4.E) DSD segment D1, from S1: SID 2001:db8:100:2:: (End.DT4, N6DN) DSD segment D1, local: SID 2001:db8:200:2:: (End.DT4, N6DN) However, these introductions (the DSD / ISD routes) alone do not yet decide what to do with which UE's packets. The introductions only prepare "candidate destinations and how to deliver to them." Which session they will be used for is decided only when the session information of the next section arrives.

Session Information U1 Is Born Now the UE (203.0.113.100) starts communicating. In the mobile system, one piece of session information is created for this UE. In this chapter, following the base document, we call it U1. The contents of U1 are written in the words of the mobile world, not in the words of routing. Written out with values, the information is as follows.

Session information U1 UE address : 203.0.113.100 (treated as a /32) gNB-side F-TEID (downlink) : IP 198.51.100.10, TEID 0x00001001 UPF-side F-TEID (uplink) : IP 198.51.100.20, TEID 0x00002001 QFI : 9 An F-TEID is the pair of "the destination IP address of the tunnel plus the TEID (tunnel identifier)" that identifies an endpoint of a GTP-U tunnel. On the downlink, the gNB is the receiving endpoint, so the gNB's pair is recorded; on the uplink, the UPF is the receiving endpoint, so the UPF's pair is recorded; these are the two ends of the session. This is a statement of fact: "the two ends of the tunnel are here." By itself, it still does not tell S1 or S2 what to write into their FIBs. An F-TEID is not a route, and the SID for delivering to 203.0.113.100/32 (2001:db8:100:1::) is not written here either. Filling that gap is the transformation at the core of MUP.

The MUP-C Transforms Session Information into Routes The session information is handed to the MUP Controller (MUP-C). The MUP-C has a single job: to transform the session information received from the mobile system into routing information, and to advertise it to the MUP network. The result of that transformation is the Session Transformed route, or ST route for short. From U1, two ST routes are born. There is a reason there are two: on the downlink and on the uplink, "what a packet is matched on" differs.

The ST1 Route, for the Downlink The downlink is the traffic from the DN side toward the UE. The destination can be looked up by the IP prefix 203.0.113.100/32. The ST1 route therefore has the form closest to an ordinary route.

ST1 route (advertised by the MUP-C) NLRI : 203.0.113.100/32 Session info : gNB F-TEID 198.51.100.10 / 0x00001001, QFI 9 Route Target : 65000:3 (C3 in the base doc; imported by N6DN) That is, ST1 expresses the reachability "203.0.113.100/32 is reachable via the radio-side endpoint of this session (198.51.100.10, TEID 0x1001)." Note, however, that ST1 itself carries no SID. "Behind which PE is that endpoint?" and "by which SID is a packet to be delivered there?" are not written in ST1. They are decided in the next stage, resolution, by matching against the introductions of .

The ST2 Route, for the Uplink The uplink is the traffic from the UE toward the DN side. Here the picture differs. What S1 receives from the radio side is a GTP-U packet, and its outer destination is not the UE's communication peer but the F-TEID of the UPF, namely 198.51.100.20 / TEID 0x00002001. Before looking at the contents of the packet (the inner destination), it is first necessary to match on "a packet addressed to this tunnel endpoint belongs to this session." So what the ST2 route carries is not a destination prefix.

ST2 route (advertised by the MUP-C) Matching key : UPF F-TEID = 198.51.100.20 / TEID 0x00002001 MUP community : D1 (the destination is Direct Segment D1) Route Target : 65000:2 (C2 in the base doc; imported by N3RAN) Note: it does not carry a destination prefix ST2 expresses, in the form of a route, the instruction: "for a packet that arrives addressed to TEID 0x2001 at 198.51.100.20, remove the encapsulation and look the destination up again within Direct Segment D1." Here, too, ST2 itself does not decide which PE's which SID (2001:db8:100:2:: or 2001:db8:200:2::) D1 will become.

Summary So Far The two routes of session U1, side by side

	ST1 route (for the downlink)	ST2 route (for the uplink)
Source session information	203.0.113.100/32, gNB F-TEID (...100.10 / 0x1001), QFI 9	UPF F-TEID (...100.20 / 0x2001)
How packets are matched	The inner destination prefix 203.0.113.100/32	The tunnel endpoint 198.51.100.20 / TEID 0x2001
What it does not carry	The SID to deliver with	A destination prefix; the SID to deliver with
Discovery route used for resolution	ISD route	DSD route

Both are the facts of a session transcribed into the form of a route, but as they stand, neither can forward. The SID is still missing. The next stage is the one most easily overlooked in MUP.

Resolution: Where ST Routes and Introductions Meet A MUP PE does not write a received ST route into the FIB as-is. First, it checks whether the reachability of that ST route can be resolved with the DSD / ISD routes it has received and holds. Only when resolution succeeds does a forwarding entry using the corresponding SID come into being. For U1, it goes as follows. Resolution of ST1 (downlink)

S1 and S2 look up the reachability of the radio-side endpoint, 198.51.100.10, that ST1 points to, using ISD routes.
198.51.100.10 is contained in the ISD route's 198.51.100.0/24. The match is the ISD route that S1 advertised.
As a result, the SID that was attached to the ISD route, 2001:db8:100:1::, goes into the FIB entry for 203.0.113.100/32.

The FIB of S2 conceptually looks like this.

FIB of S2 (N6DN, after resolution of ST1) 203.0.113.100/32 -> attach SID 2001:db8:100:1:: and forward to S1 (retained: gNB F-TEID 0x1001, QFI 9) 10.10.1.0/24 -> ordinary route toward S1 (to server A) 10.10.2.0/24 -> locally connected (to server B) Only now does the way downlink packets are delivered become concrete. "For destinations to 203.0.113.100/32, use the behavior of 2001:db8:100:1::" was written neither in the session information nor in ST1. ST1 (the facts on the session side) and the ISD (the introduction on the segment side) were distributed separately, met inside the receiving MUP PE, and only then was this information born. Resolution of ST2 (uplink)

S1 looks up the Direct Segment community D1 attached to ST2, using DSD routes.
Two PEs announce D1: S1 itself (SID 2001:db8:100:2::) and S2 (SID 2001:db8:200:2::). S1 adopts its own local N6DN as D1 (this is the choice to prefer the closer segment).
As a result, for packets matching TEID 0x2001, a forwarding entry is created for the processing "terminate the GTP-U, and look the contents up in the local N6DN."

Forwarding entry of S1 (N3RAN, after resolution of ST2) Matches GTP-U dst 198.51.100.20, TEID 0x00002001 -> decapsulate, and look the inner packet up in the N6DN (= the behavior of the local End.DT4, SID 2001:db8:100:2::) Note that, for an ST route that fails to resolve, no forwarding entry is created. In that case, packets matching that prefix or endpoint follow the ordinary IP routing of the routing instance. MUP applies only to "the sessions that could be resolved"; it is not a mechanism that drops the ones it cannot resolve onto a broken path. This completes the preparation. On the control plane, in the end, the following three things were distributed separately and met at the receiver:

The introductions of the segments (the DSD / ISD routes, and their SIDs and behaviors)
The routes transformed from the session (the ST1 / ST2 routes)
The procedure of resolution, which matches the two against each other

Now Let the Packets Flow Now we run actual packets, one round trip. For both, we write the header values as well.

Downlink: from Server B to the UE Suppose a reply packet leaves server B (10.10.2.10) for the UE (203.0.113.100).

Downlink packet flow (1) Within the DN (until it reaches S2) IPv4 src 10.10.2.10 -> dst 203.0.113.100 (2) In the N6DN FIB of S2: 203.0.113.100/32 -> SID 2001:db8:100:1:: SRv6 dst 2001:db8:100:1:: (the original packet is kept inside) (3) S1 executes the behavior of the SID, End.M.GTP4.E GTP-U/IPv4 src (N3 addr of S1) -> dst 198.51.100.10, TEID 0x1001 QFI 9 in the PDU session container Inside is the original IPv4 packet (dst 203.0.113.100) (4) The gNB ends the GTP-U and delivers it to the UE, 203.0.113.100 What deserves attention is that, at step (3), S1 goes back to "the mobile way of doing things." Inside the domain, packets are carried by routing and SRv6; only at the final exit are they converted into the user-plane protocol that the peer understands (here, GTP-U). What the term Interwork Segment refers to is this conversion at the exit. Note that how the SID appears in the packet that leaves S2 in step (2) depends on whether the ingress is remote or local (Section 7.2 of the base document contains a note to the effect that, in a packet from the local E/e to U/u, S1:: does not appear on the wire). This chapter confines itself to the point that "as a result of resolution, the packet heads toward the behavior of S1," and does not distinguish the wire format.

Uplink: from the UE to Server A This time, suppose a packet leaves the UE (203.0.113.100) for server A (10.10.1.10), which is near S1.

Uplink packet flow (1) The inner packet sent by the UE IPv4 src 203.0.113.100 -> dst 10.10.1.10 (2) The gNB puts it in GTP-U, addressed to the UPF (as usual) GTP-U/IPv4 src 198.51.100.10 -> dst 198.51.100.20, TEID 0x00002001 Inside is the packet of (1) (3) It reaches the N3RAN of S1; outer dst and TEID match the ST2 key (198.51.100.20 / 0x2001) -> terminate the GTP-U, and look the inner packet up in the N6DN (4) The FIB of the N6DN: 10.10.1.0/24 is locally connected -> it is delivered to server A, 10.10.1.10, as-is On the uplink, the packet does not pass through the UPF. A packet that the gNB sent addressed to the UPF (198.51.100.20) is received along the way by S1, based on the session information; S1 removes the encapsulation and hands it directly to the routing on the DN side. That is the substance of what MUP is doing in this example. It is not that "the UPF disappears"; it is that "for this session, a path that can deliver without passing through the UPF is assembled from routing." If the destination were server B (10.10.2.0/24), everything is the same up to step (3). The difference is in the result of the re-lookup in step (4): the packet is carried toward S2, following the ordinary routing of the N6DN. And, to repeat, the target is only the session of U1. Packets addressed to F-TEIDs other than TEID 0x2001, and packets of UEs that have no ST route (for example, a terminal with the address 203.0.113.101), go to the UPF via S3, exactly as before.

What This Chapter Wants You to Hold On To Having walked through one example, we write the flow shown at the start once more, this time with values.

Session information U1 is born on the mobile side (UE 203.0.113.100/32, gNB F-TEID 0x1001, UPF F-TEID 0x2001, QFI 9) -> the MUP-C transforms it into an ST1 route (toward 203.0.113.100/32) and an ST2 route (toward TEID 0x2001) and distributes them -> each MUP PE matches them against the ISD route (SID 2001:db8:100:1::) / DSD route (D1, SID ...:2::) distributed beforehand, and resolves them -> as a result of resolution, SIDs and their behaviors enter the FIB -> packets flow with SRv6 inside the domain, and with GTP-U at the exit

The overall picture of . The session information (the facts on the mobile side) and the introductions of the segments (the facts on the PE side) are distributed separately, and become forwarding only upon resolution inside the receiving MUP PE. Within this flow, three things are intentionally kept separate: the facts of the session (known by the mobile side), where the segments are and how to deliver to them (known by the MUP PEs), and the resolution that ties the two together (executed by the receiver). Why go to the trouble of separating them, and what becomes replaceable by separating them? That is the subject of the next chapter, . If you have read this far, Sections 5, 6, and 7 of the base document should be readable as "a normative rewriting of a story you already know." That is the aim of this companion.

Why the Indirection Is Necessary

Meaning is not inside things; it arises when they meet.

To be honest, the flow of is roundabout. Session information U1 is born, the MUP-C transforms it into ST1 / ST2 routes, that alone still cannot forward, each MUP PE matches them against DSD / ISD routes and resolves them, and only then is the SID decided. A single UE has been added, and yet three kinds of routing information are flying around. The naive question is this. Why doesn't the MUP-C compute everything down to the SID from the start and distribute that? The session information holds the F-TEIDs of both ends, so writing it all in one statement -- "for 203.0.113.100/32, send with SID 2001:db8:100:1::" -- looks easier for both the reader and the implementer. In this chapter, we deliberately take that naive proposal seriously. Indirection is not complexity for complexity's sake. If we line up what goes wrong when the direct approach is taken, the reasons it had to be separated come into view. This chapter also uses the example of as-is (the UE is 203.0.113.100, the gNB is 198.51.100.10, the UPF is 198.51.100.20, the locator of S1 is 2001:db8:100::/48, and that of S2 is 2001:db8:200::/48).

The Problem with Writing Directly: More Things the MUP-C Has to Know With the direct approach, at the point in time when the MUP-C creates an ST route, it must decide everything down to the final SID. The SID 2001:db8:100:1:: is a value that comes out of the locator of S1. That is, in addition to the facts of the session, the MUP-C would have to know the following as well:

Behind which PE the radio-side network 198.51.100.0/24 lies (in this example, S1)
Which SID and which behavior that PE assigned to that segment (2001:db8:100:1::, End.M.GTP4.E)
Which PEs the DN-side segment D1 is at, and which PE should be chosen (2001:db8:100:2:: of S1, or 2001:db8:200:2:: of S2)

This is a conflation of roles. The original input of the MUP-C was supposed to be the facts of the session that the mobile system knows (the address of the UE, the F-TEIDs of both ends, the QFI). The direct approach makes it take on, in addition, all of the circumstances on the network side: the topology of the SR domain and the SID assignments of each PE. Moreover, those circumstances change. A PE is added, SID assignments change, the number of PEs that offer the same segment grows. Each time, the knowledge on the side that distributes the sessions must be made to follow. The job of transforming session information and the job of managing the configuration of the domain pile up in a single place. MUP's way of dividing it is the reverse of this.

Where a segment is, and how to deliver to it, is announced by the MUP PE that hosts it, itself (the DSD / ISD routes). A PE knows its own affairs best.
The facts of the session are transcribed by the MUP-C into the form of a route (the ST route). But it does not write the SID. Not because it cannot, but because it does not.
What ties the two together is the resolution that the MUP PE that received them performs on the spot.

No one knows the whole. But if each party distributes only what it knows, the whole is assembled at the receiver. This is the first reason for the indirection: separating where knowledge resides.

Do Not Mix Things That Change at Different Speeds Another reason for the separation is the timescale. An introduction of a segment (for example, "beyond S1 there is the N3 network 198.51.100.0/24," or "D1 is at S1 and S2") changes only when equipment or configuration changes. It is a matter of days or months. Sessions are different. A session is born each time a UE connects and a session is set up, and disappears when it ends. In , U1 was a single case, but in actual operation the number piles up to tens of thousands or millions, in constant turnover. If the SID were embedded in the ST route, information that ought to change slowly (SID assignments and the placement of segments) would end up replicated in bulk inside information that turns over quickly (the individual sessions). A single change of placement would force the redistribution of the routing information of every session affected by it. If the two are kept separate, a change of placement is finished with a change of the introductions alone. For example, even if the set of PEs that offer D1 changes, the ST1 route for 203.0.113.100/32 itself does not change by a single character. Each PE re-resolves it at hand, and follows the new placement. Distribute things that change quickly and things that change slowly, separately. This is a principle that has existed in the world of routing for a long time, and MUP can be read as having applied it to session information as well.

Resolution Is "Late Binding": The Same ST Route Yields a Different Answer at Each PE Let us look once more at a scene that appeared in . The ST2 route carried the identifier D1 of a Direct Segment, and there were two PEs that announced D1: S1 (SID 2001:db8:100:2::) and S2 (SID 2001:db8:200:2::). S1 adopted its own local N6DN as D1. What is happening here is that the same input yields a different forwarding result, depending on the PE that interprets it. If another PE were to receive the same ST2, that PE would choose the D1 that is appropriate as seen from its own position (for example, the one of S2, or its own local segment). The ST route carries only the intent "to D1"; the decision of "which PE's D1 it is" is left to the receiver. This is not so by accident. The base document states that when multiple DSD routes match, which one the route is resolved with is left to BGP best path selection (Section 5.1 of the architecture document). That is, the selection mechanism does not invent something new; it uses, as-is, the property that routing originally has, that "the receiver chooses the best with the information in its hands." The direct approach cannot obtain this suppleness. At the point in time when the distributing side has fixed the SID to one value, an answer common to all PEs is fixed. Room for judgments that differ by place -- "I want to use the closer segment," "at this PE, let the local one take precedence" -- disappears. Inserting the one stage of resolution also moves the decision from the distributing side to the receiving side. In technical terminology, this is late binding; in plain words, it is "specify the segment to deliver to by name, and decide which PE it actually is on the spot, each time."

Late binding. An ST2 route specifies the destination by name (D1) only; which PE's segment it is is decided by the receiver, on the spot.

You See It When You Try Replacing Things: The Example of S4 Joining The effect of the indirection is clearest when the configuration is changed. We use the example of Section 7.3 of the base document: the case in which a new PE, S4, joins the SR domain and hosts a new group of edge servers. When values are assigned in the style of , it looks like this.

S4 joining (only the things that are added) Locator : 2001:db8:400::/48 DN : 10.10.3.0/24, server C is 10.10.3.10 Introduction (DSD): segment D2, SID 2001:db8:400:2:: (End.DT4) Note: the :2:: function follows the same pattern as the DSDs of S1 / S2 Now, among the existing things, what changes?

The ST1 / ST2 routes of U1: they do not change. U1 remains a session toward D1.
The introductions of S1 / S2: they do not change. They remain D1.
What is newly needed: only that, for a session that uses server C (10.10.3.10), the MUP-C issues an ST route with D2 attached. For example, if the session U1' of another UE (203.0.113.101) is toward D2, D2 is attached to its ST2; when S1 receives it, it is resolved with the DSD for D2 (SID 2001:db8:400:2::), and the packets head toward S4.

The addition closes within the addition, and there is no need to rebuild the routing information of existing sessions. This is the result of combining the "separation of the speeds of change" described in with the "specify by name, and leave the resolution to the receiver" of . With the direct approach, the joining of S4 would have been the work of "the MUP-C learns the SID of S4, and changes the contents it distributes for the related sessions." Note that, in this example, as the behavior that S1 uses for packets toward D2, the base document lists behaviors for bridging to a remote segment, such as H.M.GTP4.D and End.M.GTP6.D. How to behave when the destination of resolution turns out to be a segment that is not at one's own location is also decided as a result of resolution. The details are beyond the scope of this chapter; here, we hold on only to the point that the behavior itself switches depending on "local or remote."

The Same ST Route Works in a Different Placement: The Collapsed Configuration Replaceability is not only a matter of adding PEs. Section 7.4 of the base document introduces a collapsed configuration in which the only MUP PE is S1. S2 and S3 remain L3VPN PEs that do not have MUP enabled. What is interesting in this configuration is that there are cases in which S1 does not advertise ISD / DSD routes for its own local segments. Since it hosts them itself, it knows them; there is no need to go out of its way to announce them with BGP and receive them itself. Instead, S1, as a result of importing the ST1 route, directly creates a GTP encapsulation entry in the FIB, and advertises the UE prefix 203.0.113.100/32 to S2 as an ordinary L3VPN route with the SID 2001:db8:100:2:: attached. That is, the discovery procedure is a means "to learn about a remote segment," and is not an end in itself. If things close locally, that stage can be omitted. The form of the input, the ST route, does not change in either the full configuration or the configuration collapsed into a single unit. The input (the facts of the session) is the same, and the way it is resolved and the way forwarding is assembled differ by deployment. This, too, is a freedom of placement that is possible only because the one stage of resolution sits in between.

The Cost of Indirection, Stated Honestly So far we have lined up only the advantages, but indirection is not free. There is a price, for the reader and for the operator alike.

The cost of tracing: when a packet does not arrive, the places to investigate are not just one. It is necessary to look, in order, at the three stages: has the ST route arrived, have the DSD / ISD routes arrived, and are the two being resolved?
The opacity of state: an entry that has entered the FIB (for example, 203.0.113.100/32 -> SID 2001:db8:100:1::) does not, from the entry itself, reveal which combination of inputs produced it. To trace its origin, information on the RIB side is needed.
The silence when resolution fails: an ST route that cannot be resolved does not enter the FIB, and the packet follows ordinary routing (). This is safe in the sense that packets are not dropped onto a broken path, but there is also the aspect that it makes it hard to notice that "MUP is not taking effect."

Turned around, these three stages become, just as they are, an inspection procedure.

Inspection when a packet does not arrive 1. Is there an ST route? In the RIB of S2, is there ST1: 203.0.113.100/32 (RT 65000:3)? In S1's RIB, is there ST2 for TEID 0x2001 (D1, RT 65000:2)? 2. Are there introductions? Is there the ISD: 198.51.100.0/24 + SID 2001:db8:100:1::? Is there DSD: D1 + SID 2001:db8:100:2:: / 2001:db8:200:2::? 3. Is it being resolved? In the FIB of S2, is 203.0.113.100/32 -> 2001:db8:100:1:: in? If not, this narrows it down to which of 1 and 2 is missing With the direct approach, the inspection would be finished in one stage. In exchange, all of the suppleness seen from Sections through would be lost. The design of MUP is making the choice to accept the trouble of inspection, in exchange for taking the separation of knowledge and replaceability. We believe that writing this trade-off down, self-consciously, is the honest thing to do, both for reviewers and for implementers.

What This Chapter Wants You to Hold On To There is not just one reason why the indirection is necessary. They overlap.

Where knowledge resides: the PE knows about segments; the MUP-C knows about sessions. Neither needs to know the circumstances of the other.
Separation of the speeds of change: the placement of segments changes slowly; sessions change quickly. Do not replicate the information of the slow side inside the fast side.
Late binding: an ST route specifies a segment by name (D1), and which PE's segment it is is decided by the receiver, on the spot. The same input becomes a different, appropriate answer at each place.
Freedom of placement: the addition of a PE (S4, D2) closes within the addition, and in the collapsed configuration, the discovery stage itself can be omitted. The form of the input does not change.

The flow that looked "roundabout" in is the form that satisfies all four of these. In the next chapter, we look at the same "benefit of not deciding" along one more axis: why it is not decided whether a segment is on the radio side or not.

Why Segments Are Symmetric

Water does not hold the shape of its vessel in advance.

Sections and talked only about N3 (the radio side). The distinction between the radio side and the data network side has presumably been an implicit premise whenever the word "segment" came up. Yet if one reads the main document carefully, the word "access side" appears nowhere in the definition of a segment. The only distinction given is between Direct Segments and Interwork Segments, and that is a distinction about how a segment is reached: whether reaching it requires interworking -- conversion -- with a user plane protocol of the mobile service architecture. Which position a segment occupies in the topology of the network is not defined. This is not an omission. In this chapter, we look at why position is left undefined, and at what becomes treatable by one and the same mechanism once it is left undefined, using the home routed (HR) roaming example in Section 7.5 of the main document. We again follow the example with concrete values; roaming brings more characters onto the stage, so we hand over the values first.

The HR roaming example (extending the assignment from Section 3) Setting : serving SR domain; the UE subscribes to HO-A N3 network : 198.51.100.0/24 (same as in Section 3) gNB : 198.51.100.10 N3 side of serving UPF : 198.51.100.20 N9A (interconnection toward HO-A) : 10.20.1.0/24 UPF of HO-A : 10.20.1.10 N9 endpoint on serving side : 10.20.1.20 N9B (toward HO-B) : 10.20.2.0/24 (UPF of HO-B is 10.20.2.10) SIDs (the behavior is End.M.GTP4.E in all cases) ISD of S1 for N3 : 2001:db8:100:1:: (as in Section 3; default) ISD of S2 for N9A : 2001:db8:200:1:: (community I1) ISD of S1 for N9B : 2001:db8:100:3:: (community I2) Note the arrangement of the SID values. For N3 and for N9A, the locators differ, but the function part is :1:: in both cases, and the behavior is the same End.M.GTP4.E. Whether it is the radio side or the side of an interconnection toward another operator, from the point of view of MUP the two stand side by side as nothing more than instances of "an Interwork Segment that requires conversion with GTP-U."

First, Consider What Would Happen If Segments Were Not Symmetric Suppose the architecture baked labels such as "access side" and "the other (non-access) side" into segments. Those labels would find their way into the route types and the resolution rules as well. A definition such as "the destination endpoint of an ST2 route is an endpoint on the non-access side" is the typical example. At first sight, this looks helpful. A reader could tell the role from the label, and an implementation could branch by side. But this assumption breaks down in the face of HR roaming. As the next section shows, in a roaming session the same kind of route (an ST2 route) takes "the F-TEID of a UPF on the N9 side" as its destination endpoint in one direction, and "the F-TEID of a gNB on the N3 side" as its destination endpoint in the other direction. That is, the destination endpoint can be on the access side or on the other side, depending on the direction. Whichever side one inserts into the sentence "the destination of an ST2 route is on the ... side," the sentence becomes false for the other direction. And this is not a contrived counterexample. If the axis of sides is brought into the definitional text of the architecture, one direction of a real deployment falls outside the definition. That is the practical reason symmetry is needed.

Following an HR Roaming Session in Both Directions Let us set the scene. The serving operator has enabled MUP: S1 hosts the N3 network, S2 hosts the N9 interconnection toward HO-A (N9A), and S1 hosts the N9 interconnection toward HO-B (N9B), each as an Interwork Segment. N9A and N9B are placed in separate routing instances, because the routing and addressing policies differ from one home operator to another. It is therefore acceptable for both home operators to use the same IP address ranges. Roaming sessions that are not handled by MUP continue to pass between N3 and N9 through the serving UPF (behind S3), as before. MUP handles only the sessions selected as its targets. Now a roaming session of a UE subscribing to HO-A arrives. The session information contains four F-TEIDs.

Session information (HR roaming, HO-A) V1 : F-TEID of the gNB IP 198.51.100.10, TEID 0x00001101 (N3 side) Xa : F-TEID on the serving core side (toward the serving UPF) IP 198.51.100.20, TEID 0x00002101 (N3 side) A1 : F-TEID of the UPF of HO-A IP 10.20.1.10, TEID 0x00003101 (N9A side) Z1 : F-TEID on the serving N9 side (entry point seen from HO-A) IP 10.20.1.20, TEID 0x00004101 (N9A side) On the conventional path, the uplink runs gNB -> (toward Xa) -> serving UPF -> (toward A1) -> UPF of HO-A, and the downlink traverses the reverse. What MUP does is to connect the two tunnels that sandwich the serving UPF directly, across the SR domain. For that purpose, the MUP-C originates two ST2 routes.

Uplink: the Match Is on the N3 Side, the Destination Is on the N9 Side

ST2 route (for the uplink) Matching key : Xa (198.51.100.20 / TEID 0x00002101) Destination endpoint : A1 (10.20.1.10 / TEID 0x00003101) MUP community : I1 (destination: Interwork Segment N9A) Route Target : 65000:2 (C2 in the main doc; imported by N3RAN) The N3RAN instance on S1 imports this route. Resolution is performed only with ISD routes carrying community I1. The match is the ISD route for N9A advertised by S2 (SID 2001:db8:200:1::). Resolution does not happen with the ISD route for N3, which carries no I1, or with the ISD route for N9B, which carries I2. Even if the address spaces overlap, there is no confusing one segment with another whose policy differs. The packet flow is as follows. S1 receives the GTP-U packet that the gNB sent toward Xa, matches it against the ST2 route, decapsulates it, and places the inner packet onto SRv6. The SID used at that point is composed from the resolution result, 2001:db8:200:1::, with the information of the destination endpoint A1 embedded in it as an argument. S2 executes the behavior of that SID, End.M.GTP4.E, converts the packet into GTP-U toward A1, and hands it to the UPF of HO-A.

Downlink: the Match Is on the N9 Side, the Destination Is on the N3 Side

ST2 route (for the downlink) Matching key : Z1 (10.20.1.20 / TEID 0x00004101) Destination endpoint : V1 (198.51.100.10 / TEID 0x00001101) MUP community : none (default Interwork Segment = N3RAN) Route Target : C5 (main doc; imported by N9A instance) The N9A instance on S2 imports this route. Since there is no community, resolution is performed with the ISD routes of the default Interwork Segment, and the match is the ISD route for N3 of S1 (SID 2001:db8:100:1::). S2 receives the GTP-U packet that the UPF of HO-A sent toward Z1, decapsulates it, and places it onto SRv6; S1 converts it, by End.M.GTP4.E, into GTP-U toward V1 and delivers it to the gNB.

Placing the Two Side by Side ST2 in the uplink and the downlink, side by side

	ST2 (uplink)	ST2 (downlink)
Matching key	Xa (endpoint on the N3 side)	Z1 (endpoint on the N9 side)
Destination endpoint	A1 (UPF on the N9 side)	V1 (gNB on the N3 side)
ISD used for resolution	ISD of N9A, with I1	ISD of the default (N3)
Resolved SID	2001:db8:200:1:: (S2)	2001:db8:100:1:: (S1)
Final behavior	End.M.GTP4.E	End.M.GTP4.E

The route type is the same, the resolution rule is the same, and the final behavior is the same. What differs is only which network the matching key and the destination endpoint belong to, and whether a community that narrows the scope of resolution is attached. And even that difference does not come from a decision of the architecture: it comes from the circumstances of the deployment, namely that this session is a roaming session. If the definition of an ST2 route contained a sentence such as "the destination endpoint is on the non-access side," the downlink row would violate the definition. If it said "access side" instead, the uplink row would be the violation. It is precisely because neither sentence is written that both routes can be processed by the same rule. This is the practical substance of the statement that segments are symmetric.

The two ST2 routes of HR roaming. The uplink is resolved to N9A by I1; the downlink is resolved to the default N3 with no community. N9B (I2, SID 2001:db8:100:3::) is co-located with N3 on S1. Note that the SID of N9B is a value reassigned in this companion document to avoid a collision of values, and differs from the notation in Section 7.5 of the main document (S1:1::). The companion's examples are self-contained and use their own consistent assignment.

Another Place Where Symmetry Pays Off: Co-location and Separation The same example contains two further ways in which symmetry is at work. Co-location is possible. In a session of HO-B, the destination is N9B, and N9B is hosted by S1. S1 also hosts N3. That is, within a single PE, the segment of the radio side and the segment of the interconnection side are co-located, and the packets of that session are processed inside S1 without traversing another PE (Section 7.5 of the main document states this). Had segments carried labels of sides, with the role of each PE fixed by them, this co-location would have had to be treated as an exception. Separation is possible. N9A and N9B are both on the "interconnection side," yet they are treated as distinct segments by means of the distinct communities I1 and I2, and their scopes of resolution are separate as well. Symmetry does not mean "treat everything the same." It is a design in which distinctions are made where they are needed for resolution (the separation of policies), by means of communities, and are not made where they are not needed (whether something is on the access side or not). How the axes are chosen is determined not by a preconception about roles, but by whether the information is needed to perform resolution correctly.

So Who Knows Which Side Is the Access Side? If the architecture does not decide it, that does not mean the information itself does not exist. In this roaming example, too, everyone involved knows that N3 is the radio side and N9 is the home operator side. Those who know are on the side of the deployment and of the session information.

Which network is N3 and which is N9 is decided by the 3GPP architecture and by the configuration of that operator.
Which network each F-TEID in the session information belongs to is known by the system on the mobile side, and the MUP-C receives it from there.
Based on that knowledge, the MUP-C selects the communities (whether to attach I1, and so on) and assembles the ST routes.

What the architecture itself takes on is only the mechanism part: "resolve an endpoint within the scope of the segment specified by name." The knowledge of roles is left on the input side and is not brought into the mechanism side. Because of this division, the same mechanism can be used for N3 and N9 in 5G, for other mobile architectures, and for future configurations. The moment the architecture fixed the sides in 3GPP terminology, that generality would be lost. In the words of , it comes down to this. What a PE advertises is only the fact that "there is such a network beyond me"; the interpretation "and it is on the access side" is not included in the advertisement. The interpretation arrives later, together with the session.

The Cost of Symmetry As in , we also write down the price.

The burden on the reader: Looking only at the type of a segment does not reveal what role that segment has. To know the role, the context of the deployment and of the session is needed. Half of the reason was written to "go through a concrete example first" is this.
The burden on the writer: When writing definitions, convenient turns of phrase such as "the ... on the access side" are unavailable. A destination endpoint can only be described as "determined by resolution," which can look vague at first reading. That this burden invites reviewers to ask "please be clear about which side this concerns" is the other side of the same coin.
The balance against what is gained: In exchange, one gains what the table in shows -- two routes in different directions handled by a single rule -- and the generality of . If only one specific deployment were under consideration, the trade would not be worthwhile; but as a burden to be borne by a document that calls itself an architecture, we believe this side of the trade is the right one.

What to Take Away from This Chapter

The distinction between segment types (Direct / Interwork) is a distinction about how a segment is reached (whether conversion is required), not a distinction about position in the topology.
In HR roaming, one and the same ST2 route type takes an endpoint on the N9 side as its destination in one direction and an endpoint on the N3 side in the other. If a label of sides is baked into the definitions, one of the two falls outside them.
The knowledge of roles resides on the side of the deployment and the session information; the architecture takes on only the mechanism of "resolving an endpoint within a scope narrowed by name."
Symmetry is not uniformity. Distinctions that resolution needs, such as the separation of policies (I1 / I2), are attached by means of communities.

In the next chapter, we turn to who carries the distribution. Why is BGP used to distribute this mechanism, and why are the definitions of the BGP extensions not in this document but in a BESS document?

Why BGP?

Do not build tools; borrow them. Say only what needs to be said.

In the chapters so far, we have written as if it were self-evident that routing information is "distributed." The MUP-C distributes ST routes, and MUP PEs distribute DSD / ISD routes. About how they are distributed, the main document states explicitly that it recommends BGP (Sections 1 and 3). Two kinds of questions tend to attach themselves to this choice.

To begin with, why BGP? Is BGP not the protocol of inter-domain routing on the Internet? Should such a heavyweight mechanism be used to distribute information that churns as finely as sessions do?
Why are the definitions of the BGP extensions not in this document? The architecture document talks about BGP, yet the formats of the SAFI and the NLRI are not written in it. Is it not an ambiguity of responsibility that they are in another document (draft-ietf-bess-mup-safi )?

Both are fair questions. This chapter answers them in turn.

First, Check What Has to Be Distributed Before asking "why BGP," let us line up "what has to be distributed" once more, using the values from .

Reachability itself, such as prefixes and endpoints (203.0.113.100/32, 198.51.100.0/24, TEID 0x00002001)
The metadata that accompanies it (segment identifiers such as D1 and I1, session information, the SID 2001:db8:100:1:: as a data plane attribute, and so on)
Control over the scope of distribution (an ST1 route is to be installed only into N6DN; that is, only into the instances that import RT 65000:3)
Selection when there are multiple candidates (D1 exists on both S1 and S2; the receiver selects one of them locally)
Prevention of mix-ups (as with N9A and N9B in , resolution must not happen in a segment of a different policy even if the address spaces overlap)

This is not a distribution for which mere delivery suffices. It is a distribution that carries reachability with metadata attached, narrows the delivered scope by policy, and lets the receiver choose among candidates. And this form of distribution already has a name: the distribution of BGP/MPLS VPNs. What the MUP PEs were doing in the example of -- holding VRFs (routing instances), controlling import and export with Route Targets, and carrying attributes in extended communities -- is exactly what the PEs of an L3VPN do every day. The examples in Section 7 of the main document are also built, in their underlying part, on "typical routing policy control using the BGP extended community." So the question is, precisely, not "shall we choose BGP as a new distribution mechanism." It is: shall we place one more kind of MUP route onto the VPN distribution substrate that is already running on the PEs, or shall we build a separate distribution mechanism dedicated to MUP?

The Reason to Use BGP Is That the Tools Are Already There If a dedicated mechanism were built, all of the requirements listed in would have to be designed from scratch: how to attach metadata, how to narrow the scope, how to select among candidates, how to handle non-delivery, and the tools and experience for operating all of that. With BGP, most of that can be covered by existing components. Mapped against the text of the main document, it looks like this. Distribution requirements and the existing tools of BGP

Distribution requirement (6.1)	Existing tool of BGP	Where it appears in the main document
Carry reachability plus metadata	The NLRI of MP-BGP and extended communities	ST / DSD / ISD routes and the MUP Extended Community (the semantics in the main document, the format in BESS)
Narrow the scope of distribution	Import policy by Route Target; a route can be discarded on mismatch	The descriptions of import and discard in Sections 5, 6.1, and 6.2
Select one among candidates	Best path selection	Section 5.1: when several DSD routes match, the one used for resolution is selected by best path
Do not confuse one segment with another	Scoping of resolution by community	Section 6.2: an ST2 route is resolved only with the ISD routes of the destination segment
Distribute at scale	The existing operational substrate of iBGP (sessions, policies, monitoring)	Section 1: a MUP network is normally iBGP within a single administrative domain

There is one more point that tends to be overlooked: how well this fits the "separation of where knowledge resides" described in . In BGP, the distributing side merely originates routes; whether to import them, and which one to select, is decided by the policy and the best path selection of the receiving side. The MUP-C can originate ST routes to all PEs in the same form, and each PE accepts or rejects them according to its own VRFs and policies. The distribution mechanism itself is built on the premise of autonomy on the receiving side. That a MUP PE is a BGP speaker is also a small additional burden. S1 and S2 in were already speaking BGP as L3VPN PEs before MUP was enabled on them. MUP adds kinds of routes for them to speak. The same holds for the MUP-C: it joins the domain as a node that advertises session information in BGP.

On the Misconception That "BGP Is for Inter-domain Use" The direct answer to the first question is this. The BGP in this context is not the inter-domain routing of the Internet. As Section 1 of the main document states, a MUP network is normally placed within a single administrative domain, and DSD / ISD / ST routes are distributed among the MUP PEs and the MUP-C over iBGP. Distribution across domains is limited to cases such as the HR roaming examined in . Distributing VPN routes over iBGP is standard practice in carrier networks, and as a use of BGP it is a second pillar standing alongside inter-domain use. The association "BGP means the whole Internet" sees only half of how BGP is used. Note, however, that one point remains: the rate at which sessions churn, and the update processing of BGP. This is not a misconception; it is a legitimate design question. As a measure on the side of the main document, aggregation by longest match over endpoint prefixes can be applied to ST2 routes (Section 6.2 of the main document), so session-level information does not necessarily translate into a proportional number of routes. Even so, whether BGP distribution suffices for an assumed scale of sessions and update frequency is something to be estimated for each deployment, and this companion does not guarantee that it "always suffices." As with the "cost of indirection" written about in , we state this explicitly as a price of the choice.

Why the Encoding Lives in a BESS Document The second question is about the division of labor among documents. The division is as follows.

draft-ietf-dmm-mup-architecture (DMM, the main document that this companion accompanies) decides: the types and semantics of segments; the types and semantics of the DSD / ISD / ST1 / ST2 routes; the procedures for distribution and resolution; and the behavior required of MUP PEs and of the MUP-C. For the MUP Extended Community as well, its semantics -- that it indicates which segment a route is about, and carries metadata including the type of the segment -- is decided here.
draft-ietf-bess-mup-safi (BESS) decides: the format. The BGP-MUP SAFI, the encoding of its NLRI, the format of the MUP Extended Community, and the corresponding IANA allocations. The main document makes no IANA requests at all.
IDR decides: the base protocol of BGP itself. The extensions for MUP do not change the base protocol of BGP. Adding a new SAFI and a community falls within the work of BESS, which handles the encodings on the service side.

The view that "this is a BGP extension, so it should be an IDR document" is a natural one, but it is not accurate. As with each of the VPN schemes, the encoding of what is carried over BGP is borne by the working group on the side of the service that uses it. MUP stands in that same line. This division has one practical consequence. To read the main document and conclude that "the BGP extensions are written only as an example, and there is no way to implement this" is to overlook the division. The absence of encoding in the main document is neither an omission nor a vagueness; the material is simply placed elsewhere. An implementer reads the semantics and the procedures in the main document, and the formats in the BESS document. The two documents refer to each other, and the BESS document lists the main document as a normative reference. Conversely, criticism of the kind "why is there no wire format" directed at the main document is not resolved by fixing the main document. The answer is the explanation of the division itself, and a place like this companion is the right venue for it (the policy of not bringing justification arguments into the body of the main document is as stated in the Introduction).

Distribution takes place over iBGP within a single domain, and the division among documents is split as "the semantics in DMM, the formats in BESS, and the base protocol left to IDR."

A Caveat: "Recommended," Not "the Only Option" Finally, a caveat for precision of language. The main document recommends BGP, and describes its procedures in the terms of BGP. The core of the architecture -- the semantics of segments, the types of routes, and the procedure of resolution -- is defined in a form that does not depend on a specific distribution protocol, as the structure examined through shows. Nevertheless, the recommendation is BGP because, as shows, the tools that fit the requirements and the operational substrate are already in place on the PEs; this is not a statement that forbids examining other distribution means in the future. This caveat is not a weakness. It is the thoroughness of the division: by keeping "semantics" and "the means of carriage" apart, a debate about the means of carriage does not break the debate about the semantics.

What to Take Away from This Chapter

The distribution requirements of MUP are "reachability plus metadata, control over scope, selection on the receiving side, and prevention of mix-ups," and that is exactly the form that the distribution substrate of BGP/MPLS VPNs already provides.
The BGP here is normally iBGP within a single administrative domain. The association of BGP with "an inter-domain heavyweight" does not apply to this use.
The division is: the semantics in the main document of DMM, and the formats (the SAFI, the NLRI, the format of the community, and IANA) in draft-ietf-bess-mup-safi of BESS; since the base protocol of BGP is not changed, this is not the work of IDR.
The absence of encoding in the main document is a result of the division; it is neither treatment as an example nor an omission.

The next chapter is a mondo, a question-and-answer exchange. We will untie, one by one, the misunderstandings that have come up repeatedly so far.

Mondo: Frequently Asked Questions

A question is not for obtaining an answer, but for untying a knot.

This chapter collects, in question form, the misunderstandings that have recurred throughout the preceding five chapters. Each answer is kept short, with a pointer to the chapter where the fuller explanation can be found. The questions are numbered from Q1. The form of this chapter is mondo, a question-and-answer exchange. Mondo is not a form for adding new teaching. It is a form for setting down one question at a time and watching a misunderstanding come undone. That is why every answer here is short. If you want to know more, follow the pointer at the end of each answer back to the earlier chapters. --- Q1. Is a SID the segment itself? No. A segment is an abstraction of a network or a service attached to a MUP PE. A SID identifies a forwarding behavior executed by the MUP PE that hosts that segment. That is why the same Direct Segment, D1, has two different SIDs: one for S1 (2001:db8:100:2::) and one for S2 (2001:db8:200:2::). In short: the segment is what lies beyond the PE; the SID is what you ask that PE to do in order to reach it. (See , .) Q2. Is the "segment" of a MUP segment the same thing as a Segment Routing segment? No. As Section 3 of the architecture document states explicitly, a MUP segment is not a Segment Routing-specific term. "Segment" is a word used broadly across networking technologies; in MUP it denotes an abstraction of a body of network that takes part in a mobile service. Confusing it with an SR segment — an instruction or a topological element represented by a SID — leads directly to the misunderstanding in Q1. (See , , and .) Q3. Does introducing MUP make the UPF disappear? No. In the example of , the UPF remains beyond S3, and traffic for sessions that MUP does not handle continues to pass through the UPF as before. What MUP does is, for a session selected for handling, build from routing a path that can deliver its packets without traversing the UPF. It is not a mechanism for migrating all sessions at once. (See , Sections and .) Q4. Do tunnels go to zero? No. GTP-U remains at the boundary with an Interwork Segment. In the downlink of , S1 finally converts the packet to GTP-U and sends it out to the gNB; in the uplink, S1 receives what the gNB has sent, as before, over GTP-U addressed to the UPF. What changes is the carriage inside the domain: instead of being pinned end to end by a tunnel, packets are carried inside by SRv6 routing and converted back to the peer's protocol only at the exit. (See , , and .) Q5. Are the BGP extensions merely given as an example? No. The architecture document (draft-ietf-dmm-mup-architecture) normatively defines the route types and their semantics, the procedures, and the required behavior. The encoding — the BGP-MUP SAFI, the NLRI, and the format of and IANA allocations for the MUP Extended Community — is deliberately defined in a separate document, draft-ietf-bess-mup-safi. The absence of a wire format in the architecture document is neither treatment as an example nor an omission; it is a division of labor between documents. (See , .) Q6. If this is about BGP, why is it not an IDR document? The MUP extensions do not modify the base BGP protocol. Adding a new SAFI and an extended community is encoding on the side of the service that uses them, and that work belongs to BESS. What IDR is responsible for is the base BGP protocol itself. (See , .) Q7. Does the MUP-C replace the mobile-side control plane, such as the SMF? No. The job of the MUP-C is to receive session information from the mobile service system, transform it into routing information (ST routes), and distribute it. Session management itself remains the job of the mobile-side system, and how the MUP-C receives session information — the interfaces and APIs — is out of scope of the architecture document and is dealt with in separate documents for each system. (See , , and Section 6.3 of the architecture document.) Q8. Is MUP a mobility management mechanism? No. Section 1 of the architecture document states that MUP is not a mobility management system itself, but an architecture that enables the mobile user plane to be integrated into the data plane of an IP network. Handover control and session lifecycle management remain on the side of the existing mobile architecture. Q9. Is SRv6 mandatory for MUP? Not for the architecture. The architecture document describes the SRv6 case because of the DMM requirements and its suitability for scalable deployments. At the same time, the principle of its Section 3 is that the auto-discovery routes and the ST routes must be dataplane independent. This companion uses SRv6 values in its examples because that is the representative case. (See , , and , .) Q10. If an ST route cannot be resolved, are its packets dropped? No. For an ST route that fails to resolve, no FIB entry is installed, and its packets follow the normal IP routing of the routing instance. MUP takes effect only for sessions that could be resolved; it is not a mechanism that breaks the conventional path when it does not take effect. One qualification is worth stating plainly. The conventional path is the path the mobile service's session was originally established on, so in falling back, delivery follows that session and its packets do not stop flowing. What the fallback does not preserve is the service requirement for which the session information was converted into routing information — the treatment MUP was there to provide. Falling back keeps the session working; it does not keep the requirement satisfied. (See , , and , .) Q11. Does MUP apply to the traffic of all UEs? No — only to sessions for which there is an ST route. In the examples in the architecture document, this is realized by having the ST2 route preferred, by longest match, over the ordinary VPN routes in instances such as N3RAN, so that only that session is handled by MUP. The remaining traffic passes through the conventional user plane. (See , , and , .) Q12. Where can I look to tell whether a segment is on the "access side"? That is not written anywhere in the architecture — and that is how it should be. Which network is on the access side is determined by the deployment (for example, the 3GPP configuration) and by the session information; the architecture gives segments no side label. If you want to know a segment's role, look not at the specification but at the configuration of that network and the context of the session. (See .) Q13. Is BGP not a protocol for use between domains on the Internet? Is distributing session information with it not overkill? The BGP used in MUP is normally iBGP within a single administrative domain, distributing routes among the MUP PEs and the MUP-C. PEs distributing VPN routes over iBGP is existing operational practice itself; MUP adds route types to it. But reuse should not be read as a performance guarantee: the architecture does not promise that distribution keeps up with the rate at which mobile sessions are created and updated. Whether an implementation does keep up is a matter for its evaluation in each deployment — a separate question from the architecture, and not something the architecture asserts. (See , Sections and .)

Security Considerations This document is an explanatory companion to the MUP architecture. It specifies no protocol, no encoding, and no new behavior, and therefore introduces no new security considerations. The security considerations of the architecture itself are discussed in the architecture document .

IANA Considerations This document has no IANA actions.

Informative References

Acknowledgements This companion grew out of the questions raised in reviews of the MUP architecture document, in particular the Routing Directorate early review, and out of the discussions with the co-authors of that document. The misunderstandings collected in the mondo section are, for the most part, real questions that were actually asked.