[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                                     R. Li
Intended status: Informational                                 Futurewei
Expires: January 9, 2020                                    S. Bhaskaran
                                                               Altiostar
                                                             J. Tantsura
                                                            Apstra, Inc.
                                                            L. Contreras
                                                              Telefonica
                                                                P. Muley
                                                                   Nokia
                                                       J. Kaippallimalil
                                                               Futurewei
                                                            July 8, 2019


                Transport Network aware Mobility for 5G
                   draft-clt-dmm-tn-aware-mobility-04

Abstract

   This document specifies a framework and a mapping function for 5G
   mobile user plane with transport network slicing, integrated with
   Mobile Radio Access and a Virtualized Core Network.  The integrated
   approach is specified in a way to fit into the 5G core network
   architecture defined in [TS23.501].

   It focuses on an optimized mobile user plane functionality with
   various transport services needed for some of the 5G traffic needing
   low and deterministic latency, real-time, mission-critical services.
   This document describes, how this objective is achieved agnostic to
   the transport underlay used (IPv6, MPLS, IPv4) in various deployments
   and with a new transport network underlay routing, called Preferred
   Path Routing (PPR).

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

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



Chunduri, et al.         Expires January 9, 2020                [Page 1]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   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 January 9, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Solution Approach . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Transport Network and Slice aware Mobility on N3/N9 . . . . .   5
     2.1.  Integrated Approach with TNF in SBI . . . . . . . . . . .   6
       2.1.1.  Transport Network Function and Interfaces . . . . . .   7
       2.1.2.  Functionality for E2E Management  . . . . . . . . . .   7
     2.2.  TNF as part of existing 5G Control Function . . . . . . .   9
       2.2.1.  Mobile Transport Network Context and Scalability  . .  11
       2.2.2.  MTNC Identifier in the Data Packet  . . . . . . . . .  12
   3.  Using PPR as TN Underlay  . . . . . . . . . . . . . . . . . .  12
     3.1.  PPR with Transport Awareness for 5GS on N3/N9 Interfaces   13
     3.2.  Path Steering Support to native IP user planes  . . . . .  15
     3.3.  Service Level Guarantee in Underlay . . . . . . . . . . .  15
   4.  Other TE Technologies Applicability . . . . . . . . . . . . .  15
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16



Chunduri, et al.         Expires January 9, 2020                [Page 2]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  New Control Plane and User Planes  . . . . . . . . .  19
     A.1.  Slice aware Mobility: Discrete Approach . . . . . . . . .  19
   Appendix B.  PPR with various 5G Mobility procedures  . . . . . .  20
     B.1.  SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . .  20
     B.2.  SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . .  21
     B.3.  SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP],
   [TS.23.502-3GPP] and [TS.23.503-3GPP].  User Plane Functions (UPF)
   are the data forwarding entities in the 5GC architecture.  The
   architecture allows the placement of Branching Point (BP) and Uplink
   Classifier (ULCL) UPFs closer to the access network (5G-AN).  The 5G-
   AN can be a radio access network or any non-3GPP access network, for
   example, WLAN.  The IP address is anchored by a PDU session anchor
   UPF (PSA UPF).

   N3, N9 Interfaces: The interface between the BP/ULCL UPF and the PSA
   UPF is called N9 [TS.23.501-3GPP].  While in REL15, 3GPP has adopted
   GTP-U for the N9 interface, new user plane protocols along with GTP-U
   are being investigated for N9 interface in REL16, as part of
   [CT4SID].  Concerning to this document another relevant interface is
   N3, which is between the 5G-AN and the UPF.  N3 interface is similar
   to the user plane interface S1U in LTE [TS.23.401-3GPP].  This
   document:

   o  Do not need architectural change to[TS.23.501-3GPP] to provide
      3GPP slice, QoS support in transport plane

   o  and can work with any encapsulation (including GTP-U) for the N9
      interface.

1.1.  Problem Statement

   [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one
   of the core capability of 5GC with slice awareness from Radio and 5G
   Core (5GC) network.  The 5G System (5GS) as defined, do not consider
   the resources and functionalities needed from transport network for
   the selection of UPF.  This is seen as independent functionality and
   currently not part of 5GS.

   However, the lack of underlying Transport Network (TN) awareness may
   lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS
   procedures.  This could also lead to inability to meet SLAs for real-



Chunduri, et al.         Expires January 9, 2020                [Page 3]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   time, mission-critical or latency sensitive services. 5GS procedures
   including but not limited to Service Request, PDU Session
   Establishment, or User Equipment (UE) mobility need same service
   level characteristics from the TN for the Protocols Data Unit (PDU)
   session, similar to as provided in Radio and 5GC for the various
   Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP].

1.2.  Solution Approach

   This document specifies 2 approaches to fulfil the needs of 5GS to
   transport user plane traffic from 5G-AN to UPF for all service
   continuity modes [TS.23.501-3GPP] in an optimized fashion.  This is
   done by, keeping mobility procedures aware of underlying transport
   network along with slicing requirements.

   Section 2 describes in detail on how TN aware mobility can be built
   irrespective of underlying TN technology used.  Using Preferred Path
   Routing (PPR), applicable to any transport network underlay (IPv6,
   MPLS and IPv4) is detailed in Section 3.  How other IETF TE
   technologies applicable for this draft is specified in Section 4.  At
   the end, Appendix B further describes the applicability and
   procedures of PPR with 5G SSC modes on N3 and N9 interfaces.

1.3.  Acronyms

   5QI      -  5G QoS Indicator

   5G-AN    -  5G Access Network

   AMF      -  Access and Mobility Management Function (5G)

   BP       -  Branch Point (5G)

   CSR      -  Cell Site Router

   DN       -  Data Network (5G)

   eMBB     -  enhanced Mobile Broadband (5G)

   FRR      -  Fast ReRoute

   gNB      -  5G NodeB

   GBR      -  Guaranteed Bit Rate (5G)

   IGP      -  Interior Gateway Protocols (e.g.  IS-IS, OSPFv2, OSPFv3)

   LFA      -  Loop Free Alternatives (IP FRR)



Chunduri, et al.         Expires January 9, 2020                [Page 4]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   mIOT     -  Massive IOT (5G)

   MPLS     -  Multi Protocol Label Switching

   QFI      -  QoS Flow ID (5G)

   PPR      -  Preferred Path Routing

   PDU      -  Protocol Data Unit (5G)

   PW       -  Pseudo Wire

   RQI      -  Reflective QoS Indicator (5G)

   SBI      -  Service Based Interface (5G)

   SID      -  Segment Identifier

   SMF      -  Session Management Function (5G)

   SSC      -  Session and Service Continuity (5G)

   SST      -  Slice and Service Types (5G)

   SR       -  Segment Routing

   TE       -  Traffic Engineering

   ULCL     -  Uplink Classifier (5G)

   UPF      -  User Plane Function (5G)

   URLLC    -  Ultra reliable and low latency communications (5G)

2.  Transport Network and Slice aware Mobility on N3/N9

   Currently specified Control Plane (CP) functions - the Access and
   Mobility Management Function (AMF), the Session Management Function
   (SMF) and the User plane (UP) components gNB, User Plane Function
   (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to this
   document.  Other Virtualized 5G control plane components NRF, AUSF,
   PCF, AUSF, UDM, NEF, and AF are not directly relevant for the
   discussion in this document and one can see the functionalities of
   these in [TS.23.501-3GPP].

   From encapsulation perspective, N3 interface is similar to S1U in 4G/
   LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to
   transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).



Chunduri, et al.         Expires January 9, 2020                [Page 5]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   Unlike S1U, N3 has some additional aspects as there is no bearer
   concept and no per bearer GTP-U tunnels.  Instead, QoS information is
   carried in the PDU Session Container GTP-U extension header.

   TN Aware Mobility with optimized transport network functionality is
   explained below with approaches specified in Section 2.1 and
   Section 2.2 . How PPR fits in this framework in detail along with
   other various TE technologies briefly are in Section 3 and Section 4
   respectively.

2.1.  Integrated Approach with TNF in SBI



                        Service Based Interfaces (SBI)
    ----+-----+-----+----+----+-----+----+--------+-----+----+------
        |     |     |    |    |     |    |        |     |    |
    +---+---+ |  +--+--+ | +--+---+ | +--+--+  +--+--+  |  +-+--+
    | NSSF  | |  | NRF | | | AUSF | | | UDM |  | NEF |  |  | AF |
    +-------+ |  +-----+ | +------+ | +-----+  +-----+  |  +----+
          +---+----+  +--+--+  +----++   +--------------+-+
          |  AMF   |  | PCF |  | TNF |   |      SMF       |
          +---+--+-+  +-----+  +-+-+-+   +-+-----------+--+
             N1  |               | |       |      To   |
    to-UE+----+  N2    +----Ns---+ +-Nn-+  N4  +--Nn-+ N4
                 |     |                |  |         | |
         +---+---+  +--++             +-+--+---+     +-+-----+      +----+
         |gNB+======+CSR+------N3-----+  UPF   +-N9--+  UPF  +--N6--+ DN |
         +---+      +---+             +-+------+     +-------+      +----+
                                        | +----+
                                        +-| DN |
                                      N6  +----+



                  Figure 1: 5G Service Based Architecture

   The above diagrams depicts one of the scenarios of the 5G network
   specified in [TS.23.501-3GPP] and with a new and virtualized control
   component Transport Network Function (TNF).  A Cell Site Router (CSR)
   is shown connecting to gNB. gNB is an entity in 5G-AN.  Though it is
   shown as a separate block from gNB, in some cases both of these can
   be co-located.  This document concerns with backhaul TN, from CSR to
   UPF on N3 interface or from Staging UPF to Anchor UPF on N9
   interface.

   Network Slice Selection Function (NSSF) as defined in
   [TS.23.501-3GPP] concerns with multiple aspects including selecting a



Chunduri, et al.         Expires January 9, 2020                [Page 6]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   network slice instance when requested by AMF based on the requested
   SNSSAI, current location of UE, roaming indication etc.  It also
   notifies NF service consumers (e.g AMF) whenever the status about the
   slice availability changes.  However, the scope is only in 5GC (both
   control and user plane) and NG Radio Access network including the
   N3IWF for the non-3GPP access.  The network slice instance(s)
   selected by the NSSF are applicable at a per PDU session granularity.
   An SMF and UPF are allocated from the selected slice instance during
   the PDU session establishment procedure.

2.1.1.  Transport Network Function and Interfaces

   To assuage the above situation, TNF is described (Figure 1) as part
   of control plane.  This has the view of the underlying transport
   network with all links and nodes as well as various possible underlay
   paths with different characteristics.  TNF can be seen as supporting
   PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get
   the TE and topology information of the underlying IGP network.

   A south bound interface Ns is shown which interacts with the 5G
   Access Network (e.g. gNB/CSR).  'Ns' can use one or more mechanism
   available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF
   [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay
   paths from gNB to UPF.  Ns and Nn interfaces can be part of the
   integrated 3GPP architecture, but the specification/ownership of
   these interfaces SHOULD be left out of scope of 3GPP.

   A north bound interface 'Nn' is shown from one or more of the
   transport network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as
   shown in Figure 1.  It would enable learning the TE characteristics
   of all links and nodes of the network continuously (through BGP-LS
   [RFC7752] or through a passive IGP adjacency and PCEP [RFC5440]).

   These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs
   and UPFs concerned to allow mobility of UEs while associated with one
   of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP].

   Proposed TNF as part of the 5GC shown in Figure 1 can be realized
   using Abstraction and Control of TE Networks (ACTN).  ACTN
   architecture, underlying topology abstraction methods and
   manageability considerations of the same are detailed in [RFC8453].

2.1.2.  Functionality for E2E Management

   With the TNF in 5GS Service Based Interface, the following additional
   functionalities are required for end-2-end slice management including
   the transport network:




Chunduri, et al.         Expires January 9, 2020                [Page 7]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   o  The Specific Network Slice Selection Assistance Information
      (SNSSAI) of PDU session's SHOULD be mapped to the assigned
      transport VPN and the TE path information for that slice.

   o  For transport slice assignment for various SSTs (eMBB, URLLC,
      MIoT) corresponding underlay paths need to be created and
      monitored from each transport end point (gNB/CSR and UPF).

   o  During PDU session creation, apart from radio and 5GC resources,
      transport network resources needed to be verified matching the
      characteristics of the PDU session traffic type.

   o  The TNF MUST provide an API that takes as input the source and
      destination 3GPP user plane element address, required bandwidth,
      latency and jitter characteristics between those user plane
      elements and returns as output a particular TE path's identifier,
      that satisfies the requested requirements.

   o  Mapping of PDU session parameters to underlay SST paths need to be
      done.  One way to do this to let the SMF install a Forwarding
      Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
      "Network Instance" in the UPF.  A "Network Instance" is a logical
      identifier for an underlying network.  The "Network Instance"
      pointed by the FAR can be mapped to a transport path (through L2/
      L3 VPN).  FARs are associated with Packet Detection Rule (PDR).
      PDRs are used to classify packets in the uplink (UL) and the
      downlink (DL) direction.  For UL GTP-U TEID and/or the QFI marked
      in the GTPU packet can be used for classifying a packet belonging
      to a particular slice characteristics.  For DL, at a PSA UPF, the
      UE IP address is used to identify the PDU session, and hence the
      slice a packet belongs to and the IP 5 tuple can be used for
      identifying the flow and QoS characteristics to be applied on the
      packet.

   o  If any other form of encapsulation (other than GTP-U) either on N3
      or N9 corresponding QFI information MUST be there in the
      encapsulation header.

   o  In some SSC modes Appendix B, if segmented path (gNB to
      staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then
      corresponding path characteristics MUST be used.  This includes a
      path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP
      UPF to eventual UPF access to DN.

   o  Continuous monitoring of transport path characteristics and
      reassignment at the endpoints MUST be performed.  For all the
      affected PDU sessions, degraded transport paths need to be updated
      dynamically with similar alternate paths.



Chunduri, et al.         Expires January 9, 2020                [Page 8]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   o  During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn
      based or N2 based), for target gNB selection, apart from radio
      resources, transport resources MUST be factored.  This enables
      handling of all PDU sessions from the UE to target gNB and this
      require co-ordination of gNB, AMF, SMF with the TNF module.

   Integrating the TNF as part of the 5GS Service Based Interfaces,
   provides the flexibility to control the allocation of required
   characteristics from the TN during a 5GS signaling procedure (e.g.
   PDU Session Establishment).  If TNF is seen as part of management
   plane, this real time flexibility is lost.  Changes to detailed
   signaling to integrate the above for various 5GS procedures as
   defined in [TS.23.502-3GPP] is beyond the scope of this document.

2.2.  TNF as part of existing 5G Control Function

   Another solution approach with TNF in Section 2.1 and transport
   provisioning for an engineered IP transport that supports 3GPP
   slicing and QoS requirements in [TS.23.501-3GPP] is described in this
   section.

   During a PDU session setup, the 3GPP AMF using input from the NSSF
   selects a network slice and SMF.  The SMF with user policy from
   Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF
   on the path of the PDU session.  While QoS and slice selection for
   the PDU session can be applied across the 3GPP control and user plane
   functions as outlined above, the transport underlay across N3 and N9
   segments do not have enough information to apply the resource
   constraints represented by the slicing and QoS classification.
   Current guidelines for interconnection with transport networks
   [IR.34-GSMA] provide an application mapping into DSCP.  However,
   apart from problems with classification of encrypted packets, these
   recommendations do not take into consideration other aspects in
   slicing like isolation, protection and replication.

   Transport networks have their own slice and QoS configuration based
   on domain policies and the underlying network capability.  Transport
   networks can enter into an agreement for virtual network services
   (VNS) with client domains using the ACTN [RFC8453] framework.  The
   3GPP mobile network, on the other side, defines a Network Slice
   Selection Management Function (NSSMF) [TS 28.533] that interacts with
   a TN domain manager (that is out of scope of 3GPP).

   The ACTN VN service can be used across the 3GPP and transport
   networks to provision and map between slices, QoS in the two domains.
   An abstraction that represents QoS and slice information in the
   mobile domain and mapped to ACTN VN service in the transport domain
   is represented here as MTNC (Mobile Transport Network Context)



Chunduri, et al.         Expires January 9, 2020                [Page 9]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   identifiers.  Details of how the 3GPP domain derives the MTNC
   identifiers and how it programs it across its control and user plane
   functions are for 3GPP standards to define.  For completeness, some
   minimal outlines are provided in the description below.

   When the 3GPP user plane function (gNB, UPF) does not terminate the
   transport underlay protocol (e.g., MPLS), it needs to be carried in
   the IP protocol header from end-to-end of the mobile transport
   connection (N3, N9).  [I-D.ietf-dmm-5g-uplane-analysis] discusses
   these scenarios in detail.

   Figure 2 shows a view of the functions and interfaces for
   provisioning the MTNC identifiers.  The focus is on provisioning
   between the 3GPP management plane (NSSMF), transport network (SDN-C)
   and carrying the MTNC identifiers in PDU packets for the transport
   network to grant the provisioned resources.

       +----------------------------------------------------+
       |                  3GPP Control/Management Plane     |
       |           +----------------------------------------|-------+
       |           | +---------------+                      |       |
       |           | | +-----+ NSSMF |                  +---+---+   |
       |           | | | TNF |       |                  |  SMF  |   |
       |           | | +--+--+       |                  +---+---+   |
       |           | +----|----------+                      |       |
       |           +------|---------------------------------|-------+
       |                  |ACTN (RFC8453)                   |
       |              +---+---+                             |
       |              | SDN-C +---+                         |
       |              +---+---+   |                         |
       | 3GPP N2/N4            ___^___                      |3GPP N2/N4
       |                 _____/       \_____                |
       |                /                   \               |
   +---+--+           +--+       IP        +--+         +---+--+
   |UP-NF1|+++++++++++|PE|    Backhaul     |PE|+++++++++|UP-NF2|
   +------+           +--+                 +--+         +------+
                        \_____         _____/
                              \       /
                                ---v---

                 Figure 2: 5G Transport Plane Provisioning

   In Figure 2, the TNF (logical functionality within the NSSMF)
   requests the SDN-C in the transport domain to program the TE path
   using ACTN [RFC 8453].  The SDN-C programs the Provider Edge (PE)
   routers and internal routers according to the underlay transport
   technology (e.g., PPR, MPLS, SRv6).  The PE router inspects incoming




Chunduri, et al.         Expires January 9, 2020               [Page 10]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   PDU data packets for the MTNC identifier, classifies and provides the
   VN service provisioned across the transport network.

   The detailed mechanisms by which the NSSMF provides the MTNC
   identifiers to the control plane and user plane functions are for
   3GPP to specify.  Two possible options are outlined below for
   completeness.  The NSSMF may provide the MTNC identifiers to the 3GPP
   control plane by either providing it to the Session Management
   Function (SMF), and the SMF in turn provisions the user plane
   functions (UP-NF1, UP-NF2) during PDU session setup.  Alternatively,
   the user plane functions may request the MTNC identifiers directly
   from the NSSMF.

   In this approach, TNF can be seen as a logical entity that can be
   part of NSSMF in the 3GPP management plane [TS.28.533-3GPP].  The
   NSSMF may use network configuration, policies, history, heuristics or
   some combination of these to derive traffic estimates that the TNF
   would use.  How these estimates are derived are not in the scope of
   this document.  The focus here is only in terms of how the TNF and
   SDN-C are programmed given that slice and QoS characteristics across
   a transport path can be represented by an MTNC identifier.  The TNF
   requests the SDN-C in the transport network to provision paths in the
   transport domain based on the MTNC identifier.  The TNF is capable of
   providing the MTNC identifier provisioned to control and user plane
   functions in the 3GPP domain.  Detailed mechanisms for programming
   the MTNC identifier should be part of the 3GPP specifications.

2.2.1.  Mobile Transport Network Context and Scalability

   The MTNC (Mobile Transport Network Context) represents a slice, QoS
   configuration for a transport path between two 3GPP user plane
   functions.  The Mobile-Transport Network Context Identifier (MTNC-ID)
   is generated by the TNF to be unique for each path and per traffic
   class (including QoS and slice aspects).  Thus, there may be more
   than one MTNC-ID for the same QoS and path if there is a need to
   provide isolation (slice) of the traffic.  It should be noted that
   MTNC are per class/path and not per user session (nor is it per data
   path entity).  The MTNC identifiers are configured by the TNF to be
   unique within a provisioning domain.

   Since the MTNC identifiers are not generated per user flow or
   session, there is no need for unique MTNC identifiers per flow/
   session.  In addition, since the traffic estimation not performed at
   the time of session establishment, there is no provisioning delay
   experienced during session setup.  The MTNC identifier space scales
   as a square of the number sites between which 3GPP user plane
   functions require paths.  If there are T traffic classes across N
   sites, the number of MTNC identifiers in a fully meshed network is



Chunduri, et al.         Expires January 9, 2020               [Page 11]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   (N*(N-1)/2) * T.  For example, if there are 3 traffic classes between
   25 sites, there would be at most 900 MTNC identifiers required.
   Multiple slices for the same QoS class that need to be fully
   isolated, will add to the MTNC provisioning.  An MTNC identifier
   space of 16 bits (65K+ identifiers) can be expected to be sufficient.

2.2.2.  MTNC Identifier in the Data Packet

   When the 3GPP user plane function (gNB, UPF) and transport provider
   edge are on different nodes, the PE router needs to have the means by
   which to classify the PDU packet.  IP header fields such as DSCP
   (DiffServ Code Point) or the IPv6 Flow Label do not satisfy the
   requirement as they are not immutable.

   Different options for carrying the MTNC identifier in the IP data
   packet or in the existing user plane overlay like GTP-U
   [TS.29.281-3GPP] or a new overlay like GUE
   [I-D.ietf-intarea-gue-extensions] are possible.  There are various
   trade-offs in terms of packet overhead, support in IPv4 and IPv6
   networks as well as working across legacy and evolving transport
   networks that need to be considered.  These considerations will be
   addressed in future revisions.

3.  Using PPR as TN Underlay

   In a network implementing source routing, packets may be transported
   through the use of Segment Identifiers (SIDs), where a SID uniquely
   identifies a segment as defined in [I-D.ietf-spring-segment-routing].
   Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out
   all SRv6 features along with a few concerns in Section 5.3.7 of the
   same document.  Those concerns are addressed by a new backhaul
   routing mechanism called Preferred Path Routing (PPR), of which this
   section provides an overview.

   The label/PPR-ID refer not to individual segments of which the path
   is composed, but to the identifier of a path that is deployed on
   network nodes.  The fact that paths and path identifiers can be
   computed and controlled by a controller, not a routing protocol,
   allows the deployment of any path that network operators prefer, not
   just shortest paths.  As packets refer to a path towards a given
   destination and nodes make their forwarding decision based on the
   identifier of a path, not the identifier of a next segment node, it
   is no longer necessary to carry a sequence of labels.  This results
   in multiple benefits including significant reduction in network layer
   overhead, increased performance and hardware compatibility for
   carrying both path and services along the path.

   Details of the IGP extensions for PPR are provided here:



Chunduri, et al.         Expires January 9, 2020               [Page 12]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   o  IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing]

   o  OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing]

3.1.  PPR with Transport Awareness for 5GS on N3/N9 Interfaces

   PPR does not remove GTP-U, unlike some other proposals laid out in
   [I-D.bogineni-dmm-optimized-mobile-user-plane].  Instead, PPR works
   with the existing cellular user plane (GTP-U) for both N3 and any
   approach selected for N9 (encapsulation or no-encapsulation).  In
   this scenario, PPR will only help providing TE benefits needed for 5G
   slices from transport domain perspective.  It does so without adding
   any additional overhead to the user plane, unlike SR-MPLS or SRv6.
   This is achieved by:

   o  For 3 different SSTs, 3 PPR-IDs can be signaled from any node in
      the transport network.  For Uplink traffic, the 5G-AN will choose
      the right PPR-ID of the UPF based on the S-NSSAI the PDU Session
      belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U
      encapsulation header.  Similarly in the Downlink direction
      matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the
      PDU Session belongs to.  The table below shows a typical mapping:





























Chunduri, et al.         Expires January 9, 2020               [Page 13]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


      +----------------+------------+------------------+-----------------+
      | QFI (Ranges)   |   SST      |   Transport Path | Transport Path  |
      |                | in S-NSSAI |   Info           | Characteristics |
      +----------------+------------+------------------+-----------------+
      | Range Xx - Xy  |            |                  |                 |
      | X1, X2(discrete|  MIOT      | PW ID/VPN info,  | GBR (Guaranteed |
      | values)        |  (massive  |   PPR-ID-A       |       Bit Rate) |
      |                |   IOT)     |                  |   Bandwidth: Bx |
      |                |            |                  |   Delay:     Dx |
      |                |            |                  |   Jitter:    Jx |
      +----------------+------------+------------------+-----------------+
      | Range Yx - Yy  |            |                  |                 |
      | Y1, Y2(discrete|  URLLC     | PW ID/VPN info,  | GBR with Delay  |
      | values)        | (ultra-low | PPR-ID-B         |     Req.        |
      |                |  latency)  |                  |   Bandwidth: By |
      |                |            |                  |   Delay:     Dy |
      |                |            |                  |   Jitter:    Jy |
      +----------------+------------+------------------+-----------------+
      | Range Zx - Zy  |            |                  |                 |
      | Z1, Z2(discrete|  EMBB      | PW ID/VPN info,  |   Non-GBR       |
      | values)        | (broadband)| PPR-ID-C         |   Bandwidth: Bx |
      +----------------+------------+------------------+-----------------+



                Figure 3: QFI Mapping with PPR-IDs on N3/N9

   o  It is possible to have a single PPR-ID for multiple input points
      through a PPR tree structure separate in UL and DL direction.

   o  Same set of PPRs are created uniformly across all needed 5G-ANs
      and UPFs to allow various mobility scenarios.

   o  Any modification of TE parameters of the path, replacement path
      and deleted path needed to be updated from TNF to the relevant
      ingress points.  Same information can be pushed to the NSSF, and/
      or SMF as needed.

   o  PPR can be supported with any native IPv4 and IPv6 data/user
      planes (Section 3.2) with optional TE features (Section 3.3) . As
      this is an underlay mechanism it can work with any overlay
      encapsulation approach including GTP-U as defined currently for N3
      interface.








