Distributed Mobility Management (DMM) U. Fattore
Internet-Draft M. Liebsch
Intended status: Standards Track NEC
Expires: March 24, 2019 September 20, 2018
Control-/Data Plane Aspects for N6 Traffic Steering
draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2019.
Fattore & Liebsch Expires March 24, 2019 [Page 1]
Internet-Draft CPDP for N6 Traffic Steering September 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Positioning of N6 policy control . . . . . . . . . . . . . . 4
3.1. System architecture for mobile access to data networks . 4
3.2. Use cases with demand for N6 traffic treatment policy . . 7
4. N6 traffic treatment - Requirements and policy types . . . . 8
5. Leveraging the mobile control plane for N6 policy control . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction
Recent releases and deployments of cellular mobile communication
systems utilize an overlay on the mobile data plane to forward a
mobile device's data packets in between the mobile device and an
anchor point, which serves as first hop router to the mobile device.
The overlay is realized by the GPRS Tunneling Protocol for user plane
(GTP-U), which is able to carry network-specific attributes in the
tunnel protocol headers.
The 3rd Generation Partnership Project (3GPP) is in charge of the
cellular mobile communication system's specification and is currently
Fattore & Liebsch Expires March 24, 2019 [Page 2]
Internet-Draft CPDP for N6 Traffic Steering September 2018
finalizing a 15th release, which has fundamental changes compared to
previous releases. Such changes include a clean split between
control- and data plane functions, more flexible deployment and re-
configuration of data plane anchors, as well as support for local
data network (DN) access and multi-homing.
In between a mobile device's current radio base station in the radio
access network (RAN) and its data plane anchor, the release 15
specification assumes an overlay per the previous releases utilizing
GTP-U. The data plane anchor is denoted as User Plane Function (UPF)
to anchor a Packet Data Unit (PDU) Session for the mobile device.
This draft abbreviates the UPF, which serves a device's PDU session
anchor, as UPF_a. In between a UPF_a and the device's current radio
base station, none, one or multiple additional UPFs can be deployed
to classify uplink traffic in support of policy-based routing to a
particular DN without traversing the UPF_a. This draft denotes such
intermediate UPF as UPF_i. Interfaces between a DN and a mobile
device's UPF_a is denoted as N6, the interface between a UPF_i and
one or multiple UPF_a is denoted as N9, and the interface between a
UPF_i and a radio base station is denoted as N3. Whereas regular
routing of mobile devices' PDUs is assumed on N6, N9 and N3 deploy a
GTP-U overlay with UPF_a, UPF_i and the radio base station serving as
tunnel endpoints. This end-to-end architecture is depicted in
Figure 1. For a more detailed description of anchor and intermediate
UPF and associated deployment and operation, please refer to
[I-D.bogineni-dmm-optimized-mobile-user-plane] and the 3GPP
specification [TS23.501].
________
mobile +-----+ N3 +-------+ N9 +-------+ N6 / data \
device---+ RAN +======/==+ UPF_i +=====/====+ UPF_a +-----/--+ network |
+-----+ GTP-U +-------+ GTP-U +-------+ IP \________/
tunnel tunnel PDUs
Figure 1: Architecture and interfaces of a 3GPP release 15 data plane
in between a data network and a mobile device.
In alignment with the 3GPP's current directions to study data plane
protocol candidates which can serve as suitable alternative to GTP-U,
the IETF's DMM WG has valuable ongoing individual work that analyzes
the GTP-U protocol and derives requirements for an alternative mobile
data plane protocol [I-D.hmm-dmm-5g-uplane-analysis], as well as work
that investigates the use of alternative protocol candidates based on
SRv6, ID-Locator separation, and locator re-writing in the current
release 15 system architecture
[I-D.bogineni-dmm-optimized-mobile-user-plane]. The focus of these
drafts is on N9 and N3.
Fattore & Liebsch Expires March 24, 2019 [Page 3]
Internet-Draft CPDP for N6 Traffic Steering September 2018
In the view of optimization options on the complete end-to-end data
plane, [I-D.gundavelli-dmm-mfa] complements other draft and proposes
data plane optimization on N6. Such operation is of particular
interest when the mobile device's UPF_a is decentralized and deployed
close to the device's current radio base station. Such deployment
may be preferable for some services, such as edge computing and
access to associated edge DNs, and mitigates the role of the UPF_i
and N9 interfaces. In particular the selection and configuration of
UPF_i instances can omitted and associated signaling costs can be
saved. However, such deployment strengthens the expectation on IP-
based PDU routing on N6, as the serving DN may not be always
topologically close to the device and its current UPF_a. Such
requirements include QoS support on N6, metering support and traffic
steering in case the mobile device's UPF_a changes while its IP
address and associated sessions should continue.
The same requirements on N6 apply for multi-homing per [TS23.501]
where the mobile device's UPF_a is close to a first DN (DN1) whereas
a UPF_i is used to enable access to a second DN (DN2), either through
a secondary UPF_a close to DN2 or directly from the UPF_i, without
the use of a secondary UPF_a. Since services in both DNs address the
same IP address of the mobile device (IP_ue) to send downlink
traffic, both DNs' traffic need to be forwarded to the most suitable
(e.g. closest) UPF_a or UPF_i respectively.
This draft focuses on a solution to control, setup and maintain such
dedicated routes and additional traffic treatment policy on N6, while
taking the UE's PDU session settings per the cellular system's
control plane, such as QoS and locator information, into account.
3. Positioning of N6 policy control
This section briefly introduces the relevant mobile system
architecture components and interfaces, and covers some high-level
use cases which can benefit from data plane policy control on N6
interface endpoints.
3.1. System architecture for mobile access to data networks
The 3GPP's 5G system architecture introduces in the core network a
clear control-/user plane separation (CUPS), in order to have
flexible deployment of the different functions (e.g., user plane
nodes can scale independently from control plane elements in case of
user traffic growth). Again to leverage flexibility and efficiency,
the control plane is split in different functions, each offering a
specific service, in the so called Service Based Architecture (SBA).
Fattore & Liebsch Expires March 24, 2019 [Page 4]
Internet-Draft CPDP for N6 Traffic Steering September 2018
Among all the control plane functions, the Session Management
function (SMF) takes care of the session management (session
establishment, modification, release), IP allocation and selection of
an IP anchor point for the session, as well as traffic steering in
between UPFs and radio base stations. In order to manage the user
session, the SMF collaborates with other control plane services
(e.g., Policy Control Function - PCF - providing policy rules for
traffic treatment and monitoring), in particular with the Access and
Mobility Management Function (AMF), which manages registration,
authentication and authorization and security context. One of the
main task of the SMF is to instruct User Plane Functions (UPFs),
through N4 interface. When a new session is to be created, the SMF
selects one or multiple UPFs for the user traffic and selects one UPF
as session anchor (UPF_a). UPF_a acts as a proxy for user traffic,
which means all traffic directed to the UE passes through the UPF
anchor. Beside the UPF_a, if other UPFs are present (i.e., between
the radio base station and the UPF_a), this are deployed as
classifiers for user uplink traffic.
In Figure 2 a simplified 5G architecture [TS23.501] is depicted,
showing two Data Networks (DN) to whom a user may need a connection.
To each Data Network a UPF_a is associated, acting as session anchor
and providing to the user an IP address needed for the connection.
UPF_a also acts as tunnel termination point, since user traffic is
encapsulated on both N3 and N9 interfaces, using the GPRS Tunneling
Protocol for User Plane (GTP-U). Whereas, on N6 interface IP PDUs
are routed without tunneling.
Fattore & Liebsch Expires March 24, 2019 [Page 5]
Internet-Draft CPDP for N6 Traffic Steering September 2018
communication between control plane functions
- - +---------------------+ - -
| |
+--+--+ +-----+
| AMF | | SMF |
+-----+ +-----+
/N2 N4| |N4
/ +------+ +------+
/ | | _________
+----+ +-----+ N3 +---+---+ N9 +---+---+ N6 / data \
| UE |-----+ RAN +=========+ UPF_i +=========+ UPF_a +----/--+ network |
+----+ +-----+ +---+---+ +-------+ IP \____1____/
IP_ue +---+---+ proxy IP_ue
proxy| UPF_a |
IP_ue+-------+ _________
| N6 / data \
+-------/----+ network |
IP \____2____/
Figure 2: Data plane with a simplified release 15 control plane
Data networks host Application Servers (AS), which provide a services
to UEs, and an internal network comprising data plane nodes (DPN),
such as routers and switches, to connect the services with the
transport network. Both, the transport network and the data
network's internal network build the N6 interface, which is depicted
in Figure 3. In order to apply traffic treatment policy to uplink
traffic in between a UPF and a data network, the UPF receives
policies via the N4 interface. For downlink traffic, the AS/DPN
should have means to receive traffic treatment policies.
A way to enforce N6 policies to the DPN/AS in a data network is
needed. It is evident that this rule must originate from the
cellular control plane due to its knowledge about the UE's states,
such as its locator or QoS, and when these states are updated or re-
configured. Different means to convey and enforce associated traffic
treatment policies in a DPN/AS exist, such as the use of routing
protocols or control-/data plane configuration protocols.
Fattore & Liebsch Expires March 24, 2019 [Page 6]
Internet-Draft CPDP for N6 Traffic Steering September 2018
communication between control plane functions
- - +-------------------+ - -
| |
+--+--+ +-----+
| AMF | | SMF |
+-----+ +-----+
/N2 N4| |N4 N6 policy
/ +-------+ +--+ | __________
/ | | v/ \
+----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +------+ data \
| UE |-----+ RAN +======+ UPF_i +======+ UPF_a +--/----+DPN|AS| network |
+----+ +-----+ +---+---+ +-------+ IP +------+ 1 /
IP_ue +---+---+ proxy IP_ue \__________/
proxy| UPF_a |
IP_ue+-------+ ___________
| / \
| N6 +------+ data \
+-------/----+DPN|AS| network |
IP +------+ 2 /
^ \___________/_
|
N6 policy
Figure 3: Data network DPN/AS as traffic treatment policy enforcement
point
3.2. Use cases with demand for N6 traffic treatment policy
The motivations behind the need for N6 treatment policy are many.
Following, some of the use cases are listed and described.
UE to UE communication: a scenario which is not explicitly shown in
Figure 2 and Figure 3 is UE to UE communication, when a UPF_a via N6
interface is connected to another UPF_a (belonging to the same or to
another network, and controlled by the same of another SMF), with the
latter UPF being associated to a second UE. In this scenario, all
the data plane elements on the path are controlled by control plane
elements of the 5GC (i.e., SMFs), but anyway additional policies on
N6 may be forwarded in order to steer traffic on an optimized route
directly towards the edge UPF for the specific UE, without passing
through the UPF_a.
UE to edge data network: in this use case, the UE connects to an edge
Data Network, meaning a DN positioned at the edge of the core
network, near to the access network (typical MEC scenario). In
mobility, a new UPF_a may be assigned to UE, and routes to the
previous edge network would follow a non-optimized path, passing
through the new UPF_a for the UE. With traffic treatment policies
Fattore & Liebsch Expires March 24, 2019 [Page 7]
Internet-Draft CPDP for N6 Traffic Steering September 2018
this can be avoid, giving a traffic steering policy to the DPN in
charge for the edge DN.
Concurrent use of multiple data networks: a possible scenario is the
one in which a UE collects the desired content from different data
networks (e.g., because of Content Delivery Networks - CDN). To
optimize routing in this scenario, the downlink traffic should
traverse for each data network the optimized path through the UE and
not be forced through a (central) UPF_a common to all the data
networks. Again, this can be done with policies on N6 interface.
This particular use case also highlights the importance to consider
optimization on N6, whereas other works focus on N9: considering a
UPF_a near the data network, as proposed in other solutions, would
not allow multiple DN access in an unique user session and so would
not allow for content access on different destinations.
4. N6 traffic treatment - Requirements and policy types
Use cases for traffic treatment on N6 per a data plane policy include
cases where the UPF_a is deployed closer at the mobile edge, e.g. to
not only access a local data network in the proximity of the UE, but
also other data networks sharing the single edge UPF_a. In that case
the N6 interface may span some distance in the transport network in
between the data network(s) and the UPF_a. Dependent on the expected
QoE/QoS of the traffic, traffic treatment policies for QoS
differentiation, packet labeling, etc. may apply to the UE's packets
on N6. For uplink traffic, the UE's UPF_a can enforce such traffic
treatment policies to uplink traffic, where a DPN associated with the
data network(s) (e.g. PE router, transit router, router/switch of
the data center transport network, TOR switches of Application
Servers, etc.) enforces such policies to downlink traffic.
The same need for traffic treatment policies applies to traffic
between a UPF_i, which classifies uplink traffic for forwarding to a
local data network, and the data network. Downlink traffic from the
local data network to the UE should then be forwarded towards the
UPF_i, not via the UE's UPF_a.
In advanced scenarios, the SMF may decide to reconfigure the UE's
UPFs, e.g. by relocating the UPF_a or a UPF_i while maintaining the
UE's IP address (IP_ue) and data sessions using this IP address. In
such case, a DPN associated with the one or multiple data networks,
which run correspondent services for the UE, must enforce traffic
steering policies to downlink traffic to achieve routing of downlink
traffic to the UE's current UPF_a or UPF_i respectively.
In summary, traffic treatment policies that apply to a UE's uplink
and downlink traffic on N6 include the following types:
Fattore & Liebsch Expires March 24, 2019 [Page 8]
Internet-Draft CPDP for N6 Traffic Steering September 2018
o QoS differentiation and traffic engineering
o Packet label push/pop
o Metering
o Traffic steering (e.g. SRv6 rules, locator re-write rules, etc.)
o UE dormancy monitoring rules to initiate paging
Requirements for N6 traffic treatment include the following:
o Awareness of UE location information (first hop router accuracy,
UPF_a/UPF_i) - Set or update DPN policy for traffic steering
o Awareness of topology - Select and update most suitable UPF (UPF_a/
UPF_i) for the communication with a data network, e.g. after UPF
changed
o Availability of initial or updated policies when needed
o No/Low impact on data traffic (packet loss, re-ordering) when
policies are updated - DPNs may request/solicit policies or get
notified about initial and updated policies
5. Leveraging the mobile control plane for N6 policy control
Methods for N6 policy control consist in instructing the DPNs with
rules for traffic steering, QoS policies enforcing, etc. The
solution described in this draft is based on leveraging the mobile
control plane, in order to introduce some logic to manage and forward
policies to DPNs on N6 interface. To do this, the Application
Function (AF) defined in 5GS [TS23.501] is used as binding element in
between the cellular network control plane and the data network data
plane.
Per [TS23.501], the AF is introduced to inter-work with the Policy
Control Function (PCF) in order to condition and contribute to some
SMF decisions. This happens with the AF sending specific requests to
the PCF and the latter translating those requests in policies for the
SMF. Depending on the domain in which the AF is located, a Network
Exposure Function (NEF) may be in between to enable the AF
collaborating with the other control plane elements of the cellular
architecture.
In support of the proposed scenario, the AF can solicit data plane
policies from the cellular control plane by sending a request. At
reception of the policies, the AF can pass the policies on for
Fattore & Liebsch Expires March 24, 2019 [Page 9]
Internet-Draft CPDP for N6 Traffic Steering September 2018
further processing and enfocement in the data network's AS/DPN. In
this way, DPNs receive from the control plane policies for the user
traffic traversing them. The AF may be co-located with a control
function, which utilizes the DMM WG's Forwarding Policy Configuration
(FPC) protocol to implement policies in the AS/DPN, or leverage an
SDN controller for the selection and configuration of AS/DPN.
The policies defined and forwarded by the AF are based on the status
of the mobile network, which the AF can obtain from the SMF. In any
moment, in fact, the SMF is in charge of keeping track of the
selected UPFs and of monitoring the user session. Based on this
information, the AF forwards specific rules to a DPN (e.g., traffic
steering rules to make the user's traffic reach the most suitable
UPF_a). In some cases (e.g., user mobility), the SMF can also change
UPFs for a specific user and in this case the AF will receive updated
policies for enforcement in the involved AS/DPN.
Figure 4 shows how the previous architecture evolves with the
introduction of the AF.
communication between control plane functions
- - +----------------+---------------+ - -
| | |
+--+--+ +-----+ +------+__ _ _ _ _ _ _ _
| AMF | | SMF | | AF |_ |
+-----+ +-----+ +------+ | |
/N2 N4| |N4 | N6 policy |
/ +-----+ +--+ | _________ |
/ | | |/ \ |
+----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +---+--+ Data \ |
| UE |----+ RAN +=====+ UPF_i +======+ UPF_a +---/---+DPN|AS| Network | |
+----+ +-----+ +---+---+ +-------+ IP +---+--+ 1 / |
IP_ue | proxy IP_ue \_________/ |
| _________ |
| / \ |
+---+---+ N6 +---+--+ Data \ |
proxy| UPF_a +--------/--+DPN|AS| Network | |
IP_ue+-------+ IP +---+--+ 2 / |
|\_________/ |
|__ _ _ _ _ _ _ _ _ _ _ _|
N6 policy
Figure 4: Using AF in control plane for traffic policy enforcement
Fattore & Liebsch Expires March 24, 2019 [Page 10]
Internet-Draft CPDP for N6 Traffic Steering September 2018
6. IANA Considerations
No IANA action is required for this version of the draft.
7. Security Considerations
Since the solution proposed in this document utilizes the AF to
solicit and receive N6 traffic treatment policies from the cellular
system's control plane, the trust relationship between the AF and the
cellular system's domain matters. In case the AF is located in a
different administrative domain, the communication from and to the AF
may happen via the system's Network Exposure Functions (NEF). The
semantic to request and receive the N6 policy at the AF and in
particular the policy types and their descriptions must be aligned to
the trust relationship.
Also, the trust relationship between the AF and the DPN/AS matters
and a secure direct or indirect (e.g. through an Network Controller)
interface, must be ensured.
8. Acknowledgments
The research leading to these results has been partially supported by
the H2020-MSCA-ITN-2016 framework under grant agreement number 722788
(SPOTLIGHT).
Authors want to thank Sri Gundavelli, John Kaippallimalil and
Shunsuke Homma for their interest and feedback to the use cases and
the solution principles for N6 traffic treatment policies.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[I-D.hmm-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d.
daniel.voyer@bell.ca, "User Plane Protocol and
Architectural Analysis on 3GPP 5G System", draft-hmm-dmm-
5g-uplane-analysis-01 (work in progress), August 2018.
[I-D.gundavelli-dmm-mfa]
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
(work in progress), September 2018.
Fattore & Liebsch Expires March 24, 2019 [Page 11]
Internet-Draft CPDP for N6 Traffic Steering September 2018
[I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
Muscariello, L., Camarillo, P., and S. Homma, "Optimized
Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
optimized-mobile-user-plane-01 (work in progress), June
2018.
[TS23.501]
3rd Generation Partnership Project (3GPP), "Technical
Specification TS23.501, System Architecture for the 5G
System, Release 15.", 3GPPTS 23.501, June 2018.
Authors' Addresses
Umberto Fattore
NEC Laboratories Europe GmbH
Kurfuersten-Anlage 36
D-69115 Heidelberg
Germany
Email: umberto.fattore@neclab.eu
Marco Liebsch
NEC Laboratories Europe GmbH
Kurfuersten-Anlage 36
D-69115 Heidelberg
Germany
Email: marco.liebsch@neclab.eu
Fattore & Liebsch Expires March 24, 2019 [Page 12]