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

Or use Mode 2. You will get a new IP address and will have no session
continuity.

Maybe it's useful in some  scenarios. If you find the usefulness then this
will become a deployment issue rather than protocol issue.

Or use Mode 3 and apply the service continuity procedures with IP address
change (if applicable*).

--
Uma C.

*warning: this needs non-psa UPF

On Tue, Apr 12, 2022 at 10:10 AM Jeffrey (Zhaohui) Zhang <zzhang=
[email protected]> wrote:

> Hi Linda,
>
>
>
> Yes, I will want to try again as a R18 TEI item. Hope to get some support
> 😊
>
>
>
> Thanks.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Linda Dunbar <[email protected]>
> *Sent:* Tuesday, April 12, 2022 12:37 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]
> *Subject:* RE: Questions about draft-zzhang-dmm-5g-distributed-upf-00
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 <[email protected]>
> *Sent:* Tuesday, April 12, 2022 9:35 AM
> *To:* Linda Dunbar <[email protected]>; [email protected]
> *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 <[email protected]>
> *Sent:* Friday, April 8, 2022 10:53 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email protected]>; [email protected]
> *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.
>
>
>
>
>
>
>
> 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 <[email protected]>
> *Sent:* Thursday, April 7, 2022 7:11 PM
> *To:* Linda Dunbar <[email protected]>; [email protected]
> *Subject:* RE: Questions about draft-zzhang-dmm-5g-distributed-upf-00
>
>
>
> Hi Linda,
>
>
>
> Please see zzh> below.
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* dmm <[email protected]> *On Behalf Of *Linda Dunbar
> *Sent:* Thursday, April 7, 2022 6:28 PM
> *To:* [email protected]
> *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://urldefense.com/v3/__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__;JSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!T347pdpAcJygu5DDw_CvBK8EqJ82efJBBSYzbNsRAdDR2oNOkfhW47isezyHSjvn$>;
> 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
>
>
>
> ,
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm