Skip to main content

Mobile Traffic Steering
draft-liebsch-dmm-mts-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Marco Liebsch
Last updated 2024-07-08
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liebsch-dmm-mts-00
Distributed Mobility Management (DMM)                         M. Liebsch
Internet-Draft                                                       NEC
Intended status: Informational                               8 July 2024
Expires: 9 January 2025

                        Mobile Traffic Steering
                      draft-liebsch-dmm-mts-00.txt

Abstract

   The evolution of cellular mobile communication systems is aligned
   with an increasing demand for customized deployments, energy
   efficiency, dynamic re-configurability and the integration and use of
   other network technologies, such as non-cellular radio access
   technologies and non-terrestrial networks.  In order to achieve and
   maintain the expected service quality and continuity, such systems
   should be designed and controllable end-to-end, taking all involved
   network domains and segments into account.  This document discusses
   an end-to-end system from an advanced use cases perspective and
   substantiates the demand for solutions to share information and
   enable control interfaces between all connected network domains,
   including the mobile communication system and the transport network
   that stretches up to the data networks that host service instances.
   Two architectural principles are described and discussed in the view
   of existing or new IETF technology that enables end-to-end mobile
   traffic treatment and steering in such complex and dynamically
   changing networks.

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

Liebsch                  Expires 9 January 2025                 [Page 1]
Internet-Draft           Mobile Traffic Steering               July 2024

Copyright Notice

   Copyright (c) 2024 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Reference Architecture in the view of advanced end-to-end
           operations  . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  System Evolution and Use Cases  . . . . . . . . . . . . . . .   6
     4.1.  General directions and impact . . . . . . . . . . . . . .   6
     4.2.  MCS proactive UPA relocation  . . . . . . . . . . . . . .   8
     4.3.  MCS reactive UPA relocation . . . . . . . . . . . . . . .   9
     4.4.  DPN ephemerality  . . . . . . . . . . . . . . . . . . . .   9
     4.5.  Communication between two mobile users  . . . . . . . . .   9
   5.  Framework and Deployment Options  . . . . . . . . . . . . . .  10
     5.1.  Mobile User Plane and Data Plane aspects  . . . . . . . .  10
     5.2.  Dedicated Control Plane . . . . . . . . . . . . . . . . .  11
     5.3.  Decentralized Control Plane . . . . . . . . . . . . . . .  12
   6.  Design Recommendations and Information Models . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Liebsch                  Expires 9 January 2025                 [Page 2]
Internet-Draft           Mobile Traffic Steering               July 2024

2.  Introduction

   The evolution of cellular mobile communication systems resulted in a
   clear separation of control plane and user plane functions.  The
   control plane comprises functions for security, mobile subscriber
   management, handover, and mobility management.  The user plane
   functions represent anchor points for a user's traffic and enforces
   policies to user plane traffic, such as for traffic engineering or
   chargeable event monitoring and reporting.  Compared to early
   standards, today's mobile communication systems support the demand of
   mobile subscribers as well as mobile network operators better in
   terms of deployment options and route optimization.  This includes
   the decentralized deployment and selection of user plane anchors,
   which can, e.g., be topologically located on the path between a
   mobile user and a user's currently connected and used application
   service.

   Such flexible deployment of user plane anchors is aligned with a
   raising interest in distributing compute resources.  Edge Computing
   enables the provisioning of compute resources, which are
   topologically close to mobile users.  This helps on the one hand side
   to reduce end-to-end latency between a mobile user and a service or a
   compute resource, that performs a certain computation task for the
   user.  On the other hand, it keeps data for certain use cases local,
   which can be leveraged for certain analytics tasks, where data is
   only of local interest, or for meeting some privacy and security
   objectives.

   Figure 1 depicts the end-to-end view of a mobile user, which connects
   to an application service function (ASF) through a mobile
   communication system (MCS).  The ASF serves a user's request at the
   data plane layer, while the service may have a dedicated application
   control function (ACF).  The user, as an example, may connect to the
   ACF to configure the service and gets served by the associated ASF.
   The service components are deployed in a data network, which may be
   represented by a central cloud, or a distributed data center with
   cloud computing resources.  In alignment with mobile communication
   system standards, the MCS is separated into a radio access network
   (RAN) part and a mobile core network, which comprises the MCN control
   plane and the user plane anchors.  The RAN offers cellular and non-
   cellular radio access technologies, such as WiFi, to a mobile user to
   connect to the MCS for mobile access to a target service.

   While mobile communication standards focus on the components of the
   MCS and their operation, details on the network in between the MCS
   and a data network are often treated out-of-scope of the mobile
   communication standard and deployment specific.  Such network may
   indeed be deployment specific and differs in the type of network

