Subject: [DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 9 Jan 2019 03:00:30 +0000

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.

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.

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.

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.

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.

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

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.

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.

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.

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?

Regards
Sridhar Bhaskaran

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 16 Jan 2019 13:00:14 +0900

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

>>> [GTP-U-6]:  Does not support to response ICMP PTB for Path MTU
[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.

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

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

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

>     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:
[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?

> -	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 addre…
[SH] Agreed, thank you.

> 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 tha…
[SH] Thanks. I'll add it as one evaluation aspect.

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

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Fri, 18 Jan 2019 09:14:59 +0000

Dear Shunsuke,

Thank you for your responses. My further comments inline marked [SB-2]

Regards
Sridhar Bhaskaran

-----Original Message-----
From: Shunsuke Homma [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2019 9:30 AM
To: Sridhar Bhaskaran <[email-masked]>; [email-masked]
Subject: Re: [DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00

Hi Sridhar,

Best regards,

Shunsuke

>>> [GTP-U-6]:  Does not support to response ICMP PTB for Path MTU
[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.

[SB-2] It would be better to clarify how 3GPP allows MTU size communication to UE now and when the statement marked [GTP-U-6] is applicable. In my opinion this becomes applicable when the MTU size provided to UE as specified in TS 23.060 is not adhered to by UE or when that size is incorrect.

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

[SB-2] You may clarify this in the draft clearly stating that tunnel setup is controlled only by SMF (by N4) while the SMF may be provided information regarding the routing path based on API request from AF (application function) to NEF / PCF.

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

[SB-2] Please consider rewording the above sentence to make it clear.

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

[SB-2] But the sentence reads as "multiple UPFs as *anchors*" closer to UE" --> are you talking about BP UPF / ULCL UPF case? For UE to UE routing (e.g. for voice call) within same network - are you hinting at routing via an anchor UPF closer to RAN? Some details on the exact scenarios you are mentioning will help the reader. Even if you move this to Arch-Req-4 the statements need to be clearly elaborated as per scenarios you are considering.
 
>     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.
[SB-2] At least the last part of the sentence " and UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel." Seems like a requirement from IETF to 3GPP. As of Rel-15 there is no normative requirement in 3GPP to support aggregation of PDU sessions into a single tunnel.

> Comments:
[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?

[SB-2] You may refer to TS 29.244 table 7.5.2.2-1 and 7.5.2.2-2.

> 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
> 
[SH] Agreed, thank you.
[SB-2] Ack. Thank you.

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

[SB-2] Ack. Thank you.

[SB-2] Ack. Thank you.

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

[SB-2] At the time of providing the FAR rule to UPF in a PFCP session, the FAR can be associated with a "network instance". What that "network instance" maps to is implementation specific. One could map a "network instance" to an underlay SR-MPLS label stack as well. So this allows fields to be stamped on to the packet as part of the traffic going via the "network instance". Additionally "network instance" also allows you to implement in such a way to map it to a static path or interface as well, without any additional markings in packet. It's entirely a deployment choice. By explicitly stating that slice information needs to be explicitly indicated in packet over the wire, you are forcing to use one particular solution in the deployment.

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 1 Feb 2019 14:16:23 +0900

Hi Sridhar,

Sorry for my late reply again... It took time for internal review.

Please find my replies tagged with [SH-2] in-line.

Best regards,

Shunsuke

> [SB-2] It would be better to clarify how 3GPP allows MTU size communication to UE now and when the statement marked [GTP-U-6] is applicable. In my opinion this becomes applicable when the MTU size…
[SH-2] Section 3 describes just observations of GTP-U 
specifications/characteristics, and some cases where [GTP-U-6] may cause 
problems are explained section 5.3.

> [SB-2] You may clarify this in the draft clearly stating that tunnel setup is controlled only by SMF (by N4) while the SMF may be provided information regarding the routing path based on API reques…
[SH-2] Sure. Thank you.

> [SB-2] Please consider rewording the above sentence to make it clear.
[SH-2] Sure.

> [SB-2] But the sentence reads as "multiple UPFs as *anchors*" closer to UE" --> are you talking about BP UPF / ULCL UPF case? For UE to UE routing (e.g. for voice call) within same network - are yo…
[SH-2] Yes, as you pointed, we assumed that deployment of UPFs closer to 
RAN allows more effective routing on UE2UE ( for a call). And, maybe, it 
will be also used for UE to local DN such as for MEC. We'll add details 
on scenarios which needs that usage.

> [SB-2] At least the last part of the sentence " and UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel." Seems like a requirement from IETF…
[SH-2] OK. We'll modify the sentence for making it be clear that it is 
not requirement from IETF.

> [SB-2] You may refer to TS 29.244 table 7.5.2.2-1 and 7.5.2.2-2.
[SH-2] Thank you. We'll refer them.

> [SB-2] At the time of providing the FAR rule to UPF in a PFCP session, the FAR can be associated with a "network instance". What that "network instance" maps to is implementation specific. One coul…
[SH-2] Suppose that it is a multi-vendor case where UPF receives the 
network instance and IP transport imposes the label to the packet. Which 
3GPP document specifies that UPF to be interoperable with IP transport 
to impose corresponding label corresponding to the network instance?

Or do you assume cases where UPF and PE router run as all-in-one-box? 
MPLS is standardized in IETF, and it is defined that MPLS labels are 
imposed by PE router in the MPLS-VPN architecture.