Subject: Re: [DMM] extended data plane discussion - N6 traffic steering

From: Marco Liebsch <[email-masked]>
Date: Mon, 1 Oct 2018 10:00:55 +0000

Hi John,

thanks for the feedback. Please see inline [ml].

From: John Kaippallimalil [mailto:[email-masked]]
Sent: Freitag, 28. September 2018 21:59
To: Marco Liebsch; [email-masked]
Subject: RE: extended data plane discussion - N6 traffic steering

Hi, Marco,
N6  aspects are generally underspecified in 3GPP - as it is an interface to an external data network (IP network) but sometimes have specific route and QoS requirements.
Descriptions in a draft like this can help to clarify aspects that are not well specified for a local  N6 interface.

[ml] yes, we thought the same.

This was a quick read - assuming that the focus is on local network N6, the discussion in section 4 about traffic treatment  looks good.
The abstract does confuse me a bit. It goes over GTP-U and other motivation around anchoring, etc. - N3, N9 (interfaces inside 5G system).
While the focus of the draft (section 4) seems to be about N6.

[ml] Ok, this document mainly addresses IETF folks so far and the abstract tries to position this draft within in a set of
other drafts of the data plane discussion. Most drafts discuss the mobile data plane on N9 and N3 and the use of
protocol candidates as alternative to the GTP overlay  This draft complements the data plane discussion
by including N6. Having the possibility to apply policies to N6 traffic treatment enables very interesting
use cases as all data plane segments from an application server's network to the UE is covered. However, the abstract
may be adjusted to be more focusses in future revisions. That's do be discussed.

Some more specific comments:

1.      in section 3.2 - the UE to edge data network use case is clear, i.e., the need for traffic steering policy (along with description in section 4)
However, use case UE to UE communication is not clear. If this is about optimal routing between 2 UEs in a 3GPP network, that would be in the scope of 3GPP.
If it is UEs in 2 PLMNs, the solution would need much more than just traffic steering.

[ml] I see and agree that UE-to-UE seems to be a bit off-topic. It's more to be complete and to cover the UE-to-service as well as the
UE-to-UE communication as it's addressed in draft-gundavelli-dmm-mfa-01<https://datatracker.ietf.org/doc/draft-gundavelli-dmm-mfa/>.  Dependent on the use cases for UE-to-UE communication,
N6 policies are needed. 3GPP has an interface in scope, which can be used, this is N4. Maybe only the semantics need to be extended in support
of the target use case. Key aspect of draft-fattore is to cover a policy control interface to the data network, which holds the DPN/AS for
N6 policing. Ad such interface is not covered in 3GPP-

2.       Local data network/N6 issues around asymmetric return route are not discussed in the draft.
In 5G, UE flows to edge network AS can bypass UPF-PSA (IP anchor) as a result of an intermediate UPF routing directly to a local UPF-PSA (not IP anchor) using flow filters.

This can result in asymmetric paths - where the return path is still via the IP address anchor UPF-PSA.
Note that this is different from N6 next to UPF-PSA that is an IP anchor (Figures 3 & 4 and the descriptions do not cover this)

[ml] well, it's covered but maybe we need to spend a few more sentences to make it more obvious. So far we write that downlink traffic
should traverse the most suitable UPF_a in case of multiple choices. More text could describe that asymmetric routing can be avoided
by solutions in this draft. Asymmetry here is uplink to a local data network traverses UPF_i/UPF_a2, whereas downlink traffic from the local
data network traverses UPF_a1. This is what you mean, correct?

2.      Section 5 /only includes control plane aspects and binding between 3GPP and N6 control plane (AF ->DPN)
There would probably be some specification for the user plane as well. For example - the N6 user plane is probably an IP tunnel between local UPF-PSA and AS?
And what if there is a load balancer that removes the tunnel before selecting the AS instance. The return path would not work as expected (i.e., asymmetric path).
Should there be requirements to LB - to retain the outer source IP address? Or some explicit header (like NSH) for the AS to route return packet to local UPF (not the anchor).

[ml] So far we thought about keeping the protocol out of N6 for traffic steering, which can be ILA or SRv6, or any encap protocol. For us it's
just a question of traffic treatment policies. Any of them allows us to achieve the flexibility we want. Important is 'how' and 'when'
policies can be enforced on data networks' DPN/AS. But we can include a protocol example as well, no problem.

4.       Motivation and introduction sections have a lot of references that are perhaps not needed in the context of the N6 focus of this draft.

I would be willing to clarify further and help with details of the draft.

[ml] sounds good. Thanks, John. I hope we can schedule a few side meetings in Bangkok. To elaborate on some more details.

Best regards,
marco

BR,
John

From: dmm [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Thursday, September 20, 2018 2:37 PM
To: [email-masked]
Subject: [DMM] extended data plane discussion - N6 traffic steering

Folks,

we submitted a new ID which extends the current data plane discussion from N9/N3 to N6 interfaces
of the mobile system's architecture.

We could discuss the use cases, problem statement and principles with some before submission, but
post this initial draft to get the larger community's feedback before we update with more details and the
received feedback.

Your comments are appreciated.

Best regards,
marco

Name:                 draft-fattore-dmm-n6-cpdp-trafficsteering

Revision:             00

Title:                    Control-/Data Plane Aspects for N6 Traffic Steering

Document date:               2018-09-20

Group:                 Individual Submission

Pages:                  12

URL:            https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt

Status:         https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/

Htmlized:       https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering

Abstract:

   Current standardization effort on the evolution of the mobile

   communication system reconsiders the mobile data plane protocol.  The

   IETF DMM Working Group has work that proposes and analyzes various

   protocols as alternative to the GPRS Tunneling Protocol for User

   Plane (GTP-U) for an overlay deployment in between the mobile

   device's assigned data plane anchor and its current radio base

   station, which are denoted as N9 and N3 interfaces.  In the view of

   some future deployment and the original intent per the very early DMM

   WG charter, a mobile device's data plane anchor may be highly

   distributed and re-selected for optimization throughout a mobile

   device's communication with one or more correspondent services.  Such

   re-configuration has impact on the packet routing in between the

   mobile device's data plane anchor and the one or multiple data

   networks hosting the services, which is denoted as N6 interface.

   This draft proposes and discusses a solution to control, setup and

   maintain traffic treatment policy on the cellular communication

   system's N6 interface while taking the UE's PDU session settings per

   the cellular system's control plane, such as QoS and locator

   information, into account.

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 12 Oct 2018 20:30:04 +0900

FYI, I discussed this topic with Marco as P2P, and copied my 
comments/questions and his answers below.

Best regards,

Shunsuke

--

General Comments and questions:
[SH] I assume that 3GPP 5G architecture is designed to provide basic 
control of user plane traffic with UPFs (and corresponded SMFs), and 
policy enforcements, such as QoS control, steering, or charging, would 
be done at UPF(s) in bi-direction. In other words, a UPF is deployed at 
place where some traffic handling is needed. Then, do you have any 
requirements to handle user plane traffic on N6 interface?
[ml] that depends a lot on the deployment. Today all policies are in the 
UPFs and these are associated with data networks, hence N6 is 
potentially short. If we think about scenarios where we decouple the 
binding of a UPF to a data network, e.g. by sharing a UPF for traffic 
from multiple data networks, these data networks should have policies to 
route downlink traffic to the right UPF, in particular if there a more 
than one. Also, relocation of a UPF while maintaining the UE's IP 
address changes the IP address from a routable to a non-routable 
address. Hence, ID-LOC protocols, for example, can be used to steer 
traffic to the new UPF by using default routes in the transport network. 
We see this not necessarily required for all traffic, but for some 
deployments, in particular for future industry verticals. Moving the UPF 
while maintaining the session may in some cases more efficient 
(signaling costs, etc) than adding more and more UPFs which serve as 
PSAs, or adding more ULCL UPFs to route to a local data network.

[SH] The current user plane protocol study proceeded in 3GPP CT4 mainly 
focuses on N9 interface, and N3 and N6 are out of scope. Do you have any 
plan to propose to expand the scope to 3GPP CT4?
[ml] well, it would be nice, hence we want to extend the data plane 
discussion to N6 in the IETF first. We tried to being some of these 
cases to 3GPP SA2 some years ago, but the reaction was obvious that 
SGi/N6 is out of scope. Let me say this way: I am not sure how CT4 will 
treat the new protocols for N9/N3, hence nothing may change. Bringing in 
N6 allows us to apply IETF protocols and enable new use cases.

Small comments:
[SH] Regarding some figures representing 5G architecture, UPFs should be 
connected with N9 interface and every UPF must have N4 interface.
[ml] Absolutely, but we did not want to sketch the complete architecture 
as it's already in many other IETF drafts we refer to. If you think it's 
confusing, we can add N4, no problem.

[SH] As you may know, there is some difference between definition of 
data/user plane on 3GPP and IETF, and thus it's better to describe the 
definition in this document.
[ml] good point. We can describe it, but let's see if in any of the 
existing drafts there is a definition, so we can align it.

On 2018/09/21 4:37, Marco Liebsch wrote:
> of the mobile system’s architecture.
> 
> post this initial draft to get the larger community’s feedback before we 
> update with more details and the
> received feedback.
> 
> URL: 
> https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/
> 
> Htmlized: 
> https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00
> 
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering
> 
> Abstract:
> 
> _______________________________________________
> 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
----------------------------------