Liebsch                  Expires 9 January 2025                 [Page 3]
Internet-Draft           Mobile Traffic Steering               July 2024

   nodes and protocols that route or switch traffic in between the MCS
   and the data network.  Figure 1 depicts this network as a set of data
   plane nodes (DPN), which can, for example, be routers with redundant
   paths and implementing MPLS or SRv6 in their transport plane.

   This document addresses relevant system components in an end-to-end
   reference architecture to discuss advanced use cases and associated
   deployment options.  In particular use cases are addressed, where
   components or network functions on the end-to-end path change, move
   or discontinue operation while the mobile user is still connected to
   the service.  The objective of this document is to analyze these use
   cases and elaborate how existing or new IETF technology can serve as
   enabler to accomplish service continuity for a mobile user in such
   agile and dynamic system by means of controlled steering and
   treatment of a mobile user's end-to-end traffic.

   Each case is analyzed and discussed in the view of technical
   challenges and operational aspects in each of the two described
   solution options.  Advanced use cases are in-line with the view in
   industry, research community as well as pre-standards effort.  The
   following deployment- and operational aspects of session and service
   continuity are included:

   0 Mid-session relocation of a mobile user's UPA, e.g. due to user
   mobility, UPA failover or load balancing.

   o Deployments with moving or ephemeral system-relevant nodes on
   the end-to-end path.  These nodes include system components, such
   as radio access network components and a MCS's UPA that are on-
   board of a moving resource, such as a low earth orbit (LEO)
   satellite, or an energy constrained node whose schedule enforces a
   power save- or inactive mode.

   o Mid-session relocation of a mobile user's serving data network,
   e.g. due to the service resource's mobility, service failover,
   energy/costs or quality of service reasons.

   This document includes the description of two solution options, that
   complement a MCS without interference by means of well inter-
   connected and collaborative control- and data planes.  Operational
   aspects of the two solution options are described and semantics as
   well as information models, that apply to relevant reference points,
   are specified.

Liebsch                  Expires 9 January 2025                 [Page 4]
Internet-Draft           Mobile Traffic Steering               July 2024

3.  Reference Architecture in the view of advanced end-to-end operations

   Figure 1 depicts a reference architecture for end-to-end operations,
   which includes communication between a mobile user and an Application
   Service Function (ASF) as well as user-to-user communications.  The
   ACF can be a service control instance hosted in a central or a
   distributed cloud resources, or a workload placed by the mobile user
   to an assigned compute resource in either a central or a
   decentralized cloud.  While the MCS ensures mobile connectivity and
   data services between a mobile user and its UPA, a Transport Network
   comprises a network of data plane nodes (DPN) and ensures routing of
   a mobile user's traffic between it's UPA and one or multiple data
   networks.

   The Transport Network may implement redundant paths and select the
   most suitable route based on the topological location and associated
   IP address of the ASF and mobile user, respectively.  The mobile
   user's IP address may be topologically correct and fit the UPA's
   network, or it does not match the network where the mobile user's
   assigned UPA is located.  The latter case applies, for example, to
   mobile user subscriptions, which have static IP addresses assigned
   and represents a view that the IETF's Distributed Mobility Management
   (DMM) group considers for a deployment of distributed UPAs.  Routing
   of topologically incorrect mobile device IP addresses can be tackled
   by overlay transport mechanisms, such as encapsulation or label
   switching, or host routes that apply to the relevant DPNs in the
   transport network in between the mobile user's UPA and its connected
   data networks.

   With reference to Figure 1, the DPNs that are depicted close to the
   data network and to the MCS can represent the associated domains' PE
   router, or be independent routers in the domain of the transport
   network provider that connect to the PE routers of the MCS domain and
   the data network domain respectively.

   The reference architecture's domains, the MCS, the transport network
   and the data network, may share the same AS or be located in
   different ASs.  The relevance and scope of solutions for mobile
   traffic steering in advanced and anticipated use cases, that this
   document describes in Section 4, depend on the involved ASs.  This
   aspect will be addressed in Section 6

