idnits 2.17.00 (12 Aug 2021) /tmp/idnits42609/draft-tjiang-dmm-5g-dupf-5mbs-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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...siderations, DMM SHOULD enable multica...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-mhkk-dmm-srv6mup-architecture-01 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dmm T. Jiang 3 Internet-Draft China Mobile 4 Intended status: Informational 7 March 2022 5 Expires: 8 September 2022 7 5G Distributed UPFs for 5G Multicast and Broadcast Services (5MBS) 8 draft-tjiang-dmm-5g-dupf-5mbs-00 10 Abstract 12 The companion draft [I-D.zzhang-dmm-5g-distributed-upf] has described 13 the 5G mobile user plane (MUP) via the refinement of distributed 14 UPFs, along with various user plane implementations that some vendors 15 and operators are exploring, with the requirement of not introducing 16 changes to 3GPP architecture & signaling. The document 3GPP TS 17 23.247 [_3GPP-23.247] for 5G multicast and broadcast services, or 18 5MBS, specifies the 5GS architecture to support MBS communication. 19 Thanks to the addition of new 5GS network functions (NFs) and MB- 20 interfaces on 5G CP & UP, this might post additional provisioning & 21 implementation challenges to the underlay transport infrastructure. 23 This document is not an attempt to do 3GPP SDO work in IETF. 24 Instead, it discusses how to potentially integrate distributed UPFs 25 with the delivery of 5MBS communication, as well as the benefits of 26 using distributed UPFs to handle 5MBS traffic delivery. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Distributed UPFs in 5G User Plane . . . . . . . . . . . . . . 2 62 2. 5G Multicast and Broadcast Services (5MBS) . . . . . . . . . 4 63 3. 5G Distributed UPF for 5G MBS Communication . . . . . . . . . 5 64 3.1. 5MBS Transport Challenges . . . . . . . . . . . . . . . . 5 65 3.2. 5G Distributed UPF for 5MBS Implementation . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 6.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Distributed UPFs in 5G User Plane 75 Mobile User Plane (MUP) in 5G has two distinct parts: the Access 76 Network part between UE and gNB, and the Core Network part between 77 gNB and UPF. UPFs are traditionally deployed at central locations, 78 with UEs' PDU sessions encapsulated and extended thru GTP-U tunnels 79 via the N3 (and potentially N9) interfaces in 5GS. The interface N6 80 supports fundamentally a direct IP or Ethernet connection to the data 81 network or DN. 83 Actually, UPFs could be distributed & deployed closer to gNBs. 84 The draft [I-D.zzhang-dmm-5g-distributed-upf] has described the 5G 85 mobile user plane (MUP) via the refinement of distributed UPFs or 86 dUPFs. The following picture shows the dUPF architecture: 88 N3 N6 89 UE1 gNB1 | dUPF1 | 90 +---------+ |+------+-----+| 91 | PDU | || PDU | || PE1 92 +---------+ +------+------+|+------+ IP/ || +-----+--+ 93 | | | |GTP-U |||GTP-U | ||----+ IP/ | | 94 | 5G-AN | |5G-AN +------+|+------+Ether|| |Ether| | 95 | xHaul | |xHaul |L3/2/1|||L3/2/1| || +-----+--+ 96 +---------+ +------|------+|+------------+| ( ) 97 | | ( Transport ) PE3 98 | | ( Network +--+-----+ 99 UE2 gNB2 | dUPF2 | ( | | IP/ | 100 +---------+ |+------+-----+| ( (DN) | |Ether| 101 | PDU | || PDU | || ( +--+-----+ 102 +---------+ +------+------+|+------+ IP/ || +-----+--+ 103 | | | |GTP-U |||GTP-U | || | IP/ | | 104 | 5G-AN | |5G-AN +------+|+------+Ether|| |Ether| | 105 | xHaul | |xHaul |L3/2/1|||L3/2/1| || +-----+--+ 106 +---------+ +-------------+|+------------+| PE2 108 In distributed UPF architecture, the central (PSA) UPF is no longer 109 needed. dUPF1 and UPF2 connect via PE1 and PE2, respectively, to the 110 DN VPN (or network instance/NI) that UE1 and UE2 intend to access. 111 There could exist other PEs, like PE3 in the picture, for other sites 112 of the same network domain(VPN or NI) or for global Internet access. 114 There are some benefits of distributed UPFs: 116 * The N3 interface becomes very simple - over a direct or short 117 transport connection between gNB and dUPF. 119 * The transport infrastructure off N3/N9 and N6 are straightforward, 120 most likely over the same underlay VPN (MPLS, SR-MPLS or SRv6) 121 supporting the traditional N3/N9 tunneling as in centralized PSA 122 UPF case. 124 * MEC becomes much simpler since no need to deploy centralized PSA 125 UPF plus ULCL UPFs; UE-UE traffic can be optimized for LAN-type 126 services (via host-route). 128 In short, the distributed UPFs model achieves "N3/N9/N6 shortcut and 129 central UPF bypass", which is desired by many operators. 131 2. 5G Multicast and Broadcast Services (5MBS) 133 The 3GPP document TS 23.247 [_3GPP-23.247] for 5G multicast and 134 broadcast services, or 5MBS, specifies the 5GS architecture to 135 support MBS communication. The following picture shows the brief 136 system architecture of 5MBS: 138 ----+----------(SBA for 5GC) ---------+----- 139 | | | 140 +--+--+ +---+---+ +---+----+ 141 | AMF | | SMF | | MB-SMF | 142 +--+--+ +-+-+-+-+ +---+----+ 143 / | | 144 N2 / N4 | N4mb| 145 / | | 146 / N3 +-+-+---+ N19mb +---+----+ N6mb +----+ 147 +-----+---------+ UPF +--------------| MB-UPF |------| DN | 148 +----+ | | +-------+ (Individual) +---+----+ +----+ 149 | UE +---+ gNB | | 150 +----+ +-----+ | 151 |_________N3mb (shared delivery)_____| 153 TS 23.247 [_3GPP-23.247] adds new 5GS network functions (NFs) on both 154 5G control-plane (CP) and user-plane (UP). For example, the CP NF 155 MB-SMF is, in collaboration with the regular SMF, to provision and 156 signal to the UP NF MB-UPF (via the interface N4mb) for setting up 157 MBS delivery path. 159 5MBS has specified two data delivery modes, individual delivery vs. 160 shared delivery: 162 * Individual delivery: When the (downlink or DL) MBS packets are 163 received by the MB-UPF from the interface N6mb, MB-UPF replicates 164 & forwards those packets towards (multiple) UPFs, via the 165 interface N19mb, through either unicast (requiring multiple GTP 166 tunnels if unicast underlay transport is applied) or multicast (if 167 multicast underlay transport over N19mb is applied) transmission. 169 * Shared delivery: When the (DL) MBS packets are received by the MB- 170 UPF from N6mb, MB-UPF replicates & forwards those packets towards 171 (multiple) gNBs, via the interface N3mb (the lower-path in the 172 picture), through either (multiple) separate GTP tunnels if 173 unicast underlay transport over N3mb is applied, or a single GTP 174 tunnel if multicast underlay over N3mb is supported. 176 3. 5G Distributed UPF for 5G MBS Communication 178 3.1. 5MBS Transport Challenges 180 The 5MBS architecture in TS 23.247 [_3GPP-23.247] introduces some 181 network challenges: 183 * Because of the addition of new CP and UP NFs, this will post 184 additional provisioning & implementation challenges to the 185 underlay transport infrastructure. For example, in the individual 186 delivery mode, both SMF and MB-SMF have to synchronize with each 187 other to help set up the relay/stitching path between UPF, MB-UPF 188 and DN. 190 * The picture in previous section shows three new interface types 191 corresponding to three different segments: N3mb, N6mb and N19mb. 192 Based on the traffic delivery mode, once MB-UPF receives DL 193 traffic from N6mb, it will have to do either individual or shared 194 delivery. 196 * In accordance with TS 23.247 [_3GPP-23.247], the underlay 197 transport infrastructure of all three segments can use either 198 unicast or multicast transmission, based on the capabilities of 199 underlay networks. For example, for the DL _shared_ delivery from 200 MB-UPF to gNB via the interface N3mb, 5G MBS packets can be 201 transmitted to multiple gNBs via multicast transmission if the 202 underlay network supports. Otherwise, MB-UPF will have to use 203 unicast to transmit separately to (multiple) gNBs. Considering 204 that this unicast/multicast flexibility is applicable to all the 205 three above-mentioned segments, the implementation will have to 206 face more challenges. 208 3.2. 5G Distributed UPF for 5MBS Implementation 210 The REQ8 of [RFC7333] talks about the multicast efficiency between 211 non-optimal and optimal routes, where it states that, in term of 212 multicast considerations, DMM SHOULD enable multicast solutions to be 213 developed to avoid network inefficiency in multicast traffic 214 delivery. 216 The current 5MBS architecture requires all DL multicast traffic go 217 through the (centralized) MB-UPF, regardless of using the individual 218 or shared delivery. In many operators' networks, 5GS might be 219 deployed in a location that is relatively distant from customer 220 (edge) sites. In this scenario, the efficiency of multicast 221 transmission will be compromised. On the other aspect, 5G dUPF, 222 deployed closer to gNB, will make the implementation more efficient: 224 * For shared delivery, the MB-UPF can be distributed closer to gNB. 225 The N6mb is a normal IP interface which is connected to DN over 226 underlay network. This transport connection will most likely use 227 the VPN infrastructure that has been provisioned by operators for 228 5GS. As a dUPF, the N3mb tunnel off MB-UPF could be made much 229 simpler. In some field edge sites, a dUPF could co-locate on-prem 230 with gNB, which can even remove the usage of complex (inter-site) 231 VPN to favor native IP transport. 233 * For individual delivery, it involves two UPFs, one regular UPF and 234 one MB-UPF. To follow the current 3GPP specification, we can 235 distribute and deploy both UPFs closer to gNB. While the DL 236 traffic off the N6mb interface may achieve the same gain as in the 237 shared-delivery mode, the transport for N19mb tunnel and (regular) 238 N3 tunnel can be significantly simplified. Remember we have 239 mentioned that either unicast or multicast (underlay) transmission 240 can be used for N19mb (and actually also for N6mb and N3mb). 241 Therefore, applying dUPF will help simplify the N19mb VPN 242 transmission. 244 * For individual delivery, if we expand the scope beyond the current 245 3GPP spec, we could integrate the regular UPF and MB-UPF together 246 as a distributed UPF, and then deploy the dUPF closer to gNB. In 247 this scenario, both the N19mb and N3 tunnels can be simplified 248 significantly. TS 23.247 [_3GPP-23.247] specifies the behaviors 249 of MB-UPF, as a standalone NF. Indeed, all the features and 250 behaviors that would be implemented by a MB-UPF can be 251 collaboratively integrated into a regular UPF. This type of 252 'merging' will lead to more network efficiency and better 253 multicast traffic forwarding, conforming the [RFC7333] REQ8. 255 The draft [I-D.zzhang-dmm-5g-distributed-upf] discussed and compared 256 briefly different tunneling mechanisms to implement 3GPP GTP, i.e., 257 SRv6, MPLS as the underlay, or in [I-D.mhkk-dmm-srv6mup-architecture] 258 specifying a new SRv6 based MUP architecture to replace GTP. While 259 these proposals may experience different issues upon 5MBS transport 260 implementation, dUPF will make it more feasible. 262 4. Security Considerations 264 TBD. 266 5. IANA Considerations 268 This document requests no IANA actions. 270 6. References 271 6.1. Normative References 273 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 274 Korhonen, "Requirements for Distributed Mobility 275 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 276 . 278 6.2. Informative References 280 [I-D.mhkk-dmm-srv6mup-architecture] 281 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 282 Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo, 283 P., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., and K. 284 Perumal, "Segment Routing IPv6 Mobile User Plane 285 Architecture for Distributed Mobility Management", Work in 286 Progress, Internet-Draft, draft-mhkk-dmm-srv6mup- 287 architecture-01, 10 November 2021, 288 . 291 [I-D.zzhang-dmm-5g-distributed-upf] 292 Zhang, Z., Patel, K., and T. Jiang, "5G Distributed UPFs", 293 Work in Progress, Internet-Draft, draft-zzhang-dmm-5g- 294 distributed-upf-00, 6 March 2022, 295 . 298 [_3GPP-23.247] 299 "Architectural enhancements for 5G multicast-broadcast 300 services; V17.1.0", December 2021. 302 Author's Address 304 Tianji Jiang 305 China Mobile 306 Email: tianjijiang@chinamobile.com