Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 1 Oct 2018 13:22:20 +0200

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-masked]]
>>>> Sent: 07 September 2018 13:08
>>>> To: Arashmid Akhavain <[email-masked]>
>>>> Cc: Tom Herbert <[email-masked]>; [email-masked];
>>>> dmm <[email-masked]>
>>>> 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-masked]> 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-masked]]
>>>>>> Sent: 07 September 2018 11:13
>>>>>> To: Arashmid Akhavain <[email-masked]>
>>>>>> Cc: Dino Farinacci <[email-masked]>;
>>>>>> [email-masked]; dmm <[email-masked]>
>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>>>>>
>>>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>>>>> <[email-masked]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Dino Farinacci [mailto:[email-masked]]
>>>>>>>> Sent: 06 September 2018 18:59
>>>>>>>> To: Arashmid Akhavain <[email-masked]>
>>>>>>>> Cc: Tom Herbert <[email-masked]>; ta-miyasaka@kddi-
>>>> research.jp;
>>>>>>>> dmm <[email-masked]>
>>>>>>>> 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-masked]] On Behalf Of Dino
>>>>>>>>>> Farinacci
>>>>>>>>>> Sent: 06 September 2018 12:45
>>>>>>>>>> To: Tom Herbert <[email-masked]>
>>>>>>>>>> Cc: [email-masked]; dmm <[email-masked]>
>>>>>>>>>> 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-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
>>
> 
>

---

From: <[email-masked]>
Date: Mon, 1 Oct 2018 11:32:59 +0000

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-masked]] On Behalf Of Alexandre Petrescu
Sent: Montag, 1. Oktober 2018 13:22
To: [email-masked]
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

Le 01/10/2018 à 05:50, Shunsuke Homma a écrit :
> Following the discussion, we're planning to update the I-D for 
> covering the points below:
> 

What is UPF?

Alex

> - problems related to IP connectivity (e.g., MTU in IPv6 networks, 
> IPv4 address duplication)
>    (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.")
>    (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.)
> 
> 
>>> 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.
>>> 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 
>>>> 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.
>>>>
>>>> header length.
>>>> side of the business and see what happens there.
>>>>>
>>>>>
>>>>>
>>>>>>>> their customers. These two services are represented by separate 
>>>>>>>> GTP tunnels in the core with each tunnel tied up to a particular QoS.
>>>>>>>>>
>>>>>>>> There is no reason why it shouldn’t. And IPv6, for this 
>>>>>>>> use-case doesn’t add anything new other than a 28 bit 
>>>>>> 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
>>>>>>>>> A factor worth considering though is that the use of GTP and 
>>>>>>>>> TEID in mobile
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>> Now, here is an interesting question for the operators. Would 
>>>>>>>>> any operator
>>>>>>>>>> 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.
>>>>>>>>>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 1 Oct 2018 07:14:31 -0700

> 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

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 2 Oct 2018 12:47:29 +0900

Thanks Dark for your explaining what is UPF instead of me.

Alex, brief definitions of UPF are described in the section 4.1.1.1 of 
this draft. Also, you can find more details in 3GPP TS23.501.

Regards,

Shunsuke

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 2 Oct 2018 10:44:03 -0500

UPF is virtualized PGW, folks.
While PGW is fixed in location and possibly serving a large number of UE
which are geographically in the area, that part of the city and that city
itself, UPF can be deployed closer to the UE and thus probably serving
smaller number of UEs

Behcet

On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma <[email-masked]>
wrote:

> >  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).

---

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 2 Oct 2018 17:09:51 +0000

Not necessarily,

You are correct in that PGW is a UPF, but a UPF is by no means limited to PGW. A UPF is any function that can be executed on user traffic in mobile network. Having said that however, I think the first UPFs that we will see will be in the form of SGW, PGW.

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma <[email-masked]>
Cc: dmm <[email-masked]>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

UPF is virtualized PGW, folks.
While PGW is fixed in location and possibly serving a large number of UE which are geographically in the area, that part of the city and that city itself, UPF can be deployed closer to the UE and thus probably serving smaller number of UEs

Behcet

On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Dark for your explaining what is UPF instead of me.

Regards,

Shunsuke