Liebsch                  Expires 9 January 2025                 [Page 5]
Internet-Draft           Mobile Traffic Steering               July 2024

        +----------MCS----------+  Transport Network  +--Data Network--+
        |                       |                     |                |
        | +-------------------+ |        +---+        |     +---+      |
        | | MCS Control Plane | |    +---+DPN+---+    |     |ACF|      |
        | +--+-------------+--+ |    |   +---+   |    |     +-+-+      |
        |    |             |    |    |           |    |       |        |
Mobile  | +--+--+       +--+--+ |  +-+-+       +-+-+  |     +-+-+      |
 User-----+ RAN +===/===+ UPA +----+DPN+-------+DPN+--+-----+ASF|      |
        | +-----+       +-----+ |  +---+       +---+  |     +---+      |
        |                       |                     |                |
        +-----------------------+                     +----------------+

             Figure 1: Reference End-to-End Architecture.

4.  System Evolution and Use Cases

4.1.  General directions and impact

   While recent standards for MCSs are still being evolved and extended,
   the research community and standards organizations started to
   elaborate on a new MCS generation and advanced use cases.  Key
   objectives include tighter integration of a variety of radio access
   technologies, including non-terrestrial networks, e.g. satellites,
   support of energy-efficiency schemes, and runtime changes of service
   instances and network functions.  Customized deployments place a set
   of UPAs topologically close to or even inside distributed data
   networks, which may host compute resources for service instances or
   temporary workload that has been offloaded from a mobile user.

Liebsch                  Expires 9 January 2025                 [Page 6]
Internet-Draft           Mobile Traffic Steering               July 2024

   In case of user mobility, the MCS may assign a new UPA to the mobile
   device, which can lead to sub-optimal routes between a data network
   and the mobile user.  While the relocation of the UPA is handled by
   the MCS, awareness of such change is required in the transport
   network and the data network to update traffic treatment.  For
   efficiency reasons, even the use of temporarily available and
   ephemeral resources is considered, which includes, for example,
   energy constrained or solar powered resources, mobile resources, such
   as vehicles, drones or satellites.  Industry develops satellites with
   radio units to enable inter-satellite links and to connect to ground
   stations as well as mobile users on earth.  Recent directions
   consider regenerative payload on satellites, which goes beyond the
   use of a satellite as a communication relay but offers on-board
   compute, storage and networking resources.  This enables the
   deployment of functions from mobile communication system, such as a
   UPA, and Internet technology, such as a routing function, on
   satellites.  Even the placement of suitable compute resources on-
   board of satellites is considered, which makes the pre-destined to
   host application service instances and other type of workload.

   These directions enable highly efficient deployments in terms of
   customization, resources usage, energy saving, communication latency,
   connectivity and Internet coverage, as well as workload placement and
   distribution.  On the other hand, the dynamics of system components'
   availability as well as their geographic and topological location
   requires sharing of information between the involved system
   components across domains, i.e. MCS, transport network and data
   network.  Exposing such information and offering control interfaces
   between these domains allows timely configuration of alternative
   paths to continue a service and steer mobile data plane traffic
   between a mobile user and its service or between two mobile users.
   In the discussed end-to-end system, a solution should also enable
   traffic engineering in the traversed network segments and data
   networks.

   UPA relocation and other dynamic changes in the network may result in
   reordering of the data plane packets.  Solutions for mobile traffic
   treatment and steering should provide suitable enablers to mitigate
   the impact of such changes to packet re-ordering.
   [I-D.zzhang-dmm-5gdn-end-marker] describes the use of End Markers to
   address this problem.

   The following sub-sections describe selected use cases, their impact
   to the end-to-end system and the need for mobile traffic steering
   solutions.  Section 5 introduces two architectural principles and
   options to tackle mobile traffic steering, which are subsequently
   discussed in the view of enabling technology, functional operation
   and required semantics on relevant control plane interfaces.

Liebsch                  Expires 9 January 2025                 [Page 7]
Internet-Draft           Mobile Traffic Steering               July 2024

4.2.  MCS proactive UPA relocation

   Figure 2 depicts a use case, where the MCS relocates the mobile
   user's current UPA, UPA1, to a new UPA, UPA2.  The resulting route
   between service instance ASF1 in the data network and UPA2 may differ
   from the previous route to UPA1.  In case the IP address of the
   mobile user's device needs to survive in order to not break the
   current session with the used service at ASF1, the transport network
   needs to enforce rules for traffic steering, e.g. by applying host
   routes on tha path's DPNs, by applying source routing or an overlay
   route, i.e. IP tunnel.  In case the user's IP address needs to
   continue only as long as the data session with ASF1 takes, the MCS
   may assign a new, topologically correct IP address from the network
   of UPA2 to the mobile user device.  After the mobile user terminates
   its data session with ASF1, new data sessions will use the new IP
   address and transient host routes in the transport network can be
   removed.  Figure 2 depicts also the change of the serving ASF, which
   may happen also as a result of user mobility.  As example, in an
   automotive use case, vehicles represent mobile users and connect to a
   most suitable, nearby ASF that is hosted by one of many available
   distributed cloud networks.  Due to mobility, the MCS may relocate
   the mobile user's UPA from UPA1 to UPA2.  In order to keep routing
   paths short and latency low, the ASF may be relocated from ASF1 to
   ASF2, as ASF2 is deployed in a more suitable data network.

        +----------MCS----------+  Transport Network  +--Data Network--+
        |                       |                     |                |
        | +-------------------+ |        +---+        |     +---+      |
        | | MCS Control Plane | |    +---+DPN+---+    |     |ACF|      |
        | +--+-------------+--+ |    |   +---+   |    |     +-+-+      |
        |    |             |    |    |           |    |       |        |
Mobile  | +--+--+      +---+--+ |  +-+-+       +-+-+  |    +--+-+      |
 User-----+ RAN +===/==+ UPA1 +----+DPN+-------+DPN+--+----+ASF1|      |
        | +--+--+      +------+ |  +---+       +-+-+  |    +----+      |
        |    |                  |                |    +----------------+
        |    |                  |                |    +----------------+
        |    |         +------+ |  +---+       +-+-+  |    +----+      |
        |    +---------+ UPA2 +----+DPN+-------|DPN|-------+ASF2|      |
        |              +------+ |  +---+       +---+  |    +----+      |
        +-----------------------+                     +----------------+

   Figure 2: Mid-session UPA relocation, e.g. due to user mobility.

Liebsch                  Expires 9 January 2025                 [Page 8]
Internet-Draft           Mobile Traffic Steering               July 2024

4.3.  MCS reactive UPA relocation

   In this case the source and rationale behind a UPF relocation in the
   MCS is different and results from a decision to change the serving
   ASF from ASF1 to ASF2 (Figure 2).  This may be because of an
   anticipation that the targeted geographic region of the mobile user
   gets better service from a data network that hosts ASF2.  As further
   example, the transport network applies changes in its routing
   strategy and as a result, a route between the MCS and a new ASF
   instance will result in better service quality and lower latency.
   The new situation in the service data network and the transport
   network can be exposed to the MCS, which may relocate the UPF from
   UPF1 to UPF2 to optimize the end-to-end path.

4.4.  DPN ephemerality

   Components from the transport network or the MCS may be of ephemeral
   nature and discontinue service at a predictable or unpredictable
   point in time.  Predictable discontinuity may be due to a scheduled
   power saving plan or mobility of the component.  The latter case
   applies, as example, to LEO satellites in space, which are non-
   stationary.  Advanced use cases consider the components of a radio
   base station and a UPA instance from the MCS as well as a DPN
   instance on-board of each satellite.  In such case, the mobile user
   on earth or a High Altitude Platform Station (HAPS) is associated
   with the satellite's radio base station, the UPF and a DPN for
   further routing of the mobile traffic.  At some point in time, the
   mobile user is not covered by the satellite's radio base station
   anymore and a different satellite, including its on-board radio base
   station, the UPF and DPN, takes over service the mobile user.  The
   end-to-end system needs to adapt to the changed triple of a radio
   base station, UPA and DPN in terms of traffic steering.

   Taking an example from a 3GPP-based MCS, a joint deployment of a
   radio base station, UPA and virtual routing function can be realized
   per the description in [I-D.zzhang-dmm-mup-evolution].

4.5.  Communication between two mobile users

   A MCS provide may deploy distributed UPAs in order to shorten the
   route and resulting latency for the communication between two mobile
   users.  Figure 3 depicts such case where mobile user1 has UPA1
   assigned, while mobile user2 has UPA3 assigned.  Mobile traffic
   between the two mobile users traverses UPA1 and UPA3 as well as the
   transport network.  In case the MCS relocates the mobile user1's UPA1
   to UPA2, a different route may apply.  In case of demand for IP
   address continuity or enforcement of particular traffic engineering
   rules in the DPNs, the change in the UPFs must be notified to the

