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