On 2018/10/01 20:32, [email-masked]<mailto:[email-masked]> wrote:
> From: dmm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
> To: [email-masked]<mailto:[email-masked]>
>>>>> From: Dino Farinacci [mailto:[email-masked]<mailto:[email-masked]>]
>>>>> To: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
>>>>> Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>>>>> dmm <[email-masked]<mailto:[email-masked]>>
>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>> From: Tom Herbert [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>> To: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
>>>>>>> Cc: Dino Farinacci <[email-masked]<mailto:[email-masked]>>;
>>>>>>> [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
>>>>>>> <[email-masked]<mailto:arashmid.akhavain@huawei..com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: Dino Farinacci [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>>>>> To: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
>>>>>>>>> Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; ta-miyasaka@kddi-
>>>>> research.jp<http://research.jp>;
>>>>>>>>> dmm <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>> From: dmm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dino
>>>>>>>>>>> Farinacci
>>>>>>>>>>> To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>> Cc: [email-masked]<mailto:[email-masked]>; dmm <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
----------------------------------
Shunsuke Homma
<[email-masked]<mailto:[email-masked]>>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 3 Oct 2018 21:59:10 +0530

>>A UPF is any function that can be executed on user traffic in mobile
network. Having said that however, I think the first UPFs that we will see
will be in the form of SGW, PGW.

Even this is not accurate.

A UPF is a *5G system core network* entity whereas the SGW-U and PGW-U are
EPC core network entities. 5G core network has many differences from EPC.
To avoid confusion it should be noted that 5G NR radio can be deployed with
EPC as the core network and technically such deployments can also be called
as 5G deployments. But an UPF has no role in such deployments.

Some of the user plane functionalities of an UPF are completely different
from SGW-U or PGW-U. Here are few differences (not exhaustive)

1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any QFI
marking. UPF on the other hand has one GTP-U tunnel per PDU session.
Different QoS flows within that PDU session are identified based on the QFI
marking. So a UPF has to support QFI marking.
2. An UPF can support classification and encapsulation Ethernet frames
whereas a SGW-U/PGW-U has no requirement to support classification and
encapsulation of Ethernet frames.
3. An UPF supporting Ethernet PDU session type may support ARP proxying /
IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement.
4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no
such requirement.

One may say that SGW-U / PGW-U also plays a role in user plane forwarding
and hence why not call it a UPF?  For the lack of a better terminology,
3GPP has called the entity that performs the user plane functionalities and
features within a *5G core network* as UPF. Those functionalities are not
exactly similar to EPC.

Thanks
Sridhar

On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain <
[email-masked]> wrote:

> Not necessarily,
>
>
>
> You are correct in that PGW is a UPF, but a UPF is by no means limited to
> PGW. A UPF is any function that can be executed on user traffic in mobile
> network. Having said that however, I think the first UPFs that we will see
> will be in the form of SGW, PGW.
>
>
>
> Arashmid
>
>
>
> *From:* dmm [mailto:[email-masked]] *On Behalf Of *Behcet Sarikaya
> *Sent:* Tuesday, October 02, 2018 11:44 AM
> *To:* Shunsuke Homma <[email-masked]>
> *Cc:* dmm <[email-masked]>
> *Subject:* Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
>
>
> On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma <
> [email-masked]> wrote:
>
> >>>>>>> <[email-masked] <arashmid.akhavain@huawei..com>>
> wrote:
> >>>>>>>>
> >>>>>>>>
> <[email-masked] <[email-masked]>>
> TEL: +81 422 59 3486
> FAX: +81 422 60 7460
>

-- 
 o__
 _>  /__
(_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner
world! :)

Sridhar Bhaskaran

---

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 4 Oct 2018 21:39:11 +0000

Well put Sridhar… Thank you for the detailed clarification.

Speaking of QoS Flow Identifiers, I am assuming that mapping the QoS requirements from 5G core to the underlying transport nodes (routers, switches) and vice versa has not been changed. Is this correct Sridhar?

Arashmid

From: Sridhar Bhaskaran [mailto:[email-masked]]
Sent: 03 October 2018 12:29
To: Arashmid Akhavain <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

>>A UPF is any function that can be executed on user traffic in mobile network. Having said that however, I think the first UPFs that we will see will be in the form of SGW, PGW.

A UPF is a 5G system core network entity whereas the SGW-U and PGW-U are EPC core network entities. 5G core network has many differences from EPC. To avoid confusion it should be noted that 5G NR radio can be deployed with EPC as the core network and technically such deployments can also be called as 5G deployments. But an UPF has no role in such deployments.

Some of the user plane functionalities of an UPF are completely different from SGW-U or PGW-U. Here are few differences (not exhaustive)

1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session. Different QoS flows within that PDU session are identified based on the QFI marking. So a UPF has to support QFI marking.
2. An UPF can support classification and encapsulation Ethernet frames whereas a SGW-U/PGW-U has no requirement to support classification and encapsulation of Ethernet frames.
3. An UPF supporting Ethernet PDU session type may support ARP proxying / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement.
4. An UPF shall support RQI bit for reflective QoS. A PGW-U/SGW-U has no such requirement.

One may say that SGW-U / PGW-U also plays a role in user plane forwarding and hence why not call it a UPF?  For the lack of a better terminology, 3GPP has called the entity that performs the user plane functionalities and features within a 5G core network as UPF. Those functionalities are not exactly similar to EPC.

Thanks
Sridhar

On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain <[email-masked]<mailto:[email-masked]>> wrote:
Not necessarily,

Arashmid

From: dmm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Cc: dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

Behcet

Regards,

Shunsuke

Sridhar Bhaskaran

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 5 Oct 2018 07:25:14 +0200

Thank you very much for the clarification.

I understand now that GTP is a user-plane function run in the network.

- the UE (smartphone) never runs GTP.  I think this is worth putting in
   the draft and state it as such, if we so believe.

- it is strange for me to call it a User-Plane Function while the user
   has no impact on it.  I think this abbreviation deserves
   clarification.  We can suggest to 3GPP to change the name.

(terms like data-plane/control-plane (not user-plane) are already in 
widespread use, and could be improved).

Alex

Le 03/10/2018 à 18:29, Sridhar Bhaskaran a écrit :
> network. Having said that however, I think the first UPFs that we will 
> see will be in the form of SGW, PGW.
> 
> Even this is not accurate..
> 
> A UPF is a _*5G system core network*_ entity whereas the SGW-U and PGW-U 
> are EPC core network entities. 5G core network has many differences from 
> EPC. To avoid confusion it should be noted that 5G NR radio can be 
> deployed with EPC as the core network and technically such deployments 
> can also be called as 5G deployments. But an UPF has no role in such 
> deployments.
> 
> Some of the user plane functionalities of an UPF are completely 
> different from SGW-U or PGW-U.. Here are few differences (not exhaustive)
> 
> 1. SGW-U and PGW-U --> one GTP-U tunnel per EPS bearer. No need of any 
> QFI marking. UPF on the other hand has one GTP-U tunnel per PDU session. 
> Different QoS flows within that PDU session are identified based on the 
> QFI marking. So a UPF has to support QFI marking.
> 3. An UPF supporting Ethernet PDU session type may support ARP proxying 
> / IPv6 ND Proxying whereas a SGW-U/PGW-U have no such requirement..
> One may say that SGW-U / PGW-U also plays a role in user plane 
> forwarding and hence why not call it a UPF?  For the lack of a better 
> terminology, 3GPP has called the entity that performs the user plane 
> functionalities and features within a _*5G core network*_ as UPF. Those 
> functionalities are not exactly similar to EPC.
> 
> Thanks
> Sridhar
> 
> On Tue, Oct 2, 2018 at 10:45 PM Arashmid Akhavain 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Not necessarily,____
> 
>     __ __
> 
>     You are correct in that PGW is a UPF, but a UPF is by no means
>     limited to PGW. A UPF is any function that can be executed on user
>     traffic in mobile network. Having said that however, I think the
>     first UPFs that we will see will be in the form of SGW, PGW.____
> 
>     __ __
> 
>     Arashmid____
> 
>     __ __
> 
>     *From:*dmm [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Behcet Sarikaya
>     *To:* Shunsuke Homma <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* dmm <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01____
> 
>     __ __
> 
>     UPF is virtualized PGW, folks.____
> 
>     While PGW is fixed in location and possibly serving a large number
>     of UE which are geographically in the area, that part of the city
>     and that city itself, UPF can be deployed closer to the UE and thus
>     probably serving smaller number of UEs____
> 
>     __ __
> 
>     Behcet____
> 
>     __ __
> 
>     On Mon, Oct 1, 2018 at 10:47 PM Shunsuke Homma
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:____
> 
>          >  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).
>          > From: dmm [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
>          > To: [email-masked] <mailto:[email-masked]>
>          >>>>> Cc: Tom Herbert <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>;
>          >>>>> dmm <[email-masked] <mailto:[email-masked]>>
>          >>>>> <[email-masked]
>         <mailto:[email-masked]>> wrote:
>          >>>>>>
>          >>>>>>> [email-masked]
>         <mailto:[email-masked]>; dmm <[email-masked]
>         <mailto:[email-masked]>>
>          >>>>>>> <[email-masked]
>         <mailto:arashmid.akhavain@huawei...com>> wrote:
>          >>>>>>>>
>          >>>>>>>>
>          >>>>>>>>> Cc: Tom Herbert <[email-masked]
>         <mailto:[email-masked]>>; ta-miyasaka@kddi-
>          >>>>> research.jp <http://research.jp>;
>          >>>>>>>>> dmm <[email-masked] <mailto:[email-masked]>>
>          >>>>>>>>> resource block allocation and can make scheduling on
>         the RAN
>          >>>>>>>>> side
>          >>>>> much more complex.
>          >>>>>>>>>>
>          >>>>>>>>>> Arashmid
>          >>>>>>>>>>
>          >>>>>>>>>>
>          >>>>>>>>>>> From: dmm [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Dino
>          >>>>>>>>>>> Farinacci
>          >>>>>>>>>>> Cc: [email-masked]
>         <mailto:[email-masked]>; dmm <[email-masked]
>         <mailto:[email-masked]>>
>          >>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>          >>> [email-masked] <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]>
>         <[email-masked]
>         <mailto:[email-masked]>>
>         TEL: +81 422 59 3486
>         FAX: +81 422 60 7460
> 
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/dmm____
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 Oct 2018 09:33:46 -0500

Alex, user plane means data plane in 3GPP terminology.
Data plane versus control plane  separation to my knowledge has first been
introduced by 3GPP.

Behcet
PS. Maybe Sridhar can add some 3GPP standard quotes/references here.