Chunduri, et al.         Expires January 9, 2020               [Page 14]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


3.2.  Path Steering Support to native IP user planes

   PPR works in fully compatible way with SR defined user planes (SR-
   MPLS and SRv6) by reducing the path overhead and other challenges as
   listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or
   Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane].  PPR
   also expands the source routing to user planes beyond SR-MPLS and
   SRv6 i.e., native IPv6 and IPv4 user planes.

   This helps legacy transport networks to get the immediate path
   steering benefits and helps in overall migration strategy of the
   network to the desired user plane.  It is important to note, these
   benefits can be realized with no hardware upgrade except control
   plane software for native IPv6 and IPv4 user planes.

3.3.  Service Level Guarantee in Underlay

   PPR also optionally allows to allocate resources that are to be
   reserved along the preferred path.  These resources are required in
   some cases (for some 5G SSTs with stringent GBR and latency
   requirements) not only for providing committed bandwidth or
   deterministic latency, but also for assuring overall service level
   guarantee in the network.  This approach does not require per-hop
   provisioning and reduces the OPEX by minimizing the number of
   protocols needed and allows dynamism with Fast-ReRoute (FRR)
   capabilities.

4.  Other TE Technologies Applicability

   RSVP-TE [RFC3209] provides a lean transport overhead for the TE path
   for MPLS user plane.  However, it is perceived as less dynamic in
   some cases and has some provisioning overhead across all the nodes in
   N3 and N9 interface nodes.  Also it has another drawback with
   excessive state refresh overhead across adjacent nodes and this can
   be mitigated with [RFC8370].

   SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal
   bandwidth reservation or mechanism to guarantee latency on the nodes/
   links on SR path.  But, SR allows path steering for any flow at the
   ingress and particular path for a flow can be chosen.  Some of the
   issues around path overhead/tax, MTU issues are documented at
   Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane].  SR-
   MPLS allows reduction of the control protocols to one IGP (with out
   needing for LDP and RSVP-TE).

   However, as specified above with PPR (Section 3), in the integrated
   transport network function (TNF) a particular RSVP-TE path for MPLS




Chunduri, et al.         Expires January 9, 2020               [Page 15]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   or SR path for MPLS and IPv6 with SRH user plane, can be supplied to
   SMF for mapping a particular PDU session to the transport path.

5.  Acknowledgements

   Thanks to Young Lee for discussions on this document including ACTN
   applicability for the proposed TNF.  Thanks to Sri Gundavelli and
   3GPP delegates who provided detailed feedback on this document.

6.  IANA Considerations

   This document has no requests for any IANA code point allocations.

7.  Security Considerations

   This document does not introduce any new security issues.

8.  Contributing Authors

   The following people contributed substantially to the content of this
   document and should be considered co-authors.

   Xavier De Foy
      InterDigital Communications, LLC
      1000 Sherbrooke West
      Montreal
      Canada

      Email: Xavier.Defoy@InterDigital.com

9.  References

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

9.2.  Informative References

   [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
              Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
              Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
              Camarillo, "Topology Independent Fast Reroute using
              Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
              lfa-05 (work in progress), October 2018.




Chunduri, et al.         Expires January 9, 2020               [Page 16]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   [I-D.bogineni-dmm-optimized-mobile-user-plane]
              Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
              Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
              Muscariello, L., Camarillo, P., and S. Homma, "Optimized
              Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
              optimized-mobile-user-plane-01 (work in progress), June
              2018.

   [I-D.chunduri-lsr-isis-preferred-path-routing]
              Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
              L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
              draft-chunduri-lsr-isis-preferred-path-routing-03 (work in
              progress), May 2019.

   [I-D.chunduri-lsr-ospf-preferred-path-routing]
              Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
              Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
              chunduri-lsr-ospf-preferred-path-routing-03 (work in
              progress), May 2019.

   [I-D.farinacci-lisp-mobile-network]
              Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
              for the Mobile Network", draft-farinacci-lisp-mobile-
              network-05 (work in progress), March 2019.

   [I-D.ietf-dmm-5g-uplane-analysis]
              Homma, S., Miyasaka, T., Matsushima, S., and d.
              daniel.voyer@bell.ca, "User Plane Protocol and
              Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-
              5g-uplane-analysis-02 (work in progress), July 2019.

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
              IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
              uplane-05 (work in progress), July 2019.

   [I-D.ietf-intarea-gue-extensions]
              Herbert, T., Yong, L., and F. Templin, "Extensions for
              Generic UDP Encapsulation", draft-ietf-intarea-gue-
              extensions-06 (work in progress), March 2019.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.




Chunduri, et al.         Expires January 9, 2020               [Page 17]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   [IR.34-GSMA]
              GSM Association (GSMA), "Guidelines for IPX Provider
              Networks (Previously Inter-Service Provider IP Backbone
              Guidelines, Version 14.0", August 2018.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <https://www.rfc-editor.org/info/rfc6830>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <https://www.rfc-editor.org/info/rfc7490>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <https://www.rfc-editor.org/info/rfc7752>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8370]  Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
              T. Saad, "Techniques to Improve the Scalability of RSVP-TE
              Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
              <https://www.rfc-editor.org/info/rfc8370>.







Chunduri, et al.         Expires January 9, 2020               [Page 18]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

   [TS.23.401-3GPP]
              3rd Generation Partnership Project (3GPP), "Procedures for
              4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018.

   [TS.23.501-3GPP]
              3rd Generation Partnership Project (3GPP), "System
              Architecture for 5G System; Stage 2, 3GPP TS 23.501
              v2.0.1", December 2017.

   [TS.23.502-3GPP]
              3rd Generation Partnership Project (3GPP), "Procedures for
              5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December
              2017.

   [TS.23.503-3GPP]
              3rd Generation Partnership Project (3GPP), "Policy and
              Charging Control System for 5G Framework; Stage 2, 3GPP TS
              23.503 v1.0.0", December 2017.

   [TS.28.533-3GPP]
              3rd Generation Partnership Project (3GPP), "Management and
              Orchestration Architecture Framework (Release 15)", June
              2018.

   [TS.29.281-3GPP]
              3rd Generation Partnership Project (3GPP), "GPRS Tunneling
              Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
              December 2018.

Appendix A.  New Control Plane and User Planes

A.1.  Slice aware Mobility: Discrete Approach

   In this approach transport network functionality from the 5G-AN to
   UPF is discrete and 5GS is not aware of the underlying transport
   network and the resources available.  Deployment specific mapping
   function is used to map the GTP-U encapsulated traffic at the 5G-AN
   (e.g. gNB) in UL and UPF in DL direction to the appropriate transport
   slice or transport Traffic Engineered (TE) paths.  These TE paths can
   be established using RSVP-TE [RFC3209] for MPLS underlay, SR
   [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or
   PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6
   with SRH, native IPv6 and native IPv4 underlays.



Chunduri, et al.         Expires January 9, 2020               [Page 19]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
   user plane traffic forwarding rules in the UPF.  The UPFs have a
   concept of a "Network Instance" which logically abstracts the
   underlying transport path.  When the SMF creates the packet detection
   rules (PDR) and forwarding action rules (FAR) for a PDU session at
   the UPF, the SMF identifies the network instance through which the
   packet matching the PDR has to be forwarded.  A network instance can
   be mapped to a TE path at the UPF.  In this approach, TNF as shown in
   Figure 1 need not be part of the 5G Service Based Interface (SBI).
   Only management plane functionality is needed to create, monitor,
   manage and delete (life cycle management) the transport TE paths/
   transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
   The management plane functionality also provides the mapping of such
   TE paths to a network instance identifier to the SMF.  The SMF uses
   this mapping to install appropriate FARs in the UPF.  This approach
   provide partial integration of the transport network into 5GS with
   some benefits.

   One of the limitations of this approach is the inability of the 5GS
   procedures to know, if underlying transport resources are available
   for the traffic type being carried in PDU session before making
   certain decisions in the 5G CP.  One example scenario/decision could
   be, a target gNB selection during a N2 mobility event, without
   knowing if the target gNB is having a underlay transport slice
   resource for the S-NSSAI and 5QI of the PDU session.  The Integrated
   approach specified below can mitigate this.

Appendix B.  PPR with various 5G Mobility procedures

   PPR fulfills the needs of 5GS to transport the user plane traffic
   from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP].  This
   is done in keeping the backhaul network at par with 5G slicing
   requirements that are applicable to Radio and virtualized core
   network to create a truly end-to-end slice path for 5G traffic.  When
   UE moves across the 5G-AN (e.g. from one gNB to another gNB), there
   is no transport network reconfiguration required with the approach
   above.

   SSC mode would be specified/defaulted by SMF.  No change in the mode
   once connection is initiated and this property is not altered here.

B.1.  SSC Mode1









Chunduri, et al.         Expires January 9, 2020               [Page 20]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


             +---+----+           +-----+   +----------------+
             |  AMF   |           | TNF |   |      SMF       |
             +---+--+-+           +-+-+-+   +-+--------------+
                N1  |               | |       |
        +--------+  N2    +----Ns---+ +-Nn-+  N4
        |           |     |                |  |
        +   +---+---+  +--++             +-+--+---+     +----+
       UE1  |gNB+======+CSR+------N3-----+  UPF   +-N6--+ DN |
       ==   +---+      +---+             +--------+     +----+


       Figure 4: SSC Mode1 with integrated Transport Slice Function

   After UE1 moved to another gNB in the same UPF serving area

             +---+----+           +-----+   +----------------+
             |  AMF   |           | TNF |   |      SMF       |
             +---_--+-+           +-+-+-+   +-+--------------+
                    |               | |       |
                    N2    +----Ns---+ +-Nn-+  N4
                    |     |                |  |
            +----+--+   +-+-+             ++--+----+     +----+
            |gNB1+======+CSR+------N3-----+  UPF   +-N6--+ DN |
            +----+      +---+             +---+----+     +----+
                                             |
                                             |
                                             |
                                             |
            +----+      +--++                |
       UE1  |gNB2+======+CSR+------N3--------+
       ==   +----+      +---+


       Figure 5: SSC Mode1 with integrated Transport Slice Function

   In this mode, IP address at the UE is preserved during mobility
   events.  This is similar to 4G/LTE mechanism and for respective
   slices, corresponding PPR-ID (TE Path) has to be assigned to the
   packet at UL and DL direction.  During Xn mobility as shown above,
   source gNB has to additionally ensure transport path's resources from
   TNF are available at the target gNB apart from radio resources check
   (at decision and request phase of Xn/N2 mobility scenario).

B.2.  SSC Mode2

   In this case, if IP Address is changed during mobility (different UPF
   area), then corresponding PDU session is released.  No session
   continuity from the network is provided and this is designed as an



Chunduri, et al.         Expires January 9, 2020               [Page 21]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   application offload and application manages the session continuity,
   if needed.  For PDU Session, Service Request and Mobility cases
   mechanism to select the transport resource and the PPR-ID (TE Path)
   is similar to SSC Mode1.

B.3.  SSC Mode3

   In this mode, new IP address may be assigned because of UE moved to
   another UPF coverage area.  Network ensures UE suffers no loss of
   'connectivity'.  A connection through new PDU session anchor point is
   established before the connection is terminated for better service
   continuity.  There are two ways in which this happens.

   o  Change of SSC Mode 3 PDU Session Anchor with multiple PDU
      Sessions.

   o  Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU
      Session.

   In the first mode, from user plane perspective, the two PDU sessions
   are independent and the use of PPR-ID by gNB and UPFs is exactly
   similar to SSC Mode 1 described above.  The following paragraphs
   describe the IPv6 multi-homed PDU session case for SSC Mode 3.



             +---+----+           +-----+   +----------------+
             |  AMF   |           | TNF |   |      SMF       |
             +---+--+-+           +-+-+-+   +-+-----------+--+
                N1  |               | |       |           |
       to-UE+----+  N2 +-------Ns---+ +-Nn-+  N4        N4|
                    |  |                   |  |           |
            +-------+--+        +--+-------+--+     +-----+-+
            |gNB/CSR   +---N3---+ BP UPF      +-N9--+  UPF  +-N6--
            +----------+        +----------+--+     +-------+ to DN
                                           | +----+
                                           +-| DN |
                                         N6  +----+



                Figure 6: SSC Mode3 and Service Continuity

   In the uplink direction for the traffic offloading from the Branching
   Point UPF, packet has to reach to the right exit UPF.  In this case
   packet gets re-encapsulated by the BP UPF (with either GTP-U or the
   chosen encapsulation) after bit rate enforcement and LI, towards the
   anchor UPF.  At this point packet has to be on the appropriate VPN/PW



Chunduri, et al.         Expires January 9, 2020               [Page 22]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   to the anchor UPF.  This mapping is done based on the S-NSSAI the PDU
   session belongs to and/or the QFI marking in the GTPU encapsulation
   header (e.g. 5QI value) to the PPR-ID of the exit node by selecting
   the respective TE PPR-ID (PPR path) of the UPF.  If it's a non-MPLS
   underlay, destination IP address of the encapsulation header would be
   the mapped PPR-ID (TE path).

   In the downlink direction for the incoming packet, UPF has to
   encapsulate the packet (with either GTP-U or the chosen
   encapsulation) to reach the BP UPF.  Here mapping is done based on
   the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the
   BP UPF.  If it's a non-MPLS underlay, destination IP address of the
   encapsulation header would be the mapped PPR-ID (TE path).  In
   summary:

   o  Respective PPR-ID on N3 and N9 has to be selected with correct
      transport characteristics from TNF.

   o  For N2 based mobility SMF has to ensure transport resources are
      available for N3 Interface to new BP UPF and from there the
      original anchor point UPF.

   o  For Service continuity with multi-homed PDU session same transport
      network characteristics of the original PDU session (both on N3
      and N9) need to be observed for the newly configured IPv6
      prefixes.

Authors' Addresses

   Uma Chunduri (editor)
   Futurewei
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: umac.ietf@gmail.com


   Richard Li
   Futurewei
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: richard.li@futurewei.com






Chunduri, et al.         Expires January 9, 2020               [Page 23]


Internet-Draft   Transport Network aware Mobility for 5G       July 2019


   Sridhar Bhaskaran
   Altiostar

   Email: sridhar.bhaskaran@gmail.com


   Jeff Tantsura
   Apstra, Inc.

   Email: jefftant.ietf@gmail.com


   Luis M. Contreras
   Telefonica
   Sur-3 building, 3rd floor
   Madrid  28050
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com


   Praveen Muley
   Nokia
   440 North Bernardo Ave
   Mountain View, CA  94043
   USA

   Email: praveen.muley@nokia.com


   John Kaippallimalil
   Futurewei
   5700 Tennyson Parkway, Suite 600
   Plano, TX  75024
   USA

   Email: john.kaippallimalil@futurewei.com














Chunduri, et al.         Expires January 9, 2020               [Page 24]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/