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

From: Marco Liebsch <[email-masked]>
Date: Thu, 20 Sep 2018 19:37:18 +0000

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: John Kaippallimalil <[email-masked]>
Date: Fri, 28 Sep 2018 19:58:59 +0000

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.

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.

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.

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)

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

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.

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,

Best regards,
marco

Revision:             00

Pages:                  12

Abstract: