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

[Behcet Sarikaya]

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
> > <mailto: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
> > <mailto:dmm-boun...@ietf.org>] On Behalf Of Alexandre Petrescu
> >  > Sent: Montag, 1. Oktober 2018 13:22
> >  > To: dmm@ietf.org <mailto: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 o

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

[Alexandre Petrescu]

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 :
 >>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 
mailto:arashmid.akhav...@huawei.com>> 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:dmm-boun...@ietf.org
<mailto:dmm-boun...@ietf.org>] *On Behalf Of *Behcet Sarikaya
*Sent:* Tuesday, October 02, 2018 11:44 AM
*To:* Shunsuke Homma mailto:homma.shuns...@lab.ntt.co.jp>>
*Cc:* dmm mailto:dmm@ietf.org>>
*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
<mailto: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
<mailto:dmm-boun...@ietf.org>] On Behalf Of Alexandre Petrescu
 > Sent: Montag, 1. Oktober 2018 13:22
 > To: dmm@ietf.org <mailto:dmm@ietf.org>
 > Subject: Re: [DMM] Comments to
draft-hmm-dmm-5g-uplane-analysis-01
 >
 >
 >
 > 

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

[Arashmid Akhavain]

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:sridhar.bhaska...@gmail.com]
Sent: 03 October 2018 12:29
To: Arashmid Akhavain 
Cc: sarik...@ieee.org; homma.shuns...@lab.ntt.co.jp; dmm@ietf.org
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.

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 
mailto:arashmid.akhav...@huawei.com>> 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:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>] On Behalf 
Of Behcet Sarikaya
Sent: Tuesday, October 02, 2018 11:44 AM
To: Shunsuke Homma 
mailto:homma.shuns...@lab.ntt.co.jp>>
Cc: dmm mailto:dmm@ietf.org>>
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<mailto: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<mailto:dmm-boun...@ietf.org>] On 
> Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org<mailto: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.)
>
> Wha

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

[Sridhar Bhaskaran]

>>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 <
arashmid.akhav...@huawei.com> 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: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 <
> 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,
> 

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<mailto: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<mailto:dmm-boun...@ietf.org>] On 
> Behalf Of Alexandre Petrescu
> Sent: Montag, 1. Oktober 2018 13:22
> To: dmm@ietf.org<mailto: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
>>&

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 

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

[Shunsuke Homma]

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

 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:t...@quantonium.net]
Sent: 07 September 2018 11:13
To: Arashmid Akhavain 
Cc: Dino Farinacci ;
ta-miyas...@kddi-research.jp; dmm 
Subject: Re: [DMM] Comments to
draft-hmm-dmm-5g-uplane-analysis-01

On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
 wrote:




-Original Message-
From: Dino Farinacci [mailto:farina...

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

[Tom Herbert]

On Mon, Oct 1, 2018 at 4:32 AM,   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: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
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -

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

[Dirk.von-Hugo]

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 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 A

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

[Alexandre Petrescu]

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

 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:t...@quantonium.net]
Sent: 07 September 2018 11:13
To: Arashmid Akhavain 
Cc: Dino Farinacci ;
ta-miyas...@kddi-research.jp; dmm 
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
 wrote:




-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: 06 September 2018 18:59
To: Arashmid Akhavain 
Cc: Tom Herbert ; ta-miyasaka@kddi-

research.jp;

dmm 
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 tha

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

[Shunsuke Homma]

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

 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:t...@quantonium.net]
Sent: 07 September 2018 11:13
To: Arashmid Akhavain 
Cc: Dino Farinacci ;
ta-miyas...@kddi-research.jp; dmm 
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
 wrote:




-Original Message-
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: 06 September 2018 18:59
To: Arashmid Akhavain 
Cc: Tom Herbert ; ta-miyasaka@kddi-

research.jp;

dmm 
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
consid

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

[Behcet Sarikaya]

Folks, let's not forget that most of these things you are talking about are
session layer issues.
According to OSI layering, the session layer is Layer 5, above Layer 4
which is transport layer.
3GPP is using UDP which is Layer 4 for this session layer coding. I think
probably it is a better layer than the Internet layer which would be the
case with IdLoc protocols, I think even with LISP which uses UDP
encapsulation.

Behcet

On Thu, Sep 6, 2018 at 11:21 AM Tom Herbert  wrote:

> On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya 
> wrote:
> >
> >
> > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
> >>
> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
> >>  wrote:
> >> > My comments inline marked [SB]
> >> >
> >> >> > >>> It was never clear to me and no one could ever explain exactly
> >> >> > >>> why a
> >> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> >> >> > >>> was a
> >> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> >> >> > >>> inner addresses
> >> >> > >>> be used for accounting?
> >> >> >
> >> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> >> > identified the QoS and charging policy applicable to the bearer is
> >> >> > applied.
> >> >> > So the purpose of TEID is not just for accounting. Its for QoS
> >> >> > treatment,
> >> >> > charging and bearer context identification.
> >> >>
> >> >> You told me what a TEID is but you didn’t say why you need to use it
> >> >> versus using the destination IP address for the tunnel.
> >> >>
> >> >>
> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the
> PDU
> >> >> > session whereas the QFI carried in GTPU extension header identifies
> >> >> > the
> >> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >> >>
> >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> >> >> which
> >> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> >> encapsualting node, and (4) the decapsulating node.
> >> >>
> >> >> So again, why use more space in the packet, when you have sufficient
> >> >> information to identify a user, and therefore their packet policy?
> >> >>
> >> > [SB] Lets say we only use UE IP address and no TEID. How will you
> >> > identify
> >> > the bearer context the packet belongs? One UE may use multiple radio
> >> > bearers
> >> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but
> these
> >> > are
> >> > IP level markings which could be changed by any on path routers. In
> >> > order to
> >> > uniquely identify the bearer / qos flow a particular packet for a UE
> >> > belongs, GTPU uses TEID.
> >>
> >> Sridhar,
> >>
> >> Couldn't the TEID be encoded in the outer IP address of an
> >> encpasulation or network overlay in a similar way that VNIs are
> >> encoded in IP addresses in virtual networking?
> >>
> >> Tom
> >>
> >
> > ILA if used would remove any need for tunneling and TEID is for
> tunneling.
> >
> Behcet,
>
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
>
> Tom
>
> > Actually if you read 29.244 it is completely based on legacy protocols
> with
> > no IdLoc content at all, as Shunsuke mentioned.
> >
> > Behcet
> >>
> >> >
> >> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> >> > are
> >> > not always unique. The same IP pools can be shared across multiple
> PDNs
> >> > /
> >> > DNs as long as these PDNs / DNs are separate autonomous networks. So
> >> > just
> >> > relying on UE IP address alone will result in wrong context
> >> > identification
> >> > for the uplink traffic. There is a clear one to one mapping of Radio
> >> > bearer
> >> > to the EPS bearer / QoS flow required all the way upto the anchor node
> >> > for
> >> > charging and QoS treatment. This comes from the requirements in stage
> 2
> >> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501
> for
> >> > 5G).
> >> >
> >> > There are also requirements to support non-IP protocols like Ethernet
> >> > PDU
> >> > and Unstructured PDU types in 5G.
> >> >
> >> >> >>
> >> >> > >>> How can packets be sent if the session is not setup. If the
> >> >> > >>> session
> >> >> > >>> is not setup, the encapsulator should have no state. And
> packets
> >> >> > >>> should be
> >> >> > >>> dropped locally and not go far to get an error back. This
> sounds
> >> >> > >>> architecturally broken.
> >> >> >
> >> >> > [Sridhar] The purpose of GTP-U error indication is to signal in
> band
> >> >> > to
> >> >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving
> side
> >> >> > is lost
> >> >> > for any reason. "No session exist" does not mean Session
> >> >>
> >> >> What does lost mean? You mean the path from encapsulator to
> >> >> decapsulator
> >> >> is not working? And since we are in a packet network, that path can
> be
> >> >> restored 

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

[Satoru Matsushima]

Thanks Sridhar for your followups.


> Just pointing people to drafts doesn’t help in understanding. It requires 
> people to go off, put in a lot of time where the odds are their question will 
> not be answered.
> 
> [SB] TS 29.244 is not a draft but rather a full fledged technical 
> specification. The issue with repeating content from elsewhere instead of 
> just pointing is the risk of providing inaccurate information in IETF draft.

I don’t believe that 3GPP forbid anyone to publish any books, papers to 
describe what the 3GPP system and the protocols and how it works.

And it was one of our reasons to introduce the user plane analysis draft that 
introduces 3GPP specifications in familiar way for IETF people which could help 
to bridge two SDOs. 


Best regards,
--satoru


