< draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt   draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt >
Distributed Mobility Management (DMM) U. Fattore Distributed Mobility Management (DMM) U. Fattore
Internet-Draft M. Liebsch Internet-Draft M. Liebsch
Intended status: Standards Track NEC Intended status: Standards Track NEC
Expires: March 24, 2019 September 20, 2018 Expires: September 12, 2019 March 11, 2019
Control-/Data Plane Aspects for N6 Traffic Steering Control-/Data Plane Aspects for N6 Traffic Steering
draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt
Abstract Abstract
Current standardization effort on the evolution of the mobile Current standardization effort on the evolution of the mobile
communication system reconsiders the mobile data plane protocol. The communication system reconsiders the mobile data plane protocol. The
IETF DMM Working Group has work that proposes and analyzes various IETF DMM Working Group has work that proposes and analyzes various
protocols as alternative to the GPRS Tunneling Protocol for User protocols as alternative to the GPRS Tunneling Protocol for User
Plane (GTP-U) for an overlay deployment in between the mobile Plane (GTP-U) for an overlay deployment in between the mobile
device's assigned data plane anchor and its current radio base device's assigned data plane anchor and its current radio base
station, which are denoted as N9 and N3 interfaces. In the view of station, which are denoted as N9 and N3 interfaces. In the view of
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Positioning of N6 policy control . . . . . . . . . . . . . . 4 3. Positioning of N6 policy control . . . . . . . . . . . . . . 4
3.1. System architecture for mobile access to data networks . 4 3.1. System architecture for mobile access to data networks . 4
3.2. Use cases with demand for N6 traffic treatment policy . . 7 3.2. Use cases with demand for N6 traffic treatment policy . . 7
4. N6 traffic treatment - Requirements and policy types . . . . 8 4. N6 traffic treatment - Requirements and policy types . . . . 8
5. Leveraging the mobile control plane for N6 policy control . . 9 5. Leveraging the mobile control plane for N6 policy control . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. N6 endpoints - loose and tight coupling options . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Operations for N6 policy enforcement in a tight coupling
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 11 7.1. AF/NC-initiated N6 policy enforcement . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. 3GPP-initiated N6 policy enforcement . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
Recent releases and deployments of cellular mobile communication Recent releases and deployments of cellular mobile communication
skipping to change at page 7, line 5 skipping to change at page 7, line 5
should have means to receive traffic treatment policies. should have means to receive traffic treatment policies.
A way to enforce N6 policies to the DPN/AS in a data network is 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 needed. It is evident that this rule must originate from the
cellular control plane due to its knowledge about the UE's states, 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- such as its locator or QoS, and when these states are updated or re-
configured. Different means to convey and enforce associated traffic configured. Different means to convey and enforce associated traffic
treatment policies in a DPN/AS exist, such as the use of routing treatment policies in a DPN/AS exist, such as the use of routing
protocols or control-/data plane configuration protocols. protocols or control-/data plane configuration protocols.
communication between control plane functions communication between control plane functions
- - +-------------------+ - - - - +-------------------+ - -
| | | |
+--+--+ +-----+ +--+--+ +-----+
| AMF | | SMF | | AMF | | SMF |
+-----+ +-----+ +-----+ +-----+
/N2 N4| |N4 N6 policy /N2 N4| |N4 N6 policy
/ +-------+ +--+ | __________ / +-------+ +--+ | __________
/ | | v/ \ / | | v/ \
+----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +------+ data \ +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +------+ data \
| UE |-----+ RAN +======+ UPF_i +======+ UPF_a +--/----+DPN|AS| network | | UE |-----+ RAN +======+ UPF_i +======+ UPF_a +--/---+DPN|AS| network|
+----+ +-----+ +---+---+ +-------+ IP +------+ 1 / +----+ +-----+ +---+---+ +-------+ IP +------+ 1 /
IP_ue +---+---+ proxy IP_ue \__________/ IP_ue +---+---+ proxy IP_ue \__________/
proxy| UPF_a | proxy| UPF_a |
IP_ue+-------+ ___________ IP_ue+-------+ ___________
| / \ | / \
| N6 +------+ data \ | N6 +------+ data \
+-------/----+DPN|AS| network | +-------/----+DPN|AS| network |
IP +------+ 2 / IP +------+ 2 /
^ \___________/_ ^ \___________/
| |
N6 policy N6 policy
Figure 3: Data network DPN/AS as traffic treatment policy enforcement Figure 3: Data network DPN/AS as traffic treatment policy enforcement
point point
3.2. Use cases with demand for N6 traffic treatment policy 3.2. Use cases with demand for N6 traffic treatment policy
The motivations behind the need for N6 treatment policy are many. The motivations behind the need for N6 treatment policy are many.
Following, some of the use cases are listed and described. Following, some of the use cases are listed and described.
UE to UE communication: a scenario which is not explicitly shown in UE to UE communication: a scenario which is not explicitly shown in
skipping to change at page 9, line 5 skipping to change at page 9, line 5
UPFs, e.g. by relocating the UPF_a or a UPF_i while maintaining the 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 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, such case, a DPN associated with the one or multiple data networks,
which run correspondent services for the UE, must enforce traffic which run correspondent services for the UE, must enforce traffic
steering policies to downlink traffic to achieve routing of downlink steering policies to downlink traffic to achieve routing of downlink
traffic to the UE's current UPF_a or UPF_i respectively. traffic to the UE's current UPF_a or UPF_i respectively.
In summary, traffic treatment policies that apply to a UE's uplink In summary, traffic treatment policies that apply to a UE's uplink
and downlink traffic on N6 include the following types: and downlink traffic on N6 include the following types:
o QoS differentiation and traffic engineering o QoS differentiation and traffic engineering"
o Packet label push/pop o Packet label push/pop"
o Metering o Metering
o Traffic steering (e.g. SRv6 rules, locator re-write rules, etc.) o Traffic steering (e.g. SRv6 rules, locator re-write rules, etc.)
o UE dormancy monitoring rules to initiate paging o E dormancy monitoring rules to initiate paging
Requirements for N6 traffic treatment include the following: Requirements for N6 traffic treatment include the following:
o Awareness of UE location information (first hop router accuracy, o Awareness of UE location information (first hop router accuracy,
UPF_a/UPF_i) - Set or update DPN policy for traffic steering UPF_a/UPF_i) - Set or update DPN policy for traffic steering
o Awareness of topology - Select and update most suitable UPF (UPF_a/ 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 UPF_i) for the communication with a data network, e.g. after UPF
changed changed
o Availability of initial or updated policies when needed o Availability of initial or updated policies when needed
o No/Low impact on data traffic (packet loss, re-ordering) when o No/Low impact on data traffic (packet loss, re-ordering) when
policies are updated - DPNs may request/solicit policies or get policies are updated - DPNs may request/solicit policies or get
notified about initial and updated policies notified about initial and updated policies
5. Leveraging the mobile control plane for N6 policy control 5. Leveraging the mobile control plane for N6 policy control
Methods for N6 policy control consist in instructing the DPNs with Methods for N6 policy control consist in instructing the DPNs with
rules for traffic steering, QoS policies enforcing, etc. The rules for traffic steering, QoS policies enforcing, etc. The
solution described in this draft is based on leveraging the mobile solution described in this draft is based on leveraging the mobile
control plane, in order to introduce some logic to manage and forward control plane, in order to introduce some logic to manage and forward
policies to DPNs on N6 interface. To do this, the Application policies to DPNs on N6 interface. To do this, the Application
Function (AF) defined in 5GS [TS23.501] is used as binding element in Function (AF) defined in 5GS [TS23.501] is used as binding element in
between the cellular network control plane and the data network data between the cellular network control plane and the data network data
skipping to change at page 10, line 24 skipping to change at page 10, line 24
selected UPFs and of monitoring the user session. Based on this selected UPFs and of monitoring the user session. Based on this
information, the AF forwards specific rules to a DPN (e.g., traffic information, the AF forwards specific rules to a DPN (e.g., traffic
steering rules to make the user's traffic reach the most suitable 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 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 UPFs for a specific user and in this case the AF will receive updated
policies for enforcement in the involved AS/DPN. policies for enforcement in the involved AS/DPN.
Figure 4 shows how the previous architecture evolves with the Figure 4 shows how the previous architecture evolves with the
introduction of the AF. introduction of the AF.
communication between control plane functions communication between control plane functions
- - +----------------+---------------+ - - - - +----------------+---------------+ - -
| | | | | |
+--+--+ +-----+ +------+__ _ _ _ _ _ _ _ +--+--+ +-----+ +------+_ _ _ _ _ _ _ _
| AMF | | SMF | | AF |_ | | AMF | | SMF | | AF |_ |
+-----+ +-----+ +------+ | | +-----+ +-----+ +------+ | |
/N2 N4| |N4 | N6 policy | /N2 N4| |N4 | N6 policy |
/ +-----+ +--+ | _________ | / +-----+ +--+ | ________ |
/ | | |/ \ | / | | |/ \ |
+----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +---+--+ Data \ | +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +---+--+ Data \ |
| UE |----+ RAN +=====+ UPF_i +======+ UPF_a +---/---+DPN|AS| Network | | | UE |---+ RAN +=====+ UPF_i +======+ UPF_a +---/---+DPN|AS|Network | |
+----+ +-----+ +---+---+ +-------+ IP +---+--+ 1 / | +----+ +-----+ +---+---+ +-------+ IP +---+--+ 1 / |
IP_ue | proxy IP_ue \_________/ | IP_ue | proxy IP_ue \________/ |
| _________ | | _________ |
| / \ | | / \ |
+---+---+ N6 +---+--+ Data \ | +---+---+ N6 +---+--+ Data \ |
proxy| UPF_a +--------/--+DPN|AS| Network | | proxy| UPF_a +--------/--+DPN|AS|Network | |
IP_ue+-------+ IP +---+--+ 2 / | IP_ue+-------+ IP +---+--+ 2 / |
|\_________/ | |\_________/ |
|__ _ _ _ _ _ _ _ _ _ _ _| |_ _ _ _ _ _ _ _ _ _ _ _|
N6 policy N6 policy
Figure 4: Using AF in control plane for traffic policy enforcement Figure 4: Using AF in control plane for traffic policy enforcement
6. IANA Considerations 6. N6 endpoints - loose and tight coupling options
As described in the previous section, we take advantage of the
Application Function (AF) to bind the 3GPP's domain functions with
those introduced in this draft for N6 policy enforcement. According
to [TS23.501], an Application Function may send requests to influence
SMF decisions for User Plane (UP) traffic of PDU Sessions (e.g.,
based on the relocation of an application on the Data Network side,
the AF can notify this to the SMF in order to trigger a relocation of
UPF(s) from the SMF, to choose a new UPF more suitable for the new
Data Network).
In addition, the AF can subscribe to events from the SMF in order to
receive notification about UP management events (e.g., when a PDU
Session anchor has been established or released).
As defined in [TS23.502], the AF interacts with the PCF/SMF via the
NEF or directly and the PCF then forwards requests from the AF
towards the SMF as Session Management (SM) Policies. For the sake of
simplicity, in this section all the 3GPP's functions apart from the
AF are collected under the name of "3GPP's C-PLANE", and the specific
service to which the AF interacts in the 3GPP C-PLANE is not relevant
for this draft.
In order to forward specific policies to the Data Plane Nodes/
Application Servers (DPNs/ASs) associated with each Data Network, a
Network Controller (NC) is considered to be co-located with the AF
element. The NC performs the selection of a DPN/AS element based on
the received information from the C-PLANE. The AF/NC forwards
control messages to a DPN/AS through an AFNC-CPUP interface, giving
indications to steer the downlink traffic properly and coherently
with the UP updates from the 3GPP's side.
Forwarding N6 polices to the N6 endpoints involved (i.e., UPF and
DPN) can happen in two different ways:
1) Tight coupling scenario: The UPF can enforce policies per the
AF/NC decisions. The UPF receives associated policies from the
3GPP's C-PLANE. The corresponding DPN/AS receives the policy
via teh AFNC-CPUP interface.
2) Loose coupling scenario: A separate DPN function is co-located
with the UPF. Main policies for N6 traffic treatment do not
traverse the 3GPP's C-PLANE but are controlled at both N6
interface endpoints' DPN by the AF/NC via the AFNC-CPUP
interface.
In the tight coupling scenario, the N6 interface configurations for
the UPF are all enforced though the 3GPP domain. Therefore, the
3GPP's C-PLANE interacts with the AF/NC element through the AFNC_3GPP
interface and receives on this interface requests to influence the UP
traffic policies. 3GPP decides if enforce those policies on the
UPF(s) involved.
The architecture and interfaces involved in this tight coupling
scenario are depicted in Figure 5.
+-------------------+ AFNC_3GPP+--------+
+-+ 3GPP's C-PLANE +----------+ AF/NC +_ _ _ _ _ _
| +-------------------+ +-+------+ |
| | | |
|N2 |N4 |AFNC_CPUP |
| | | __________ |
| | |/ \ |
+----+ +-----+ N3 +--+----+ N6 +---+--+ Data \ |
| UE |-----+ RAN +===/====+ UPF +-----/----+DPN|AS| Network | |
+----+ +-----+ +---+---+ +---+--+ 1 / |
IP_ue | \__________/ |
| _________ |
| / \ |
| N6 +---+--+ Data \ |
+------/----+DPN|AS| Network | |
+---+--+ 2 / |
|\_________/ |
|__ _ _ _ _ _ _ _ _ _|
AFNC_CPUP
Figure 5: N6 endpoints tight coupling scenario
In Section 7.1 the operation flow and information model for the
messages exchanged in this type of coupling are presented and
described. Both the cases of a AF/NC-initiated and 3GPP-initiated
message flow are considered.
In the loose coupling scenario, an additional DPN element is
associated with a UPF and represents a key element to enforce N6
traffic treatment policies on the UPF-side of the N6 interface. This
DPN is controlled by the AF/NC through the AFNC_CPUP interface, as
depicted in Figure 6.
Loose coupling allows reducing 3GPP's role in the N6 endpoint
management, potentially allowing under certain assumptions (e.g., no
UPF re-selection is needed), an optimized control of the N6 interface
from the AF/NC element, transparently from 3GPP's domain. This kind
of scenario results as an advantage particularly for use cases in
which the UPF is deployed in the proximity of the Data Network and
far from the 3GPP's C-PLANE (i.e., in a Mobile Edge Computing - MEC -
alike scenario).
For particular cases which request 3GPP's C-PLANE involvement (i.e.,
UPF re-selection or other changes not related to the only N6
endpoint) the AFNC_3GPP is still used for notifications and requests
between the AF/NC and the 3GPP's C-PLANE.
+-------------------+ AFNC_3GPP+--------+
+-+ 3GPP's C-PLANE +----------+ AF/NC +__________
| +-------------------+ +-+------+ |
| | _ _ _ _/ | |
|N2 |N4 / |AFNC_CPUP |
| | AFNC_CPUP | __________ |
| | / |/ \ |
+----+ +-----+ N3 +--+--+--+--+ N6 +--+---+ Data \ |
| UE |-----+ RAN +===/====+ UPF | DPN +---/---+DPN|AS| Network | |
+----+ +-----+ +---+-+-----+ +--+---+ 1 / |
IP_ue | \__________/ |
| _________ |
| / \ |
| N6 +---+--+ Data \ |
+------/----+DPN|AS| Network | |
+---+--+ 2 / |
|\_________/ |
|__ _ _ _ _ _ _ _ _ |
AFNC_CPUP
Figure 6: N6 endpoints loose coupling scenario
7. Operations for N6 policy enforcement in a tight coupling scenario
In the following sub-sections, message sequences are shown assuming a
tight coupling scenario between N6 interface endpoints, as depicted
in Figure 5. Two different operation flows can be distinguished,
based on the entity initiating and requesting for the N6 policy.
Section 7.1 describes the message sequence in the case of AF/NC-
initiated N6 policy request, while Section 7.2 covers the alternative
case in which the request for a N6 policy is initiated from the
3GPP's C-PLANE.
In the message sequences, special attention is given to the AFNC_CPUP
and AFNC_3GPP interfaces defined in this draft and Information Models
for messages exchanged on those interfaces are provided.
7.1. AF/NC-initiated N6 policy enforcement
A N6 policy can be triggered from the AF/NC element and is then
forwarded directly to the DPN N6 endpoint (through AFNC_CPUP
interface) and indirectly to the UPF N6 endpoint (through AFNC_3GPP
interface).
As example, the AF/NC may request updated n6 policies for the
following reasons:
o there is the need of a different QoS to be applied to traffic,
which is identified in the request.
o there is the need for a re-location of the application to a
different Data Network and therefore changes for traffic in uplink
on the UPF's N6 endpoint should be applied.
Figure 7 depicts the AF/NC-initiaed N6 policy enforcement message
sequence.
+--------+
+-------+ +--------+ | +-------+ +--------+
|C-PLANE| | UPF(s) |-+ | AF/NC | | DPN/AS |
+---+---+ +--+-----+ +---+---+ +---+----+
| | | |
| | | |
|<-----(1)TRAFFIC------------| |
| INFLUENCE REQUEST | |
| | | |
|---(2a)---->| | |
|<----(2b)---| | |
| N4 SESSION EST/MOD/REL | |
| | | |
| | | |
|------(3)TRAFFIC----------->| |
| INFLUENCE RESPONSE | |
| | | |
| | |---(4a)---->|
| | |<---(4b)----|
| | | AFNC_CPUP |
| | | CONFIGURATION
| | | |
Figure 7: Message flow for AF/NC-initiated N6 policy enforcement
Following, a description for each message is given:
(1) TRAFFIC INFLUENCE REQUEST: this message is sent from the AF/NC to
the 3GPP's C-PLANE in order to request a modification for UP traffic.
The message contains the fields listed in Table 1.
Information model for TRAFFIC INFLUENCE REQUEST message
+------------+---------------------------+--------------------------+
| Message | Description | Notes |
| Fields | | |
+------------+---------------------------+--------------------------+
| Request ID | Identifies the current | - |
| | request in order to match | |
| | it with following | |
| | response messages. | |
| | | |
| Traffic | Identifies the UP traffic | 3GPP's identifiers |
| Identifier | which is targeted by the | defined in [TS23.501] |
| | request. Traffic may be | may be used to identify |
| | identified based on the | traffic (e.g., DNN for |
| | session, UE-based or even | traffic toward a |
| | slice-based (i.e., | specific Data Network, |
| | addressing all the | NSSAI for a specific |
| | traffic belonging to a | slice, UE GUTI for a |
| | specific network slice). | specific user, etc.) |
| | | |
| QoS | Contains the QoS | - |
| parameters | parameters for the | |
| | targeted traffic | |
| | | |
| DPN N6 | Brings information about | - |
| endpoint | the N6 endpoint on the | |
| | Data Network side. | |
+------------+---------------------------+--------------------------+
Table 1
Based on the N6 endpoint information, the 3GPP's C-PLANE may take
decisions on UPF(s) selection and re-location. For instance, this
field could carry a Data Network Access ID (DNAI), identifying a
specific Data Network on which the 3GPP's domain could select the
best matching UPF (e.g., based on proximity).
(2a)(2b) N4 SESSION ESTABLISHMENT/MODIFICATION/RELEASE: this are
3GPP's messages defined in [TS23.502] and used to enforce changing to
one or more UPF or to select and configure a new UPF. Through this
messages, the N6 policies requested from the AF/NC can be enforced to
the UPF(s).
(3) TRAFFIC INFLUENCE RESPONSE: this message is sent from the 3GPP's
C-PLANE to the AF/NC in order to acknowledge the UP changes made
based on the previous request message. The message contains the
fields listed in Table 2.
Information model for TRAFFIC INFLUENCE RESPONSE message
+------------+-----------------------------------+------------------+
| Message | Description | Notes |
| Fields | | |
+------------+-----------------------------------+------------------+
| Request ID | Identifies the request message to | - |
| | which this response is referred | |
| | to. | |
| | | |
| Traffic | Identifies the UP traffic which | Traffic actually |
| Identifier | is targeted by the request. | influenced could |
| | Traffic may be identified based | differ from the |
| | on the session, UE-based or even | original traffic |
| | slice-based (i.e., addressing all | targeted in the |
| | the traffic belonging to a | request. |
| | specific network slice). | |
| | | |
| UPF N6 | Brings information about the N6 | - |
| endpoint | endpoint on the 3GPP's side. | |
+------------+-----------------------------------+------------------+
Table 2
N6 endpoint information on 3GPP's side (e.g., IP address of the N6
endpoint UPF) are used from the AF/NC to set the DPN(s) in order to
properly route downlink traffic.
(4a)(4b) AFNC_CPUP CONFIGURATION: This message is used to instruct
the DPN(s) involved in the UP changes. For instance, in case of UPF
re-selection and UPF's N6 endpoint (e.g., IP address) changing,
traffic steering rules for downlink traffic need to be enforced to
the DPN. The structure of this message is out of the scope of this
draft and candidates for managing this interface are already present
(e.g., Forwarding Policy Configuration (FPC) defined in [FPC]).
7.2. 3GPP-initiated N6 policy enforcement
A N6 policy can be triggered by the 3GPP domain. In this case, an
initial subscription mechanism is needed, in which one or multiple AF
subscribe the 3GPP's C-PLANE in order to receive notification about
the subscribed events. Some of the events, of which a AF/NC could be
interested in, are:
o re-selection one or multiple UPF(s) from the 3GPP's C-PLANE.
o changes in the UP traffic QoS parameters.
o etc.
Figure 8 depicts the message sequence described the AF subscription
and a notification from the 3GPP's domain when the specific event
occurs.
+--------+
+-------+ +--------+ | +-------+ +--------+
|C-PLANE| | UPF(s) |-+ | AF/NC | | DPN/AS |
+---+---+ +--+-----+ +---+---+ +---+----+
| | | |
|<-----(0)EVENT--------------| |
_|_ SUBSCRIPTION | |
|___| | | |
event | | |
| | | |
|------(1)EVENT ------------>| |
| NOTIFICATION | |
| | |----(2a)--->|
| | |<---(2b)----|
| | | AFNC_CPUP |
| | | CONFIGURATION
| | | |
Figure 8: Message flow for 3GPP-initiated N6 policy enforcement
The messages used are here described:
(0) EVENT SUBSCRIPTION: this message is sent from the AF/NC to the
3GPP's C-PLANE in order for the AF/NC to subscribe to some specific
UP events. When received from the 3GPP's C-PLANE, all future UP
events (e.g., UPF re-selection, changing in UP traffic parameters)
which match with the subscription will be notified to the AF/NC.
This message fields are listed in Table 3.
Information model for EVENT SUBSCRIPTION message
+--------------+---------------------------+--------------------------+
| Message | Description | Notes |
| Fields | | |
+--------------+---------------------------+--------------------------+
| Subscription | Identifies the | - |
| ID | subscription in order to | |
| | then match the resulting | |
| | notification. | |
| | | |
| Event | Identifies the type of | Can be 'all-events' or |
| | event to which the | identify a specific type |
| | subscription is referred. | of event. |
| | For instance, the | |
| | subscription could refer | |
| | only to an UPF re- | |
| | selection event, or may | |
| | refer to any event for | |
| | the targeted traffic. | |
| | | |
| Traffic | Identifies the UP traffic | 3GPP's identifiers |
| Identifier | which is targeted by the | defined in [TS23.501] |
| | request. Traffic may be | may be used to identify |
| | identified based on the | traffic (e.g., DNN for |
| | session, UE-based or even | traffic toward a |
| | slice-based (i.e., | specific Data Network, |
| | addressing all the | NSSAI for a specific |
| | traffic belonging to a | slice, UE IP address for |
| | specific network slice). | a specific user, etc.) |
+--------------+---------------------------+--------------------------+
Table 3
(1) EVENT NOTIFICATION: this message is sent from the 3GPP's C-PLANE
to the AF/NC, triggered by the subscribed event for the targeted
traffic. If no subscription for the specific traffic and event was
received before the modification occurs the 3GPP's C-PLANE will not
provide any notification for the UP traffic changes. Table 4 lists
the field contained in the message.
Information model for EVENT NOTIFICATION message
+--------------+--------------+-------------------------------------+
| Message | Description | Notes |
| Fields | | |
+--------------+--------------+-------------------------------------+
| Subscription | Identifies | - |
| ID | the | |
| | subscription | |
| | message to | |
| | which this | |
| | notification | |
| | is referred | |
| | to. | |
| | | |
| Traffic | Identifies | Even if there is no notification |
| Identifier | the UP | for traffic which has not been |
| | traffic | targeted through a subscription, |
| | which has | this field may refer to a subset of |
| | been change. | the traffic targeted in the |
| | | subscription (e.g., subscription to |
| | | a specific user traffic and |
| | | modification of only one PDU |
| | | sessions for that user). |
| | | |
| QoS | Brings | - |
| parameters | information | |
| | about QoS | |
| | parameters | |
| | which have | |
| | been | |
| | changed. | |
| | | |
| UPF N6 | Brings | - |
| endpoint | information | |
| | about the N6 | |
| | endpoint on | |
| | the 3GPP's | |
| | side which | |
| | have been | |
| | changed. | |
+--------------+--------------+-------------------------------------+
Table 4
(2a)(2b) AFNC_CPUP CONFIGURATION: This message is used to instruct
the DPN(s) involved in the UP changes. For instance, in case of UPF
re-selection and UPF's N6 endpoint (e.g., IP address) changing,
traffic steering rules for downlink traffic need to be enforced to
the DPN. The structure of this message is anyway out of the scope of
this draft and candidates for managing this interface are already
present (e.g., Forwarding Polciy Configuration (FPC) defined in
[FPC]).
8. IANA Considerations
No IANA action is required for this version of the draft. No IANA action is required for this version of the draft.
7. Security Considerations 9. Security Considerations
Since the solution proposed in this document utilizes the AF to Since the solution proposed in this document utilizes the AF to
solicit and receive N6 traffic treatment policies from the cellular solicit and receive N6 traffic treatment policies from the cellular
system's control plane, the trust relationship between the AF and the 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 cellular system's domain matters. In case the AF is located in a
different administrative domain, the communication from and to the AF different administrative domain, the communication from and to the AF
may happen via the system's Network Exposure Functions (NEF). The may happen via the system's Network Exposure Functions (NEF). The
semantic to request and receive the N6 policy at the AF and in semantic to request and receive the N6 policy at the AF and in
particular the policy types and their descriptions must be aligned to particular the policy types and their descriptions must be aligned to
the trust relationship. the trust relationship.
Also, the trust relationship between the AF and the DPN/AS matters Also, the trust relationship between the AF and the DPN/AS matters
and a secure direct or indirect (e.g. through an Network Controller) and a secure direct or indirect (e.g. through an Network Controller)
interface, must be ensured. interface, must be ensured.
8. Acknowledgments 10. Acknowledgments
The research leading to these results has been partially supported by The research leading to these results has been partially supported by
the H2020-MSCA-ITN-2016 framework under grant agreement number 722788 the H2020-MSCA-ITN-2016 framework under grant agreement number 722788
(SPOTLIGHT). (SPOTLIGHT).
Authors want to thank Sri Gundavelli, John Kaippallimalil and Authors want to thank Sri Gundavelli, John Kaippallimalil and
Shunsuke Homma for their interest and feedback to the use cases and Shunsuke Homma for their interest and feedback to the use cases and
the solution principles for N6 traffic treatment policies. the solution principles for N6 traffic treatment policies.
9. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[I-D.hmm-dmm-5g-uplane-analysis] [I-D.hmm-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d. Homma, S., Miyasaka, T., Matsushima, S., and d.
daniel.voyer@bell.ca, "User Plane Protocol and daniel.voyer@bell.ca, "User Plane Protocol and
Architectural Analysis on 3GPP 5G System", draft-hmm-dmm- Architectural Analysis on 3GPP 5G System", draft-hmm-dmm-
5g-uplane-analysis-01 (work in progress), August 2018. 5g-uplane-analysis-02 (work in progress), October 2018.
[I-D.gundavelli-dmm-mfa] [I-D.gundavelli-dmm-mfa]
Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
(work in progress), September 2018. (work in progress), September 2018.
[I-D.bogineni-dmm-optimized-mobile-user-plane] [I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
Rodriguez-Natal, A., Carofiglio, G., Auge, J., Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
Muscariello, L., Camarillo, P., and S. Homma, "Optimized Muscariello, L., Camarillo, P., and S. Homma, "Optimized
Mobile User Plane Solutions for 5G", draft-bogineni-dmm- Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
optimized-mobile-user-plane-01 (work in progress), June optimized-mobile-user-plane-01 (work in progress), June
2018. 2018.
[FPC] S.Matsushima, L.Bertz, M.Liebsch, S.Gundavelli, D.Moses,
C. Perkins, "Protocol for Forwarding Policy Configuration
(FPC) in DMM.", 3GPPTS 23.501, June 2018.
[TS23.501] [TS23.501]
3rd Generation Partnership Project (3GPP), "Technical 3rd Generation Partnership Project (3GPP), "Technical
Specification TS23.501, System Architecture for the 5G Specification TS23.501, System Architecture for the 5G
System, Release 15.", 3GPPTS 23.501, June 2018. System, Release 15.", 3GPPTS 23.501, June 2018.
[TS23.502]
3rd Generation Partnership Project (3GPP), "Technical
Specification TS23.502, Procedure for the 5G System,
Release 15.", 3GPPTS 23.502, June 2018.
Authors' Addresses Authors' Addresses
Umberto Fattore Umberto Fattore
NEC Laboratories Europe GmbH NEC Laboratories Europe GmbH
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
D-69115 Heidelberg D-69115 Heidelberg
Germany Germany
Email: umberto.fattore@neclab.eu Email: umberto.fattore@neclab.eu
 End of changes. 21 change blocks. 
62 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/