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

Versions: 00 01 02

DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                                     R. Li
Intended status: Standards Track                              Huawei USA
Expires: April 19, 2019                                      J. Tantsura
                                                            Apstra, Inc.
                                                            L. Contreras
                                                              Telefonica
                                                               X. De Foy
                                        InterDigital Communications, LLC
                                                        October 16, 2018


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

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 specified in a way to address all the mobility scenarios
   defined in [TS23.501] and to be backward compatible with LTE
   [TS.23.401-3GPP] network deployments.

   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 (IPv4, IPv6, MPLS) 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
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.




Chunduri, et al.         Expires April 19, 2019                 [Page 1]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   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 April 19, 2019.

Copyright Notice

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

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

Table of Contents

   1.  Introduction and Problem Statement  . . . . . . . . . . . . .   3
     1.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Solution Approach . . . . . . . . . . . . . . . . . . . .   5
   2.  Transport Network (TN) and Slice aware Mobility on N3/N9  . .   5
     2.1.  Discrete Approach . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Integrated Approach . . . . . . . . . . . . . . . . . . .   7
     2.3.  Transport Network Function  . . . . . . . . . . . . . . .   9
   3.  Using PPR as TN Underlay  . . . . . . . . . . . . . . . . . .   9
     3.1.  PPR with Transport Awareness for 5GS on N3/N9 Interfaces   10
     3.2.  Path Steering Support to native IP user planes  . . . . .  12
     3.3.  Service Level Guarantee in Underlay . . . . . . . . . . .  12
     3.4.  PPR with various 5G Mobility procedures . . . . . . . . .  12
       3.4.1.  SSC Mode1 . . . . . . . . . . . . . . . . . . . . . .  12
       3.4.2.  SSC Mode2 . . . . . . . . . . . . . . . . . . . . . .  13
       3.4.3.  SSC Mode3 . . . . . . . . . . . . . . . . . . . . . .  14
   4.  Other TE Technologies Applicability . . . . . . . . . . . . .  15
   5.  Summary and Benefits with PPR . . . . . . . . . . . . . . . .  15
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Appendix: New Control Plane and User Planes  . . . .  19



Chunduri, et al.         Expires April 19, 2019                 [Page 2]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


     A.1.  LISP and PPR  . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  ILA and PPR . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction and Problem Statement

   3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP],
   [TS.23.502-3GPP], [TS.23.503-3GPP].  A new user plane interface N9
   [TS.23.501-3GPP] has been created between 2 User Plane
   Functionalities (UPFs).  While user plane for N9 interface being
   finalized for REL16, both GTP-U based encapsulation or any other
   compatible approach is being considered [CT4SID].  Concerning to this
   document another relevant interface is N3, which is between gNB and
   the UPF.  N3 interface is similar to the user plane interface S1U in
   LTE [TS.23.401-3GPP].  This document:

   o  does not propose any change to existing N3 user plane
      encapsulations to realize the benefits with the approach specified
      here

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

   [TS.23.501-3GPP] defines various Session and Service Continuity (SSC)
   modes and mobility scenarios for 5G with slice awareness from Radio
   and 5G Core (5GC) network. 5G System (5GS) as defined, allows
   transport network between N3 and N9 interfaces work independently
   with various IETF Traffic Engineering (TE) technologies.

   However, lack of underlying Transport Network (TN) awareness can be
   problematic for some of the 5GS procedures, for real-time, mission-
   critical or for any deterministic latency services.  These 5GS
   procedures including but not limited to Service Request, PDU Session,
   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 various 5QI's
   defined in [TS.23.501-3GPP] .

1.1.  Acronyms

   5QI      -  5G QoS Indicator

   AMF      -  Access and Mobility Management Function (5G)

   BP       -  Branch Point (5G)

   CSR      -  Cell Site Router




Chunduri, et al.         Expires April 19, 2019                 [Page 3]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   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)

   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)




Chunduri, et al.         Expires April 19, 2019                 [Page 4]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


1.2.  Solution Approach

   This document specifies a mechanism to fulfil the needs of 5GS to
   transport user plane traffic from gNB 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.  TN with mobility awareness
   described here in a way, which does not erase performance and latency
   gains made with 5G New Radio(5GNR) and virtualized cellular core
   network features developed in [TS.23.501-3GPP].

   Section 2 describes two methods, with which Transport Network (TN)
   aware mobility can be built irrespective of underlying TN technology
   used.  Using Preferred Path Routing (PPR) as TN Underlay is detailed
   in Section 3.  Section 3.4 further describes the applicability and
   procedures of the same with 5G SSC modes on N3 and N9 interfaces.  At
   the end, Section 5 recapitulates the benefits of specified approach
   in mobile networks.

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



                        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



