Hi Sridhar,
Thank you for your review and comments. (And I'm sorry for the late
replay...)
Please find my replies in-line.(Tagged with [SH].)
Best regards,
Shunsuke
On 2019/01/09 12:00, Sridhar Bhaskaran wrote:
Dear authors of draft-ietf-dmm-5g-uplane-analysis-00,
Thank you for the draft.
I have the following questions for clarification and comments on
draft-ietf-dmm-5g-uplane-analysis-00
Questions
========
1. Section 3.6 - could you elaborate on what you mean by
[GTP-U-6]: Does not support to response ICMP PTB for Path MTU
Discovery.
[SH] What we want to say in this observations is that 3GPP does not
define PMTUD in user plane while TS23.060 requires well managed MTU
size.Thereby there's no specification on how to handle ICMP Packet Too
Big message at U-Plane functions like UPF. But if ICMP PTB message is
generated at an intermediate router, the UPF which receives PTB message
may not take any action due to lack of 3GPP specification. It may cause
black hole for mobile user.
2. Section 4.1
These tunnels are available to be handled by other
authorized functions through the control plane.
Could you elaborate on what you mean by "other" authorized functions? Right now
only SMF is allows to setup / teardown tunnels via N4 at UPF.
[SH] "other authorized functions" means functions which are external to
the 5GS owned by the NOP. The 5GS has NEF and it provides some
controllabilties to external parties. For example, an MVNO may handle UP
tunnels/traffic flows on UPFs via NEF, SMF, and N4 interface. I can
modify this text to describe the above more clearly.
3. Section 4.2 Arch-Req-3: Could you please clarify the following sentence?
First part of sentence talks about multiple PDU sessions but end of the
sentence talks about one PDU session. So its not clear to me which case this is
talking about.
However
it should be the multiple PDU sessions multihoming case where the
destination gNB or UPF needs to maintain multiple tunnel states under
the one PDU session to one UP tunnel architectural principle.
[SH] What we want to express here is that multihoming with P2P needs to
maintain a tunnel state for each source UPF which leads increase of
loads on management of tunnel states.
4. Section 4.2 - Arch-Req-5. I am not able to understand the following sentences. Could you clarify
what you mean by "connecting them without extra anchor points"? Also what does
"them" refer to here? Does it refer to UE or UPF?
In addition, deployment of multiple UPFs as anchors closed to UEs'
site and connecting them without extra anchor points enable to make
data path more efficient.
[SH] In the current LTE, all of UP traffic is forwarded to a P-GW which
is centralized and it may cause trombone routing. On the other hand, the
5GS allows flexible deployment of UPFs mainly for MEC use cases. For
example, in case these UPFs are distributed geographically, UP flows can
be applied LBO or forwarded between UPFs nearby src and dst directly.
Anyway, I think it should be described in ARCH-Req-4: Flexible UPF
selection, and I'll move this text to there.
5. Section Arch-Req-5: Are the following statements an architectural requirement derived
from 23.501 or an architectural requirement this draft is putting on 3GPP? Atleast the
words " UP protocol shall support to aggregate several PDU sessions into a tunnel or
shall be a session-less tunnel." Seems like this draft is putting a requirement on
3GPP.
It is expected that multiple UPFs with per session tunnel handling
for a PDU session becomes complicated task more and more for a SMF by
increasing number of UPFs, and UP protocol shall support to aggregate
several PDU sessions into a tunnel or shall be a session-less tunnel.
[SH] It's not requirement to 3GPP from IETF. We are assuming that the
current 5GS potencially have this requirement on UP protocol. If this
text seems not to be appropriate, we can change it.
Comments:
==========
1. Section 4.1.1 - traffic detection based on UE IP address and SDF filters is
missing in the below list
o For IPv4 or IPv6 PDU Session type
* PDU Session
* QFI
* Application Identifier: The Application ID is an index to a set
of application detection rules configured in UPF
[SH] Thanks. I'll add UE IP address and SDF filters into the list. BTW,
can you tell me which sections should be referred? I'm referring section
5.7.6 and 5.8.2 in TS23.501. Are there any others?
2. Section 4.2 Arch-Req-2:
The 5G system requires IP connectivity for N3, N6, and N9 interfaces.
There is a specific case where IP connectivity on N6 is not mandatory. For
Ethernet PDU sessions, the anchor UPF could use L2 switching on N6 side. You
refer clause 5.6.10.2 of TS 23.501 especially the statements below
- Configurations, where more than one PDU Session to the same DNN (e.g.
for more than one UE) corresponds to the same N6 interface. In this case the
UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU
Session in order to map down-link Ethernet frames received over N6 to the
appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is
managed by SMF as specified in clause 5.8.2.5.
[SH] Agreed, thank you.
3. Section 4.2 Arch-Req-3:
Multihoming is provided with Branching Point (BP) or Uplink
Classifier (UL CL) which are functionalities of UPF.
ULCL is not used for multihoming. ULCL is used for traffic splitting towards a
local DN. Only BP is used for multihoming case.
[SH] I reviewed the section 5.6.4 in TS23.501, and I understood that
multiple anchor UPFs is realized by either ULCL or IPv6 multi-homing and
a way with ULCL is not called multihoming. I'll modify the description
about multihoming and add suplementaly expanation on difference between
ULCL and IPv6 multi-homing.
4. Section 5 is missing one evaluation aspect. GTP-U supports "End markers" to
help RAN sequence the packets when there is a change of UPF during mobility procedures.
So any user plane protocol that is to be evaluated need to support some mechanism to help
the last downlink node on path (e.g gNB) to sequence the packets coming from multiple
UPFs during mobility cases.
[SH] Thanks. I'll add it as one evaluation aspect.
5. Section 5.7 - Need justification for the following statement:
However some means need to indicate a slice on the shared
underlying networks of the UP over the wire.
What is broken or what is the issue if slice for transport is not indicated on the UP
over the wire? What are the issues with providing a "network instance" (which
could be mapped to a transport path) in the forwarding action rule of a PDU session?
What are the advantages of carrying slice information in every packet?
[SH] Is to provide a greater affinity between the UP and the underlying
network infrastructure. For example, if a UP session
requires certain level of latency with dedicated BW requirements,
traffic engineering (TE) embodies appropriate forwarding policy through
the underlay transport network to that specific UP session.
Regards
Sridhar Bhaskaran
_______________________________________________
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
