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

Versions: 00

DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                                 Futurewei
Intended status: Informational                              L. Contreras
Expires: May 6, 2021                                          Telefonica
                                                            S. Bhaskaran
                                                               Altiostar
                                                             J. Tantsura
                                                            Apstra, Inc.
                                                                P. Muley
                                                                   Nokia
                                                        November 2, 2020


                  Transport aware 5G mobility with PPR
               draft-chunduri-dmm-5g-mobility-with-ppr-00

Abstract

   This document describes few 5G mobility scenarios and how mobile
   network functions map its SST criteria to identifiers in IP packets
   that transport segments use to grant transport layer services.  This
   is based on mapping between mobile and IP transport underlays (IPv6,
   MPLS, IPv4) and a new transport network underlay routing mechanism,
   Preferred Path Routing (PPR), which brings slice properties and works
   with any underlying transport (L2, IPv4, SR and MPLS) is described.

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

   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 May 6, 2021.



Chunduri, et al.           Expires May 6, 2021                  [Page 1]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


Copyright Notice

   Copyright (c) 2020 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Transport Network Underlays . . . . . . . . . . . . . . . . .   4
     2.1.  Using PPR as TN Underlay  . . . . . . . . . . . . . . . .   4
       2.1.1.  PPR on F1-U/N3/N9 Interfaces  . . . . . . . . . . . .   5
       2.1.2.  Path Steering Support to native IP user planes  . . .   6
       2.1.3.  Service Level Guarantee in Underlay . . . . . . . . .   6
   3.  PPR with various 5G Mobility procedures . . . . . . . . . . .   7
     3.1.  SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   [I-D.clt-dmm-tn-aware-mobility] describes in detail on how TN aware
   mobility can be built irrespective of underlying TN technology used.

   This document specifies an approach to fulfil the needs of 5GS to
   transport user plane traffic from 5G-AN to UPF for all session and
   service continuity modes (SSC) [TS.23.501-3GPP] in an optimized
   fashion.  This is done by, keeping establishment and mobility
   procedures aware of underlying transport network along with slicing
   requirements using integrated routing and traffic engineering
   mechanism, Preferred Path Routing (PPR).



Chunduri, et al.           Expires May 6, 2021                  [Page 2]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


   PPR is applicable to any transport network underlay (IPv6, MPLS and
   IPv4) is detailed in Section 2.1 used 5G x-haul as described in
   [I-D.clt-dmm-tn-aware-mobility] .  At the end, Section 3 further
   describes the applicability and procedures of PPR with 5G mobility
   scenarios in variou mobility scenarios in variouss SSC modes on F1-U,
   N3 and N9 interfaces.

1.1.  Acronyms

   5G-AN    -  5G Access Network

   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)

   GTP-U    -  GPRS Tunneling Protocol - Userplane (3GPP)

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

   mIOT     -  Massive IOT (5G)

   MPLS     -  Multi Protocol Label Switching

   NSSMF    -  Network Slice Selection Management Function

   PPR      -  Preferred Path Routing

   PDU      -  Protocol Data Unit (5G)

   RAN      -  Radio Access Network

   SID      -  Segment Identifier

   SSC      -  Session and Service Continuity (5G)

   SST      -  Slice and Service Types (5G)

   SR       -  Segment Routing



Chunduri, et al.           Expires May 6, 2021                  [Page 3]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


   TE       -  Traffic Engineering

   ULCL     -  Uplink Classifier (5G)

   UP       -  User Plane(5G)

   UPF      -  User Plane Function (5G)

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

2.  Transport Network Underlays

   Apart from the various flavors of IETF VPN technologies to share the
   transport network resources and capacity, TE capabilities in the
   underlay network is an essential component to realize the 5G TN
   requirements.  This section focuses on PPR and its applicability to
   realize Midhaul/Backhaul transport networks.  Focus is on the user/
   data plane i.e., F1-U/N3/N9 interfaces as laid out in the framework
   [I-D.clt-dmm-tn-aware-mobility].

2.1.  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].
   The need for underlay agnostic (L2/IPv4/IPv6/MPLS) TE requirements
   are addressed by PPR, of which this section provides an overview.

   With PPR, 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:

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

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

   o  PPR Graph Structure (P2MP) - [I-D.ce-lsr-ppr-graph]



Chunduri, et al.           Expires May 6, 2021                  [Page 4]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


2.1.1.  PPR on F1-U/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 F1-U/N3 and 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 for any underlying user/data plane used in
   the transport network (L2/IPv4/IPv6/MPLS).  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 based on the S-NSSAI the PDU Session belongs to
      and/or the UDP Source port (corresponds to the MTNC-ID
      [I-D.clt-dmm-tn-aware-mobility]) of 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:


      +----------------+------------+------------------+-----------------+
      |GTP/UDP SRC PORT|   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 1: Mapping of PPR-IDs on N3/N9





Chunduri, et al.           Expires May 6, 2021                  [Page 5]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


   o  It is possible to have a single PPR-ID for multiple input points
      through a PPR tree/graph structure ([I-D.ce-lsr-ppr-graph])
      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 2.1.2) with optional TE features (Section 2.1.3) .
      As this is an underlay mechanism it can work with any overlay
      encapsulation approach including GTP-U as defined currently for N3
      interface.

2.1.2.  Path Steering Support to native IP user planes

   PPR works in fully compatible way with SR [RFC8402] defined user
   planes (SR-MPLS and SRv6) by reducing the path overhead and other
   challenges as listed in Section 5.3.7 of
   [I-D.bogineni-dmm-optimized-mobile-user-plane].  PPR also expands the
   source routing to beyond SR-MPLS and SRv6 i.e., L2, 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.  Some of these benefits with PPR
   can be realized with no hardware upgrade except control plane
   software for native IPv6 and IPv4 user planes.

2.1.3.  Service Level Guarantee in Underlay

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








Chunduri, et al.           Expires May 6, 2021                  [Page 6]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


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

3.1.  SSC Mode1


                           +--------------+
             +---+----+    |NSSMF +-----+ | +----------------+
             |  AMF   |    |      | TNF | | |      SMF       |
             +---+--+-+    |      +-+-+-+ | +-----+----------+
                N1  |      +--------+-+---+       |
                 |  |               | |           |
                 |  |           +---+-+--+        |
                 |  |           | SDN-C  |        |
                 |  |           +---+-+--+        |
                 |  |               | |           |
        +--------+  N2    +---------+ + ---+      |
        |           |     |                |      |
        +    +---+--+   +--++             +---+ +-+--+     +----+
        UE1  |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN |
        ==   +---+      +---+             +---+ +----+     +----+


       Figure 2: SSC Mode1 with integrated Transport Slice Function

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














Chunduri, et al.           Expires May 6, 2021                  [Page 7]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


                           +--------------+
             +---+----+    |NSSMF +-----+ | +----------------+
             |  AMF   |    |      | TNF | | |      SMF       |
             +------+-+    |      +-+-+-+ | +-----+----------+
                    |      +--------+-+---+       |
                    |               | |           |
                    |           +---+-+--+        |
                    |           | SDN-C  |        |
                    |           +---+-+--+        |
                    |               | |           |
                    N2    +---------+ + ---+      |
                    |     |                |      |
             +---+--+   +--++             +---+ +-+--+     +----+
             |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN |
             +---+      +---+             +-+-+ +----+     +----+
                                            |
                                            |
                                            |
                                            |
            +----+      +---+               |
       UE1  |gNB2|======|CSR|------N3-------+
       ==   +----+      +---+


       Figure 3: 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.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
   application offload and application manage 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.








Chunduri, et al.           Expires May 6, 2021                  [Page 8]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


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



                          +--------------+
            +---+----+    |NSSMF +-----+ | +----------------+
            |  AMF   |    |      | TNF | | |      SMF       |
            +---+--+-+    |      +-+-+-+ | +-+-----------+--+
                |  |      +--------+-+---+   |           |
               N1  |               | |       |           |
                |  |           +---+-+--+    |           |
                |  |           | SDN-C  |    |           |
                |  |           +---+-+--+    |           |
                |  |               | |       |           |
      to-UE+----+  N2  +-----------+ |       N4        N4|
               +---+   |             |       |           |
               |       |             |       |           |
           +---+   +---++        +---+ +-------+--+    +---+ +---+
           |gNB|===|CSR |---N3---|PE |-| BP UPF   |-N9-|PE |-|UPF|-N6->
           +---+   +----+        +---+ +-------+--+    +---+ +---+ to DN
                                               | +----+
                                               +-| DN |
                                             N6  +----+



                Figure 4: 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



Chunduri, et al.           Expires May 6, 2021                  [Page 9]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


   chosen encapsulation) after bit rate enforcement and LI, towards 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 S-NSSAI the PDU
   session belongs to and/or with the UDP source port (corresponds to
   the MTNC-ID [I-D.clt-dmm-tn-aware-mobility]) of the GTP-U
   encapsulation header 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.

4.  Acknowledgements

   TBD.

5.  IANA Considerations

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

6.  Security Considerations

   This document does not introduce any new security issues.

7.  References








Chunduri, et al.           Expires May 6, 2021                 [Page 10]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


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

7.2.  Informative References

   [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.ce-lsr-ppr-graph]
              Chunduri, U. and T. Eckert, "Preferred Path Route Graph
              Structure", draft-ce-lsr-ppr-graph-04 (work in progress),
              September 2020.

   [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-06 (work in
              progress), September 2020.

   [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-04 (work in
              progress), March 2020.

   [I-D.clt-dmm-tn-aware-mobility]
              Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J.,
              Tantsura, J., Contreras, L., and P. Muley, "Transport
              Network aware Mobility for 5G", draft-clt-dmm-tn-aware-
              mobility-07 (work in progress), September 2020.

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              Voyer, D., and C. Perkins, "Segment Routing IPv6 for
              Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09
              (work in progress), July 2020.






Chunduri, et al.           Expires May 6, 2021                 [Page 11]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

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

Authors' Addresses

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

   Email: umac.ietf@gmail.com


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

   Email: luismiguel.contrerasmurillo@telefonica.com


   Sridhar Bhaskaran
   Altiostar

   Email: sridharb@altiostar.com


   Jeff Tantsura
   Apstra, Inc.

   Email: jefftant.ietf@gmail.com





Chunduri, et al.           Expires May 6, 2021                 [Page 12]


Internet-Draft    Transport aware 5G mobility with PPR     November 2020


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

   Email: praveen.muley@nokia.com












































Chunduri, et al.           Expires May 6, 2021                 [Page 13]

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