Chunduri, et al.         Expires April 19, 2019                 [Page 5]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   component Transport Network Function (TNF).  A Cell Site Router (CSR)
   is shown connecting to gNB.  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.

   Currently specified Control Plane (CP) functions Access and Mobility
   Management Function (AMF), Session Management Function (SMF) and User
   plane (UP) components gNodeB (gNB), User Plane Function (UPF) with
   N2, N3, N4, N6 and N9 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).
   Unlike S1U, N3 has some additional aspects as there is no bearer
   concept and per no per bearer GTP-U tunnels.  Instead, QoS
   information is carried in the PDU Session Container GTP-U extension
   header.  N9 interface is a new interface to connect UPFs and right
   user plane protocol/encapsulation is being studied through 3GPP CT4
   WG approved study item [CT4SID] for REL-16.

   TN Aware Mobility with optimized transport network functionality is
   explained below.  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.  Discrete Approach

   In this approach transport network functionality from gNB 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 gNB at 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.

   In this case, the encapsulation provided by GTP-U helps carry
   different PDU session types (IPv4, IPv6, IPv4IPv6, Ethernet and
   Unstructured) independent of the underlying transport or user plane
   (IPv4, IPv6 or MPLS) network.  Mapping of the PDU sessions to TE
   paths can be done based on the source UDP port ranges (if these are



Chunduri, et al.         Expires April 19, 2019                 [Page 6]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   assigned based on the PDU session QCIs, as done in some deployments
   with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or
   RQI values in the GTP-U header.  Here, 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
   gNB to UPF (on N3/N9 interfaces).  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 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 in Xn mobility event, without knowing if
   the target gNB is having a underlay transport slice resource for the
   5QI of the PDU session.  The below approach can mitigate this.

2.2.  Integrated Approach

   Network Slice Selection Function (NSSF) as defined in
   [TS.23.501-3GPP] concerns with multiple aspects including selecting a
   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 N3IWF
   for non-3GPP access.  Slice functionality is per PDU session
   granularity, which covers needed functionality and resources from UE
   registration, Tracking Area (TA) updates, mobility and roaming,
   resources and functionalities needed from transport network is not
   specified.  This is seen as independent functionality and currently
   not part of 5GS.  If transport network is not factored in an
   integrated fashion w.r.t available resources (with network
   characteristics from desired bandwidth, latency, burst size handling
   and optionally jitter) some of the gains made with optimizations
   through 5GNR and 5GC can be degraded.

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



Chunduri, et al.         Expires April 19, 2019                 [Page 7]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   interfaces can be part of the integrated 3GPP architecture, but the
   specification/ownership of these interfaces SHOULD be left out of
   scope of 3GPP.

   These VPNs and/or underlay TE paths MUST be similar on all gNB/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].  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]).

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

   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  Mapping of PDU session parameters to underlay SST paths need to be
      done.  One way to do this is through 5QI/QFI information in the
      GTP-U header and map the same to the underlying transport path
      (including VPN or PW).  This works for uplink (UL) direction.

   o  For downlink direction RQI need to be considered to map the DL
      packet to one of the underlay paths at the UPF.

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

   o  In some SSC modes Section 3.4, 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.





Chunduri, et al.         Expires April 19, 2019                 [Page 8]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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

   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.

   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.3.  Transport Network Function

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

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 April 19, 2019                 [Page 9]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   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 (encap or no-encap).  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 signaled from any node in the
      transport network.  For Uplink traffic, gNB will choose the right
      PPR-ID of the UPF based on the 5QI value in the encapsulation
      header of the PDU session.  Similarly in the Downlink direction
      matching PPR-ID of the gNB is chosen for the RQI value in the
      encapsulated SL payload.  The table below shows a typical mapping:






























Chunduri, et al.         Expires April 19, 2019                [Page 10]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


      +----------------+------------+------------------+-----------------+
      | 5QI (Ranges)/  |   SST      |   Transport Path | Transport Path  |
      | RQI (Ranges)   |            |   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 2: 5QI/RQI 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 gNBs 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, AMF
      and 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 April 19, 2019                [Page 11]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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.

3.4.  PPR with various 5G Mobility procedures

   PPR fulfills the needs of 5GS to transport the user plane traffic
   from gNB 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 from one gNB to another gNB, there is no transport network
   reconfiguration require 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.

3.4.1.  SSC Mode1










Chunduri, et al.         Expires April 19, 2019                [Page 12]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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


       Figure 3: 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 4: 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).

3.4.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 April 19, 2019                [Page 13]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   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.

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



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



                Figure 5: SSC Mode3 and Service Continuity

   In the uplink direction for the traffic offloading from UL/CL case,
   packet has to reach to the right exit UPF.  In this case packet gets
   re-encapsulated with ULCL marker (with either GTP-U or the chosen
   encapsulation) after bit rate enforcement and LI to the anchor UPF.
   At this point packet has to be on the appropriate VPN/PW to the
   anchor UPF.  This mapping is done based on the 5QI 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/ULCL UPF.  Here mapping is done for
   RQI parameter in the encapsulation header to PPR-ID (TE Path) of the
   BP/ULCL UPF.  If it's a non-MPLS underlay, destination IP address of




Chunduri, et al.         Expires April 19, 2019                [Page 14]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   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 AMF/SMF has to ensure transport resources
      are available for N3 Interface to new ULCL 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 created PDU session.

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
   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.  Summary and Benefits with PPR

   This document specifies an approach to transport and slice aware
   mobility with a simple mapping function from PDU Session to transport
   path applicable to any TE underlay.

   This also describes PPR
   [I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay
   routing mechanism, which helps with goal of optimized user plane for
   N9 interface.  PPR provides a method for N3 and N9 interfaces to
   support transport slicing in a way which does not erase the gains



Chunduri, et al.         Expires April 19, 2019                [Page 15]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   made with 5GNR and virtualized cellular core network features for
   various types of 5G traffic (e.g. needing low and deterministic
   latency, real-time, mission-critical or AR/VR traffic).  PPR provides
   path steering, optionally guaranteed services with TE, unique Fast-
   ReRoute (FRR) mechanism with preferred backups (beyond shortest path
   backups through existing LFA schemes) in the mobile backhaul network
   with any underlay being used in the operator's network (IPv4, IPv6 or
   MPLS) in an optimized fashion.

6.  Acknowledgements

   Thanks to Young Lee and John Kaippallimalil 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.

7.  IANA Considerations

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

8.  Security Considerations

   This document does not introduce any new security issues.

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 April 19, 2019                [Page 16]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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

   [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-01 (work in
              progress), July 2018.

   [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-01 (work in
              progress), July 2018.

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

   [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-02 (work in progress), July 2018.

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

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





Chunduri, et al.         Expires April 19, 2019                [Page 17]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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

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



Chunduri, et al.         Expires April 19, 2019                [Page 18]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


   [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.29.281-3GPP]
              3rd Generation Partnership Project (3GPP), "GPRS Tunneling
              Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
              December 2017.

Appendix A.  Appendix: New Control Plane and User Planes

A.1.  LISP and PPR

   PPR can also be used with LISP control plane for 3GPP as described in
   [I-D.farinacci-lisp-mobile-network].  This can be achieved by mapping
   the UE IP address (EID) to PPR-ID, which acts as Routing Locator
   (RLOC).  Any encapsulation supported by LISP can work well with PPR.
   If the RLOC refers to an IPv4 or IPv6 destination address in the LISP
   encapsulated header, packets are transported on the preferred path in
   the network as opposed to traditional shortest path routing with no
   additional user plane overhead related to TE path in the network
   layer.

   Some of the distinct advantages of the LISP approach is, its
   scalability, support for service continuity in SSC Mode3 as well as
   native support for session continuity (session survivable mobility).
   Various other advantages are documented at
   [I-D.farinacci-lisp-mobile-network].

A.2.  ILA and PPR

   If an ILA-prefix is allowed to refer to a PPR-ID, ILA can be
   leveraged with all the benefits (including mobility) that it
   provides.  This works fine in the DL direction as packet is destined
   to UE IP address at UPF.  However, in the UL direction, packet is
   destined to an external internet address (SIR Prefix to ILA Prefix
   transformation happens on the Source address of the original UE
   packet).  One way to route the packet with out bringing the complete
   DFZ BGP routing table is by doing a default route to the UPF (ILA-R).
   In this case, how TE can be achieved is TBD (to be expanded further
   with details).

Authors' Addresses







Chunduri, et al.         Expires April 19, 2019                [Page 19]


Internet-Draft   Transport Network aware Mobility for 5G    October 2018


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

   Email: uma.chunduri@huawei.com


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

   Email: renwei.li@huawei.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


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

   Email: Xavier.Defoy@InterDigital.com











Chunduri, et al.         Expires April 19, 2019                [Page 20]

Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/