> 2018/09/06 19:24、Sridhar Bhaskaran のメール:
> 
> My comments inline marked [SB]
> 
> > >>> It was never clear to me and no one could ever explain exactly why a 
> > >>> TEID is needed. I presumed for accounting reasons. But if there was a 
> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
> > >>> addresses be used for accounting?
> > 
> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel 
> > and hence consequently a bearer. Once the bearer context is identified the 
> > QoS and charging policy applicable to the bearer is applied. So the purpose 
> > of TEID is not just for accounting. Its for QoS treatment, charging and 
> > bearer context identification.
> 
> You told me what a TEID is but you didn’t say why you need to use it versus 
> using the destination IP address for the tunnel.
>   
> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU 
> > session whereas the QFI carried in GTPU extension header identifies the 
> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> 
> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which 
> tells us (1) the UE, (2) the destination it is talking to, (3) the 
> encapsualting node, and (4) the decapsulating node.
> 
> So again, why use more space in the packet, when you have sufficient 
> information to identify a user, and therefore their packet policy?
> 
> [SB] Lets say we only use UE IP address and no TEID. How will you identify 
> the bearer context the packet belongs? One UE may use multiple radio bearers 
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are 
> IP level markings which could be changed by any on path routers. In order to 
> uniquely identify the bearer / qos flow a particular packet for a UE belongs, 
> GTPU uses TEID. 
> 
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are 
> not always unique. The same IP pools can be shared across multiple PDNs / DNs 
> as long as these PDNs / DNs are separate autonomous networks. So just relying 
> on UE IP address alone will result in wrong context identification for the 
> uplink traffic. There is a clear one to one mapping of Radio bearer to the 
> EPS bearer / QoS flow required all the way upto the anchor node for charging 
> and QoS treatment. This comes from the requirements in stage 2 documents (c.f 
> section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for 5G). 
> 
> There are also requirements to support non-IP protocols like Ethernet PDU and 
> Unstructured PDU types in 5G.
> 
> >> 
> > >>> How can packets be sent if the session is not setup. If the session is 
> > >>> not setup, the encapsulator should have no state. And packets should be 
> > >>> dropped locally and not go far to get an error back. This sounds 
> > >>> architecturally broken.
> > 
> > [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> > sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost 
> > for any reason. "No session exist" does not mean Session 
> 
> What does lost mean? You mean the path from encapsulator to decapsulator is 
> not working? And since we are in a packet network, that path can be restored 
> quite quickly.
> 
> [SB] Lost here means - the "context" at the receiving entity is deleted. For 
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and 
> correspondingly the GTPU context. If gNB or eNB loses a context for known 
> reasons, there could be signaling from gNB / eNB to AMF/MME and corresponding 
> removal of PDU session / EPS bearer at the core network. But if the context 
> is removed due to administrative reasons or unforeseen local errors, 
> signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU error 
> indication is an inband error detection mechanism.
> 
> Note TEID identifies a context at the receiving side. So all GTPU error 
> indication tells is that the receiver is not able to identify any context for 
> the received TEID.
> 
> 
> > is not setup. "No session exist" scenario after a session setup can happen 
> > due to local error conditions, bearers released for administrative 

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

[Tom Herbert]

On Fri, Sep 7, 2018 at 10:46 AM, Arashmid Akhavain
 wrote:
> 100% Agree with you Tom. And these are type of questions we need to answer 
> when we talk about GTP replacement. The control plane in today's mobile core 
> sets up the tunnel and ensure the uniformity of QoS in
> both forward and backward path.

Hi Arashmid,

FAST should be orthogonal to the issue of GTP replacement and is
agnostic to underlying RAN protocols. It's implemented at the IP layer
and the network services it conveys can be supported by a network in
an arbitrary fashion.

>
> Can you elaborate on using FAST?  FAST on UPFs?

The basic idea of FAST is that hosts (UE) requests tickets from a
"ticket agent" in their local network. The request is an abstract
description of desired services (like low latency, low jitter for
1080p video chat). The ticket agent sends back a "ticket" that encodes
the services the network has granted. The ticket is opaque to the
application and anyone else outside of the network provider. The
application attaches the ticket to its packets (in IPv6 HBH options)
and sends them normally otherwise. At the first hop node in the
network, the ticket is decoded by the network. Appropriate services
are applied (e.g. set DSCP, set QoS, send into a tunnel or slice,
etc.). The packet makes it's way to the destination with the ticket
attached. The destination saves the ticket in it's context for
communication. When the remote server replies, it attaches saved
tickets as a "reflected tickets". When the return packet enters the
client's network of the client, a node decodes the ticket and maps it
to the right services for transit the provider networks back the UE.

There are lot of details: like how to keep overhead low, how to make
this secure ans stateless, how to limit scope of sensitive
information, how to deal with paths that block HBH options. Please
take a look at the FAST draft
https://tools.ietf.org/html/draft-herbert-fast and white paper
https://github.com/quantonium/papers/blob/master/FAST.pdf

Tom

>
> Arashmid
>
>
>> -Original Message-
>> From: Tom Herbert [mailto:t...@quantonium.net]
>> Sent: 07 September 2018 11:51
>> To: Arashmid Akhavain 
>> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
>> dmm 
>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>
>> On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain
>>  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.
>>
>> Arashmid,
>>
>> Yes, slices are a good model. The key question is how does a user's packets
>> get mapped to the right slice. Presumably, this is done at an ingress point
>> into the network. There are two ingress points to be considered, one from
>> UE into the network and one from Internet into network (return path). If the
>> UE sets bits in the packet to get service in the forward path, we somehow
>> need to have those bits available on packets in the return path to map
>> incoming packets. In lieu or requiring the network to maintain a whole bunch
>> of complex flow state, FAST arranges that the remote server reflects the bits
>> in response packets.
>>
>> Tom
>>
>> >
>> >
>> >
>> >> -Original Message-
>> >> From: Tom Herbert [mailto:t...@quantonium.net]
>> >> Sent: 07 September 2018 11:13
>> >> To: Arashmid Akhavain 
>> >> Cc: Dino Farinacci ;
>> >> ta-miyas...@kddi-research.jp; dmm 
>> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>> >>
>> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>> >>  wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Dino Farinacci [mailto:farina...@gmail.com]
>> >> >> Sent: 06 September 2018 18:59
>> >> >> To: Arashmid Akhavain 
>> >> >> Cc: Tom Herbert ;
>> >> >> ta-miyas...@kddi-research.jp; dmm 
>> >> >> 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
>> >> >> &

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

[Dino Farinacci]

> 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 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
>>  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:t...@quantonium.net]
>>>> Sent: 07 September 2018 11:13
>>>> To: Arashmid Akhavain 
>>>> Cc: Dino Farinacci ;
>>>> ta-miyas...@kddi-research.jp; dmm 
>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>>> 
>>>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>>>  wrote:
>>>>> 
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Dino Farinacci [mailto:farina...@gmail.com]
>>>>>> Sent: 06 September 2018 18:59
>>>>>> To: Arashmid Akhavain 
>>>>>> Cc: Tom Herbert ; ta-miyasaka@kddi-
>> research.jp;
>>>>>> dmm 
>>>>>> 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'

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

[Arashmid Akhavain]

100% Agree with you Tom. And these are type of questions we need to answer when 
we talk about GTP replacement. The control plane in today's mobile core sets up 
the tunnel and ensure the uniformity of QoS in
both forward and backward path. 

Can you elaborate on using FAST?  FAST on UPFs?

Arashmid


> -Original Message-
> From: Tom Herbert [mailto:t...@quantonium.net]
> Sent: 07 September 2018 11:51
> To: Arashmid Akhavain 
> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain
>  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.
> 
> Arashmid,
> 
> Yes, slices are a good model. The key question is how does a user's packets
> get mapped to the right slice. Presumably, this is done at an ingress point
> into the network. There are two ingress points to be considered, one from
> UE into the network and one from Internet into network (return path). If the
> UE sets bits in the packet to get service in the forward path, we somehow
> need to have those bits available on packets in the return path to map
> incoming packets. In lieu or requiring the network to maintain a whole bunch
> of complex flow state, FAST arranges that the remote server reflects the bits
> in response packets.
> 
> Tom
> 
> >
> >
> >
> >> -Original Message-
> >> From: Tom Herbert [mailto:t...@quantonium.net]
> >> Sent: 07 September 2018 11:13
> >> To: Arashmid Akhavain 
> >> Cc: Dino Farinacci ;
> >> ta-miyas...@kddi-research.jp; dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-----
> >> >> From: Dino Farinacci [mailto:farina...@gmail.com]
> >> >> Sent: 06 September 2018 18:59
> >> >> To: Arashmid Akhavain 
> >> >> Cc: Tom Herbert ;
> >> >> ta-miyas...@kddi-research.jp; dmm 
> >> >> 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

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

[Arashmid Akhavain]

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.  

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.

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.





> -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 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
>  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:t...@quantonium.net]
> >> Sent: 07 September 2018 11:13
> >> To: Arashmid Akhavain 
> >> Cc: Dino Farinacci ;
> >> ta-miyas...@kddi-research.jp; dmm 
> >> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> >>
> >> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
> >>  wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Dino Farinacci [mailto:farina...@gmail.com]
> >>>> Sent: 06 September 2018 18:59
> >>>> To: Arashmid Akhavain 
> >>>> Cc: Tom Herbert ; ta-miyasaka@kddi-
> research.jp;
> >>>> dmm 
> >>>> 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/conte

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

[Dino Farinacci]

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  
> 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:t...@quantonium.net]
>> Sent: 07 September 2018 11:13
>> To: Arashmid Akhavain 
>> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
>> dmm 
>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>> 
>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>  wrote:
>>> 
>>> 
>>>> -Original Message-
>>>> From: Dino Farinacci [mailto:farina...@gmail.com]
>>>> Sent: 06 September 2018 18:59
>>>> To: Arashmid Akhavain 
>>>> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
>>>> dmm 
>>>> 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 

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

[Tom Herbert]

On Fri, Sep 7, 2018 at 8:26 AM, Arashmid Akhavain
 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.

Arashmid,

Yes, slices are a good model. The key question is how does a user's
packets get mapped to the right slice. Presumably, this is done at an
ingress point into the network. There are two ingress points to be
considered, one from UE into the network and one from Internet into
network (return path). If the UE sets bits in the packet to get
service in the forward path, we somehow need to have those bits
available on packets in the return path to map incoming packets. In
lieu or requiring the network to maintain a whole bunch of complex
flow state, FAST arranges that the remote server reflects the bits in
response packets.

Tom

>
>
>
>> -Original Message-
>> From: Tom Herbert [mailto:t...@quantonium.net]
>> Sent: 07 September 2018 11:13
>> To: Arashmid Akhavain 
>> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
>> dmm 
>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>>
>> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Dino Farinacci [mailto:farina...@gmail.com]
>> >> Sent: 06 September 2018 18:59
>> >> To: Arashmid Akhavain 
>> >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
>> >> dmm 
>> >> 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 inne

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

[Arashmid Akhavain]

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:t...@quantonium.net]
> Sent: 07 September 2018 11:13
> To: Arashmid Akhavain 
> Cc: Dino Farinacci ; ta-miyas...@kddi-research.jp;
> dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Dino Farinacci [mailto:farina...@gmail.com]
> >> Sent: 06 September 2018 18:59
> >> To: Arashmid Akhavain 
> >> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> >> dmm 
> >> 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 

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

[Arashmid Akhavain]

Hi Tom and Dino,

Yes, I agree that these are the type of services that operator might want to 
look into to extend their revenue. Tom put it nicely: "it allows operators the 
chance to offer and monetize services that can benefit users".

I doubt that operators would like to allow dynamic QoS control to shift to UEs. 
But I think a mechanism that would allow QoS request to sit on the UE 
and the control to be done at the operator side would work well. This is value 
that the slicing concept in 5G brings to the table. It allows the operators
to setup preconfigured slices with different QoS, delay, jitter, etc behaviour. 
UE flows then will be mapped to appropriate 5G slice.

The complexity of the scheduler on the RAN side is a different story. But 
certainly use of the slicing concept makes the scheduler job less complicated.

Arashmid

> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: 06 September 2018 19:01
> To: Tom Herbert 
> Cc: Arashmid Akhavain ; ta-
> miyas...@kddi-research.jp; dmm 
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
> 
> I’d ask the question another way:
> 
> Would users like to set QoS bits that may charge them more for service?
> Could they set bits to get cheaper service?
> 
> Let alone if the operator can deliver the service (in this net-neutrality-less
> era).
> 
> Dino
> 
> > On Sep 6, 2018, at 3:15 PM, Tom Herbert  wrote:
> >
> > On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain
> >  wrote:
> >> Dino brought up a good point. Here is my two cents worth:
> >>
> >> 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 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.
> >>
> >> 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.
> >>
> >> Using the information in UE's IP packet header can jeopardise the above
> tight QoS control. I think going 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.
> >>
> >
> > Hi Arashmid,
> >
> > I might pose the question a bit differently: Do operators want to
> > offer a rich set of services, e.g. QoS, and allow applications request
> > what services they want applied for their packets? I believe the
> > answer to that should be "yes" since it allows operators the chance
> > offer and monetize services that can benefit users. That is the easier
> > question to ask. The harder one is _how_ to do this in a secure,
> > generic, net neutrality compliant, practical, and fair manner that
> > doesn't require users to divulge the details of their content to the
> > provider or the whole Internet. Firewall and Service Tickets is being
> > proposed as one such mechanism to solve this (see
> > https://tools.ietf.org/html/draft-herbert-fast).
> >
> > Tom
> >
> >> Arashmid
> >>
> >>
> >>> -Original Message-
> >>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> >>> Sent: 06 September 2018 12:45
> >>> To: Tom Herbert 
> >>> Cc: ta-miyas...@kddi-research.jp; dmm 
> >>> 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
> &g

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

[Tom Herbert]

On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
 wrote:
>
>
>> -Original Message-
>> From: Dino Farinacci [mailto:farina...@gmail.com]
>> Sent: 06 September 2018 18:59
>> To: Arashmid Akhavain 
>> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
>> dmm 
>> 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:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
>> >> Sent: 06 September 2018 12:45
>> >> To: Tom Herbert 
>> >> Cc: ta-miyas...@kddi-research.jp; dmm 
>> >> Subject: Re: [DMM] Comments to draft-hmm-

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

[Arashmid Akhavain]

> -Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com]
> Sent: 06 September 2018 18:59
> To: Arashmid Akhavain 
> Cc: Tom Herbert ; ta-miyas...@kddi-research.jp;
> dmm 
> 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.

> 
> > 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:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> >> Sent: 06 September 2018 12:45
> >> To: Tom Herbert 
> >> Cc: ta-miyas...@kddi-research.jp; dmm 
> >> 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
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Behcet Sarikaya]

Hi Marco,

On Thu, Sep 6, 2018 at 11:39 AM Marco Liebsch 
wrote:

> Tom, Behcet, I think TEID may still be needed in some cases, e.g. for
> mapping to a radio bearer
> or to avoid superfluous packet classification if it has been done on the
> packet's path beforehand
> already.
>
>
 So it should be treat as a special case.
My suggestion is let's solve the main problem first, i.e. privacy issues,
make idloc deployable in large scale.

IMO, for non-encapsulation protocols, overloading of id-loc space seems
> interesting if the attribute
> cannot be carried in extensions. What about encoding QoS class/flow IDs in
> that space as well ;-) ?
>
>
Sure.


Behcet

> marco
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Donnerstag, 6. September 2018 18:22
> To: Behcet Sarikaya
> Cc: ta-miyas...@kddi-research.jp; dmm
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
> On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya 
> wrote:
> >
> >
> > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
> >>
> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
> >>  wrote:
> >> > My comments inline marked [SB]
> >> >
> >> >> > >>> It was never clear to me and no one could ever explain exactly
> >> >> > >>> why a
> >> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> >> >> > >>> was a
> >> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> >> >> > >>> inner addresses
> >> >> > >>> be used for accounting?
> >> >> >
> >> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> >> > identified the QoS and charging policy applicable to the bearer is
> >> >> > applied.
> >> >> > So the purpose of TEID is not just for accounting. Its for QoS
> >> >> > treatment,
> >> >> > charging and bearer context identification.
> >> >>
> >> >> You told me what a TEID is but you didn’t say why you need to use it
> >> >> versus using the destination IP address for the tunnel.
> >> >>
> >> >>
> >> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the
> PDU
> >> >> > session whereas the QFI carried in GTPU extension header identifies
> >> >> > the
> >> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >> >>
> >> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> >> >> which
> >> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> >> encapsualting node, and (4) the decapsulating node.
> >> >>
> >> >> So again, why use more space in the packet, when you have sufficient
> >> >> information to identify a user, and therefore their packet policy?
> >> >>
> >> > [SB] Lets say we only use UE IP address and no TEID. How will you
> >> > identify
> >> > the bearer context the packet belongs? One UE may use multiple radio
> >> > bearers
> >> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but
> these
> >> > are
> >> > IP level markings which could be changed by any on path routers. In
> >> > order to
> >> > uniquely identify the bearer / qos flow a particular packet for a UE
> >> > belongs, GTPU uses TEID.
> >>
> >> Sridhar,
> >>
> >> Couldn't the TEID be encoded in the outer IP address of an
> >> encpasulation or network overlay in a similar way that VNIs are
> >> encoded in IP addresses in virtual networking?
> >>
> >> Tom
> >>
> >
> > ILA if used would remove any need for tunneling and TEID is for
> tunneling.
> >
> Behcet,
>
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
>
> Tom
>
> > Actually if you read 29.244 it is completely based on legacy protocols
> with
> > no IdLoc content at all, as Shunsuke mentioned.
> >
> > Behcet
> >>
> >> >
> >> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> >> > are
> >> > 

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

[Behcet Sarikaya]

On Fri, Sep 7, 2018 at 8:35 AM Alexandre Petrescu <
alexandre.petre...@gmail.com> wrote:

>
>
> Le 06/09/2018 à 12:27, Sridhar Bhaskaran a écrit :
> > Dear Behcet,
> >
> >  >>What is PFCP, is it GTP-U?
> >
> > PFCP is a control plane protocol used between control plane function and
> > user plane function. In EPC, the PFCP protocol is used on the Sx
> > interface. In 5G its used on the N4 interface. It is used to set up the
> > packet classifiers and forwarding rules in the user plane function.
>
> It's the first time I hear about this.
>
> Where was discussed the allocation of this port number?
>
>
Individuals can ask IANA to assign port numbers for their applications, I
think. In this case Kimmo asked in the name of 3GPP CT4
in 2017 as the recording shows.
I don't think there is any associated draft as PFCP which is a UDP
application was defined by CT4 much like GTP-U.
If you remember Cameron used to say that are a lot of protocols used in
practice defined elsewhere not in IETF.