Liebsch                  Expires 9 January 2025                 [Page 9]
Internet-Draft           Mobile Traffic Steering               July 2024

   transport network to apply adjusted policies in the relevant DPNs.

                   +----------MCS----------+  Transport Network
                   |                       |
                   | +-------------------+ |
                   | | MCS Control Plane | |
                   | +--+-------------+--+ |
                   |    |             |    |
           Mobile  | +--+--+      +---+--+ |  +-+-+
           User1-----+ RAN +===/==+ UPA1 +----+DPN+-----+
                   | +--+--+      +------+ |  +---+     |
                   |    |I                 |            |
                   |    ||                 |            |
                   |    ||        +------+ |  +---+   +-+-+
                   |    +=========+ UPA2 +----+DPN+---|DPN|
                   |              +------+ |  +---+   +-+-+
           Mobile  | +-----+      +------+ |  +---+     |
           User 2----+ RAN +======+ UPA3 +----+DPN+-----+
                   | +-----+      +------+ |  +---+
                   +-----------------------+

        Figure 3: Mid-session UPA relocation, e.g. due to one user's
                                 mobility.

5.  Framework and Deployment Options

   This section discusses two architecture principles and deployment
   options that enable end-to-end awareness of changes in the network
   and its configuration that have impact on a mobile user's access to a
   service and the expected service quality.  One option leverages a
   transport network controller (TN Controller) that shares relevant
   states and information with the MCS through a control plane
   interface.  The same interface is used to receive notification from
   the MCS and to apply control commands in the MCS.  The second option
   is based on decentralized control and requires tighter coupling of
   the transport network's routing functions with the MCS.

5.1.  Mobile User Plane and Data Plane aspects

   A mobile user plane applies to the scope of the MCS and is managed by
   the MCS control plane to enable bi-directional data traffic between a
   mobile user's device and its assigned UPA.  The network in between
   the UPA and a data network includes DPNs of the transport network and
   PE routers.  This document focuses on IETF technology that applies to
   the control and data plane in the transport network and data network.
   The transport network's data plane transits into the MCS domain at a

Liebsch                  Expires 9 January 2025                [Page 10]
Internet-Draft           Mobile Traffic Steering               July 2024

   PE router or the UPA.

5.2.  Dedicated Control Plane

   Figure 4 illustrates a deployment with a dedicated TN controller.
   The TN controller leverages an interface to the MCS control plane to
   receive notifications, such as during the change of a mobile user's
   UPA, and to apply changes in the configuration of a mobile user's
   states in the MCS, such as enforcement of a UPA change in alignment
   with a change in the transport network or data network.  The data
   network may also use an interface either to the TN controller or to
   the MCS control plane, which is used to enforce re-configurations in
   the transport network and/or the MCS in alignment with changes in the
   data network or a mobile user's service, e.g.  ASF relocation or QoS
   settings.

   The transport network's DPNs may make use of a dedicated PE router to
   reach the MCS's UPAs.  In this deployment option, the control of the
   UPAs is clearly separated from the DPN control, though the two
   control planes, the MCS control plane and the TN controller, are
   connected through a control plane interface.  The MCS control plane
   may enforce rules in a UPA for uplink traffic treatment, e.g. to
   forward a mobile user's traffic to a particular DPN.

        +----------MCS----------+  Transport Network  +--Data Network--+
        |                       |                     |                |
        | +-------------------+ |   +-------------+   |     +---+      |
        | | MCS Control Plane +-----+TN Controller+---------+ACF|      |
        | +--+-------------+--+ |   +-------------+   |     +---+      |
        |    |             |    |    |           |    |       |        |
Mobile  | +--+--+      +--+---+ |  +-+-+       +-+-+  |    +--+-+      |
 User-----+ RAN +===/==+ UPA1 +----+DPN+-------+DPN+--+----+ASF1|      |
        | +-----+      +------+ |  +---+       +-+-+  |    +----+      |
        |    ||                 |                |    +----------------+
        |    ||                 |    :           |    +----------------+
        |    ||        +------+ |  +-+-+       +-+-+  |    +----+      |
        |    +=========+ UPA2 +----+DPN+-------|DPN|-------+ASF2|      |
        |              +------+ |  +---+       +---+  |    +----+      |
        +-----------------------+                     +----------------+

     Figure 4: End-to-end architecture with a dedicated transport
            network controller and loose UPA-DPN coupling

