Re: [DMM] Questions about draft-zzhang-dmm-5g-distributed-upf-00

[Linda Dunbar <[e-mail]>]

Jeffrey,

3GPP, at least Release 18, requires UE getting a new IP address when anchoring to a new UPF. Are you suggesting to add another mode (say Mode 4) that allow the UE to maintain the same IP address?

Your proposal makes sense to me. But  3GPP might not like it. Are you going to propose again?

Linda

From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Tuesday, April 12, 2022 9:35 AM
To: Linda Dunbar <[e-mail]>; [e-mail]
Subject: RE: Questions about draft-zzhang-dmm-5g-distributed-upf-00

Hi Linda,

Moving to a new gNB is different from moving to a new PSA UPF. I was referring to re-anchoring to a new UPF.

Jeffrey



Juniper Business Use Only
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 8, 2022 10:53 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Questions about draft-zzhang-dmm-5g-distributed-upf-00

[External Email. Be cautious of content]

Jeffrey:

3GPP SSC Mode 1 supports persistent IP for UE when handover to a new Cell tower, as shown in the figure below.

[cid:image001.png@01D84E62.4D0D04D0]


What is your following statement referring to?
Zzh> There is one thing that needs 3GPP work for traditional (but distributed) PSA UPFs - there could be some PDU sessions that need persistent IP addresses even if they re-anchor from one distributed PSA UPF to anothers. 3GPP currently does not support that.


Linda

From: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 7, 2022 7:11 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Questions about draft-zzhang-dmm-5g-distributed-upf-00

Hi Linda,

Please see zzh> below.



Juniper Business Use Only
From: dmm <[e-mail]<mailto:[e-mail]>> On Behalf Of Linda Dunbar
Sent: Thursday, April 7, 2022 6:28 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [DMM] Questions about draft-zzhang-dmm-5g-distributed-upf-00

[External Email. Be cautious of content]

Jeffrey,

As an IETFer, I like the idea you presented at IETF113 DMM session for draft-zzhang-dmm-5g-distributed-upf & draft-zzhang-dmm-mup-evolution.

Zzh> Thanks!

Just a few questions.

3GPP Release 18 does allow the distributed UFPs, and allow UFP and gNB to be collocated. As 5G deploy large number of Cell Towers, it is possible that one UPF can handle traffic for multiple gNBs.

Zzh> My understanding is that, in O-RAN case, the gNB function that does N2 signaling with AMF and N3 tunneling with UPF is on O-CU that handles many cell towers. Even in that case, there could be one distributed UPF for several gNBs (O-CUs). In that case (and in home-routed roaming and MVNO cases), separate gNB and UPF are still needed and that is discussed in https://datatracker.ietf.org/doc/html/draft-zzhang-dmm-mup-evolution-00#section-1.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-zzhang-dmm-mup-evolution-00*23section-1.2%26data%3D04*7C01*7Clinda.dunbar*40futurewei.com*7Ce02894714a4748b529f708da18f44ce0*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637849734801867735*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3D62hAHOJSa0Gz0ldx0OqI9Hptg0guywjWe2Gk43Ma2X8*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!ROquSQ5gWOXdF-zT-DSxK7o1jym0zDNFNlCfmKS4ZtUWVlRiEYam-IcBwjPpT5of%24&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C8ae7b810028d45cc585c08da1c91a178%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637853709056765182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Chk2m3o5pGj7Z%2FP6KDlMjq2UEuTCA%2Bas5h2WPeoYaTg%3D&reserved=0>; but as long as you can co-locate gNB and UPF on a single device then it make sense to integrate them into a single logical entity for optimized signaling and data plane.

Q1: When gNB and a UPF is collocated, what are the special features needed by  draft-zzhang-dmm-5g-distributed-upf?

Zzh> This draft is (actually both are) an informational draft - no work is need either in IETF or 3GPP (ok except one thing - see below - on 3GPP side). It just sets the stage for discussion in draft-zzhang-dmm-mup-evolution.

Zzh> There is one thing that needs 3GPP work for traditional (but distributed) PSA UPFs - there could be some PDU sessions that need persistent IP addresses even if they re-anchor from one distributed PSA UPF to anothers. 3GPP currently does not support that. I had a proposal that was accepted in 3GPP SA2's EC SID in R17 but I was not available to defend it when it came to the evaluation phase, so it was pushed out. I am trying to get it in R18 TEI phase in June time frame.

Zzh> On the other hand, with the SRv6 MUP architecture (and its SR-agnostic version), this is not a problem because SMF still thinks there is a central PSA UPF and the UE addresses won't change.

When one UPF is shared multiple gNBs, a GTP tunnel can carry additional information for UPF to process the data inside the GTP tunnel. Once the UPF decapsulate the GTP encapsulation, the inner IP is forwarded to the N6 interface (IP). Very often the UPF use NAT so the routers on the N6 interfaces don't see the actual source IP of the UE.
How is your proposed structure different from the current practice?

Zzh> I don't think NAT makes a difference. The additional information in GTP has nothing to do with NAT. It only tells the UPF which DN the traffic belongs to. Even if there is NAT on UPF, it is a separate logical non-3GPP function that happens to be implemented on the UPF, and it is done after GTP decapsulation and should be considered as done by a device on the DN. Now if we integrate gNB/UPF function into ANUP (or use MUP GW), and if NAT is needed before traffic is handed to a DN router, then the NAT must be implemented by the integrated ANUP device (or the MUP GW) or by a device directly connected to it.

Zzh> Jeffrey

Linda

,