Behcet

> Alex
>
> >
> > Thanks
> > Sridhar
> >
> >
> > ___
> > dmm mailing list
> > dmm@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmm
> >
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Alexandre Petrescu]

Le 04/09/2018 à 18:42, Dino Farinacci a écrit :
Folks, I sent comment to the authors and they asked me to forward them 
to the WG list.


I also attended 3GPP/CT4 a couple of weeks ago and can report on it in 
Bangkok. Maybe Satoru can as well. There were two IETF-related 
presentations given.


Thanks,
Dino


Begin forwarded message:

*From: *Dino Farinacci mailto:d...@lispers.net>>
*Subject: **My comments to draft-hmm-dmm-5g-uplane-analysis-01 *
*Date: *August 30, 2018 at 4:17:09 PM PDT
*To: *Dan Voyer mailto:daniel.vo...@bell.ca>>, 
Satoru Matsushima >, 
satoru.matsush...@g.softbank.co.jp 

*Cc: *Shunsuke Homma >, ta-miyas...@kddi-research.jp 
, Dino Farinacci 
mailto:farina...@gmail.com>>


Your draft text comes first and is indented and my comments follow.

Cheers,
Dino


In this section you should make it very clear where the tunnel 
terminates. It is not clear from the diagram on the N3 interface if it 
terminates on the eNodeB or the UE.


Even if it says it terminates at UE it must say what is the 'UE' for them.

Because some people may think 'UE' is the smartphone, but others can 
think it is the modem in the smartphone.


A typical smartphone has many processors and only some of them can be 
easily verifiable in a straightforward manner (open source, root access, 
etc.)


If the GTP-U terminates to a point that is hardly verifiable by average 
readers then its interest is very limited.


Alex




Dan made this point verbally to me about unidirectional versus 
bidirectional tunnels. I don’t know if it matters because it all comes 
down to the amount of state that a router uses to terminate the 
tunnel. In cisco routers, we also used one “virtual interface” (called 
an idb) to support a tunnel. And we used it and all the accounting 
associated with it for both input and output counters, addressing, 
encap/decap functions, etc.


Dan made the comment that if tunnels were bidirectional, you reduce 
the tunnel state in half. That is only if an implementation used two 
data structues for different TEID values. But that would be a poor 
implementation where you could store a rec_teid and send_teid in one 
data structure not duplicating other parts of the data structure.






All tunneling protocols should “copy inner to outer” fields like TOS, 
flow label, and TTL to outer header. That needs to be done by default 
and then later if there is marking policy, it happens at boundaries 
only in the outer header.


This won’t be an issue with IPv6/SRv6 but if one wants to preserve the 
original host values, and there is a rewrite at the boundaries, you 
will lose the information. People need to decide if this is a hard 
requirement.



It just doesn’t matter. Link layer CRCs are very good these days and 
does a good job protecting bit errors and bad actor corruption of 
packet data.



SRv6 will have this problem too. With just 1 SID can still put an 
user’s MTU sized packet over the effective path MTU.



If this is the case, then the ECMP algorithm in GTP is broken. No 
packets should be reordered. So why are they?



It was never clear to me and no one could ever explain exactly why a 
TEID is needed. I presumed for accounting reasons. But if there was a 
one-to-one mapping between tunnel and user, why couldn’t the inner 
addresses be used for accounting?



How can packets be sent if the session is not setup. If the session is 
not setup, the encapsulator should have no state. And packets should 
be dropped locally and not go far to get an error back. This sounds 
architecturally broken.



You should explain in summary form the model the control-plane uses. 
Does it use TCP for reliability, does it use multicast, is it like a 
routing protocol, is it like a management protocol. What are the 
failure modes, the state/bandwidth tradeoffs.




You should state if a UP/CP pair that is self contained with a slice. 
Or is there a CP that operates each UP in each slice. And how much 
fault isolation and resource reservation is obtained by slicing. I 
hope its more like containers than VRFs.  ;-)



What I got from the CT4 meeting is that the LISP mapping system can be 
put in a box above and you could combine SMF, AMF, and PCF functions 
just in the mapping database data structure. I think more of those 
compoents could be combined, but I don’t understand what they all do 
yet. LOL.  ;-)


Note a holistic architecture would have the N6 interface terminate on 
a top-of-rack router in the DN data-center.



So I think you need a CP equivalent to this document. Because the 
complexity, even though present here in the UP, is order of magnitude 
more in the CP and the costs of scale, security, and manageability is 
in the control-plane. Have you consider doing this?


Like I mentiioned to Satoru in West Palm Beach, without a level of 
indirection in routing, 

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

[Tom Herbert]

On Thu, Sep 6, 2018 at 4:01 PM, Dino Farinacci  wrote:
> I’d ask the question another way:
>
> Would users like to set QoS bits that may charge them more for service? Could 
> they set bits to get cheaper service?
>
Hey, if I could set some bits and save a few bucks (legally) on my
mobile phone bill each month that'd be great! How do I do that? ;-)

In lieu of those magic bits, what I'd settle for now as as a user is
better, more transparent accounting and pay-per-use for service. I
don't have a problem paying more to get better Internet service **if**
it's clear I'm getting money's worth. For instance, for the past few
months my home Internet provider is currently charging me for going
over my data limits each month, but they can't give me any detailed
break down of my Internet usage. They can't even tell me _how_ they're
doing accounting since they've outsourced it to a third party company.
Very irritating! And then, of course, there's the story of
firefighters fighting wild fires in California and having their data
rate throttled to 1/100th of the nominal rate even though they were on
the "unlimited" data plan. Not just irritating, but this put lives at
risk! Such problems can be fix with precise accounting and
transparency on services and service plans.

Tom

> Let alone if the operator can deliver the service (in this 
> net-neutrality-less era).
>
> Dino
>
>> On Sep 6, 2018, at 3:15 PM, Tom Herbert  wrote:
>>
>> On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain
>>  wrote:
>>> Dino brought up a good point. Here is my two cents worth:
>>>
>>> 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 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.
>>>
>>> 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.
>>>
>>> Using the information in UE's IP packet header can jeopardise the above 
>>> tight QoS control. I think going 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.
>>>
>>
>> Hi Arashmid,
>>
>> I might pose the question a bit differently: Do operators want to
>> offer a rich set of services, e.g. QoS, and allow applications request
>> what services they want applied for their packets? I believe the
>> answer to that should be "yes" since it allows operators the chance
>> offer and monetize services that can benefit users. That is the easier
>> question to ask. The harder one is _how_ to do this in a secure,
>> generic, net neutrality compliant, practical, and fair manner that
>> doesn't require users to divulge the details of their content to the
>> provider or the whole Internet. Firewall and Service Tickets is being
>> proposed as one such mechanism to solve this (see
>> https://tools.ietf.org/html/draft-herbert-fast).
>>
>> Tom
>>
>>> Arashmid
>>>
>>>
>>>> -Original Message-
>>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
>>>> Sent: 06 September 2018 12:45
>>>> To: Tom Herbert 
>>>> Cc: ta-miyas...@kddi-research.jp; dmm 
>>>> 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
>>

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

[Tom Herbert]

On Thu, Sep 6, 2018 at 2:49 PM, Arashmid Akhavain
 wrote:
> Dino brought up a good point. Here is my two cents worth:
>
> 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 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.
>
> 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.
>
> Using the information in UE's IP packet header can jeopardise the above tight 
> QoS control. I think going 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.
>

Hi Arashmid,

I might pose the question a bit differently: Do operators want to
offer a rich set of services, e.g. QoS, and allow applications request
what services they want applied for their packets? I believe the
answer to that should be "yes" since it allows operators the chance
offer and monetize services that can benefit users. That is the easier
question to ask. The harder one is _how_ to do this in a secure,
generic, net neutrality compliant, practical, and fair manner that
doesn't require users to divulge the details of their content to the
provider or the whole Internet. Firewall and Service Tickets is being
proposed as one such mechanism to solve this (see
https://tools.ietf.org/html/draft-herbert-fast).

Tom

> Arashmid
>
>
>> -Original Message-
>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
>> Sent: 06 September 2018 12:45
>> To: Tom Herbert 
>> Cc: ta-miyas...@kddi-research.jp; dmm 
>> 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
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Arashmid Akhavain]

Dino brought up a good point. Here is my two cents worth:

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

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.

Using the information in UE's IP packet header can jeopardise the above tight 
QoS control. I think going 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:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: 06 September 2018 12:45
> To: Tom Herbert 
> Cc: ta-miyas...@kddi-research.jp; dmm 
> 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
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Arashmid Akhavain]

Today TEID is a MUST in mobile core and as Sridhar indicated in his emails 
identifies a bearer or context.
I agree with Tom. A mechanism to encode the TEID should work.

Arashmid

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: 06 September 2018 12:18
To: Tom Herbert 
Cc: ta-miyas...@kddi-research.jp; dmm 
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01


