idnits 2.17.00 (12 Aug 2021) /tmp/idnits38595/draft-zzhang-dmm-5g-distributed-upf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (6 March 2022) is 69 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-18 == Outdated reference: A later version (-03) exists of draft-mhkk-dmm-srv6mup-architecture-01 == Outdated reference: A later version (-01) exists of draft-zzhang-pals-pw-for-ip-udp-payload-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dmm Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Informational K. Patel 5 Expires: 7 September 2022 Arrcus 6 T. Jiang 7 China Mobile 8 6 March 2022 10 5G Distributed UPFs 11 draft-zzhang-dmm-5g-distributed-upf-00 13 Abstract 15 This document describes evolution of mobile user plane in 5G, 16 including distributed UPFs and alternative user plane implementations 17 that some vendors/operators are pushing without changing 3GPP 18 architecture/signaling. This also sets the stage for discussions in 19 a companion document about potentially integrating UPF and Acess Node 20 (AN) in a future generation (xG) of mobile network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 7 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Current User Plane in 5G . . . . . . . . . . . . . . . . . . 2 56 2. MUP Evolution in 5G: Distributed UPFs . . . . . . . . . . . . 3 57 2.1. Advantages of Distributed PSA UPFs . . . . . . . . . . . 5 58 2.2. Enablers of Distributed PSA UPFs . . . . . . . . . . . . 6 59 3. MUP Evolution in 5G: Alternative Implementation Options . . . 7 60 3.1. GTP vs. SRv6 vs. MPLS tunneling . . . . . . . . . . . . . 7 61 3.2. Routing Based UPF . . . . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. Informative References . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Current User Plane in 5G 68 Mobile User Plane (MUP) in 5G [_3GPP-23.501] has two distinct parts: 69 the Access Network part between UE and AN/gNB, and the Core Network 70 part between AN/gNB and UPF. 72 N3 N9 N6 73 UE AN(gNB) | I-UPF | PSA UPF | 74 +---------+ | | | 75 |App Layer| | | routing | __ 76 +---------+ | |+--/---+---\-+| ( ) 77 |PDU Layer| relay | relay || PDU | || ( ) 78 +---------+ +---/--+--\---+|+---/--+--\---+|+------+IP+L2|| ( ) 79 | | | |GTP-U |||GTP-U |GTP-U |||GTP-U | || ( DN ) 80 | 5G-AN | |5G-AN +------+||------+------+||------+ or || ( ) 81 | | | |UDP+IP|||UDP+IP|UDP+IP|||UDP+IP| || ( ) 82 | Proto | |Proto +------+||------+------+||------+Ether|| ( ) 83 | | | | L2 ||| L2 | L2 ||| L2 | || -- 84 | Layers | |Layers+------+||------+------+||------+-----+| 85 | | | | L1 ||| L1 | L1 ||| L1 | L1 || 86 +---------+ +------+------+|+------+------+|+------+-----+| 87 | | | 89 For the core network (CN) part, N3 interface extends the PDU layer 90 from AN/gNB towards the PSA UPF, optionally through I-UPFs and in 91 that case N9 interface is used between I-UPF and PSA UPF. 92 Traditionally, UPFs are deployed at central locations and the N3/N9 93 tunnels extend the PDU layer to them. The N3/N9 interface uses GTP-U 94 tunnels that are typically over a VPN over a transport 95 infrastructure. While N6 is a 3GPP defined interface, it is for 96 reference only and there is no tunneling or specification involved - 97 it is simply a direct IP (in case of IP PDU session) or Ethernet (in 98 case of Ethernet PDU session) connection to the DN. 100 At the AN/gNB, relay is done between the radio layer and the GTP-U 101 layer. At the PSA UPF, routing/switching is done for IP/Ethernet 102 before GTP-U encapsulation (for downlink traffic) or after GTP-U 103 decapsulation (for uplink traffic). 105 2. MUP Evolution in 5G: Distributed UPFs 107 With MEC, ULCL UPFs are deployed closer to gNBs, while centralized 108 PSA UPFs are still used to provide persistent IP addresses to UEs. 110 In fact, even PSA UPFs could be distributed closer to gNBs and then 111 the N3 interface becomes very simple - over a direct or short 112 transport connection between gNB and UPF (or even an internal 113 connection if the gNB and UPF are hosted on the same server). On the 114 other hand, since the UPF to DN connection is direct, the DN becomes 115 a VPN (e.g., IP VPN in case of IP PDU sessions or EVPN in case of 116 Ethernet PDU sessions) over a transport infrastructure, most likely 117 the same transport infrastructure for the VPN supporting the N3/N9 118 tunneling in centralized PSA UPF case, as shown in the following 119 picture: 121 N3 N6 122 UE1 AN1/gNB1 | PSA UPF1 | 123 +---------+ | | 124 |App Layer| | routing | 125 +---------+ |+--/---+---\-+| 126 |PDU Layer| relay || PDU | || PE1 127 +---------+ +---/--+--\---+|+------+IP+L2|| +----+--+ 128 | | | |GTP-U |||GTP-U | ||----+VRF1| | 129 | 5G-AN | |5G-AN +------+||------+ or || +----+ | 130 | | | |UDP+IP|||UDP+IP| || |VRFn| | 131 | Proto | |Proto +------+||------+Ether|| +----+--+ 132 | | | | L2 ||| L2 | || ( ) 133 | Layers | |Layers+------+||------+-----+| ( ) 134 | | | | L1 ||| L1 | L1 || ( Transport ) 135 +---------+ +------+------+|+------+-----+| ( ) 136 | | ( Network ) PE3 137 | | ( +--+----+ 138 UE2 AN2/gNB2 | PSA UPF2 | ( | |VRF1| 139 +---------+ | | ( | |----+ 140 |App Layer| | routing | ( | |VRFn| 141 +---------+ |+--/---+---\-+| ( +--+----+ 142 |PDU Layer| relay || PDU | || ( ) 143 +---------+ +---/--+--\---+|+------+IP+L2|| ( ) 144 | | | |GTP-U |||GTP-U | || ( ) 145 | 5G-AN | |5G-AN +------+||------+ or || +----+--+ 146 | | | |UDP+IP|||UDP+IP| ||----+VRF1| | 147 | Proto | |Proto +------+||------+Ether|| +----+ | 148 | | | | L2 ||| L2 | || |VRFn| | 149 | Layers | |Layers+------+||------+-----+| +----+--+ 150 | | | | L1 ||| L1 | L1 || PE2 151 +---------+ +------+------+|+------+-----+| 152 | | 154 The central PSA UPF is no longer needed in this case. Distributed 155 UPF1/UPF2 connect to VRF1 on PE1/PE2 and VRF1 is for the VPN of the 156 DN that UE1/UE2 access. There is also a PE3 for other sites of the 157 VPN, which could be wireline sites including sites providing Internet 158 access. 160 UEs may keep their persistent IP addresses even when they re-anchor 161 from one PSA UPF to another. In that case, for downlink traffic to 162 be sent to the right UPF, when a UE anchors at a UPF the UPF 163 advertises a host route for the UE and when a UE de-achors from a UPF 164 the UPF withdraws the host route. 166 While this relies on host routes to direct to-UE traffic to the right 167 UPF, it does not introduce additional scaling burden compared to 168 centralized PSA UPF model, as the centralized UPFs need to maintain 169 per-UE forwarding state (in the form of PDRs/FARs) and the number is 170 the same as the number of host routes that a hub DN router (e.g. vrf1 171 on PE3 for internet access) need to maintain in the distributed PSA 172 UPFs model. Since the host routes may be lighter-weighted than the 173 PDRs/FARs, the total amount of state may be actually smaller in the 174 distributed model. 176 For UE-UE traffic, the distributed PSA UPFs may maintain host routes 177 that they learn from each other. With that the UE-UE traffic may 178 take direct UPF-UPF path instead of going through a hub router in the 179 DN (equivalent of central UPF). That is important in LAN-type 180 services that require low delay. Alternatively, the distributed UPFs 181 may maintain only a default route pointing to the hub router like PE3 182 (besides the host routes for locally anchored UEs). That way, they 183 don't need to maintain many host routes though UPF-UPF traffic has to 184 go through the hub router (and that is similar to all traffic going 185 through a central PSA UPF). 187 Optionally, even the host routes for locally anchored UEs can be 188 omitted in the FIB of local UPF. Traffic among local UEs can be 189 simply routed to the hub router following the default route, who will 190 then send back to local UPF using VPN tunnels (MPLS or SRv6) that are 191 stitched to GTP tunnels for destination UEs. 193 2.1. Advantages of Distributed PSA UPFs 195 Distributed PSA UPFs have the following advantages: 197 * MEC becomes much simpler - no need for centralized PSA UPF plus 198 ULCL UPFs, and no need for special procedures for location based 199 edge server discovery. 201 * For LAN-type services, UE-UE traffic can be optimized (no need to 202 go through centralized PSA UPFs) when UPFs maintain host routes. 203 It also allows seamless integration of services across wireline/ 204 wireless-connected customer sites. 206 * N3/N9 tunneling is simplified 208 In particular, there is now only short/simple N3 tunneling between 209 AN/gNB and local UPFs in proximity. Among the distributed UPFs and 210 other DN sites, versatile IETF/wireline VPN technologies are used 211 instead. For example: 213 * Any tunneling technology - MPLS, SR-MPLS or SRV6 - with any 214 traffic engineering/differentiation capabilities can be used. 215 Removal of the GTP/UDP header (and IPv4/IPv6 header in case of 216 MPLS data plane) brings additional bandwidth savings in the 217 transport infrastructure. 219 * Any control plane model for VPN can be used - traditional 220 distributed or newer controller based route advertisement. 222 In short, the distributed PSA UPFs model achieves "N3/N9/N6 shortcut 223 and central UPF bypass", which is desired by many operators. 225 Notice that, since UPF has routing functions, depending on the 226 capability of a UPF device, it may even be possible for a UPF device 227 to act as a VPN PE. That can be done in one of the two models: 229 * The UPF function and VPN PE function are separate but co-hosted on 230 the same device with a logical/internal N6 connection between 231 them. 233 * The UPF and VPN PE function are integrated and the PDU sessions 234 become VPN PE-CE links. 236 The second model is especially useful when a UE is multi-homed to 237 different EVPN PEs in case of Ethernet PDU sessions - EVPN's all- 238 active multihoming procedures can be utilized. 240 2.2. Enablers of Distributed PSA UPFs 242 To distribute PSA UPFs, if persistent addresses must be used for UEs, 243 the SMF must be able to allocate persistent IP addresses from a 244 central pool even when a UE re-anchors at different PSA UPFs (e.g. 245 due to mobility). If DHCPv4 is used, either the SMF acts as a 246 central DHCP server or it relays DCHP requests to a central DHCP 247 server on the DN. 249 The distributed PSA UPFs must be able to advertise host routes in the 250 DN. This should not be a problem since a UPF is essentially a router 251 in that it routes traffic between DN and UEs (that are connected via 252 PDU sessions). 254 Notice that, advertising host routes for persistent IP addresses is 255 no different from advertising MAC addresses in case of Ethernet PDU 256 sessions. 258 3. MUP Evolution in 5G: Alternative Implementation Options 260 3.1. GTP vs. SRv6 vs. MPLS tunneling 262 3GPP specifies that all tunneling (e.g. N3/N9) use GTP, whose 263 encapsulation includes IP header, UDP header and GTP header. The 264 tunnel is between 3GPP NFs (e.g. gNBs and UPFs) over an IP transport, 265 and the IP transport may be a VPN over the multi-service transport 266 infrastructure of an operator. 268 There have been proposals to replace GTP with SRv6 tunnels for the 269 following benefits: 271 * Traffic Engineering (TE) and Service Function Chaining (SFC) 272 capability provided by SRv6 274 * Bandwidth savings because UDP and GTP headers are no longer needed 276 While 3GPP has not adopted the proposal, and GTP can be transported 277 over SRv6 (as overlay, instead of SRv6 replacing GTP), some operators 278 still prefer to replace GTP with SRv6 "under the hood". That is, 279 while RAN/UPF still use N2/N4 signaling, the actual tunnel are no 280 longer GTP but SRv6 based on GTP parameters signaled by N2/N4. The 281 SRv6 tunnel could be between two NFs, or a GW could be attached to an 282 NF that still use traditional GTP and the GW will convert GTP to/from 283 SRv6. This is specified in [I-D.ietf-dmm-srv6-mobile-uplane]. 285 Similarly, if an operator prefers to use MPLS, a GTP tunnel can also 286 be replaced with an MPLS PW instead of an SRv6 tunnel. Compared with 287 SRv6, it is even more bandwidth efficient (no need for a minimum 288 40-byte IPv6 header) and SR-MPLS can also provide TE/SFC 289 capabilities. This is specified in 290 [I-D.zzhang-pals-pw-for-ip-udp-payload]. 292 Note that, While only IPv6 can scale to the 5G requirements for the 293 transport infrastructure, it does not mean MPLS can not be used as 294 data plane in the IPv6 network. 296 3.2. Routing Based UPF 298 Traditionally, a UPF is implemented to follow 3GPP specifications. 299 Specifically, N4 signaling is used for SMF to instruct a UPF to set 300 up its session state in terms of PDRs/FARs. On N6 side, a UPF 301 receives downlink traffic with destination addresses that are covered 302 by the UPF's address range for its anchored UEs. The packet is 303 matched against the installed PDRs and forwarded according to the 304 associated FARs. On N3 side, a UPF decapsulates GTP+UDP+IP header of 305 uplink traffic and uses the TEID to identify the DN where inner IP 306 routing or Ethernet switching is done. 308 [I-D.mhkk-dmm-srv6mup-architecture] specifies a new SRv6 based MUP 309 architecture. When it is applied to a 3GPP based mobile 310 architecture: 312 * BGP signaling from a MUP Controller replaces N4 signaling from 313 SMF. N4 signaling is still used between the MUP Controller and 314 SMF - from SMF's point of view it is just interacting with a 315 traditional UPF as usual. 317 * A MUP GW becomes a distributed UPF for uplink traffic. 319 * A MUP PE, which is different from a usually central PSA UPF, 320 becomes a UPF for downlink traffic, in that traffic to each UE is 321 placed into a different tunnel that is stitched to a GTP tunnel 322 for that UE by a MUP GW (no route lookup is needed on the MUP GW 323 for the downlink traffic). 325 In this approach UE to UE traffic may still optionally go through the 326 central PSA UPF. This is similar to that a hub router may be used in 327 Section 2. 329 This approach can be viewed as a specific way of implementing/ 330 deploying distributed UPFs discussed in Section 2. It does have the 331 advantage that from SMF's point of view, nothing is different from 332 before - both from N4 signaling and deployment model point of view. 334 While the above is specific to SRv6, a similar MPLS based approach 335 will be specified separately for operators who prefer MPLS data 336 plane, and it can even be SR-agnostic. 338 4. Security Considerations 340 To be provided. 342 5. Informative References 344 [I-D.ietf-dmm-srv6-mobile-uplane] 345 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 346 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 347 Mobile User Plane", Work in Progress, Internet-Draft, 348 draft-ietf-dmm-srv6-mobile-uplane-18, 18 February 2022, 349 . 352 [I-D.mhkk-dmm-srv6mup-architecture] 353 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 354 Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo, 355 P., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., and K. 356 Perumal, "Segment Routing IPv6 Mobile User Plane 357 Architecture for Distributed Mobility Management", Work in 358 Progress, Internet-Draft, draft-mhkk-dmm-srv6mup- 359 architecture-01, 10 November 2021, 360 . 363 [I-D.zzhang-pals-pw-for-ip-udp-payload] 364 Zhang, Z., "PW for IP/UDP Payload without IP/UDP Headers", 365 Work in Progress, Internet-Draft, draft-zzhang-pals-pw- 366 for-ip-udp-payload-00, 22 December 2021, 367 . 370 [_3GPP-23.501] 371 "System architecture for the 5G System (5GS), V17.3.0", 372 December 2021. 374 Authors' Addresses 376 Zhaohui Zhang 377 Juniper Networks 379 Email: zzhang@juniper.net 381 Keyur Patel 382 Arrcus 384 Email: keyur@arrcus.com 386 Tianji Jiang 387 China Mobile 389 Email: tianjijiang@chinamobile.com