Liebsch                  Expires 9 January 2025                [Page 11]
Internet-Draft           Mobile Traffic Steering               July 2024

5.3.  Decentralized Control Plane

   Figure 5 illustrates a decentralized deployment without a dedicated
   TN controller.  DPNs expose routes through a routing protocol.  To
   cover cases where the MCS relocates a mobile user's UPA, the DPN must
   either tightly couple with the UPAs and apply local APIs to learn
   about the mobile user and it's changes configuration in the MCS, or
   the UPF applies a protocol to share relevant states and information
   with the DPN.  This document does not consider a dedicated control
   interface between the MCS control plane and the DPN.  Relevant
   semantic to enable the DPN to propagate updated routes towards the
   transport network and the data network must be available at the UPA.
   This may require an extension to the MCS control plane to configure
   the UPA with information that is relevant for mobile traffic
   treatment and steering in the transport network and the data network.

        +----------MCS----------+  Transport Network  +--Data Network--+
        |                       |                     |                |
        | +-------------------+ |                     |     +---+      |
        | | MCS Control Plane | |                     |     +ACF|      |
        | +--+-------------+--+ |                     |     +---+      |
        |    |             |    |                     |       |        |
Mobile  | +--+--+      +--+---+---+           +-+-+   |    +--+-+      |
 User-----+ RAN +===/==+ UPA1 +DPN+-----------+DPN+---+----+ASF1|      |
        | +-----+      +------+---+           +-+-+   |    +----+      |
        |    ||                 |               |     +----------------+
        |    ||                 |               |     +----------------+
        |    ||        +------+---+           +-+-+   |    +----+      |
        |    +=========+ UPA2 +DPN+-----------|DPN|--------+ASF2|      |
        |              +------+---+           +---+   |    +----+      |
        +-----------------------+                     +----------------+

   Figure 5: End-to-end architecture with a routing protocol-based
      propagation of traffic steering policies and tight UPA-DPN
                               coupling

6.  Design Recommendations and Information Models

   This section will be compiled in an updated version of this draft.
   Details in this section depend on further analysis of operational
   aspects and required control plane interface semantics for enabling
   the different use cases in the end-to-end architecture with and
   without a dedicated TN controller.

Liebsch                  Expires 9 January 2025                [Page 12]
Internet-Draft           Mobile Traffic Steering               July 2024

   Dependency on MCS standards organizations in extending control plane
   semantics will be addressed in this section.

7.  IANA Considerations

   This document has no request to IANA.

8.  Security Considerations

   TBD.

9.  Acknowledgments

   This document includes results from discussion with various IETF and
   non-IETF delegates.  Many thanks to Jeffrey Zhang, Jari Mutikainen,
   Tianji Jiang and David Lake for their immediate interest in this
   topic and feedback at various opportunities and through different
   channels.  Many thanks also to Joel Halpern for his clear and apt
   feedback during the public side meeting@IETF118 and to Sri Gundavelli
   and Satoru Matsushima for their support and advice on this matter.

10.  References

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2.  Informative References

   [I-D.zzhang-dmm-mup-evolution]
              Zhang, Z. J., Patel, K., Contreras, L. M., Islam, K.,
              Mutikainen, J., Jiang, T., Jalil, L., Sejati, O. P., and
              S. Zadok, "Mobile User Plane Evolution", Work in Progress,
              Internet-Draft, draft-zzhang-dmm-mup-evolution-09, 2 July
              2024, <https://datatracker.ietf.org/doc/html/draft-zzhang-
              dmm-mup-evolution-09>.

Liebsch                  Expires 9 January 2025                [Page 13]
Internet-Draft           Mobile Traffic Steering               July 2024

   [I-D.zzhang-dmm-5gdn-end-marker]
              Zhang, Z. J., Liebsch, M., and T. Jiang, "End Marker in 5G
              Data Network", Work in Progress, Internet-Draft, draft-
              zzhang-dmm-5gdn-end-marker-01, 6 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-dmm-
              5gdn-end-marker-01>.

Author's Address

   Marco Liebsch
   NEC Laboratories Europe GmbH
   Kurfuersten-Anlage 36
   D-69115 Heidelberg
   Germany
   Email: marco.liebsch@neclab.eu

Liebsch                  Expires 9 January 2025                [Page 14]