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