Hi Alex, and sorry for jumping into the discussion... From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting on the other side of RAN (gNB) - whereas a UPF normally is seen as UP entry (and exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP split fashion). Any other ideas on this? Can someone imagine any scenario where UE implements UPF? Thanks! Best Regards Dirk
-----Original Message----- From: dmm [mailto:[email protected]] On Behalf Of Alexandre Petrescu Sent: Montag, 1. Oktober 2018 13:22 To: [email protected] Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 Le 01/10/2018 à 05:50, Shunsuke Homma a écrit : > Hi all, > # Sorry for my late response... > > Thank you for your lively discussion. It is very helpful for > understanding points which need supplemental explanation and more > consideration. > > Following the discussion, we're planning to update the I-D for > covering the points below: > > - termination points of GTP-U > (RANs and UPFs terminate GTP-U in 5GS.) What is UPF? I understand UPF stands for User-Plane Function. Is my smartphone supposed to implement UPF? Alex > - setting QoS parameter of outer IP header > (Note that it's not just copy of inner to outer.) > - problems related to IP connectivity (e.g., MTU in IPv6 networks, > IPv4 address duplication) > - summary of network slicing in 5GS > (E.g., "slice is composed of SMF and UPFs. AMF selects SMF > depending on NSSAI sent from UE, and SMF indicates to the UE the UPF > that it is > allocated.") > - case studies on UPF selection > (E.g., parameters used for deciding destination UPF) # Optimizing > forwarding paths solution might be realized with UPF selection > mechanism in 3GPP architecture. (ID-LOC may be applied as such > mechanism.) > > > If you have any request for us on this updating, please let us know. > > Best regards, > > Shunsuke > > On 2018/09/08 3:28, Dino Farinacci wrote: >>> I understand your point, but there is no guarantee for a precise QoS >>> without using some sort of encapsulation being it GTP, RSVP, etc. >>> Even with tunnels, there is no guarantee that all nodes along the >>> path have the same hardware capability and can provide the same QoS >>> treatment. >> >> There is existing hardware where the encapsulator copies inner QoS to >> outer QoS. All routers along the path just process the outer QoS, no >> changes to or new processing requirements for them. >> >>> For example, the code points in routers need to be configured to >>> correctly handle the EXP bits in MPLS labels. But there is no >>> guarantee that all routers can support all values. The EXP values >>> get mapped to code points but the mapping is not always one to one. >>> 3-bit EXPs can map to 4 code points on those routers with less >>> capable H/W. >> >> That is a completely different matter. The discussion is about >> remarking. And if one remarks to what the path cannot support, well >> things don’t work as expected. >> >>> Slicing is almost the same. It allows user traffic to be mapped to >>> what the operator provides. >>> I agree with you that network should not touch/change original >>> header bits. GTP or any other encapsulation easily allow for this. >>> The question is whether we can provide for this without using >>> encapsulation. IPv6 might be the answer. But as Tom pointed out, >>> flow labels can still change in the middle. Is there any room for >>> improvement. SIDs might present an opportunity. >> >> Not if they are encapsulated and routers don’t touch packets inside. >> >> Dino >> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Dino Farinacci [mailto:[email protected]] >>>> Sent: 07 September 2018 13:08 >>>> To: Arashmid Akhavain <[email protected]> >>>> Cc: Tom Herbert <[email protected]>; [email protected]; >>>> dmm <[email protected]> >>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 >>>> >>>> I think you’ll still have the PHB re-marking issues I mentioned in >>>> previous emails. The question is, should the network touch/change >>>> any header bits of the packet the source has built. The answer >>>> should probably be no. >>>> >>>> Having said that, GTP did it the right way, even though it cost in >>>> header length. >>>> >>>> Dino >>>> >>>>> On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain >>>> <[email protected]> wrote: >>>>> >>>>> Correct, flow labels can change along the path. That's why I like >>>>> the slicing >>>> concept. >>>>> UEs can request services with different attributes, operators >>>>> control how >>>> service request are mapped into slices. I should look into the air >>>> side of the business and see what happens there. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Tom Herbert [mailto:[email protected]] >>>>>> Sent: 07 September 2018 11:13 >>>>>> To: Arashmid Akhavain <[email protected]> >>>>>> Cc: Dino Farinacci <[email protected]>; >>>>>> [email protected]; dmm <[email protected]> >>>>>> Subject: Re: [DMM] Comments to >>>>>> draft-hmm-dmm-5g-uplane-analysis-01 >>>>>> >>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dino Farinacci [mailto:[email protected]] >>>>>>>> Sent: 06 September 2018 18:59 >>>>>>>> To: Arashmid Akhavain <[email protected]> >>>>>>>> Cc: Tom Herbert <[email protected]>; ta-miyasaka@kddi- >>>> research.jp; >>>>>>>> dmm <[email protected]> >>>>>>>> Subject: Re: [DMM] Comments to >>>>>>>> draft-hmm-dmm-5g-uplane-analysis- >>>> 01 >>>>>>>> >>>>>>>>> Dino brought up a good point. Here is my two cents worth: >>>>>>>> >>>>>>>> Not sure which point. >>>>>>>> >>>>>>>>> As it was explained by Sridhar, each UE can have multiple >>>>>>>>> contexts. For >>>>>>>> example, today some operators provide Data and VoLTE service to >>>>>>>> their customers. These two services are represented by separate >>>>>>>> GTP tunnels in the core with each tunnel tied up to a particular QoS. >>>>>>>>> >>>>>>>>> IPv4 didn't fit the bill when GTP work was under way as it >>>>>>>>> couldn't uniquely identify multiple UE >>>>>>>> >>>>>>>> There is no reason why it shouldn’t. And IPv6, for this >>>>>>>> use-case doesn’t add anything new other than a 28 bit >>>>>>>> traffic-class/flow-label that can provide more bits for “new >>>> functionality”. >>>>>>> >>>>>>> >>>>>>> [Arashmid] And that's what I meant. Having a flow label is handy. >>>>>>> We can perhaps use it to identify different UE sessions. >>>>>>> >>>>>> Careful if you use the flow label to identify flows. It should be >>>>>> considered "soft identification" since it might not always be >>>>>> correct (it can be changed en route, isn't protected by any >>>>>> checksum, anyone can set it however they want, etc.). It's useful >>>>>> for things like ECMP that don't require 100% accuracy in >>>>>> identifying flow. The flow label was briefly considered for >>>>>> holding VNIs in network virtualization, but we >>>> talked them out of that. >>>>>> >>>>>> Tom >>>>>> >>>>>>>> >>>>>>>>> sessions/context/bearer. So, GTP and TEID did the job. But I >>>>>>>>> agree with >>>>>>>> Dino that IPv6 is much more versatile and is definitely worth >>>>>>>> looking at as an alternative. >>>>>>>> >>>>>>>> That is not what I said. I said “IP could have solved this >>>>>>>> problem”. And >>>> “IP” >>>>>>>> means either IPv4 or IPv6, or both at the same time. >>>>>>> >>>>>>> >>>>>>> [Arashmid] >>>>>>> How would we employ IPv4 to distinguish between different UE >>>>>>> sessions. >>>>>> TOS? >>>>>>> Or you mean using encapsulation? >>>>>>> >>>>>>>> >>>>>>>>> A factor worth considering though is that the use of GTP and >>>>>>>>> TEID in mobile >>>>>>>> core allows operators to deal with QoS on their own terms. The >>>>>>>> tunnels with specific operator-controlled QoS are established >>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or >>>>>>>> applications sitting in the UEs have no say in this. Well at >>>>>>>> least till the packet exits operator's >>>>>> network. >>>>>>>> >>>>>>>> The problem with one header, is that if you re-mark (known as >>>>>>>> PHB markign in the ole days) you lose the original value. >>>>>>>> Encapsulation is useful here because you can map the inner to >>>>>>>> outer and anywhere along the path you can PHB remark on the >>>>>>>> outer header. And then the destination can see the orignal >>>>>>>> source’s ToS/QoS/TC/flow-label >>>> whatever. >>>>>>> >>>>>>> >>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. >>>>>>> Encapsulation certainly makes things easier and the inner to >>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple >>>>>>> labels like service and transport) >>>>>>> >>>>>>>> >>>>>>>>> Using the information in UE's IP packet header can jeopardise >>>>>>>>> the above tight QoS control. I think going >>>>>>>> >>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly >>>>>>>> retain the original flow-label if the SID can retain those bits >>>>>>>> before overwriting the destination address from the option’s value. >>>>>>> >>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why >>>>>>> GTP has worked well and served the purpos in the mobile >>>>>>> back-haul so far. >>>>>>> >>>>>>>> >>>>>>>> Dino >>>>>>>> >>>>>>>>> down this path, operators need proof that they will be still >>>>>>>>> in the driving >>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any >>>>>>>> application running in it. >>>>>>>>> >>>>>>>>> Now, here is an interesting question for the operators. Would >>>>>>>>> any operator >>>>>>>> be interested in allowing QoS to be set by the UE or by >>>>>>>> applications running in the UE and charged for by the network? >>>>>>>> "Yes" could potentially imply impacts on the air interface, UE >>>>>>>> resource block allocation and can make scheduling on the RAN >>>>>>>> side >>>> much more complex. >>>>>>>>> >>>>>>>>> Arashmid >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: dmm [mailto:[email protected]] On Behalf Of Dino >>>>>>>>>> Farinacci >>>>>>>>>> Sent: 06 September 2018 12:45 >>>>>>>>>> To: Tom Herbert <[email protected]> >>>>>>>>>> Cc: [email protected]; dmm <[email protected]> >>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- >>>> analysis- >>>>>> 01 >>>>>>>>>> >>>>>>>>>>> Behcet, >>>>>>>>>>> >>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a >>>>>>>>>>> locator easily enough. >>>>>>>>>>> >>>>>>>>>>> Tom >>>>>>>>>> >>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. >>>>>>>>>> >>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, >>>>>>>>>> that could have been the UE’s IP address. And with IPv6 it >>>>>>>>>> can be unique and not the issue that Sridhar brought up. >>>>>>>>>> >>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. >>>>>>>>>> >>>>>>>>>> Dino >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> dmm mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> >>> >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmm >> > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
