On Mon, Oct 1, 2018 at 4:32 AM, <[email protected]> wrote: > 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?
Dirk, I am wondering what a UE that has thousands of downstream nodes and is multi-homed with attachments to several networks is called. It seems like it would be making UPF-like decisions in routing, QoS, and cost as to how forward uplink traffic. I don't think it can be a UPF of any attached network, but it seems like it's maybe acting as a "UPF" for it's own network (I think in IETF terminology we would just call it a glorified router). Tom > 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
