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]>; [email protected]; > >> 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