On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert 
mailto:t...@quantonium.net>> wrote:
On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
mailto:sridhar.bhaska...@gmail.com>> wrote:
> My comments inline marked [SB]
>
>> > >>> It was never clear to me and no one could ever explain exactly why a
>> > >>> TEID is needed. I presumed for accounting reasons. But if there was a
>> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
>> > >>> addresses
>> > >>> be used for accounting?
>> >
>> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> > tunnel and hence consequently a bearer. Once the bearer context is
>> > identified the QoS and charging policy applicable to the bearer is applied.
>> > So the purpose of TEID is not just for accounting. Its for QoS treatment,
>> > charging and bearer context identification.
>>
>> You told me what a TEID is but you didn’t say why you need to use it
>> versus using the destination IP address for the tunnel.
>>
>>
>> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> > session whereas the QFI carried in GTPU extension header identifies the
>> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>>
>> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which
>> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> encapsualting node, and (4) the decapsulating node.
>>
>> So again, why use more space in the packet, when you have sufficient
>> information to identify a user, and therefore their packet policy?
>>
> [SB] Lets say we only use UE IP address and no TEID. How will you identify
> the bearer context the packet belongs? One UE may use multiple radio bearers
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are
> IP level markings which could be changed by any on path routers. In order to
> uniquely identify the bearer / qos flow a particular packet for a UE
> belongs, GTPU uses TEID.

Sridhar,

Couldn't the TEID be encoded in the outer IP address of an
encpasulation or network overlay in a similar way that VNIs are
encoded in IP addresses in virtual networking?

Tom

ILA if used would remove any need for tunneling and TEID is for tunneling.

Actually if you read 29.244 it is completely based on legacy protocols with no 
IdLoc content at all, as Shunsuke mentioned.

Behcet
>
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are
> not always unique. The same IP pools can be shared across multiple PDNs /
> DNs as long as these PDNs / DNs are separate autonomous networks. So just
> relying on UE IP address alone will result in wrong context identification
> for the uplink traffic. There is a clear one to one mapping of Radio bearer
> to the EPS bearer / QoS flow required all the way upto the anchor node for
> charging and QoS treatment. This comes from the requirements in stage 2
> documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
> 5G).
>
> There are also requirements to support non-IP protocols like Ethernet PDU
> and Unstructured PDU types in 5G.
>
>> >>
>> > >>> How can packets be sent if the session is not setup. If the session
>> > >>> is not setup, the encapsulator should have no state. And packets 
>> > >>> should be
>> > >>> dropped locally and not go far to get an error back. This sounds
>> > >>> architecturally broken.
>> >
>> > [Sridhar] The purpose of GTP-U error indication is to signal in band to
>> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is 
>> > lost
>> > for any reason. "No session exist" does not mean Session
>>
>> What does lost mean? You mean the path from encapsulator to decapsulator
>> is not working? And since we are in a packet network, that path can be
>> restored quite quickly.
>
>
> [SB] Lost here means - the "context" at the receiving entity is deleted. For
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and
> correspondingly the GTPU context. If gNB or eNB loses a context for known
&

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

[Tom Herbert]

On Thu, Sep 6, 2018 at 9:39 AM, Marco Liebsch  wrote:
> Tom, Behcet, I think TEID may still be needed in some cases, e.g. for mapping 
> to a radio bearer
> or to avoid superfluous packet classification if it has been done on the 
> packet's path beforehand
> already.
>
> IMO, for non-encapsulation protocols, overloading of id-loc space seems 
> interesting if the attribute
> cannot be carried in extensions. What about encoding QoS class/flow IDs in 
> that space as well ;-) ?
>
Marco,

Yes, there is a lot of opportunity to encode different things in
addresses. The giantic address space of IPv6 almost begs us to do
that! :-) The amount of data is limited, so it's unlikely that we can
encapsulate all of the GTP-U extension headers. But with some careful
planning, we could probably encode the critical information that is
most common for fast data path. Address encoding is critical to ILA
and is what can eliminate the overhead of encapsulation for a fast,
low latency, data path.

Tom

> marco
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Donnerstag, 6. September 2018 18:22
> To: Behcet Sarikaya
> Cc: ta-miyas...@kddi-research.jp; dmm
> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
>
> On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya  
> wrote:
>>
>>
>> On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
>>>
>>> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>>>  wrote:
>>> > My comments inline marked [SB]
>>> >
>>> >> > >>> It was never clear to me and no one could ever explain exactly
>>> >> > >>> why a
>>> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
>>> >> > >>> was a
>>> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
>>> >> > >>> inner addresses
>>> >> > >>> be used for accounting?
>>> >> >
>>> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>>> >> > tunnel and hence consequently a bearer. Once the bearer context is
>>> >> > identified the QoS and charging policy applicable to the bearer is
>>> >> > applied.
>>> >> > So the purpose of TEID is not just for accounting. Its for QoS
>>> >> > treatment,
>>> >> > charging and bearer context identification.
>>> >>
>>> >> You told me what a TEID is but you didn’t say why you need to use it
>>> >> versus using the destination IP address for the tunnel.
>>> >>
>>> >>
>>> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>>> >> > session whereas the QFI carried in GTPU extension header identifies
>>> >> > the
>>> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>>> >>
>>> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
>>> >> which
>>> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
>>> >> encapsualting node, and (4) the decapsulating node.
>>> >>
>>> >> So again, why use more space in the packet, when you have sufficient
>>> >> information to identify a user, and therefore their packet policy?
>>> >>
>>> > [SB] Lets say we only use UE IP address and no TEID. How will you
>>> > identify
>>> > the bearer context the packet belongs? One UE may use multiple radio
>>> > bearers
>>> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
>>> > are
>>> > IP level markings which could be changed by any on path routers. In
>>> > order to
>>> > uniquely identify the bearer / qos flow a particular packet for a UE
>>> > belongs, GTPU uses TEID.
>>>
>>> Sridhar,
>>>
>>> Couldn't the TEID be encoded in the outer IP address of an
>>> encpasulation or network overlay in a similar way that VNIs are
>>> encoded in IP addresses in virtual networking?
>>>
>>> Tom
>>>
>>
>> ILA if used would remove any need for tunneling and TEID is for tunneling.
>>
> Behcet,
>
> I was thinking if TEID is need then that can be encoded in a locator
> easily enough.
>
> Tom
>
>> Actually if you read 29.244 it is completely based on l

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

[Dino Farinacci]

> 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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Dino Farinacci]

> Sridhar,
> 
> Couldn't the TEID be encoded in the outer IP address of an
> encpasulation or network overlay in a similar way that VNIs are
> encoded in IP addresses in virtual networking?
> 
> Tom

There are lots of ways to do it. The point is, was an additional 32 bits 
necessary solely for this purpose. 

Dino
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Marco Liebsch]

Tom, Behcet, I think TEID may still be needed in some cases, e.g. for mapping 
to a radio bearer
or to avoid superfluous packet classification if it has been done on the 
packet's path beforehand
already.

IMO, for non-encapsulation protocols, overloading of id-loc space seems 
interesting if the attribute
cannot be carried in extensions. What about encoding QoS class/flow IDs in that 
space as well ;-) ?

marco

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Donnerstag, 6. September 2018 18:22
To: Behcet Sarikaya
Cc: ta-miyas...@kddi-research.jp; dmm
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01

On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya  wrote:
>
>
> On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
>>
>> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>>  wrote:
>> > My comments inline marked [SB]
>> >
>> >> > >>> It was never clear to me and no one could ever explain exactly
>> >> > >>> why a
>> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
>> >> > >>> was a
>> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
>> >> > >>> inner addresses
>> >> > >>> be used for accounting?
>> >> >
>> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> >> > tunnel and hence consequently a bearer. Once the bearer context is
>> >> > identified the QoS and charging policy applicable to the bearer is
>> >> > applied.
>> >> > So the purpose of TEID is not just for accounting. Its for QoS
>> >> > treatment,
>> >> > charging and bearer context identification.
>> >>
>> >> You told me what a TEID is but you didn’t say why you need to use it
>> >> versus using the destination IP address for the tunnel.
>> >>
>> >>
>> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> >> > session whereas the QFI carried in GTPU extension header identifies
>> >> > the
>> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>> >>
>> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
>> >> which
>> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> >> encapsualting node, and (4) the decapsulating node.
>> >>
>> >> So again, why use more space in the packet, when you have sufficient
>> >> information to identify a user, and therefore their packet policy?
>> >>
>> > [SB] Lets say we only use UE IP address and no TEID. How will you
>> > identify
>> > the bearer context the packet belongs? One UE may use multiple radio
>> > bearers
>> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
>> > are
>> > IP level markings which could be changed by any on path routers. In
>> > order to
>> > uniquely identify the bearer / qos flow a particular packet for a UE
>> > belongs, GTPU uses TEID.
>>
>> Sridhar,
>>
>> Couldn't the TEID be encoded in the outer IP address of an
>> encpasulation or network overlay in a similar way that VNIs are
>> encoded in IP addresses in virtual networking?
>>
>> Tom
>>
>
> ILA if used would remove any need for tunneling and TEID is for tunneling.
>
Behcet,

I was thinking if TEID is need then that can be encoded in a locator
easily enough.

Tom

