Internet DRAFT - draft-fattore-dmm-n6-cpdp-trafficsteering

draft-fattore-dmm-n6-cpdp-trafficsteering







Distributed Mobility Management (DMM)                         U. Fattore
Internet-Draft                                                M. Liebsch
Intended status: Standards Track                                     NEC
Expires: September 12, 2019                               March 11, 2019


          Control-/Data Plane Aspects for N6 Traffic Steering
            draft-fattore-dmm-n6-cpdp-trafficsteering-01.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 September 12, 2019.




Fattore & Liebsch      Expires September 12, 2019               [Page 1]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


Copyright Notice

   Copyright (c) 2019 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.  N6 endpoints - loose and tight coupling options . . . . . . .  11
   7.  Operations for N6 policy enforcement in a tight coupling
       scenario  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  AF/NC-initiated N6 policy enforcement . . . . . . . . . .  14
     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

   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



Fattore & Liebsch      Expires September 12, 2019               [Page 2]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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



Fattore & Liebsch      Expires September 12, 2019               [Page 3]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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.

   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



Fattore & Liebsch      Expires September 12, 2019               [Page 4]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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

   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 September 12, 2019               [Page 5]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


         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 September 12, 2019               [Page 6]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


          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 September 12, 2019               [Page 7]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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 September 12, 2019               [Page 8]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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 E 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 September 12, 2019               [Page 9]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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 September 12, 2019              [Page 10]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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.





Fattore & Liebsch      Expires September 12, 2019              [Page 11]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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



Fattore & Liebsch      Expires September 12, 2019              [Page 12]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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.




Fattore & Liebsch      Expires September 12, 2019              [Page 13]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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:



Fattore & Liebsch      Expires September 12, 2019              [Page 14]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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




Fattore & Liebsch      Expires September 12, 2019              [Page 15]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   (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:



Fattore & Liebsch      Expires September 12, 2019              [Page 16]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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.











Fattore & Liebsch      Expires September 12, 2019              [Page 17]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


             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.











Fattore & Liebsch      Expires September 12, 2019              [Page 18]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


             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,



Fattore & Liebsch      Expires September 12, 2019              [Page 19]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


   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.

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

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

11.  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-02 (work in progress), October 2018.



Fattore & Liebsch      Expires September 12, 2019              [Page 20]

Internet-Draft        CPDP for N6 Traffic Steering            March 2019


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

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

   [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]
              3rd Generation Partnership Project (3GPP), "Technical
              Specification TS23.501, System Architecture for the 5G
              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

   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 September 12, 2019              [Page 21]