idnits 2.17.00 (12 Aug 2021) /tmp/idnits41628/draft-zzhang-dmm-mup-evolution-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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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.) ** The abstract seems to contain references ([I-D.zzhang-dmm-5g-distributed-upf]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (6 March 2022) is 69 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.zzhang-dmm-5g-distributed-upf' is mentioned on line 73, but not defined == Missing Reference: 'RFC3916' is mentioned on line 226, but not defined Summary: 3 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 6 March 2022 8 Mobile User Plane Evolution 9 draft-zzhang-dmm-mup-evolution-00 11 Abstract 13 [I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile 14 user plane in 5G, including distributed UPFs and alternative user 15 plane implementations that some vendors/operators are pushing without 16 changing 3GPP architecture/signaling. Building on top of that, this 17 document further discusses potentially integrating UPF and Acess Node 18 (AN) in a future generation (xG) of mobile network. 20 This document is not an attempt to do 3GPP work in IETF. Rather, it 21 discusses potential integration of IETF/wireline and 3GPP/wireless 22 technologies - first among parties who are familiar with both areas 23 and friendly with IETF/wireline technologies. If the ideas in this 24 document are deemed reasonable, feasible and desired among these 25 parties, they can then be brought to 3GPP for further discussions. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 7 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. MUP Evolution in xG . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Integrated AN/UP Function . . . . . . . . . . . . . . . . 2 62 1.2. Separate AN/UP Functions Connected by Pseudo Wires . . . 4 63 1.2.1. Details on Pseudo Wire . . . . . . . . . . . . . . . 5 64 2. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 4.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. MUP Evolution in xG 73 [I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile 74 user plane in 5G [_3GPP-23.501], including distributed UPFs and 75 alternative user plane implementations that some vendors/operators 76 are pushing without changing 3GPP architecture/signaling. 78 This section discusses potential MUP evolution in a future generation 79 (referred to as xG) of mobile networks. It does involve changes in 80 3GPP architecture and signaling, so the purpose of this section is to 81 share the ideas in IETF community first. If it gains consensus 82 within IETF community especially among mobile operators, then the 83 proposal may be brought to 3GPP community for further discussions. 85 1.1. Integrated AN/UP Function 87 In the distributed UPF model for 5G [I-D.zzhang-dmm-5g-distributed- 88 upf], AN and UPF are separate functions connected by N3 tunneling 89 over a short/internel transport connection. Routing happens on the 90 UPF between the DN and UEs over the N3 tunnels, and relay happens on 91 the AN between the N3 tunnels and AN protocol stack. 93 With AN and UPF functions more and more disaggregated and virtualized 94 even in 5G, it is becoming more and more feasible and attractive to 95 integrate the AN and UPF functions, eliminating the N3 tunneling and 96 the relay on AN entirely. The combined function is referred to as 97 ANUP in this document, which does routing between DN and UEs over the 98 AN protocol stack directly: 100 N6 101 UE1 ANUP | 102 +---------+ | 103 |App Layer| routing | 104 +---------+ +--/---+---\-+| 105 |PDU Layer| | PDU | || PE1 106 +---------+ +------+IP+L2|| +----+--+ 107 | | | | ||----+VRF1| | 108 | xG-AN | |xG-AN + or || +----+ | 109 | | | | || |VRFn| | 110 | Proto | |Proto +Ether|| +----+--+ 111 | | | | || ( ) 112 | Layers | |Layers+-----+| ( ) 113 | | | | L1 || ( Transport ) 114 +---------+ +------+-----+| ( ) 115 | ( Network ) PE3 116 | ( +--+----+ 117 UE2 ANUP | ( | |VRF1| 118 +---------+ | ( | |----+ 119 |App Layer| routing | ( | |VRFn| 120 +---------+ +--/---+---\-+| ( +--+----+ 121 |PDU Layer| | PDU | || ( ) 122 +---------+ +------+IP+L2|| ( ) 123 | | | | || ( ) 124 | xG-AN | |xG-AN + or || +----+--+ 125 | | | | ||----+VRF1| | 126 | Proto | |Proto +Ether|| +----+ | 127 | | | | || |VRFn| | 128 | Layers | |Layers+-----+| +----+--+ 129 | | | | L1 || PE2 130 +---------+ +------+-----+| 131 | 133 With this architecture, 3GPP and IETF technologies are applied where 134 they are best applicable: 3GPP technologies responsible for radio 135 access and IETF technologies for the rest. As IETF technologies 136 continue to evolve, they can be automatically applied in mobile 137 networks without any changes in 3GPP architecture/specification. 139 Some advantages of this new architecture include: 141 * Any kind of tunnels can be used for the DN VPN, whether it is MPLS 142 or SRv6, w/o the overhead of UDP/GTP encapsulation compared to GTP 143 tunneling. Network slicing function is still supported (even with 144 current GTP tunneling the transport network need to instantiate 145 slices for N3/N9 tunnels as well). 147 * 5G-LAN and MEC become native applications (PDU sessions terminate 148 into the closest ANUP and routed/switched to various DNs). 150 * MBS becomes very simple - the ANUP gets the multicast traffic from 151 the DN and then use either shared radio bearer or individual 152 bearers to send to interested UEs. 154 Because the ANUP already implement the routing/switching functions, 155 even the PE functions (for the DN VPN) could be optionally integrated 156 into it, further streamlining end-to-end communication by reducing 157 NFs and connections between them. 159 1.2. Separate AN/UP Functions Connected by Pseudo Wires 161 There are still cases where separate AN/UP functions are desired/ 162 required: 164 * An MNO may want to deploy one UPF for a cluster of ANs in 165 proximity in some scenarios/locations 167 * An MNO may support MVNOs who have their own UP functions but make 168 use of the hosting MNO's ANs 170 * Home Routed roaming requires separate HPLMN UPs and VPLMN ANs 172 All these still require tunneling between ANs and UPs, but the 173 tunneling can be achieved via IETF's Pseudo Wire technology [RFC3985] 174 as shown in the following diagram. Note that, using PW is just an 175 option - GTP can still be used if that is desired. 177 UE1 AN 178 +---------+ 179 |App Layer| 180 +---------+ 181 |PDU Layer| relay 182 +---------+ +--/---+--\---+ Pseudo Wire 183 | | | | |--------------------------------+ 184 | xG-AN | |xG-AN | PW | \ 185 | | | | | \ 186 | Proto | |Proto |Proto | +----+--+ \ 187 | | | | | ( ) \ 188 | Layers | |Layers|Layers| ( ) \ 189 | | | | | ( Transport ) UP \ 190 +---------+ +------+------+ ( ) | + 191 ( Network ) PE3 | routing | 192 N6 ( +--+----+|+--/--+---\--+ | 193 UE2 ANUP | ( | |VRF1||| | PDU | | 194 +---------+ | ( | |----+||IP+L2+------+ | 195 |App Layer| routing | ( | |VRFn||| | | | 196 +---------+ +--/---+---\-+ | ( +--+----+|| or | PW +-+ 197 |PDU Layer| | PDU | | | ( ) || | | 198 +---------+ +------+IP+L2| | ( ) ||Ether|Proto | 199 | | | | | | ( ) || | | 200 | xG-AN | |xG-AN + or | | +----+--+ ||-----|Layers| 201 | | | | +-+---+VRF1| | || L1 | | 202 | Proto | |Proto +Ether| | +----+ | |+-----+------+ 203 | | | | | | |VRFn| | | 204 | Layers | |Layers+-----+ | +----+--+ N6 205 | | | | L1 | | PE2 206 +---------+ +------+-----+ | 207 | 209 On the AN, relay happens between the AN protocol stack and PW 210 protocol stack. On the UP (at the right side of the above diagram), 211 routing happens at PDU layer (over the PW that is stitched to the AN 212 protocol stack on the AN) between UE1 and N6 connection to VRF1 on 213 PE3. The UP is either one in HPLMN in Home Routed Roaming case (and 214 the AN is in the VPLMN), or one in VMNO (and the AN is in the hosting 215 MNO), or one for a cluster of ANs. 217 1.2.1. Details on Pseudo Wire 219 This section provides some details on how PWs are used for the AN-UP 220 tunneling. 222 From [RFC3985]: 224 --------------------------------------------------------------------- 225 This document an architecture for Pseudo Wire Emulation 226 Edge-to-Edge (PWE3) in support of [RFC3916]. It discusses the 227 emulation of services such as Frame Relay, ATM, Ethernet, TDM, and 228 SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It 229 presents the architectural framework for pseudo wires (PWs), defines 230 terminology, and specifies the various protocol elements and their 231 functions. 232 … 233 PWs provide the following functions in order to emulate the behavior 234 and characteristics of the native service. 236 o Encapsulation of service-specific PDUs or circuit data arriving 237 at the PE-bound port (logical or physical). 238 o Carriage of the encapsulated data across a PSN tunnel. 239 o Establishment of the PW, including the exchange and/or 240 distribution of the PW identifiers used by the PSN tunnel 241 endpoints. 242 … 243 The payload is classified into the following generic types of native 244 data units: 246 o Packet 247 o Cell 248 o Bit stream 249 o Structured bit stream 250 --------------------------------------------------------------------- 252 When applied to tunneling between AN and UP, the PW payload type is 253 "Packet" - IP packet or Ethernet frame (that is the over the SDAP 254 layer between UE and AN) for IP or Ethernet PDU session respectively. 255 In case of Unstructured PDU session type, the PW payload type would 256 be "Bit stream" or "Structured bit stream". 258 Also from [RFC3985]: 260 --------------------------------------------------------------------- 261 Figure 2 illustrates the network reference model for point-to-point 262 PWs. 263 |<-------------- Emulated Service ---------------->| 264 | |<------- Pseudo Wire ------>| | 265 | | |<-- PSN Tunnel -->| | | 266 | V V V V | 267 V AC +----+ +----+ AC V 268 +-----+ | | PE1|==================| PE2| | +-----+ 269 | |----------|............PW1.............|----------| | 270 | CE1 | | | | | | | | CE2 | 271 | |----------|............PW2.............|----------| | 272 +-----+ ^ | | |==================| | | ^ +-----+ 273 ^ | +----+ +----+ | | ^ 274 | | Provider Edge 1 Provider Edge 2 | | 275 | | | | 276 Customer | | Customer 277 Edge 1 | | Edge 2 278 | | 279 | | 280 Native service Native service 281 --------------------------------------------------------------------- 283 The following explains the mapping to AN-UP tunneling: 285 * CE1 corresponds to a UE and PE1 corresponds to the AN 287 * The radio link between CE1/UE and PE1/AN is the AC in PW 288 architecture. PDU session is the Emulated Service. Pseudo Wire 289 corresponds to the AN-UP tunnel. TSN tunnel corresponds to the 290 UDP tunnel that transports N3/N9 in 5G. 292 * PE2 and CE2 together correspond to the UP. It could be viewed 293 that the PE2 provides AN function (with the PW corresponding to 294 the radio link) and CE2 provides the UP function. 296 * PE1 takes the PDU packet from UE (after decapsulate the SDAP 297 stack), which is treated as PW payload, and sends to PE2 over the 298 PW. PE2 decapsulates the PW encapsulation and exposes the PDU 299 (like that a gNB decapsulates the SDAP stack), which is then 300 terminated by CE2 (though PE2 and CE2 are integrated into a single 301 UP). 303 In 5G Home Routed roaming architecture, there is a pair of I-UPFs 304 between the two PLMNs - the N3 tunnel does not extend directly from a 305 VPLMN's AN to a HPLMN's UPF. The same concept also exists in VPN/PW 306 technology - the I-UPFs are comparable to a pair of ASBRs that 307 provide Option-B inter-AS VPN/PW services. 309 2. Security Considerations 311 To be provided. 313 3. Acknowledgements 315 The authors thank Arda Akamn, Constantine Polychronopoulos, Sandeep 316 Patel and Shraman Adhikary for their review, comments and suggestions 317 to make this document and solution more complete. 319 4. References 321 4.1. Normative References 323 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 324 Edge-to-Edge (PWE3) Architecture", RFC 3985, 325 DOI 10.17487/RFC3985, March 2005, 326 . 328 4.2. Informative References 330 [_3GPP-23.501] 331 "System architecture for the 5G System (5GS), V17.3.0", 332 December 2021. 334 Authors' Addresses 336 Zhaohui Zhang 337 Juniper Networks 339 Email: zzhang@juniper.net 341 Keyur Patel 342 Arrcus 344 Email: keyur@arrcus.com