> Actually if you read 29.244 it is completely based on legacy protocols with
> no IdLoc content at all, as Shunsuke mentioned.
>
> Behcet
>>
>> >
>> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
>> > are
>> > not always unique. The same IP pools can be shared across multiple PDNs
>> > /
>> > DNs as long as these PDNs / DNs are separate autonomous networks. So
>> > just
>> > relying on UE IP address alone will result in wrong context
>> > identification
>> > for the uplink traffic. There is a clear one to one mapping of Radio
>> > bearer
>> > to the EPS bearer / QoS flow required all the way upto the anchor node
>> > for
>> > charging and QoS treatment. This comes from the requirements in stage 2
>> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
>> > 5G).
>> >
>> > There are also requirements t

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

[Dino Farinacci]

Sridhar,

> [SB] Lets say we only use UE IP address and no TEID. How will you identify 
> the bearer context the packet belongs? One UE may use multiple radio bearers 
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are 
> IP level markings which could be changed by any on path routers. In order to 
> uniquely identify the bearer / qos flow a particular packet for a UE belongs, 
> GTPU uses TEID. 
> 
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are 
> not always unique. The same IP pools can be shared across multiple PDNs / DNs 
> as long as these PDNs / DNs are separate autonomous networks. So just relying 
> on UE IP address alone will result in wrong context identification for the 
> uplink traffic. There is a clear one to one mapping of Radio bearer to the 
> EPS bearer / QoS flow required all the way upto the anchor node for charging 
> and QoS treatment. This comes from the requirements in stage 2 documents (c.f 
> section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for 5G). 
> 
> There are also requirements to support non-IP protocols like Ethernet PDU and 
> Unstructured PDU types in 5G.

Then you have proven there is a lot of simplication opportunity. That is, use 
the IP header for charging, and for ethernet serivce encapsulate that at the UE 
so the eNodeB has a common and single way of classifying packets.

> 
> >> 
> > >>> How can packets be sent if the session is not setup. If the session is 
> > >>> not setup, the encapsulator should have no state. And packets should be 
> > >>> dropped locally and not go far to get an error back. This sounds 
> > >>> architecturally broken.
> > 
> > [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> > sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost 
> > for any reason. "No session exist" does not mean Session 
> 
> What does lost mean? You mean the path from encapsulator to decapsulator is 
> not working? And since we are in a packet network, that path can be restored 
> quite quickly.
> 
> [SB] Lost here means - the "context" at the receiving entity is deleted. For 
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and 
> correspondingly the GTPU context. If gNB or eNB loses a context for known 
> reasons, there could be signaling from gNB / eNB to AMF/MME and corresponding 
> removal of PDU session / EPS bearer at the core network. But if the context 
> is removed due to administrative reasons or unforeseen local errors, 
> signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU error 
> indication is an inband error detection mechanism.
> 
> Note TEID identifies a context at the receiving side. So all GTPU error 
> indication tells is that the receiver is not able to identify any context for 
> the received TEID.

Right, you are using “sessions” or “connections” at a packet layer. That is the 
fundamental problem. Why can't this 3GPP network be more like an IP network? 
You know that most of the critical traffic is IP traffic, even voice these days.

It looks like the dmm WG should propose a slice that is called an IP slice 
where we just do good ole datagram routing over it. Do charging with packet 
counters and strive to make the 3GPP network like an ethernet (or wifi 
network). 

I would like to hear arguments why this can’t be done. It is definitely a good 
place to start for 5G IMO. You do this and we can give users IP mobility from 
3GPP to wifi more seamlessly.

IMO, if 3GPP does not solve the 3GPP to wifi mobility problem, it has failed to 
solve real world problems.

> > is not setup. "No session exist" scenario after a session setup can happen 
> > due to local error conditions, bearers released for administrative reasons 
> > etc.
> 
> So at the encapsulator, do you choose another decapsultor? Note that tunnels 
> *usually* stay up since the topology that realizes the tunnel is robust and 
> redundant.
> 
> >> 
> > >>> You should explain in summary form the model the control-plane uses. 
> > >>> Does it use TCP for reliability, does it use multicast, is it like a 
> > >>> routing protocol, is it like a management protocol. What are the 
> > >>> failure modes, the state/bandwidth tradeoffs.
> > 
> > [Sridhar] Explaining all these in IETF draft is simply reproducing what is 
> > already there in TS 29.244. A reference to TS 29.244 should be enough. See 
> > section 6.4 of TS 29.244 for reliable delivery of PFCP messages.
> 
> Just pointing people to drafts doesn’t help in understanding. It requires 
> people to go off, put in a lot of time where the odds are their question will 
> not be answered.
> 
> [SB] TS 29.244 is not a draft but rather a full fledged technical 
> specification. The issue with repeating content from elsewhere instead of 
> just pointing is the risk of providing inaccurate information in IETF draft.

My point is that if you would simply summarize here in email, a lot of people 

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

[Tom Herbert]

On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya  wrote:
>
>
> On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:
>>
>> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>>  wrote:
>> > My comments inline marked [SB]
>> >
>> >> > >>> It was never clear to me and no one could ever explain exactly
>> >> > >>> why a
>> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
>> >> > >>> was a
>> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
>> >> > >>> inner addresses
>> >> > >>> be used for accounting?
>> >> >
>> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> >> > tunnel and hence consequently a bearer. Once the bearer context is
>> >> > identified the QoS and charging policy applicable to the bearer is
>> >> > applied.
>> >> > So the purpose of TEID is not just for accounting. Its for QoS
>> >> > treatment,
>> >> > charging and bearer context identification.
>> >>
>> >> You told me what a TEID is but you didn’t say why you need to use it
>> >> versus using the destination IP address for the tunnel.
>> >>
>> >>
>> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> >> > session whereas the QFI carried in GTPU extension header identifies
>> >> > the
>> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>> >>
>> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
>> >> which
>> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> >> encapsualting node, and (4) the decapsulating node.
>> >>
>> >> So again, why use more space in the packet, when you have sufficient
>> >> information to identify a user, and therefore their packet policy?
>> >>
>> > [SB] Lets say we only use UE IP address and no TEID. How will you
>> > identify
>> > the bearer context the packet belongs? One UE may use multiple radio
>> > bearers
>> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
>> > are
>> > IP level markings which could be changed by any on path routers. In
>> > order to
>> > uniquely identify the bearer / qos flow a particular packet for a UE
>> > belongs, GTPU uses TEID.
>>
>> Sridhar,
>>
>> Couldn't the TEID be encoded in the outer IP address of an
>> encpasulation or network overlay in a similar way that VNIs are
>> encoded in IP addresses in virtual networking?
>>
>> Tom
>>
>
> ILA if used would remove any need for tunneling and TEID is for tunneling.
>
Behcet,

I was thinking if TEID is need then that can be encoded in a locator
easily enough.

Tom

> Actually if you read 29.244 it is completely based on legacy protocols with
> no IdLoc content at all, as Shunsuke mentioned.
>
> Behcet
>>
>> >
>> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
>> > are
>> > not always unique. The same IP pools can be shared across multiple PDNs
>> > /
>> > DNs as long as these PDNs / DNs are separate autonomous networks. So
>> > just
>> > relying on UE IP address alone will result in wrong context
>> > identification
>> > for the uplink traffic. There is a clear one to one mapping of Radio
>> > bearer
>> > to the EPS bearer / QoS flow required all the way upto the anchor node
>> > for
>> > charging and QoS treatment. This comes from the requirements in stage 2
>> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
>> > 5G).
>> >
>> > There are also requirements to support non-IP protocols like Ethernet
>> > PDU
>> > and Unstructured PDU types in 5G.
>> >
>> >> >>
>> >> > >>> How can packets be sent if the session is not setup. If the
>> >> > >>> session
>> >> > >>> is not setup, the encapsulator should have no state. And packets
>> >> > >>> should be
>> >> > >>> dropped locally and not go far to get an error back. This sounds
>> >> > >>> architecturally broken.
>> >> >
>> >> > [Sridhar] The purpose of GTP-U error indication is to signal in band
>> >> > to
>> >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side
>> >> > is lost
>> >> > for any reason. "No session exist" does not mean Session
>> >>
>> >> What does lost mean? You mean the path from encapsulator to
>> >> decapsulator
>> >> is not working? And since we are in a packet network, that path can be
>> >> restored quite quickly.
>> >
>> >
>> > [SB] Lost here means - the "context" at the receiving entity is deleted.
>> > For
>> > e.g due to administrative reasons, gNB or eNB removes the radio bearers
>> > and
>> > correspondingly the GTPU context. If gNB or eNB loses a context for
>> > known
>> > reasons, there could be signaling from gNB / eNB to AMF/MME and
>> > corresponding removal of PDU session / EPS bearer at the core network.
>> > But
>> > if the context is removed due to administrative reasons or unforeseen
>> > local
>> > errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the
>> > GTPU
>> > error indication is an inband error detection mechanism.
>> >
>> > Note TEID identifies a context at the receiving side. So 

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

[Behcet Sarikaya]

On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert  wrote:

> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
>  wrote:
> > My comments inline marked [SB]
> >
> >> > >>> It was never clear to me and no one could ever explain exactly
> why a
> >> > >>> TEID is needed. I presumed for accounting reasons. But if there
> was a
> >> > >>> one-to-one mapping between tunnel and user, why couldn’t the
> inner addresses
> >> > >>> be used for accounting?
> >> >
> >> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> >> > tunnel and hence consequently a bearer. Once the bearer context is
> >> > identified the QoS and charging policy applicable to the bearer is
> applied.
> >> > So the purpose of TEID is not just for accounting. Its for QoS
> treatment,
> >> > charging and bearer context identification.
> >>
> >> You told me what a TEID is but you didn’t say why you need to use it
> >> versus using the destination IP address for the tunnel.
> >>
> >>
> >> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
> >> > session whereas the QFI carried in GTPU extension header identifies
> the
> >> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
> >>
> >> When a packet is encapsulated in a tunnel, a packet has 4 addresses,
> which
> >> tells us (1) the UE, (2) the destination it is talking to, (3) the
> >> encapsualting node, and (4) the decapsulating node.
> >>
> >> So again, why use more space in the packet, when you have sufficient
> >> information to identify a user, and therefore their packet policy?
> >>
> > [SB] Lets say we only use UE IP address and no TEID. How will you
> identify
> > the bearer context the packet belongs? One UE may use multiple radio
> bearers
> > / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these
> are
> > IP level markings which could be changed by any on path routers. In
> order to
> > uniquely identify the bearer / qos flow a particular packet for a UE
> > belongs, GTPU uses TEID.
>
> Sridhar,
>
> Couldn't the TEID be encoded in the outer IP address of an
> encpasulation or network overlay in a similar way that VNIs are
> encoded in IP addresses in virtual networking?
>
> Tom
>
>
ILA if used would remove any need for tunneling and TEID is for tunneling.

Actually if you read 29.244 it is completely based on legacy protocols with
no IdLoc content at all, as Shunsuke mentioned.

Behcet

> >
> > Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF
> are
> > not always unique. The same IP pools can be shared across multiple PDNs /
> > DNs as long as these PDNs / DNs are separate autonomous networks. So just
> > relying on UE IP address alone will result in wrong context
> identification
> > for the uplink traffic. There is a clear one to one mapping of Radio
> bearer
> > to the EPS bearer / QoS flow required all the way upto the anchor node
> for
> > charging and QoS treatment. This comes from the requirements in stage 2
> > documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
> > 5G).
> >
> > There are also requirements to support non-IP protocols like Ethernet PDU
> > and Unstructured PDU types in 5G.
> >
> >> >>
> >> > >>> How can packets be sent if the session is not setup. If the
> session
> >> > >>> is not setup, the encapsulator should have no state. And packets
> should be
> >> > >>> dropped locally and not go far to get an error back. This sounds
> >> > >>> architecturally broken.
> >> >
> >> > [Sridhar] The purpose of GTP-U error indication is to signal in band
> to
> >> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side
> is lost
> >> > for any reason. "No session exist" does not mean Session
> >>
> >> What does lost mean? You mean the path from encapsulator to decapsulator
> >> is not working? And since we are in a packet network, that path can be
> >> restored quite quickly.
> >
> >
> > [SB] Lost here means - the "context" at the receiving entity is deleted..
> For
> > e.g due to administrative reasons, gNB or eNB removes the radio bearers
> and
> > correspondingly the GTPU context. If gNB or eNB loses a context for known
> > reasons, there could be signaling from gNB / eNB to AMF/MME and
> > corresponding removal of PDU session / EPS bearer at the core network.
> But
> > if the context is removed due to administrative reasons or unforeseen
> local
> > errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the
> GTPU
> > error indication is an inband error detection mechanism.
> >
> > Note TEID identifies a context at the receiving side. So all GTPU error
> > indication tells is that the receiver is not able to identify any context
> > for the received TEID.
> >
> >>
> >> > is not setup. "No session exist" scenario after a session setup can
> >> > happen due to local error conditions, bearers released for
> administrative
> >> > reasons etc.
> >>
> >> So at the encapsulator, do you choose another decapsultor? Note that
> >> tunnels 

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

[Tom Herbert]

On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran
 wrote:
> My comments inline marked [SB]
>
>> > >>> It was never clear to me and no one could ever explain exactly why a
>> > >>> TEID is needed. I presumed for accounting reasons. But if there was a
>> > >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
>> > >>> addresses
>> > >>> be used for accounting?
>> >
>> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
>> > tunnel and hence consequently a bearer. Once the bearer context is
>> > identified the QoS and charging policy applicable to the bearer is applied.
>> > So the purpose of TEID is not just for accounting. Its for QoS treatment,
>> > charging and bearer context identification.
>>
>> You told me what a TEID is but you didn’t say why you need to use it
>> versus using the destination IP address for the tunnel.
>>
>>
>> > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
>> > session whereas the QFI carried in GTPU extension header identifies the
>> > flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>>
>> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which
>> tells us (1) the UE, (2) the destination it is talking to, (3) the
>> encapsualting node, and (4) the decapsulating node.
>>
>> So again, why use more space in the packet, when you have sufficient
>> information to identify a user, and therefore their packet policy?
>>
> [SB] Lets say we only use UE IP address and no TEID. How will you identify
> the bearer context the packet belongs? One UE may use multiple radio bearers
> / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are
> IP level markings which could be changed by any on path routers. In order to
> uniquely identify the bearer / qos flow a particular packet for a UE
> belongs, GTPU uses TEID.

Sridhar,

Couldn't the TEID be encoded in the outer IP address of an
encpasulation or network overlay in a similar way that VNIs are
encoded in IP addresses in virtual networking?

Tom

>
> Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are
> not always unique. The same IP pools can be shared across multiple PDNs /
> DNs as long as these PDNs / DNs are separate autonomous networks. So just
> relying on UE IP address alone will result in wrong context identification
> for the uplink traffic. There is a clear one to one mapping of Radio bearer
> to the EPS bearer / QoS flow required all the way upto the anchor node for
> charging and QoS treatment. This comes from the requirements in stage 2
> documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
> 5G).
>
> There are also requirements to support non-IP protocols like Ethernet PDU
> and Unstructured PDU types in 5G.
>
>> >>
>> > >>> How can packets be sent if the session is not setup. If the session
>> > >>> is not setup, the encapsulator should have no state. And packets 
>> > >>> should be
>> > >>> dropped locally and not go far to get an error back. This sounds
>> > >>> architecturally broken.
>> >
>> > [Sridhar] The purpose of GTP-U error indication is to signal in band to
>> > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is 
>> > lost
>> > for any reason. "No session exist" does not mean Session
>>
>> What does lost mean? You mean the path from encapsulator to decapsulator
>> is not working? And since we are in a packet network, that path can be
>> restored quite quickly.
>
>
> [SB] Lost here means - the "context" at the receiving entity is deleted. For
> e.g due to administrative reasons, gNB or eNB removes the radio bearers and
> correspondingly the GTPU context. If gNB or eNB loses a context for known
> reasons, there could be signaling from gNB / eNB to AMF/MME and
> corresponding removal of PDU session / EPS bearer at the core network. But
> if the context is removed due to administrative reasons or unforeseen local
> errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU
> error indication is an inband error detection mechanism.
>
> Note TEID identifies a context at the receiving side. So all GTPU error
> indication tells is that the receiver is not able to identify any context
> for the received TEID.
>
>>
>> > is not setup. "No session exist" scenario after a session setup can
>> > happen due to local error conditions, bearers released for administrative
>> > reasons etc.
>>
>> So at the encapsulator, do you choose another decapsultor? Note that
>> tunnels *usually* stay up since the topology that realizes the tunnel is
>> robust and redundant.
>>
>> >>
>> > >>> You should explain in summary form the model the control-plane uses.
>> > >>> Does it use TCP for reliability, does it use multicast, is it like a 
>> > >>> routing
>> > >>> protocol, is it like a management protocol. What are the failure 
>> > >>> modes, the
>> > >>> state/bandwidth tradeoffs.
>> >
>> > [Sridhar] Explaining all these in IETF draft is simply reproducing 

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

[Sridhar Bhaskaran]

My comments inline marked [SB]

> >>> It was never clear to me and no one could ever explain exactly why a
> TEID is needed. I presumed for accounting reasons. But if there was a
> one-to-one mapping between tunnel and user, why couldn’t the inner
> addresses be used for accounting?
> >
> > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a
> tunnel and hence consequently a bearer. Once the bearer context is
> identified the QoS and charging policy applicable to the bearer is applied.
> So the purpose of TEID is not just for accounting. Its for QoS treatment,
> charging and bearer context identification.
>
> You told me what a TEID is but you didn’t say why you need to use it
> versus using the destination IP address for the tunnel.
>
>
> In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
> session whereas the QFI carried in GTPU extension header identifies the
> flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>
> When a packet is encapsulated in a tunnel, a packet has 4 addresses, which
> tells us (1) the UE, (2) the destination it is talking to, (3) the
> encapsualting node, and (4) the decapsulating node.
>
> So again, why use more space in the packet, when you have sufficient
> information to identify a user, and therefore their packet policy?
>
> [SB] Lets say we only use UE IP address and no TEID. How will you identify
the bearer context the packet belongs? One UE may use multiple radio
bearers / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but
these are IP level markings which could be changed by any on path routers.
In order to uniquely identify the bearer / qos flow a particular packet for
a UE belongs, GTPU uses TEID.

Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are
not always unique. The same IP pools can be shared across multiple PDNs /
DNs as long as these PDNs / DNs are separate autonomous networks. So just
relying on UE IP address alone will result in wrong context identification
for the uplink traffic. There is a clear one to one mapping of Radio bearer
to the EPS bearer / QoS flow required all the way upto the anchor node for
charging and QoS treatment. This comes from the requirements in stage 2
documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for
5G).

