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, [email protected] wrote:
Hi Alex,
and sorry for jumping into the discussion...
From my and (AFAIK) 3GPPs understanding your smartphone is a UE - sitting on
the other side of RAN (gNB) - whereas a UPF normally is seen as UP entry (and
exit) of the 5G core (i.e. handling all UP traffic in a true CP/UP split
fashion).
Any other ideas on this? Can someone imagine any scenario where UE implements
UPF?
Thanks!
Best Regards
Dirk
-----Original Message-----
From: dmm [mailto:[email protected]] On Behalf Of Alexandre Petrescu
Sent: Montag, 1. Oktober 2018 13:22
To: [email protected]
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
Le 01/10/2018 à 05:50, Shunsuke Homma a écrit :
Hi all,
# Sorry for my late response...
Thank you for your lively discussion. It is very helpful for
understanding points which need supplemental explanation and more
consideration.
Following the discussion, we're planning to update the I-D for
covering the points below:
- termination points of GTP-U
(RANs and UPFs terminate GTP-U in 5GS.)
What is UPF?
I understand UPF stands for User-Plane Function.
Is my smartphone supposed to implement UPF?
Alex
- setting QoS parameter of outer IP header
(Note that it's not just copy of inner to outer.)
- problems related to IP connectivity (e.g., MTU in IPv6 networks,
IPv4 address duplication)
- summary of network slicing in 5GS
(E.g., "slice is composed of SMF and UPFs. AMF selects SMF
depending on NSSAI sent from UE, and SMF indicates to the UE the UPF
that it is
allocated.")
- case studies on UPF selection
(E.g., parameters used for deciding destination UPF) # Optimizing
forwarding paths solution might be realized with UPF selection
mechanism in 3GPP architecture. (ID-LOC may be applied as such
mechanism.)
If you have any request for us on this updating, please let us know.
Best regards,
Shunsuke
On 2018/09/08 3:28, Dino Farinacci wrote:
I understand your point, but there is no guarantee for a precise QoS
without using some sort of encapsulation being it GTP, RSVP, etc.
Even with tunnels, there is no guarantee that all nodes along the
path have the same hardware capability and can provide the same QoS
treatment.
There is existing hardware where the encapsulator copies inner QoS to
outer QoS. All routers along the path just process the outer QoS, no
changes to or new processing requirements for them.
For example, the code points in routers need to be configured to
correctly handle the EXP bits in MPLS labels. But there is no
guarantee that all routers can support all values. The EXP values
get mapped to code points but the mapping is not always one to one.
3-bit EXPs can map to 4 code points on those routers with less
capable H/W.
That is a completely different matter. The discussion is about
remarking. And if one remarks to what the path cannot support, well
things don’t work as expected.
Slicing is almost the same. It allows user traffic to be mapped to
what the operator provides.
I agree with you that network should not touch/change original
header bits. GTP or any other encapsulation easily allow for this.
The question is whether we can provide for this without using
encapsulation. IPv6 might be the answer. But as Tom pointed out,
flow labels can still change in the middle. Is there any room for
improvement. SIDs might present an opportunity.
Not if they are encapsulated and routers don’t touch packets inside.
Dino
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: 07 September 2018 13:08
To: Arashmid Akhavain <[email protected]>
Cc: Tom Herbert <[email protected]>; [email protected];
dmm <[email protected]>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
I think you’ll still have the PHB re-marking issues I mentioned in
previous emails. The question is, should the network touch/change
any header bits of the packet the source has built. The answer
should probably be no.
Having said that, GTP did it the right way, even though it cost in
header length.
Dino
On Sep 7, 2018, at 8:26 AM, Arashmid Akhavain
<[email protected]> wrote:
Correct, flow labels can change along the path. That's why I like
the slicing
concept.
UEs can request services with different attributes, operators
control how
service request are mapped into slices. I should look into the air
side of the business and see what happens there.
-----Original Message-----
From: Tom Herbert [mailto:[email protected]]
Sent: 07 September 2018 11:13
To: Arashmid Akhavain <[email protected]>
Cc: Dino Farinacci <[email protected]>;
[email protected]; dmm <[email protected]>
Subject: Re: [DMM] Comments to
draft-hmm-dmm-5g-uplane-analysis-01
On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
<[email protected]> wrote:
-----Original Message-----
From: Dino Farinacci [mailto:[email protected]]
Sent: 06 September 2018 18:59
To: Arashmid Akhavain <[email protected]>
Cc: Tom Herbert <[email protected]>; ta-miyasaka@kddi-
research.jp;
dmm <[email protected]>
Subject: Re: [DMM] Comments to
draft-hmm-dmm-5g-uplane-analysis-
01
Dino brought up a good point. Here is my two cents worth:
Not sure which point.
As it was explained by Sridhar, each UE can have multiple
contexts. For
example, today some operators provide Data and VoLTE service to
their customers. These two services are represented by separate
GTP tunnels in the core with each tunnel tied up to a particular QoS.
IPv4 didn't fit the bill when GTP work was under way as it
couldn't uniquely identify multiple UE
There is no reason why it shouldn’t. And IPv6, for this
use-case doesn’t add anything new other than a 28 bit
traffic-class/flow-label that can provide more bits for “new
functionality”.
[Arashmid] And that's what I meant. Having a flow label is handy.
We can perhaps use it to identify different UE sessions.
Careful if you use the flow label to identify flows. It should be
considered "soft identification" since it might not always be
correct (it can be changed en route, isn't protected by any
checksum, anyone can set it however they want, etc.). It's useful
for things like ECMP that don't require 100% accuracy in
identifying flow. The flow label was briefly considered for
holding VNIs in network virtualization, but we
talked them out of that.
Tom
sessions/context/bearer. So, GTP and TEID did the job. But I
agree with
Dino that IPv6 is much more versatile and is definitely worth
looking at as an alternative.
That is not what I said. I said “IP could have solved this
problem”. And
“IP”
means either IPv4 or IPv6, or both at the same time.
[Arashmid]
How would we employ IPv4 to distinguish between different UE
sessions.
TOS?
Or you mean using encapsulation?
A factor worth considering though is that the use of GTP and
TEID in mobile
core allows operators to deal with QoS on their own terms. The
tunnels with specific operator-controlled QoS are established
by the control plane between eNB, SGW, and PGW. UEs or
applications sitting in the UEs have no say in this. Well at
least till the packet exits operator's
network.
The problem with one header, is that if you re-mark (known as
PHB markign in the ole days) you lose the original value.
Encapsulation is useful here because you can map the inner to
outer and anywhere along the path you can PHB remark on the
outer header. And then the destination can see the orignal
source’s ToS/QoS/TC/flow-label
whatever.
[Arashmid] Yes, I agree. The original value is lost with PHB.
Encapsulation certainly makes things easier and the inner to
outer mapping trick has been widely used in IP and MPLS(multiple
labels like service and transport)
Using the information in UE's IP packet header can jeopardise
the above tight QoS control. I think going
Not if you encapsulate. But note with SRv6, you can possibly
retain the original flow-label if the SID can retain those bits
before overwriting the destination address from the option’s value.
[Arashmid] Agree. Encapsulation does the trick again. That's why
GTP has worked well and served the purpos in the mobile
back-haul so far.
Dino
down this path, operators need proof that they will be still
in the driving
seat and QoS cannot be dictated/tampered by the UE or any
application running in it.
Now, here is an interesting question for the operators. Would
any operator
be interested in allowing QoS to be set by the UE or by
applications running in the UE and charged for by the network?
"Yes" could potentially imply impacts on the air interface, UE
resource block allocation and can make scheduling on the RAN
side
much more complex.
Arashmid
-----Original Message-----
From: dmm [mailto:[email protected]] On Behalf Of Dino
Farinacci
Sent: 06 September 2018 12:45
To: Tom Herbert <[email protected]>
Cc: [email protected]; dmm <[email protected]>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-
analysis-
01
Behcet,
I was thinking if TEID is need then that can be encoded in a
locator easily enough.
Tom
Not if a locator is a PGW that is shared by many UEs.
3GPP wants per bearer awareness so they need a specific ID,
that could have been the UE’s IP address. And with IPv6 it
can be unique and not the issue that Sridhar brought up.
If ILA was in use, just use the ILA-ID for this purpose.
Dino
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
--
----------------------------------
Shunsuke Homma
<[email protected]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460
NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
