Skip to main content

Mobile User Plane Evolution
draft-zzhang-dmm-mup-evolution-01

Document Type Active Internet-Draft (individual)
Authors Zhaohui (Jeffrey) Zhang , Keyur Patel , Luis M. Contreras
Last updated 2022-07-11
Stream (None)
Intended RFC status (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-zzhang-dmm-mup-evolution-01
dmm                                                             Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Informational                                  K. Patel
Expires: 12 January 2023                                          Arrcus
                                                            L. Contreras
                                                              Telefonica
                                                            11 July 2022

                      Mobile User Plane Evolution
                   draft-zzhang-dmm-mup-evolution-01

Abstract

   [I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile
   user plane in 5G, including distributed UPFs and alternative user
   plane implementations that some vendors/operators are pushing without
   changing 3GPP architecture/signaling.  Building on top of that, this
   document further discusses potentially integrating UPF and Acess Node
   (AN) in a future generation (xG) of mobile network.

   This document is not an attempt to do 3GPP work in IETF.  Rather, it
   discusses potential integration of IETF/wireline and 3GPP/wireless
   technologies - first among parties who are familiar with both areas
   and friendly with IETF/wireline technologies.  If the ideas in this
   document are deemed reasonable, feasible and desired among these
   parties, they can then be brought to 3GPP for further discussions.

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 12 January 2023.

Zhang, et al.            Expires 12 January 2023                [Page 1]
Internet-Draft                MUP Evolution                    July 2022

Copyright Notice

   Copyright (c) 2022 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.  MUP Evolution in xG . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Integrated AN/UP Function . . . . . . . . . . . . . . . .   2
     1.2.  Separate AN/UP Functions Connected by Pseudo Wires  . . .   4
       1.2.1.  Details on Pseudo Wire  . . . . . . . . . . . . . . .   5
   2.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  MUP Evolution in xG

   [I-D.zzhang-dmm-5g-distributed-upf] describes evolution of mobile
   user plane in 5G [_3GPP-23.501], including distributed UPFs and
   alternative user plane implementations that some vendors/operators
   are pushing without changing 3GPP architecture/signaling.

   This section discusses potential MUP evolution in a future generation
   (referred to as xG) of mobile networks.  It does involve changes in
   3GPP architecture and signaling, so the purpose of this section is to
   share the ideas in IETF community first.  If it gains consensus
   within IETF community especially among mobile operators, then the
   proposal may be brought to 3GPP community for further discussions.

1.1.  Integrated AN/UP Function

   In the distributed UPF model for 5G [I-D.zzhang-dmm-5g-distributed-
   upf], AN and UPF are separate functions connected by N3 tunneling
   over a short/internel transport connection.  Routing happens on the
   UPF between the DN and UEs over the N3 tunnels, and relay happens on
   the AN between the N3 tunnels and AN protocol stack.

Zhang, et al.            Expires 12 January 2023                [Page 2]
Internet-Draft                MUP Evolution                    July 2022

   With AN and UPF functions more and more disaggregated and virtualized
   even in 5G, it is becoming more and more feasible and attractive to
   integrate the AN and UPF functions, eliminating the N3 tunneling and
   the relay on AN entirely.  The combined function is referred to as
   ANUP in this document, which does routing between DN and UEs over the
   AN protocol stack directly:

                            N6
       UE1          ANUP     |
   +---------+               |
   |App Layer|     routing   |
   +---------+ +--/---+---\-+|
   |PDU Layer| | PDU  |     ||      PE1
   +---------+ +------+IP+L2||    +----+--+
   |         | |      |     ||----+VRF1|  |
   | xG-AN   | |xG-AN +  or ||    +----+  |
   |         | |      |     ||    |VRFn|  |
   | Proto   | |Proto +Ether||    +----+--+
   |         | |      |     ||   (         )
   | Layers  | |Layers+-----+|  (           )
   |         | |      |  L1 ||  ( Transport  )
   +---------+ +------+-----+|  (            )
                             |  ( Network    )  PE3
                             |  (            +--+----+
       UE2          ANUP     |  (            |  |VRF1|
   +---------+               |  (            |  |----+
   |App Layer|     routing   |  (            |  |VRFn|
   +---------+ +--/---+---\-+|  (            +--+----+
   |PDU Layer| | PDU  |     ||  (            )
   +---------+ +------+IP+L2||  (           )
   |         | |      |     ||   (         )
   | xG-AN   | |xG-AN +  or ||    +----+--+
   |         | |      |     ||----+VRF1|  |
   | Proto   | |Proto +Ether||    +----+  |
   |         | |      |     ||    |VRFn|  |
   | Layers  | |Layers+-----+|    +----+--+
   |         | |      |  L1 ||      PE2
   +---------+ +------+-----+|
                             |

   With this architecture, 3GPP and IETF technologies are applied where
   they are best applicable: 3GPP technologies responsible for radio
   access and IETF technologies for the rest.  As IETF technologies
   continue to evolve, they can be automatically applied in mobile
   networks without any changes in 3GPP architecture/specification.

   Some advantages of this new architecture include:

Zhang, et al.            Expires 12 January 2023                [Page 3]
Internet-Draft                MUP Evolution                    July 2022

   *  Any kind of tunnels can be used for the DN VPN, whether it is MPLS
      or SRv6, w/o the overhead of UDP/GTP encapsulation compared to GTP
      tunneling.  Network slicing function is still supported (even with
      current GTP tunneling the transport network need to instantiate
      slices for N3/N9 tunnels as well).

   *  5G-LAN and MEC become native applications (PDU sessions terminate
      into the closest ANUP and routed/switched to various DNs).

   *  MBS becomes very simple - the ANUP gets the multicast traffic from
      the DN and then use either shared radio bearer or individual
      bearers to send to interested UEs.

   *  Simplified signaling - instead of separate N2/N4 signaling
      interface from separate AMF/UPF to separate AN/UPF entities, a
      single interface from a single controle plane entity to the single
      integrated ANUP is used.

   *  Simplified/Optimized data plane - AN-UPF connection is not needed
      anymore.

   Because the ANUP already implement the routing/switching functions,
   even the PE functions (for the DN VPN) could be optionally integrated
   into it, further streamlining end-to-end communication by reducing
   NFs and connections between them.

1.2.  Separate AN/UP Functions Connected by Pseudo Wires

   There are still cases where separate AN/UP functions are desired/
   required:

   *  An MNO may want to deploy one UPF for a cluster of ANs in
      proximity in some scenarios/locations

   *  An MNO may support MVNOs who have their own UP functions but make
      use of the hosting MNO's ANs

   *  Home Routed roaming requires separate HPLMN UPs and VPLMN ANs

   All these still require tunneling between ANs and UPs, but the
   tunneling can be achieved via IETF's Pseudo Wire technology [RFC3985]
   as shown in the following diagram.  Note that, using PW is just an
   option - GTP can still be used if that is desired.

Zhang, et al.            Expires 12 January 2023                [Page 4]
Internet-Draft                MUP Evolution                    July 2022

       UE1            AN
   +---------+
   |App Layer|
   +---------+
   |PDU Layer|      relay
   +---------+ +--/---+--\---+            Pseudo Wire
   |         | |      |      |--------------------------------+
   | xG-AN   | |xG-AN |  PW  |                                  \
   |         | |      |      |                                   \
   | Proto   | |Proto |Proto |    +----+--+                       \
   |         | |      |      |   (         )                       \
   | Layers  | |Layers|Layers|  (           )                       \
   |         | |      |      |  ( Transport  )               UP      \
   +---------+ +------+------+  (            )        |               +
                                ( Network    )  PE3   |    routing    |
                             N6 (            +--+----+|+--/--+---\--+ |
       UE2          ANUP      | (            |  |VRF1|||     | PDU  | |
   +---------+                | (            |  |----+||IP+L2+------+ |
   |App Layer|     routing    | (            |  |VRFn|||     |      | |
   +---------+ +--/---+---\-+ | (            +--+----+||  or |  PW  +-+
   |PDU Layer| | PDU  |     | | (            )        ||     |      |
   +---------+ +------+IP+L2| | (           )         ||Ether|Proto |
   |         | |      |     | |  (         )          ||     |      |
   | xG-AN   | |xG-AN +  or | |   +----+--+           ||-----|Layers|
   |         | |      |     +-+---+VRF1|  |           ||  L1 |      |
   | Proto   | |Proto +Ether| |   +----+  |           |+-----+------+
   |         | |      |     | |   |VRFn|  |           |
   | Layers  | |Layers+-----+ |   +----+--+           N6
   |         | |      |  L1 | |     PE2
   +---------+ +------+-----+ |
                              |

   On the AN, relay happens between the AN protocol stack and PW
   protocol stack.  On the UP (at the right side of the above diagram),
   routing happens at PDU layer (over the PW that is stitched to the AN
   protocol stack on the AN) between UE1 and N6 connection to VRF1 on
   PE3.  The UP is either one in HPLMN in Home Routed Roaming case (and
   the AN is in the VPLMN), or one in VMNO (and the AN is in the hosting
   MNO), or one for a cluster of ANs.

1.2.1.  Details on Pseudo Wire

   This section provides some details on how PWs are used for the AN-UP
   tunneling.

   From [RFC3985]:

Zhang, et al.            Expires 12 January 2023                [Page 5]
Internet-Draft                MUP Evolution                    July 2022

   ---------------------------------------------------------------------
   This document an architecture for Pseudo Wire Emulation
   Edge-to-Edge (PWE3) in support of [RFC3916].  It discusses the
   emulation of services such as Frame Relay, ATM, Ethernet, TDM, and
   SONET/SDH over packet switched networks (PSNs) using IP or MPLS.  It
   presents the architectural framework for pseudo wires (PWs), defines
   terminology, and specifies the various protocol elements and their
   functions.
     …
   PWs provide the following functions in order to emulate the behavior
   and characteristics of the native service.

       o Encapsulation of service-specific PDUs or circuit data arriving
         at the PE-bound port (logical or physical).
       o Carriage of the encapsulated data across a PSN tunnel.
       o Establishment of the PW, including the exchange and/or
         distribution of the PW identifiers used by the PSN tunnel
         endpoints.
   …
   The payload is classified into the following generic types of native
   data units:

       o Packet
       o Cell
       o Bit stream
       o Structured bit stream
   ---------------------------------------------------------------------

   When applied to tunneling between AN and UP, the PW payload type is
   "Packet" - IP packet or Ethernet frame (that is the over the SDAP
   layer between UE and AN) for IP or Ethernet PDU session respectively.
   In case of Unstructured PDU session type, the PW payload type would
   be "Bit stream" or "Structured bit stream".

   Also from [RFC3985]:

Zhang, et al.            Expires 12 January 2023                [Page 6]
Internet-Draft                MUP Evolution                    July 2022

   ---------------------------------------------------------------------
   Figure 2 illustrates the network reference model for point-to-point
   PWs.
            |<-------------- Emulated Service ---------------->|
            |          |<------- Pseudo Wire ------>|          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         Native service                               Native service
   ---------------------------------------------------------------------

   The following explains the mapping to AN-UP tunneling:

   *  CE1 corresponds to a UE and PE1 corresponds to the AN

   *  The radio link between CE1/UE and PE1/AN is the AC in PW
      architecture.  PDU session is the Emulated Service.  Pseudo Wire
      corresponds to the AN-UP tunnel.  TSN tunnel corresponds to the
      UDP tunnel that transports N3/N9 in 5G.

   *  PE2 and CE2 together correspond to the UP.  It could be viewed
      that the PE2 provides AN function (with the PW corresponding to
      the radio link) and CE2 provides the UP function.

   *  PE1 takes the PDU packet from UE (after decapsulate the SDAP
      stack), which is treated as PW payload, and sends to PE2 over the
      PW.  PE2 decapsulates the PW encapsulation and exposes the PDU
      (like that a gNB decapsulates the SDAP stack), which is then
      terminated by CE2 (though PE2 and CE2 are integrated into a single
      UP).

   In 5G Home Routed roaming architecture, there is a pair of I-UPFs
   between the two PLMNs - the N3 tunnel does not extend directly from a
   VPLMN's AN to a HPLMN's UPF.  The same concept also exists in VPN/PW
   technology - the I-UPFs are comparable to a pair of ASBRs that
   provide Option-B inter-AS VPN/PW services.

Zhang, et al.            Expires 12 January 2023                [Page 7]
Internet-Draft                MUP Evolution                    July 2022

2.  Security Considerations

   To be provided.

3.  Acknowledgements

   The authors thank Arda Akamn, Constantine Polychronopoulos, Sandeep
   Patel and Shraman Adhikary for their review, comments and suggestions
   to make this document and solution more complete.

4.  References

4.1.  Normative References

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <https://www.rfc-editor.org/info/rfc3985>.

4.2.  Informative References

   [_3GPP-23.501]
              "System architecture for the 5G System (5GS), V17.3.0",
              December 2021.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks

   Email: zzhang@juniper.net

   Keyur Patel
   Arrcus

   Email: keyur@arrcus.com

   Luis M. Contreras
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com

Zhang, et al.            Expires 12 January 2023                [Page 8]