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 <arashmid.akhav...@huawei.com>
Cc: Tom Herbert <t...@quantonium.net>; ta-miyas...@kddi-research.jp;
dmm <dmm@ietf.org>
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
<arashmid.akhav...@huawei.com> 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 <arashmid.akhav...@huawei.com>
Cc: Dino Farinacci <farina...@gmail.com>;
ta-miyas...@kddi-research.jp; dmm <dmm@ietf.org>
Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
On Fri, Sep 7, 2018 at 8:01 AM, Arashmid Akhavain
<arashmid.akhav...@huawei.com> wrote:
-----Original Message-----
From: Dino Farinacci [mailto:farina...@gmail.com]
Sent: 06 September 2018 18:59
To: Arashmid Akhavain <arashmid.akhav...@huawei.com>
Cc: Tom Herbert <t...@quantonium.net>; ta-miyasaka@kddi-
research.jp;
dmm <dmm@ietf.org>
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 <t...@quantonium.net>
Cc: ta-miyas...@kddi-research.jp; dmm <dmm@ietf.org>
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
--
----------------------------------
Shunsuke Homma
<homma.shuns...@lab.ntt.co.jp>
TEL: +81 422 59 3486
FAX: +81 422 60 7460
NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
