idnits 2.17.1 draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-hmm-dmm-5g-uplane-analysis (ref. 'I-D.hmm-dmm-5g-uplane-analysis') ** Downref: Normative reference to an Informational draft: draft-bogineni-dmm-optimized-mobile-user-plane (ref. 'I-D.bogineni-dmm-optimized-mobile-user-plane') -- Possible downref: Non-RFC (?) normative reference: ref. 'FPC' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management (DMM) U. Fattore 3 Internet-Draft M. Liebsch 4 Intended status: Standards Track NEC 5 Expires: September 12, 2019 March 11, 2019 7 Control-/Data Plane Aspects for N6 Traffic Steering 8 draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt 10 Abstract 12 Current standardization effort on the evolution of the mobile 13 communication system reconsiders the mobile data plane protocol. The 14 IETF DMM Working Group has work that proposes and analyzes various 15 protocols as alternative to the GPRS Tunneling Protocol for User 16 Plane (GTP-U) for an overlay deployment in between the mobile 17 device's assigned data plane anchor and its current radio base 18 station, which are denoted as N9 and N3 interfaces. In the view of 19 some future deployment and the original intent per the very early DMM 20 WG charter, a mobile device's data plane anchor may be highly 21 distributed and re-selected for optimization throughout a mobile 22 device's communication with one or more correspondent services. Such 23 re-configuration has impact on the packet routing in between the 24 mobile device's data plane anchor and the one or multiple data 25 networks hosting the services, which is denoted as N6 interface. 26 This draft proposes and discusses a solution to control, setup and 27 maintain traffic treatment policy on the cellular communication 28 system's N6 interface while taking the UE's PDU session settings per 29 the cellular system's control plane, such as QoS and locator 30 information, into account. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 12, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 3. Positioning of N6 policy control . . . . . . . . . . . . . . 4 69 3.1. System architecture for mobile access to data networks . 4 70 3.2. Use cases with demand for N6 traffic treatment policy . . 7 71 4. N6 traffic treatment - Requirements and policy types . . . . 8 72 5. Leveraging the mobile control plane for N6 policy control . . 9 73 6. N6 endpoints - loose and tight coupling options . . . . . . . 11 74 7. Operations for N6 policy enforcement in a tight coupling 75 scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.1. AF/NC-initiated N6 policy enforcement . . . . . . . . . . 14 77 7.2. 3GPP-initiated N6 policy enforcement . . . . . . . . . . 16 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 81 11. Normative References . . . . . . . . . . . . . . . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Introduction 92 Recent releases and deployments of cellular mobile communication 93 systems utilize an overlay on the mobile data plane to forward a 94 mobile device's data packets in between the mobile device and an 95 anchor point, which serves as first hop router to the mobile device. 96 The overlay is realized by the GPRS Tunneling Protocol for user plane 97 (GTP-U), which is able to carry network-specific attributes in the 98 tunnel protocol headers. 100 The 3rd Generation Partnership Project (3GPP) is in charge of the 101 cellular mobile communication system's specification and is currently 102 finalizing a 15th release, which has fundamental changes compared to 103 previous releases. Such changes include a clean split between 104 control- and data plane functions, more flexible deployment and re- 105 configuration of data plane anchors, as well as support for local 106 data network (DN) access and multi-homing. 108 In between a mobile device's current radio base station in the radio 109 access network (RAN) and its data plane anchor, the release 15 110 specification assumes an overlay per the previous releases utilizing 111 GTP-U. The data plane anchor is denoted as User Plane Function (UPF) 112 to anchor a Packet Data Unit (PDU) Session for the mobile device. 113 This draft abbreviates the UPF, which serves a device's PDU session 114 anchor, as UPF_a. In between a UPF_a and the device's current radio 115 base station, none, one or multiple additional UPFs can be deployed 116 to classify uplink traffic in support of policy-based routing to a 117 particular DN without traversing the UPF_a. This draft denotes such 118 intermediate UPF as UPF_i. Interfaces between a DN and a mobile 119 device's UPF_a is denoted as N6, the interface between a UPF_i and 120 one or multiple UPF_a is denoted as N9, and the interface between a 121 UPF_i and a radio base station is denoted as N3. Whereas regular 122 routing of mobile devices' PDUs is assumed on N6, N9 and N3 deploy a 123 GTP-U overlay with UPF_a, UPF_i and the radio base station serving as 124 tunnel endpoints. This end-to-end architecture is depicted in 125 Figure 1. For a more detailed description of anchor and intermediate 126 UPF and associated deployment and operation, please refer to 127 [I-D.bogineni-dmm-optimized-mobile-user-plane] and the 3GPP 128 specification [TS23.501]. 130 ________ 131 mobile +-----+ N3 +-------+ N9 +-------+ N6 / data \ 132 device---+ RAN +======/==+ UPF_i +=====/====+ UPF_a +-----/--+ network | 133 +-----+ GTP-U +-------+ GTP-U +-------+ IP \________/ 134 tunnel tunnel PDUs 136 Figure 1: Architecture and interfaces of a 3GPP release 15 data plane 137 in between a data network and a mobile device. 139 In alignment with the 3GPP's current directions to study data plane 140 protocol candidates which can serve as suitable alternative to GTP-U, 141 the IETF's DMM WG has valuable ongoing individual work that analyzes 142 the GTP-U protocol and derives requirements for an alternative mobile 143 data plane protocol [I-D.hmm-dmm-5g-uplane-analysis], as well as work 144 that investigates the use of alternative protocol candidates based on 145 SRv6, ID-Locator separation, and locator re-writing in the current 146 release 15 system architecture 147 [I-D.bogineni-dmm-optimized-mobile-user-plane]. The focus of these 148 drafts is on N9 and N3. 150 In the view of optimization options on the complete end-to-end data 151 plane, [I-D.gundavelli-dmm-mfa] complements other draft and proposes 152 data plane optimization on N6. Such operation is of particular 153 interest when the mobile device's UPF_a is decentralized and deployed 154 close to the device's current radio base station. Such deployment 155 may be preferable for some services, such as edge computing and 156 access to associated edge DNs, and mitigates the role of the UPF_i 157 and N9 interfaces. In particular the selection and configuration of 158 UPF_i instances can omitted and associated signaling costs can be 159 saved. However, such deployment strengthens the expectation on IP- 160 based PDU routing on N6, as the serving DN may not be always 161 topologically close to the device and its current UPF_a. Such 162 requirements include QoS support on N6, metering support and traffic 163 steering in case the mobile device's UPF_a changes while its IP 164 address and associated sessions should continue. 166 The same requirements on N6 apply for multi-homing per [TS23.501] 167 where the mobile device's UPF_a is close to a first DN (DN1) whereas 168 a UPF_i is used to enable access to a second DN (DN2), either through 169 a secondary UPF_a close to DN2 or directly from the UPF_i, without 170 the use of a secondary UPF_a. Since services in both DNs address the 171 same IP address of the mobile device (IP_ue) to send downlink 172 traffic, both DNs' traffic need to be forwarded to the most suitable 173 (e.g. closest) UPF_a or UPF_i respectively. 175 This draft focuses on a solution to control, setup and maintain such 176 dedicated routes and additional traffic treatment policy on N6, while 177 taking the UE's PDU session settings per the cellular system's 178 control plane, such as QoS and locator information, into account. 180 3. Positioning of N6 policy control 182 This section briefly introduces the relevant mobile system 183 architecture components and interfaces, and covers some high-level 184 use cases which can benefit from data plane policy control on N6 185 interface endpoints. 187 3.1. System architecture for mobile access to data networks 189 The 3GPP's 5G system architecture introduces in the core network a 190 clear control-/user plane separation (CUPS), in order to have 191 flexible deployment of the different functions (e.g., user plane 192 nodes can scale independently from control plane elements in case of 193 user traffic growth). Again to leverage flexibility and efficiency, 194 the control plane is split in different functions, each offering a 195 specific service, in the so called Service Based Architecture (SBA). 197 Among all the control plane functions, the Session Management 198 function (SMF) takes care of the session management (session 199 establishment, modification, release), IP allocation and selection of 200 an IP anchor point for the session, as well as traffic steering in 201 between UPFs and radio base stations. In order to manage the user 202 session, the SMF collaborates with other control plane services 203 (e.g., Policy Control Function - PCF - providing policy rules for 204 traffic treatment and monitoring), in particular with the Access and 205 Mobility Management Function (AMF), which manages registration, 206 authentication and authorization and security context. One of the 207 main task of the SMF is to instruct User Plane Functions (UPFs), 208 through N4 interface. When a new session is to be created, the SMF 209 selects one or multiple UPFs for the user traffic and selects one UPF 210 as session anchor (UPF_a). UPF_a acts as a proxy for user traffic, 211 which means all traffic directed to the UE passes through the UPF 212 anchor. Beside the UPF_a, if other UPFs are present (i.e., between 213 the radio base station and the UPF_a), this are deployed as 214 classifiers for user uplink traffic. 216 In Figure 2 a simplified 5G architecture [TS23.501] is depicted, 217 showing two Data Networks (DN) to whom a user may need a connection. 218 To each Data Network a UPF_a is associated, acting as session anchor 219 and providing to the user an IP address needed for the connection. 220 UPF_a also acts as tunnel termination point, since user traffic is 221 encapsulated on both N3 and N9 interfaces, using the GPRS Tunneling 222 Protocol for User Plane (GTP-U). Whereas, on N6 interface IP PDUs 223 are routed without tunneling. 225 communication between control plane functions 226 - - +---------------------+ - - 227 | | 228 +--+--+ +-----+ 229 | AMF | | SMF | 230 +-----+ +-----+ 231 /N2 N4| |N4 232 / +------+ +------+ 233 / | | _________ 234 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 / data \ 235 | UE |-----+ RAN +=========+ UPF_i +=========+ UPF_a +----/--+ network | 236 +----+ +-----+ +---+---+ +-------+ IP \____1____/ 237 IP_ue +---+---+ proxy IP_ue 238 proxy| UPF_a | 239 IP_ue+-------+ _________ 240 | N6 / data \ 241 +-------/----+ network | 242 IP \____2____/ 244 Figure 2: Data plane with a simplified release 15 control plane 246 Data networks host Application Servers (AS), which provide a services 247 to UEs, and an internal network comprising data plane nodes (DPN), 248 such as routers and switches, to connect the services with the 249 transport network. Both, the transport network and the data 250 network's internal network build the N6 interface, which is depicted 251 in Figure 3. In order to apply traffic treatment policy to uplink 252 traffic in between a UPF and a data network, the UPF receives 253 policies via the N4 interface. For downlink traffic, the AS/DPN 254 should have means to receive traffic treatment policies. 256 A way to enforce N6 policies to the DPN/AS in a data network is 257 needed. It is evident that this rule must originate from the 258 cellular control plane due to its knowledge about the UE's states, 259 such as its locator or QoS, and when these states are updated or re- 260 configured. Different means to convey and enforce associated traffic 261 treatment policies in a DPN/AS exist, such as the use of routing 262 protocols or control-/data plane configuration protocols. 264 communication between control plane functions 265 - - +-------------------+ - - 266 | | 267 +--+--+ +-----+ 268 | AMF | | SMF | 269 +-----+ +-----+ 270 /N2 N4| |N4 N6 policy 271 / +-------+ +--+ | __________ 272 / | | v/ \ 273 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +------+ data \ 274 | UE |-----+ RAN +======+ UPF_i +======+ UPF_a +--/---+DPN|AS| network| 275 +----+ +-----+ +---+---+ +-------+ IP +------+ 1 / 276 IP_ue +---+---+ proxy IP_ue \__________/ 277 proxy| UPF_a | 278 IP_ue+-------+ ___________ 279 | / \ 280 | N6 +------+ data \ 281 +-------/----+DPN|AS| network | 282 IP +------+ 2 / 283 ^ \___________/ 284 | 285 N6 policy 287 Figure 3: Data network DPN/AS as traffic treatment policy enforcement 288 point 290 3.2. Use cases with demand for N6 traffic treatment policy 292 The motivations behind the need for N6 treatment policy are many. 293 Following, some of the use cases are listed and described. 295 UE to UE communication: a scenario which is not explicitly shown in 296 Figure 2 and Figure 3 is UE to UE communication, when a UPF_a via N6 297 interface is connected to another UPF_a (belonging to the same or to 298 another network, and controlled by the same of another SMF), with the 299 latter UPF being associated to a second UE. In this scenario, all 300 the data plane elements on the path are controlled by control plane 301 elements of the 5GC (i.e., SMFs), but anyway additional policies on 302 N6 may be forwarded in order to steer traffic on an optimized route 303 directly towards the edge UPF for the specific UE, without passing 304 through the UPF_a. 306 UE to edge data network: in this use case, the UE connects to an edge 307 Data Network, meaning a DN positioned at the edge of the core 308 network, near to the access network (typical MEC scenario). In 309 mobility, a new UPF_a may be assigned to UE, and routes to the 310 previous edge network would follow a non-optimized path, passing 311 through the new UPF_a for the UE. With traffic treatment policies 312 this can be avoid, giving a traffic steering policy to the DPN in 313 charge for the edge DN. 315 Concurrent use of multiple data networks: a possible scenario is the 316 one in which a UE collects the desired content from different data 317 networks (e.g., because of Content Delivery Networks - CDN). To 318 optimize routing in this scenario, the downlink traffic should 319 traverse for each data network the optimized path through the UE and 320 not be forced through a (central) UPF_a common to all the data 321 networks. Again, this can be done with policies on N6 interface. 322 This particular use case also highlights the importance to consider 323 optimization on N6, whereas other works focus on N9: considering a 324 UPF_a near the data network, as proposed in other solutions, would 325 not allow multiple DN access in an unique user session and so would 326 not allow for content access on different destinations. 328 4. N6 traffic treatment - Requirements and policy types 330 Use cases for traffic treatment on N6 per a data plane policy include 331 cases where the UPF_a is deployed closer at the mobile edge, e.g. to 332 not only access a local data network in the proximity of the UE, but 333 also other data networks sharing the single edge UPF_a. In that case 334 the N6 interface may span some distance in the transport network in 335 between the data network(s) and the UPF_a. Dependent on the expected 336 QoE/QoS of the traffic, traffic treatment policies for QoS 337 differentiation, packet labeling, etc. may apply to the UE's packets 338 on N6. For uplink traffic, the UE's UPF_a can enforce such traffic 339 treatment policies to uplink traffic, where a DPN associated with the 340 data network(s) (e.g. PE router, transit router, router/switch of 341 the data center transport network, TOR switches of Application 342 Servers, etc.) enforces such policies to downlink traffic. 344 The same need for traffic treatment policies applies to traffic 345 between a UPF_i, which classifies uplink traffic for forwarding to a 346 local data network, and the data network. Downlink traffic from the 347 local data network to the UE should then be forwarded towards the 348 UPF_i, not via the UE's UPF_a. 350 In advanced scenarios, the SMF may decide to reconfigure the UE's 351 UPFs, e.g. by relocating the UPF_a or a UPF_i while maintaining the 352 UE's IP address (IP_ue) and data sessions using this IP address. In 353 such case, a DPN associated with the one or multiple data networks, 354 which run correspondent services for the UE, must enforce traffic 355 steering policies to downlink traffic to achieve routing of downlink 356 traffic to the UE's current UPF_a or UPF_i respectively. 358 In summary, traffic treatment policies that apply to a UE's uplink 359 and downlink traffic on N6 include the following types: 361 o QoS differentiation and traffic engineering" 363 o Packet label push/pop" 365 o Metering 367 o Traffic steering (e.g. SRv6 rules, locator re-write rules, etc.) 369 o E dormancy monitoring rules to initiate paging 371 Requirements for N6 traffic treatment include the following: 373 o Awareness of UE location information (first hop router accuracy, 374 UPF_a/UPF_i) - Set or update DPN policy for traffic steering 376 o Awareness of topology - Select and update most suitable UPF (UPF_a/ 377 UPF_i) for the communication with a data network, e.g. after UPF 378 changed 380 o Availability of initial or updated policies when needed 382 o No/Low impact on data traffic (packet loss, re-ordering) when 383 policies are updated - DPNs may request/solicit policies or get 384 notified about initial and updated policies 386 5. Leveraging the mobile control plane for N6 policy control 388 Methods for N6 policy control consist in instructing the DPNs with 389 rules for traffic steering, QoS policies enforcing, etc. The 390 solution described in this draft is based on leveraging the mobile 391 control plane, in order to introduce some logic to manage and forward 392 policies to DPNs on N6 interface. To do this, the Application 393 Function (AF) defined in 5GS [TS23.501] is used as binding element in 394 between the cellular network control plane and the data network data 395 plane. 397 Per [TS23.501], the AF is introduced to inter-work with the Policy 398 Control Function (PCF) in order to condition and contribute to some 399 SMF decisions. This happens with the AF sending specific requests to 400 the PCF and the latter translating those requests in policies for the 401 SMF. Depending on the domain in which the AF is located, a Network 402 Exposure Function (NEF) may be in between to enable the AF 403 collaborating with the other control plane elements of the cellular 404 architecture. 406 In support of the proposed scenario, the AF can solicit data plane 407 policies from the cellular control plane by sending a request. At 408 reception of the policies, the AF can pass the policies on for 409 further processing and enfocement in the data network's AS/DPN. In 410 this way, DPNs receive from the control plane policies for the user 411 traffic traversing them. The AF may be co-located with a control 412 function, which utilizes the DMM WG's Forwarding Policy Configuration 413 (FPC) protocol to implement policies in the AS/DPN, or leverage an 414 SDN controller for the selection and configuration of AS/DPN. 416 The policies defined and forwarded by the AF are based on the status 417 of the mobile network, which the AF can obtain from the SMF. In any 418 moment, in fact, the SMF is in charge of keeping track of the 419 selected UPFs and of monitoring the user session. Based on this 420 information, the AF forwards specific rules to a DPN (e.g., traffic 421 steering rules to make the user's traffic reach the most suitable 422 UPF_a). In some cases (e.g., user mobility), the SMF can also change 423 UPFs for a specific user and in this case the AF will receive updated 424 policies for enforcement in the involved AS/DPN. 426 Figure 4 shows how the previous architecture evolves with the 427 introduction of the AF. 429 communication between control plane functions 430 - - +----------------+---------------+ - - 431 | | | 432 +--+--+ +-----+ +------+_ _ _ _ _ _ _ _ 433 | AMF | | SMF | | AF |_ | 434 +-----+ +-----+ +------+ | | 435 /N2 N4| |N4 | N6 policy | 436 / +-----+ +--+ | ________ | 437 / | | |/ \ | 438 +----+ +-----+ N3 +---+---+ N9 +---+---+ N6 +---+--+ Data \ | 439 | UE |---+ RAN +=====+ UPF_i +======+ UPF_a +---/---+DPN|AS|Network | | 440 +----+ +-----+ +---+---+ +-------+ IP +---+--+ 1 / | 441 IP_ue | proxy IP_ue \________/ | 442 | _________ | 443 | / \ | 444 +---+---+ N6 +---+--+ Data \ | 445 proxy| UPF_a +--------/--+DPN|AS|Network | | 446 IP_ue+-------+ IP +---+--+ 2 / | 447 |\_________/ | 448 |_ _ _ _ _ _ _ _ _ _ _ _| 449 N6 policy 451 Figure 4: Using AF in control plane for traffic policy enforcement 453 6. N6 endpoints - loose and tight coupling options 455 As described in the previous section, we take advantage of the 456 Application Function (AF) to bind the 3GPP's domain functions with 457 those introduced in this draft for N6 policy enforcement. According 458 to [TS23.501], an Application Function may send requests to influence 459 SMF decisions for User Plane (UP) traffic of PDU Sessions (e.g., 460 based on the relocation of an application on the Data Network side, 461 the AF can notify this to the SMF in order to trigger a relocation of 462 UPF(s) from the SMF, to choose a new UPF more suitable for the new 463 Data Network). 465 In addition, the AF can subscribe to events from the SMF in order to 466 receive notification about UP management events (e.g., when a PDU 467 Session anchor has been established or released). 469 As defined in [TS23.502], the AF interacts with the PCF/SMF via the 470 NEF or directly and the PCF then forwards requests from the AF 471 towards the SMF as Session Management (SM) Policies. For the sake of 472 simplicity, in this section all the 3GPP's functions apart from the 473 AF are collected under the name of "3GPP's C-PLANE", and the specific 474 service to which the AF interacts in the 3GPP C-PLANE is not relevant 475 for this draft. 477 In order to forward specific policies to the Data Plane Nodes/ 478 Application Servers (DPNs/ASs) associated with each Data Network, a 479 Network Controller (NC) is considered to be co-located with the AF 480 element. The NC performs the selection of a DPN/AS element based on 481 the received information from the C-PLANE. The AF/NC forwards 482 control messages to a DPN/AS through an AFNC-CPUP interface, giving 483 indications to steer the downlink traffic properly and coherently 484 with the UP updates from the 3GPP's side. 486 Forwarding N6 polices to the N6 endpoints involved (i.e., UPF and 487 DPN) can happen in two different ways: 489 1) Tight coupling scenario: The UPF can enforce policies per the 490 AF/NC decisions. The UPF receives associated policies from the 491 3GPP's C-PLANE. The corresponding DPN/AS receives the policy 492 via teh AFNC-CPUP interface. 494 2) Loose coupling scenario: A separate DPN function is co-located 495 with the UPF. Main policies for N6 traffic treatment do not 496 traverse the 3GPP's C-PLANE but are controlled at both N6 497 interface endpoints' DPN by the AF/NC via the AFNC-CPUP 498 interface. 500 In the tight coupling scenario, the N6 interface configurations for 501 the UPF are all enforced though the 3GPP domain. Therefore, the 502 3GPP's C-PLANE interacts with the AF/NC element through the AFNC_3GPP 503 interface and receives on this interface requests to influence the UP 504 traffic policies. 3GPP decides if enforce those policies on the 505 UPF(s) involved. 507 The architecture and interfaces involved in this tight coupling 508 scenario are depicted in Figure 5. 510 +-------------------+ AFNC_3GPP+--------+ 511 +-+ 3GPP's C-PLANE +----------+ AF/NC +_ _ _ _ _ _ 512 | +-------------------+ +-+------+ | 513 | | | | 514 |N2 |N4 |AFNC_CPUP | 515 | | | __________ | 516 | | |/ \ | 517 +----+ +-----+ N3 +--+----+ N6 +---+--+ Data \ | 518 | UE |-----+ RAN +===/====+ UPF +-----/----+DPN|AS| Network | | 519 +----+ +-----+ +---+---+ +---+--+ 1 / | 520 IP_ue | \__________/ | 521 | _________ | 522 | / \ | 523 | N6 +---+--+ Data \ | 524 +------/----+DPN|AS| Network | | 525 +---+--+ 2 / | 526 |\_________/ | 527 |__ _ _ _ _ _ _ _ _ _| 528 AFNC_CPUP 530 Figure 5: N6 endpoints tight coupling scenario 532 In Section 7.1 the operation flow and information model for the 533 messages exchanged in this type of coupling are presented and 534 described. Both the cases of a AF/NC-initiated and 3GPP-initiated 535 message flow are considered. 537 In the loose coupling scenario, an additional DPN element is 538 associated with a UPF and represents a key element to enforce N6 539 traffic treatment policies on the UPF-side of the N6 interface. This 540 DPN is controlled by the AF/NC through the AFNC_CPUP interface, as 541 depicted in Figure 6. 543 Loose coupling allows reducing 3GPP's role in the N6 endpoint 544 management, potentially allowing under certain assumptions (e.g., no 545 UPF re-selection is needed), an optimized control of the N6 interface 546 from the AF/NC element, transparently from 3GPP's domain. This kind 547 of scenario results as an advantage particularly for use cases in 548 which the UPF is deployed in the proximity of the Data Network and 549 far from the 3GPP's C-PLANE (i.e., in a Mobile Edge Computing - MEC - 550 alike scenario). 552 For particular cases which request 3GPP's C-PLANE involvement (i.e., 553 UPF re-selection or other changes not related to the only N6 554 endpoint) the AFNC_3GPP is still used for notifications and requests 555 between the AF/NC and the 3GPP's C-PLANE. 557 +-------------------+ AFNC_3GPP+--------+ 558 +-+ 3GPP's C-PLANE +----------+ AF/NC +__________ 559 | +-------------------+ +-+------+ | 560 | | _ _ _ _/ | | 561 |N2 |N4 / |AFNC_CPUP | 562 | | AFNC_CPUP | __________ | 563 | | / |/ \ | 564 +----+ +-----+ N3 +--+--+--+--+ N6 +--+---+ Data \ | 565 | UE |-----+ RAN +===/====+ UPF | DPN +---/---+DPN|AS| Network | | 566 +----+ +-----+ +---+-+-----+ +--+---+ 1 / | 567 IP_ue | \__________/ | 568 | _________ | 569 | / \ | 570 | N6 +---+--+ Data \ | 571 +------/----+DPN|AS| Network | | 572 +---+--+ 2 / | 573 |\_________/ | 574 |__ _ _ _ _ _ _ _ _ | 575 AFNC_CPUP 577 Figure 6: N6 endpoints loose coupling scenario 579 7. Operations for N6 policy enforcement in a tight coupling scenario 581 In the following sub-sections, message sequences are shown assuming a 582 tight coupling scenario between N6 interface endpoints, as depicted 583 in Figure 5. Two different operation flows can be distinguished, 584 based on the entity initiating and requesting for the N6 policy. 585 Section 7.1 describes the message sequence in the case of AF/NC- 586 initiated N6 policy request, while Section 7.2 covers the alternative 587 case in which the request for a N6 policy is initiated from the 588 3GPP's C-PLANE. 590 In the message sequences, special attention is given to the AFNC_CPUP 591 and AFNC_3GPP interfaces defined in this draft and Information Models 592 for messages exchanged on those interfaces are provided. 594 7.1. AF/NC-initiated N6 policy enforcement 596 A N6 policy can be triggered from the AF/NC element and is then 597 forwarded directly to the DPN N6 endpoint (through AFNC_CPUP 598 interface) and indirectly to the UPF N6 endpoint (through AFNC_3GPP 599 interface). 601 As example, the AF/NC may request updated n6 policies for the 602 following reasons: 604 o there is the need of a different QoS to be applied to traffic, 605 which is identified in the request. 607 o there is the need for a re-location of the application to a 608 different Data Network and therefore changes for traffic in uplink 609 on the UPF's N6 endpoint should be applied. 611 Figure 7 depicts the AF/NC-initiaed N6 policy enforcement message 612 sequence. 614 +--------+ 615 +-------+ +--------+ | +-------+ +--------+ 616 |C-PLANE| | UPF(s) |-+ | AF/NC | | DPN/AS | 617 +---+---+ +--+-----+ +---+---+ +---+----+ 618 | | | | 619 | | | | 620 |<-----(1)TRAFFIC------------| | 621 | INFLUENCE REQUEST | | 622 | | | | 623 |---(2a)---->| | | 624 |<----(2b)---| | | 625 | N4 SESSION EST/MOD/REL | | 626 | | | | 627 | | | | 628 |------(3)TRAFFIC----------->| | 629 | INFLUENCE RESPONSE | | 630 | | | | 631 | | |---(4a)---->| 632 | | |<---(4b)----| 633 | | | AFNC_CPUP | 634 | | | CONFIGURATION 635 | | | | 637 Figure 7: Message flow for AF/NC-initiated N6 policy enforcement 639 Following, a description for each message is given: 641 (1) TRAFFIC INFLUENCE REQUEST: this message is sent from the AF/NC to 642 the 3GPP's C-PLANE in order to request a modification for UP traffic. 643 The message contains the fields listed in Table 1. 645 Information model for TRAFFIC INFLUENCE REQUEST message 647 +------------+---------------------------+--------------------------+ 648 | Message | Description | Notes | 649 | Fields | | | 650 +------------+---------------------------+--------------------------+ 651 | Request ID | Identifies the current | - | 652 | | request in order to match | | 653 | | it with following | | 654 | | response messages. | | 655 | | | | 656 | Traffic | Identifies the UP traffic | 3GPP's identifiers | 657 | Identifier | which is targeted by the | defined in [TS23.501] | 658 | | request. Traffic may be | may be used to identify | 659 | | identified based on the | traffic (e.g., DNN for | 660 | | session, UE-based or even | traffic toward a | 661 | | slice-based (i.e., | specific Data Network, | 662 | | addressing all the | NSSAI for a specific | 663 | | traffic belonging to a | slice, UE GUTI for a | 664 | | specific network slice). | specific user, etc.) | 665 | | | | 666 | QoS | Contains the QoS | - | 667 | parameters | parameters for the | | 668 | | targeted traffic | | 669 | | | | 670 | DPN N6 | Brings information about | - | 671 | endpoint | the N6 endpoint on the | | 672 | | Data Network side. | | 673 +------------+---------------------------+--------------------------+ 675 Table 1 677 Based on the N6 endpoint information, the 3GPP's C-PLANE may take 678 decisions on UPF(s) selection and re-location. For instance, this 679 field could carry a Data Network Access ID (DNAI), identifying a 680 specific Data Network on which the 3GPP's domain could select the 681 best matching UPF (e.g., based on proximity). 683 (2a)(2b) N4 SESSION ESTABLISHMENT/MODIFICATION/RELEASE: this are 684 3GPP's messages defined in [TS23.502] and used to enforce changing to 685 one or more UPF or to select and configure a new UPF. Through this 686 messages, the N6 policies requested from the AF/NC can be enforced to 687 the UPF(s). 689 (3) TRAFFIC INFLUENCE RESPONSE: this message is sent from the 3GPP's 690 C-PLANE to the AF/NC in order to acknowledge the UP changes made 691 based on the previous request message. The message contains the 692 fields listed in Table 2. 694 Information model for TRAFFIC INFLUENCE RESPONSE message 696 +------------+-----------------------------------+------------------+ 697 | Message | Description | Notes | 698 | Fields | | | 699 +------------+-----------------------------------+------------------+ 700 | Request ID | Identifies the request message to | - | 701 | | which this response is referred | | 702 | | to. | | 703 | | | | 704 | Traffic | Identifies the UP traffic which | Traffic actually | 705 | Identifier | is targeted by the request. | influenced could | 706 | | Traffic may be identified based | differ from the | 707 | | on the session, UE-based or even | original traffic | 708 | | slice-based (i.e., addressing all | targeted in the | 709 | | the traffic belonging to a | request. | 710 | | specific network slice). | | 711 | | | | 712 | UPF N6 | Brings information about the N6 | - | 713 | endpoint | endpoint on the 3GPP's side. | | 714 +------------+-----------------------------------+------------------+ 716 Table 2 718 N6 endpoint information on 3GPP's side (e.g., IP address of the N6 719 endpoint UPF) are used from the AF/NC to set the DPN(s) in order to 720 properly route downlink traffic. 722 (4a)(4b) AFNC_CPUP CONFIGURATION: This message is used to instruct 723 the DPN(s) involved in the UP changes. For instance, in case of UPF 724 re-selection and UPF's N6 endpoint (e.g., IP address) changing, 725 traffic steering rules for downlink traffic need to be enforced to 726 the DPN. The structure of this message is out of the scope of this 727 draft and candidates for managing this interface are already present 728 (e.g., Forwarding Policy Configuration (FPC) defined in [FPC]). 730 7.2. 3GPP-initiated N6 policy enforcement 732 A N6 policy can be triggered by the 3GPP domain. In this case, an 733 initial subscription mechanism is needed, in which one or multiple AF 734 subscribe the 3GPP's C-PLANE in order to receive notification about 735 the subscribed events. Some of the events, of which a AF/NC could be 736 interested in, are: 738 o re-selection one or multiple UPF(s) from the 3GPP's C-PLANE. 740 o changes in the UP traffic QoS parameters. 742 o etc. 744 Figure 8 depicts the message sequence described the AF subscription 745 and a notification from the 3GPP's domain when the specific event 746 occurs. 748 +--------+ 749 +-------+ +--------+ | +-------+ +--------+ 750 |C-PLANE| | UPF(s) |-+ | AF/NC | | DPN/AS | 751 +---+---+ +--+-----+ +---+---+ +---+----+ 752 | | | | 753 |<-----(0)EVENT--------------| | 754 _|_ SUBSCRIPTION | | 755 |___| | | | 756 event | | | 757 | | | | 758 |------(1)EVENT ------------>| | 759 | NOTIFICATION | | 760 | | |----(2a)--->| 761 | | |<---(2b)----| 762 | | | AFNC_CPUP | 763 | | | CONFIGURATION 764 | | | | 766 Figure 8: Message flow for 3GPP-initiated N6 policy enforcement 768 The messages used are here described: 770 (0) EVENT SUBSCRIPTION: this message is sent from the AF/NC to the 771 3GPP's C-PLANE in order for the AF/NC to subscribe to some specific 772 UP events. When received from the 3GPP's C-PLANE, all future UP 773 events (e.g., UPF re-selection, changing in UP traffic parameters) 774 which match with the subscription will be notified to the AF/NC. 775 This message fields are listed in Table 3. 777 Information model for EVENT SUBSCRIPTION message 779 +--------------+---------------------------+--------------------------+ 780 | Message | Description | Notes | 781 | Fields | | | 782 +--------------+---------------------------+--------------------------+ 783 | Subscription | Identifies the | - | 784 | ID | subscription in order to | | 785 | | then match the resulting | | 786 | | notification. | | 787 | | | | 788 | Event | Identifies the type of | Can be 'all-events' or | 789 | | event to which the | identify a specific type | 790 | | subscription is referred. | of event. | 791 | | For instance, the | | 792 | | subscription could refer | | 793 | | only to an UPF re- | | 794 | | selection event, or may | | 795 | | refer to any event for | | 796 | | the targeted traffic. | | 797 | | | | 798 | Traffic | Identifies the UP traffic | 3GPP's identifiers | 799 | Identifier | which is targeted by the | defined in [TS23.501] | 800 | | request. Traffic may be | may be used to identify | 801 | | identified based on the | traffic (e.g., DNN for | 802 | | session, UE-based or even | traffic toward a | 803 | | slice-based (i.e., | specific Data Network, | 804 | | addressing all the | NSSAI for a specific | 805 | | traffic belonging to a | slice, UE IP address for | 806 | | specific network slice). | a specific user, etc.) | 807 +--------------+---------------------------+--------------------------+ 809 Table 3 811 (1) EVENT NOTIFICATION: this message is sent from the 3GPP's C-PLANE 812 to the AF/NC, triggered by the subscribed event for the targeted 813 traffic. If no subscription for the specific traffic and event was 814 received before the modification occurs the 3GPP's C-PLANE will not 815 provide any notification for the UP traffic changes. Table 4 lists 816 the field contained in the message. 818 Information model for EVENT NOTIFICATION message 820 +--------------+--------------+-------------------------------------+ 821 | Message | Description | Notes | 822 | Fields | | | 823 +--------------+--------------+-------------------------------------+ 824 | Subscription | Identifies | - | 825 | ID | the | | 826 | | subscription | | 827 | | message to | | 828 | | which this | | 829 | | notification | | 830 | | is referred | | 831 | | to. | | 832 | | | | 833 | Traffic | Identifies | Even if there is no notification | 834 | Identifier | the UP | for traffic which has not been | 835 | | traffic | targeted through a subscription, | 836 | | which has | this field may refer to a subset of | 837 | | been change. | the traffic targeted in the | 838 | | | subscription (e.g., subscription to | 839 | | | a specific user traffic and | 840 | | | modification of only one PDU | 841 | | | sessions for that user). | 842 | | | | 843 | QoS | Brings | - | 844 | parameters | information | | 845 | | about QoS | | 846 | | parameters | | 847 | | which have | | 848 | | been | | 849 | | changed. | | 850 | | | | 851 | UPF N6 | Brings | - | 852 | endpoint | information | | 853 | | about the N6 | | 854 | | endpoint on | | 855 | | the 3GPP's | | 856 | | side which | | 857 | | have been | | 858 | | changed. | | 859 +--------------+--------------+-------------------------------------+ 861 Table 4 863 (2a)(2b) AFNC_CPUP CONFIGURATION: This message is used to instruct 864 the DPN(s) involved in the UP changes. For instance, in case of UPF 865 re-selection and UPF's N6 endpoint (e.g., IP address) changing, 866 traffic steering rules for downlink traffic need to be enforced to 867 the DPN. The structure of this message is anyway out of the scope of 868 this draft and candidates for managing this interface are already 869 present (e.g., Forwarding Polciy Configuration (FPC) defined in 870 [FPC]). 872 8. IANA Considerations 874 No IANA action is required for this version of the draft. 876 9. Security Considerations 878 Since the solution proposed in this document utilizes the AF to 879 solicit and receive N6 traffic treatment policies from the cellular 880 system's control plane, the trust relationship between the AF and the 881 cellular system's domain matters. In case the AF is located in a 882 different administrative domain, the communication from and to the AF 883 may happen via the system's Network Exposure Functions (NEF). The 884 semantic to request and receive the N6 policy at the AF and in 885 particular the policy types and their descriptions must be aligned to 886 the trust relationship. 888 Also, the trust relationship between the AF and the DPN/AS matters 889 and a secure direct or indirect (e.g. through an Network Controller) 890 interface, must be ensured. 892 10. Acknowledgments 894 The research leading to these results has been partially supported by 895 the H2020-MSCA-ITN-2016 framework under grant agreement number 722788 896 (SPOTLIGHT). 898 Authors want to thank Sri Gundavelli, John Kaippallimalil and 899 Shunsuke Homma for their interest and feedback to the use cases and 900 the solution principles for N6 traffic treatment policies. 902 11. Normative References 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, 906 DOI 10.17487/RFC2119, March 1997, 907 . 909 [I-D.hmm-dmm-5g-uplane-analysis] 910 Homma, S., Miyasaka, T., Matsushima, S., and d. 911 daniel.voyer@bell.ca, "User Plane Protocol and 912 Architectural Analysis on 3GPP 5G System", draft-hmm-dmm- 913 5g-uplane-analysis-02 (work in progress), October 2018. 915 [I-D.gundavelli-dmm-mfa] 916 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 917 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 918 (work in progress), September 2018. 920 [I-D.bogineni-dmm-optimized-mobile-user-plane] 921 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 922 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 923 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 924 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 925 optimized-mobile-user-plane-01 (work in progress), June 926 2018. 928 [FPC] S.Matsushima, L.Bertz, M.Liebsch, S.Gundavelli, D.Moses, 929 C. Perkins, "Protocol for Forwarding Policy Configuration 930 (FPC) in DMM.", 3GPPTS 23.501, June 2018. 932 [TS23.501] 933 3rd Generation Partnership Project (3GPP), "Technical 934 Specification TS23.501, System Architecture for the 5G 935 System, Release 15.", 3GPPTS 23.501, June 2018. 937 [TS23.502] 938 3rd Generation Partnership Project (3GPP), "Technical 939 Specification TS23.502, Procedure for the 5G System, 940 Release 15.", 3GPPTS 23.502, June 2018. 942 Authors' Addresses 944 Umberto Fattore 945 NEC Laboratories Europe GmbH 946 Kurfuersten-Anlage 36 947 D-69115 Heidelberg 948 Germany 950 Email: umberto.fattore@neclab.eu 952 Marco Liebsch 953 NEC Laboratories Europe GmbH 954 Kurfuersten-Anlage 36 955 D-69115 Heidelberg 956 Germany 958 Email: marco.liebsch@neclab.eu