There are also requirements to support non-IP protocols like Ethernet PDU
and Unstructured PDU types in 5G.

>>
> > >>> How can packets be sent if the session is not setup. If the session
> is not setup, the encapsulator should have no state. And packets should be
> dropped locally and not go far to get an error back. This sounds
> architecturally broken.
> >
> > [Sridhar] The purpose of GTP-U error indication is to signal in band to
> the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is
> lost for any reason. "No session exist" does not mean Session
>
> What does lost mean? You mean the path from encapsulator to decapsulator
> is not working? And since we are in a packet network, that path can be
> restored quite quickly.
>

[SB] Lost here means - the "context" at the receiving entity is deleted.
For e.g due to administrative reasons, gNB or eNB removes the radio bearers
and correspondingly the GTPU context. If gNB or eNB loses a context for
known reasons, there could be signaling from gNB / eNB to AMF/MME and
corresponding removal of PDU session / EPS bearer at the core network. But
if the context is removed due to administrative reasons or unforeseen local
errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the
GTPU error indication is an inband error detection mechanism.

Note TEID identifies a context at the receiving side. So all GTPU error
indication tells is that the receiver is not able to identify any context
for the received TEID.


> > is not setup. "No session exist" scenario after a session setup can
> happen due to local error conditions, bearers released for administrative
> reasons etc.
>
> So at the encapsulator, do you choose another decapsultor? Note that
> tunnels *usually* stay up since the topology that realizes the tunnel is
> robust and redundant.
>
> >>
> > >>> You should explain in summary form the model the control-plane uses..
> Does it use TCP for reliability, does it use multicast, is it like a
> routing protocol, is it like a management protocol. What are the failure
> modes, the state/bandwidth tradeoffs.
> >
> > [Sridhar] Explaining all these in IETF draft is simply reproducing what
> is already there in TS 29.244. A reference to TS 29.244 should be enough.
> See section 6.4 of TS 29.244 for reliable delivery of PFCP messages.
>
> Just pointing people to drafts doesn’t help in understanding. It requires
> people to go off, put in a lot of time where the odds are their question
> will not be answered.
>

[SB] TS 29.244 is not a draft but rather a full fledged technical
specification. The issue with repeating content from elsewhere instead of
just pointing is 

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

[Behcet Sarikaya]

On Wed, Sep 5, 2018 at 3:56 AM Sridhar Bhaskaran <
sridhar.bhaska...@gmail.com> wrote:

> Dear Dino,
>
> Some clarifications on your comments
>
> >>> It was never clear to me and no one could ever explain exactly why a
> TEID is needed. I presumed for accounting reasons. But if there was a
> one-to-one mapping between tunnel and user, why couldn’t the inner
> addresses be used for accounting?
>
> [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel
> and hence consequently a bearer. Once the bearer context is identified the
> QoS and charging policy applicable to the bearer is applied. So the purpose
> of TEID is not just for accounting. Its for QoS treatment, charging and
> bearer context identification.
>
> In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
> session whereas the QFI carried in GTPU extension header identifies the
> flow. So in 5G TEID + QFI is used for QoS treatment and charging.
>
> >>> How can packets be sent if the session is not setup. If the session is
> not setup, the encapsulator should have no state. And packets should be
> dropped locally and not go far to get an error back. This sounds
> architecturally broken.
>
> [Sridhar] The purpose of GTP-U error indication is to signal in band to
> the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is
> lost for any reason. "No session exist" does not mean Session is not setup.
> "No session exist" scenario after a session setup can happen due to local
> error conditions, bearers released for administrative reasons etc.
>
> >>> You should explain in summary form the model the control-plane uses.
> Does it use TCP for reliability, does it use multicast, is it like a
> routing protocol, is it like a management protocol. What are the failure
> modes, the state/bandwidth tradeoffs.
>
> [Sridhar] Explaining all these in IETF draft is simply reproducing what is
> already there in TS 29.244. A reference to TS 29.244 should be enough. See
> section 6.4 of TS 29.244 for reliable delivery of PFCP messages.
>
>
I checked in IETF IANA UDP assignments,

pfcp 8805 udp Destination Port number for PFCP [Kimmo_Kymalainen

] [Kimmo_Kymalainen

] 2017-05-08
 for packet forwarding control protocol. What is PFCP, is it GTP-U?

Behcet

> Thanks
> Sridhar
> 3GPP CT4 Delegate
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Dino Farinacci]

> Dear Dino,
> 
> Some clarifications on your comments

I am going to use general terms here so we don’t get hung up in IETF and/or 
3GPP terminology. Which doesn’t make things clear to anyone really. So we can 
stay on point.

> >>> It was never clear to me and no one could ever explain exactly why a TEID 
> >>> is needed. I presumed for accounting reasons. But if there was a 
> >>> one-to-one mapping between tunnel and user, why couldn’t the inner 
> >>> addresses be used for accounting?
> 
> [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel and 
> hence consequently a bearer. Once the bearer context is identified the QoS 
> and charging policy applicable to the bearer is applied. So the purpose of 
> TEID is not just for accounting. Its for QoS treatment, charging and bearer 
> context identification.

You told me what a TEID is but you didn’t say why you need to use it versus 
using the destination IP address for the tunnel.

> In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU session 
> whereas the QFI carried in GTPU extension header identifies the flow. So in 
> 5G TEID + QFI is used for QoS treatment and charging.

When a packet is encapsulated in a tunnel, a packet has 4 addresses, which 
tells us (1) the UE, (2) the destination it is talking to, (3) the 
encapsualting node, and (4) the decapsulating node.

So again, why use more space in the packet, when you have sufficient 
information to identify a user, and therefore their packet policy?

>> 
> >>> How can packets be sent if the session is not setup. If the session is 
> >>> not setup, the encapsulator should have no state. And packets should be 
> >>> dropped locally and not go far to get an error back. This sounds 
> >>> architecturally broken.
> 
> [Sridhar] The purpose of GTP-U error indication is to signal in band to the 
> sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost for 
> any reason. "No session exist" does not mean Session 

What does lost mean? You mean the path from encapsulator to decapsulator is not 
working? And since we are in a packet network, that path can be restored quite 
quickly.

> is not setup. "No session exist" scenario after a session setup can happen 
> due to local error conditions, bearers released for administrative reasons 
> etc.

So at the encapsulator, do you choose another decapsultor? Note that tunnels 
*usually* stay up since the topology that realizes the tunnel is robust and 
redundant.

>> 
> >>> You should explain in summary form the model the control-plane uses. Does 
> >>> it use TCP for reliability, does it use multicast, is it like a routing 
> >>> protocol, is it like a management protocol. What are the failure modes, 
> >>> the state/bandwidth tradeoffs.
> 
> [Sridhar] Explaining all these in IETF draft is simply reproducing what is 
> already there in TS 29.244. A reference to TS 29.244 should be enough. See 
> section 6.4 of TS 29.244 for reliable delivery of PFCP messages.

Just pointing people to drafts doesn’t help in understanding. It requires 
people to go off, put in a lot of time where the odds are their question will 
not be answered.

The points I’m trying to make is not “what it is” you are designing but “why 
you did what you did” in the design. That is rarely in the specs.

Dino

> 
> Thanks
> Sridhar
> 3GPP CT4 Delegate

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Sridhar Bhaskaran]

Dear Dino,

Some clarifications on your comments

>>> It was never clear to me and no one could ever explain exactly why a
TEID is needed. I presumed for accounting reasons. But if there was a
one-to-one mapping between tunnel and user, why couldn’t the inner
addresses be used for accounting?

[Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel
and hence consequently a bearer. Once the bearer context is identified the
QoS and charging policy applicable to the bearer is applied. So the purpose
of TEID is not just for accounting. Its for QoS treatment, charging and
bearer context identification.

In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU
session whereas the QFI carried in GTPU extension header identifies the
flow. So in 5G TEID + QFI is used for QoS treatment and charging.

>>> How can packets be sent if the session is not setup. If the session is
not setup, the encapsulator should have no state. And packets should be
dropped locally and not go far to get an error back. This sounds
architecturally broken.

[Sridhar] The purpose of GTP-U error indication is to signal in band to the
sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost
for any reason. "No session exist" does not mean Session is not setup. "No
session exist" scenario after a session setup can happen due to local error
conditions, bearers released for administrative reasons etc.

>>> You should explain in summary form the model the control-plane uses.
Does it use TCP for reliability, does it use multicast, is it like a
routing protocol, is it like a management protocol. What are the failure
modes, the state/bandwidth tradeoffs.

[Sridhar] Explaining all these in IETF draft is simply reproducing what is
already there in TS 29.244. A reference to TS 29.244 should be enough. See
section 6.4 of TS 29.244 for reliable delivery of PFCP messages.

Thanks
Sridhar
3GPP CT4 Delegate
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm