< draft-clt-dmm-tn-aware-mobility-01.txt   draft-clt-dmm-tn-aware-mobility-02.txt >
DMM Working Group U. Chunduri, Ed. DMM Working Group U. Chunduri, Ed.
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Standards Track Huawei USA Intended status: Standards Track Huawei USA
Expires: January 17, 2019 J. Tantsura Expires: April 19, 2019 J. Tantsura
Nuage Networks Apstra, Inc.
L. Contreras L. Contreras
Telefonica Telefonica
X. De Foy X. De Foy
InterDigital Communications, LLC InterDigital Communications, LLC
July 16, 2018 October 16, 2018
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-clt-dmm-tn-aware-mobility-01 draft-clt-dmm-tn-aware-mobility-02
Abstract Abstract
This document specifies a framework and a mapping function for 5G This document specifies a framework and a mapping function for 5G
mobile user plane with transport network slicing, integrated with mobile user plane with transport network slicing, integrated with
Mobile Radio Access and a Virtualized Core Network. The integrated Mobile Radio Access and a Virtualized Core Network. The integrated
approach specified in a way to address all the mobility scenarios approach specified in a way to address all the mobility scenarios
defined in [TS23.501] and to be backward compatible with LTE defined in [TS23.501] and to be backward compatible with LTE
[TS.23.401-3GPP] network deployments. [TS.23.401-3GPP] network deployments.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2019. This Internet-Draft will expire on April 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5
2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5 2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5
2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6 2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6
2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7 2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7
2.3. Transport Network Function . . . . . . . . . . . . . . . 9
3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9
3.1. PPR with Transport Slicing aware Mobility on N3/N9 . . . 9 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 10
3.2. Path Steering Support to native IP user planes . . . . . 11 3.2. Path Steering Support to native IP user planes . . . . . 12
3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 11 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 12
3.4. PPR with various 5G Mobility procedures . . . . . . . . . 11 3.4. PPR with various 5G Mobility procedures . . . . . . . . . 12
3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 14
4. Other TE Technologies Applicability . . . . . . . . . . . . . 14 4. Other TE Technologies Applicability . . . . . . . . . . . . . 15
5. New Control Plane and User Planes . . . . . . . . . . . . . . 15 5. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15
5.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
5.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Appendix: New Control Plane and User Planes . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 16 A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Problem Statement 1. Introduction and Problem Statement
3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 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.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9
[TS.23.501-3GPP] has been created between 2 User Plane [TS.23.501-3GPP] has been created between 2 User Plane
Functionalities (UPFs). While user plane for N9 interface being Functionalities (UPFs). While user plane for N9 interface being
finalized for REL16, both GTP-U based encapsulation or any other finalized for REL16, both GTP-U based encapsulation or any other
compatible approach is being considered [CT4SID]. Concerning to this compatible approach is being considered [CT4SID]. Concerning to this
document another relevant interface is N3, which is between gNB and document another relevant interface is N3, which is between gNB and
skipping to change at page 5, line 21 skipping to change at page 5, line 21
network along with slicing requirements. TN with mobility awareness network along with slicing requirements. TN with mobility awareness
described here in a way, which does not erase performance and latency described here in a way, which does not erase performance and latency
gains made with 5G New Radio(5GNR) and virtualized cellular core gains made with 5G New Radio(5GNR) and virtualized cellular core
network features developed in [TS.23.501-3GPP]. network features developed in [TS.23.501-3GPP].
Section 2 describes two methods, with which Transport Network (TN) Section 2 describes two methods, with which Transport Network (TN)
aware mobility can be built irrespective of underlying TN technology aware mobility can be built irrespective of underlying TN technology
used. Using Preferred Path Routing (PPR) as TN Underlay is detailed used. Using Preferred Path Routing (PPR) as TN Underlay is detailed
in Section 3. Section 3.4 further describes the applicability and 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 procedures of the same with 5G SSC modes on N3 and N9 interfaces. At
the end, Section 6 recapitulates the benefits of specified approach the end, Section 5 recapitulates the benefits of specified approach
in mobile networks. in mobile networks.
2. Transport Network (TN) and Slice aware Mobility on N3/N9 2. Transport Network (TN) and Slice aware Mobility on N3/N9
Service Based Interfaces (SBI) Service Based Interfaces (SBI)
----+-----+-----+----+----+-----+----+--------+-----+----+------ ----+-----+-----+----+----+-----+----+--------+-----+----+------
| | | | | | | | | | | | | | | | | | | |
+---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+
| NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF |
+-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+
skipping to change at page 6, line 19 skipping to change at page 6, line 19
Currently specified Control Plane (CP) functions Access and Mobility Currently specified Control Plane (CP) functions Access and Mobility
Management Function (AMF), Session Management Function (SMF) and User Management Function (AMF), Session Management Function (SMF) and User
plane (UP) components gNodeB (gNB), User Plane Function (UPF) with plane (UP) components gNodeB (gNB), User Plane Function (UPF) with
N2, N3, N4, N6 and N9 are relevant to this document. Other N2, N3, N4, N6 and N9 are relevant to this document. Other
Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM,
NEF, and AF are not directly relevant for the discussion in this NEF, and AF are not directly relevant for the discussion in this
document and one can see the functionalities of these in document and one can see the functionalities of these in
[TS.23.501-3GPP]. [TS.23.501-3GPP].
N3 interface is similar to S1U in 4G/LTE [TS.23.401-3GPP] network and From encapsulation perspective, N3 interface is similar to S1U in 4G/
uses GTP-U [TS.29.281-3GPP] encapsulation to transport any UE PDUs LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to
(IPv4, IPv6, IPv4v6, Ethernet or Unstructured). N9 interface is a transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
new interface to connect UPFs in SSC Mode3 Section 3.4.3 and right 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 user plane protocol/encapsulation is being studied through 3GPP CT4
WG approved study item [CT4SID] for REL-16. WG approved study item [CT4SID] for REL-16.
TN Aware Mobility with optimized transport network functionality is TN Aware Mobility with optimized transport network functionality is
explained below. How PPR fits in this framework in detail along with explained below. How PPR fits in this framework in detail along with
other various TE technologies briefly are in Section 3 and Section 4 other various TE technologies briefly are in Section 3 and Section 4
respectively. respectively.
2.1. Discrete Approach 2.1. Discrete Approach
skipping to change at page 7, line 14 skipping to change at page 7, line 17
not be part of the 5G Service Based Interface (SBI). Only management not be part of the 5G Service Based Interface (SBI). Only management
plane functionality is needed to create, monitor, manage and delete plane functionality is needed to create, monitor, manage and delete
(life cycle management) the transport TE paths/transport slices from (life cycle management) the transport TE paths/transport slices from
gNB to UPF (on N3/N9 interfaces). This approach provide partial gNB to UPF (on N3/N9 interfaces). This approach provide partial
integration of the transport network into 5GS with some benefits. integration of the transport network into 5GS with some benefits.
One of the limitations of this approach is the inability of 5GS One of the limitations of this approach is the inability of 5GS
procedures to know, if underlying transport resources are available procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could certain decisions in the 5G CP. One example scenario/decision could
be, a target gNB selection in Xn mobility in SSC Mode1, without be, a target gNB selection in Xn mobility event, without knowing if
knowing if the target gNB is having a underlay transport slice the target gNB is having a underlay transport slice resource for the
resource for the 5QI of the PDU session. The below approach can 5QI of the PDU session. The below approach can mitigate this.
mitigate this.
2.2. Integrated Approach 2.2. Integrated Approach
Network Slice Selection Function (NSSF) as defined in Network Slice Selection Function (NSSF) as defined in
[TS.23.501-3GPP] concerns with multiple aspects related to creation, [TS.23.501-3GPP] concerns with multiple aspects including selecting a
selection, mobility, roaming and co-ordination among other CP network slice instance when requested by AMF based on the requested
functions in 5GS. However, the scope is only in 5GC (both control SNSSAI, current location of UE, roaming indication etc. It also
and user plane) and NG Radio Access network including N3IWF for non- notifies NF service consumers (e.g AMF) whenever the status about the
3GPP access. Slice functionality is per PDU session granularity. slice availability changes. However, the scope is only in 5GC (both
While this fully covers needed functionality and resources from UE 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, registration, Tracking Area (TA) updates, mobility and roaming,
resources and functionalities needed from transport network is not resources and functionalities needed from transport network is not
specified. This is seen as independent functionality though part of specified. This is seen as independent functionality and currently
5GS. If transport network is not factored in an integrated fashion not part of 5GS. If transport network is not factored in an
w.r.t available resources (with network characteristics from desired integrated fashion w.r.t available resources (with network
bandwidth, latency, burst size handling and optionally jitter) some characteristics from desired bandwidth, latency, burst size handling
of the gains made with optimizations through 5GNR and 5GC can be and optionally jitter) some of the gains made with optimizations
degraded. through 5GNR and 5GC can be degraded.
To assuage the above situation, TNF is described (Figure 1) as part To assuage the above situation, TNF is described (Figure 1) as part
of control plane. This has the view of the underlying transport of control plane. This has the view of the underlying transport
network with all links and nodes as well as various possible underlay network with all links and nodes as well as various possible underlay
paths with different characteristics. TNF can be seen as supporting paths with different characteristics. TNF can be seen as supporting
PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get
the TE and topology information of the underlying IGP network. the TE and topology information of the underlying IGP network.
A south bound interface Ns is shown which interacts with the gNB/CSR. A south bound interface Ns is shown which interacts with the gNB/CSR.
'Ns' can use one or more mechanism available today (PCEP [RFC5440], 'Ns' can use one or more mechanism available today (PCEP [RFC5440],
NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3 NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3
VPNs along with TE underlay paths from gNB to UPF. 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.
These VPNs and/or underlay TE paths MUST be similar on all gNB/CSRs 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 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 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 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 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 Figure 1. It would enable learning the TE characteristics of all
links and nodes of the network continuously (through BGP-LS [RFC7752] links and nodes of the network continuously (through BGP-LS [RFC7752]
or through a passive IGP adjacency and PCEP [RFC5440]). or through a passive IGP adjacency and PCEP [RFC5440]).
With the TNF in 5GS Service Based Interface, the following additional With the TNF in 5GS Service Based Interface, the following additional
functionalities are required for end-2-end slice management including functionalities are required for end-2-end slice management including
the transport network: the transport network:
o In the Network Slice Selection Assistance Information (NSSAI) PDU o The Specific Network Slice Selection Assistance Information
session's assigned transport VPN and the TE path information is (SNSSAI) of PDU session's SHOULD be mapped to the assigned
needed. transport VPN and the TE path information for that slice.
o For transport slice assignment for various SSTs (eMBB, URLLC, o For transport slice assignment for various SSTs (eMBB, URLLC,
MIoT) corresponding underlay paths need to be created and MIoT) corresponding underlay paths need to be created and
monitored from each transport end point (gNB/CSR and UPF). monitored from each transport end point (gNB/CSR and UPF).
o During PDU session creation, apart from radio and 5GC resources, o During PDU session creation, apart from radio and 5GC resources,
transport network resources needed to be verified matching the transport network resources needed to be verified matching the
characteristics of the PDU session traffic type. characteristics of the PDU session traffic type.
o Mapping of PDU session parameters to underlay SST paths need to be o Mapping of PDU session parameters to underlay SST paths need to be
skipping to change at page 8, line 38 skipping to change at page 8, line 45
GTP-U header and map the same to the underlying transport path GTP-U header and map the same to the underlying transport path
(including VPN or PW). This works for uplink (UL) direction. (including VPN or PW). This works for uplink (UL) direction.
o For downlink direction RQI need to be considered to map the DL o For downlink direction RQI need to be considered to map the DL
packet to one of the underlay paths at the UPF. packet to one of the underlay paths at the UPF.
o If any other form of encapsulation (other than GTP-U) either on N3 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 or N9 corresponding 5QI/QFI or RQI information MUST be there in
the encapsulation header. the encapsulation header.
o If SSC Mode3 Section 3.4.3 is used, segmented path (gNB to o In some SSC modes Section 3.4, if segmented path (gNB to
staging/ULCL/BP-UPF to anchor-point-UPF) with corresponding path staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then
characteristics MUST be used. This includes a path from gNB/CSR corresponding path characteristics MUST be used. This includes a
to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP
access to DN. UPF to eventual UPF access to DN.
o Continuous monitoring of transport path characteristics and o Continuous monitoring of transport path characteristics and
reassignment at the endpoints MUST be performed. For all the reassignment at the endpoints MUST be performed. For all the
effected PDU sessions, degraded transport paths need to be updated effected PDU sessions, degraded transport paths need to be updated
dynamically with similar alternate paths. dynamically with similar alternate paths.
o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 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 based or N2 based), for target gNB selection, apart from radio
resources, transport resources MUST be factored. This enables resources, transport resources MUST be factored. This enables
handling of all PDU sessions from the UE to target gNB and this handling of all PDU sessions from the UE to target gNB and this
require co-ordination of AMF, SMF with the TNF module. require co-ordination of gNB, AMF, SMF with the TNF module.
Changes to detailed signaling to integrate the above for various 5GS 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 procedures as defined in [TS.23.502-3GPP] is beyond the scope of this
document. 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 3. Using PPR as TN Underlay
In a network implementing source routing, packets may be transported In a network implementing source routing, packets may be transported
through the use of Segment Identifiers (SIDs), where a SID uniquely through the use of Segment Identifiers (SIDs), where a SID uniquely
identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 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 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 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 same document. Those concerns are addressed by a new backhaul
routing mechanism called Preferred Path Routing (PPR), of which this routing mechanism called Preferred Path Routing (PPR), of which this
Section provides an overview. Section provides an overview.
skipping to change at page 9, line 41 skipping to change at page 10, line 9
in multiple benefits including significant reduction in network layer in multiple benefits including significant reduction in network layer
overhead, increased performance and hardware compatibility for overhead, increased performance and hardware compatibility for
carrying both path and services along the path. carrying both path and services along the path.
Details of the IGP extensions for PPR are provided here: Details of the IGP extensions for PPR are provided here:
o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing]
o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing]
3.1. PPR with Transport Slicing aware Mobility on N3/N9 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 PPR does not remove GTP-U, unlike some other proposals laid out in
[I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works
with the existing cellular user plane (GTP-U) for both N3 and any 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 approach selected for N9 (encap or no-encap). In this scenario, PPR
will only help providing TE benefits needed for 5G slices from will only help providing TE benefits needed for 5G slices from
transport domain perspective. It does so without adding any transport domain perspective. It does so without adding any
additional overhead to the user plane, unlike SR-MPLS or SRv6. This additional overhead to the user plane, unlike SR-MPLS or SRv6. This
is achieved by: is achieved by:
skipping to change at page 12, line 44 skipping to change at page 13, line 41
+----+ +--++ | +----+ +--++ |
UE1 |gNB2+======+CSR+------N3--------+ UE1 |gNB2+======+CSR+------N3--------+
== +----+ +---+ == +----+ +---+
Figure 4: SSC Mode1 with integrated Transport Slice Function Figure 4: SSC Mode1 with integrated Transport Slice Function
In this mode, IP address at the UE is preserved during mobility In this mode, IP address at the UE is preserved during mobility
events. This is similar to 4G/LTE mechanism and for respective events. This is similar to 4G/LTE mechanism and for respective
slices, corresponding PPR-ID (TE Path) has to be assigned to the slices, corresponding PPR-ID (TE Path) has to be assigned to the
packet at UL and DL direction. During Xn mobility as shown above, packet at UL and DL direction. During Xn mobility as shown above,
AMF has to additionally ensure transport path's resources from TNF source gNB has to additionally ensure transport path's resources from
are available at the target gNB apart from radio resources check (at TNF are available at the target gNB apart from radio resources check
decision and request phase of Xn/N2 mobility scenario). (at decision and request phase of Xn/N2 mobility scenario).
3.4.2. SSC Mode2 3.4.2. SSC Mode2
In this case, if IP Address is changed during mobility (different UPF In this case, if IP Address is changed during mobility (different UPF
area), then corresponding PDU session is released. No session area), then corresponding PDU session is released. No session
continuity from the network is provided and this is designed as an continuity from the network is provided and this is designed as an
application offload and application manages the session continuity, application offload and application manages the session continuity,
if needed. For PDU Session, Service Request and Mobility cases if needed. For PDU Session, Service Request and Mobility cases
mechanism to select the transport resource and the PPR-ID (TE Path) mechanism to select the transport resource and the PPR-ID (TE Path)
is similar to SSC Mode1. is similar to SSC Mode1.
skipping to change at page 14, line 34 skipping to change at page 15, line 28
4. Other TE Technologies Applicability 4. Other TE Technologies Applicability
RSVP-TE [RFC3209] provides a lean transport overhead for the TE path RSVP-TE [RFC3209] provides a lean transport overhead for the TE path
for MPLS user plane. However, it is perceived as less dynamic in for MPLS user plane. However, it is perceived as less dynamic in
some cases and has some provisioning overhead across all the nodes in some cases and has some provisioning overhead across all the nodes in
N3 and N9 interface nodes. Also it has another drawback with N3 and N9 interface nodes. Also it has another drawback with
excessive state refresh overhead across adjacent nodes and this can excessive state refresh overhead across adjacent nodes and this can
be mitigated with [RFC8370]. be mitigated with [RFC8370].
SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal
neither bandwidth reservation nor mechanism to guarantee latency on bandwidth reservation or mechanism to guarantee latency on the nodes/
the nodes/links on SR path. But, SR allows path steering for any links on SR path. But, SR allows path steering for any flow at the
flow at the ingress and particular path for a flow can be chosen. ingress and particular path for a flow can be chosen. Some of the
Some of the issues around path overhead/tax, MTU issues are issues around path overhead/tax, MTU issues are documented at
documented at Section 5.3 of Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR-
[I-D.bogineni-dmm-optimized-mobile-user-plane]. Also SR allows MPLS allows reduction of the control protocols to one IGP (with out
reduction of the control protocols to one IGP (with out needing for needing for LDP and RSVP-TE).
LDP and RSVP).
However, as specified above with PPR (Section 3), in the integrated However, as specified above with PPR (Section 3), in the integrated
transport network function (TNF) a particular RSVP-TE path for MPLS 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 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to
NSSF/AMF/SMF for mapping a particular PDU session to the transport SMF for mapping a particular PDU session to the transport path.
path.
5. New Control Plane and User Planes
5.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].
5.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).
6. Summary and Benefits with PPR 5. Summary and Benefits with PPR
This document specifies an approach to transport and slice aware This document specifies an approach to transport and slice aware
mobility with a simple mapping function from PDU Session to transport mobility with a simple mapping function from PDU Session to transport
path applicable to any TE underlay. path applicable to any TE underlay.
This also describes PPR This also describes PPR
[I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay [I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay
routing mechanism, which helps with goal of optimized user plane for routing mechanism, which helps with goal of optimized user plane for
N9 interface. PPR provides a method for N3 and N9 interfaces to N9 interface. PPR provides a method for N3 and N9 interfaces to
support transport slicing in a way which does not erase the gains support transport slicing in a way which does not erase the gains
made with 5GNR and virtualized cellular core network features for made with 5GNR and virtualized cellular core network features for
various types of 5G traffic (e.g. needing low and deterministic various types of 5G traffic (e.g. needing low and deterministic
latency, real-time, mission-critical or AR/VR traffic). PPR provides latency, real-time, mission-critical or AR/VR traffic). PPR provides
path steering, optionally guaranteed services with TE, unique Fast- path steering, optionally guaranteed services with TE, unique Fast-
ReRoute (FRR) mechanism with preferred backups (beyond shortest path ReRoute (FRR) mechanism with preferred backups (beyond shortest path
backups through existing LFA schemes) in the mobile backhaul network backups through existing LFA schemes) in the mobile backhaul network
with any underlay being used in the operator's network (IPv4, IPv6 or with any underlay being used in the operator's network (IPv4, IPv6 or
MPLS) in an optimized fashion. MPLS) in an optimized fashion.
7. Acknowledgements 6. Acknowledgements
TBD. 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.
8. IANA Considerations 7. IANA Considerations
This document has no requests for any IANA code point allocations. This document has no requests for any IANA code point allocations.
9. Security Considerations 8. Security Considerations
This document does not introduce any new security issues. This document does not introduce any new security issues.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 9.2. Informative References
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., and d. daniel.voyer@bell.ca, "Topology Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Independent Fast Reroute using Segment Routing", draft- Camarillo, "Topology Independent Fast Reroute using
bashandy-rtgwg-segment-routing-ti-lfa-04 (work in Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
progress), April 2018. lfa-05 (work in progress), October 2018.
[I-D.bogineni-dmm-optimized-mobile-user-plane] [I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
Rodriguez-Natal, A., Carofiglio, G., Auge, J., Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
Muscariello, L., Camarillo, P., and S. Homma, "Optimized Muscariello, L., Camarillo, P., and S. Homma, "Optimized
Mobile User Plane Solutions for 5G", draft-bogineni-dmm- Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
optimized-mobile-user-plane-01 (work in progress), June optimized-mobile-user-plane-01 (work in progress), June
2018. 2018.
[I-D.chunduri-lsr-isis-preferred-path-routing] [I-D.chunduri-lsr-isis-preferred-path-routing]
skipping to change at page 17, line 14 skipping to change at page 17, line 28
[I-D.chunduri-lsr-ospf-preferred-path-routing] [I-D.chunduri-lsr-ospf-preferred-path-routing]
Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
Contreras, "Preferred Path Routing (PPR) in OSPF", draft- Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
chunduri-lsr-ospf-preferred-path-routing-01 (work in chunduri-lsr-ospf-preferred-path-routing-01 (work in
progress), July 2018. progress), July 2018.
[I-D.farinacci-lisp-mobile-network] [I-D.farinacci-lisp-mobile-network]
Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
for the Mobile Network", draft-farinacci-lisp-mobile- for the Mobile Network", draft-farinacci-lisp-mobile-
network-03 (work in progress), March 2018. network-04 (work in progress), September 2018.
[I-D.ietf-dmm-srv6-mobile-uplane] [I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
uplane-02 (work in progress), July 2018. uplane-02 (work in progress), July 2018.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
skipping to change at page 18, line 20 skipping to change at page 18, line 35
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
T. Saad, "Techniques to Improve the Scalability of RSVP-TE T. Saad, "Techniques to Improve the Scalability of RSVP-TE
Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
<https://www.rfc-editor.org/info/rfc8370>. <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] [TS.23.401-3GPP]
3rd Generation Partnership Project (3GPP), "Procedures for 3rd Generation Partnership Project (3GPP), "Procedures for
4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018.
[TS.23.501-3GPP] [TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "System 3rd Generation Partnership Project (3GPP), "System
Architecture for 5G System; Stage 2, 3GPP TS 23.501 Architecture for 5G System; Stage 2, 3GPP TS 23.501
v2.0.1", December 2017. v2.0.1", December 2017.
[TS.23.502-3GPP] [TS.23.502-3GPP]
skipping to change at page 18, line 44 skipping to change at page 19, line 15
[TS.23.503-3GPP] [TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "Policy and 3rd Generation Partnership Project (3GPP), "Policy and
Charging Control System for 5G Framework; Stage 2, 3GPP TS Charging Control System for 5G Framework; Stage 2, 3GPP TS
23.503 v1.0.0", December 2017. 23.503 v1.0.0", December 2017.
[TS.29.281-3GPP] [TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "GPRS Tunneling 3rd Generation Partnership Project (3GPP), "GPRS Tunneling
Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
December 2017. December 2017.
Authors' Addresses 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
Uma Chunduri (editor) Uma Chunduri (editor)
Huawei USA Huawei USA
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: uma.chunduri@huawei.com Email: uma.chunduri@huawei.com
Richard Li Richard Li
Huawei USA Huawei USA
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: renwei.li@huawei.com Email: renwei.li@huawei.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra, Inc.
755 Ravendale Drive
Mountain View, CA 94043
USA
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
 End of changes. 36 change blocks. 
118 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/