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

[Arashmid Akhavain]

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:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma 
Cc: dmm 
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 
mailto:homma.shuns...@lab.ntt.co.jp>> wrote:
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

On 2018/10/01 20:32, dirk.von-h...@telekom.de 
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?
> Thanks!
> Best Regards
> Dirk
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On 
> Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org
> 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-

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

[Behcet Sarikaya]

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 
wrote:

> 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
>
> On 2018/10/01 20:32, dirk.von-h...@telekom.de 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?
> > Thanks!
> > Best Regards
> > Dirk
> >
> > -Original Message-
> > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu
> > Sent: Montag, 1. Oktober 2018 13:22
> > To: dmm@ietf.org
> > 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:farina...@gmail.com]
> > Sent: 07 September 2018 13:08
> > To: Arashmid Akhavain 
> > Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> > dmm 
> > 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