| dmm | S. Homma |
| Internet-Draft | K. Kawakami |
| Intended status: Standards Track | NTT |
| Expires: September 19, 2018 | D. Farinacci |
| lispers.net | |
| March 18, 2018 |
Co-existence of 3GPP 5GS and Identifier Locator Separation Solution
draft-homma-dmm-5gs-id-loc-coexistence-00
This document describes an approach to introduce Identifier Locator Separation solution into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach.
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 September 19, 2018.
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.
Identifier Locator Separation (ID-LOC) solutions, including LISP, ILA, ILNP, etc, are technologies that provide new numbering spaces, identifier of end point and locator for routing, within IP framework and enables to make management of networks, devices, or sessions be easier. ID-LOC solutions are also expected to be used for optimizing user-plane of mobile netowrk [I-D.bogineni-dmm-optimized-mobile-user-plane], and ways to introduce ID-LOC systems into the next generation mobile network, especially it often indicates 3GPP 5GS (5th Generation System), are considered in the related IETF WGs.
On the other hand, the discussion of the architecture of 5GS Rel.15 including NG-RAN and 5GC (5th Generation Core) was completed on December 2017, and thus it would be difficult to push an ID-LOC solution that requires major changes of the architecture or specifications. From this reason, an approach that enables to introduce an ID-LOC mechanism into 5GS without change of its specifications and to support migration into ID-LOC native network would be required. Here, ID-LOC native network means a network which functionalities of ID-LOC mechanism are integrated into as a fundamental forwarding mechanism.
The goal of this document is providing one of such approaches and clarifying the features and benefits.
As a matter of convenience, this document uses the definitions of LISP (Locator Identifier Separation Protocol) to express functionalities regarding ID-LOC systems. The detailed specifications of LISP are described in [RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061], and [RFC8111]. Moreover, definitions and specifications of another approach to introduce LISP into 3GPP 5GS is described in [I-D.farinacci-lisp-mobile-network].
This document also referes definitions of 3GPP 5GS [TS.23.501-3GPP]. Some of such terms which are used in this document are listed in this section.
This approach achieves traffic forwarding with optimized path and session continuity by using ID-LOC and ULCL for particular communication including UE-2-UE or MEC (Mobile Edge Computing) communication. ULCL is one of fundamental functions of 5GC Rel.15 and it provides functionalities of packet filtering and divert for uplink packets sent by UEs.
The overview of the assumed 5GC architecture of data plane where the proposal approach works is shown in Figure 1. The details of numbered interfaces in the figure are described in [TS.23.501-3GPP].
.--.
( )-.
.' cDN/ '
( Internet )
( -'
'-( )
'---'
|N6
+-----+-----+
| cUPF | ===
+-----+-----+ ^
|N9 |
,-----------------------+-----------------------. |
/ \ |
| Transport Network | |
\ / |
`----+---------------------------+--------------'
|N9 |N9 Connected
+-----+-----+ ,-----. +-----+-----+ ,-----. with
| dUPF#1 |N6 / \ | dUPF#2 |N6 / \ GTP-U
| [UL]+---| dDN#A | | [UL]+---| dDN#B |..
| [CL]| \ / | [CL]| \ / |
+-----+-----+ `-----' +-----+-----+ `-----' |
|N3 |N3 |
|
(( o )) (( o )) |
A A v
/-\ RAN /-\ RAN ===
/-|-\ /-|-\
| |
[ UE ] .. [ UE ] ..
dUPF: Distributed UPF
cUPF: Central UPF
dDN: Distributed DN
cDN: Central DN
Figure 1: Assumed 5GC Network Architecture
This network has following features;
GTP-U packets GTP-U packets
from cUPF to cUPF
| ^
| N9 |
| |
+----|------------|-----+
| | dUPF | | ,---------.
| v | | IP packet / \
| o<-----------------------------| |
| | | | | |
| | | | N6 | dDN |
| | +------+ | | |
| | | ULCL |------------->| |
| | +------+ | IP packet | |
| | ^ | \ /
+----|------------|-----+ `---------'
| |
| |
| N3 |
v |
GTP-U packets GTP-U packets
to UE from UE
Figure 2: Behaviors of dUPF and ULCL
In the proposal approach, an xTR is installed between dUPF and dDN. xTRs are connected with a tunneling protocol (it may be LISP header or other protocol such as SRv6 [I-D.ietf-6man-segment-routing-header]) and each xTR has connectivity with one or more Mapping Systems. The overview is shown in Figure 3.
.--.
( )-.
.' cDN/ '
( Internet )
( -'
'-( )
'---'
|N6 ,---------.
+-----+-----+ | Mapping |
| cUPF | | System |
+-----+-----+ `---------'
|N9 .
,-----------------------+----------------.---------.
/ Transport Network . . . . . . . . . . . . . . . \
| . . |
\ #===========================#=== /
`----+------------#--.-----------+------------#--.-'
|N9 # . |N9 # .
+-----+-----+ +-------+ +-----+-----+ +-------+
| dUPF#1 |N6 | | | dUPF#2 |N6 | |
| [UL]+---+ xTR#1 | | [UL]+---| xTR#2 |..
| [CL]| | | | [CL]| | |
+-----+-----+ +---+---+ +-----+-----+ +---+---+
|N3 | |N3 |
,-----. ,-----.
(( o )) / \ (( o )) / \
A | dDN#A | A | dDN#B |
/-\ RAN \ / /-\ RAN \ /
/-|-\ `-----' /-|-\ `-----'
| |
[ UE ] .. [ UE ] ..
===== : Tunnel connects xTRs
. . . : IF to Mapping System
Figure 3: Proposal Network Architecture
Each dUPF has a filter table of ULCL. Each filter table is configured to mach addresses assigned within own network domain (i.e., addresses for UEs assigned by cUPF) or assigned corresponding with address space of some of dDN. UPFs monitor each uplink GTP-U packet with its ULCL and divert it to the connected xTR with decapsulation if the destination address of the inner packet matches the table. When xTR receives a packet from the dUPF, it obtains RLOC which the destination of the packet (EID) belongs to by looking up its own EID-to-RLOC mapping cache or querying it from the Mapping System according ID-LOC mechanism. Then it sends the packet to peered xTR indicated by the RLOC.
The detailed processing flow with LISP below as an example. In this example, a Mapping System obtains location of each UE from SMF and keeps its own EID-to-RLOC mapping database up to date. Each xTR obtains EID-to-RLOC map information which isn't stored in the cache by sending Map-Request to a Mapping System.
From the above processes, forwarding paths of user traffic diverted by ULCL from 5GC to xTR are optimized without changing their IP address (EID).
Further case studies are described in Appendix A.
For ID-LOC mechanism in mobile networks, a control plane mechanism to manage location information of UEs is required. There are mainly three patterns to realize control plane mechanism for ID-LOC as follows:
Some of patterns may require to use 5GS interfaces or add some functionalities to functions of 5GC. 5GS architecture and the service-based interfaces are shown in Figure 4. The details of functions and interfaces are described in [TS.23.501-3GPP].
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|NSSF | | NEF | | NRF | | PCF | | UDM | | AF |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
Nnssf| Nnef| Nnrf| Npcf| Nudm| |Naf
---+--------+--+-----+--+--------+--+-----+--------+-
Nausf| Namf| Nsmf|
+--+--+ +--+--+ +--+--+
|AUSR | | AMF | | SMF |
+-----+ +--+--+ +-----+
/| |
C-plane N1/ |N2 |N4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D-plane / | |
N1 / |N2 |N4
/ | |
+-+-+ +--+--+ N3 +--+--+ N6 +----+
|UE +--+(R)AN+-----+ UPF +-----+ DN |
+---+ +-----+ +-----+ +----+
Figure 4: 5GS Architecture and Service-based Interfaces
In this pattern, control plane of 5GC and EID-to-RLOC mapping mechanism are completely separated. Information of an UE and an xTR which the UE is attached is sent to a Mapping System and registered in the mapping database only when the xTR receives a packet from the UE and the UE is not registered yet.
This pattern does not cause any impacts on 5GC architecture. However, in this pattern, an UE cannot be accessed from other UEs within the same network domain until a packet from the UE is diverted to the xTR by the UPF which the UE is located and the EID and RLOC are registered to the Mapping System.
In this pattern, a Mapping System interworks with an SMF which manages sessions of each UE. A scheme to inform, that an UE moves and is relocated to another UPF, from SMF to AF via Naf interface is defined in 5GS ([TS.23.502-3GPP])*. A Mapping System is installed as an AF and obtains mobility information of UEs with the above scheme.
* The stage 3 of discussion of 5GS has not been fixed yet and the specification may be changed.
This pattern would not cause any impacts on 5GS architecture, and a Mapping System can always keep the current mobility information of each UE.
In this pattern, a Mapping System has functionalities of SMF and acts as a part of 5GS. In 5GS architecture, an SMF has a role of session management of UEs, and it updates its own mapping database depending on movement of an UE.
This approach enables to always keep mapping databases the latest status, however, it obviously requires extension or replacement of SMF actually deployed in 5GS network.
TBD
This memo includes no request to IANA.
The authors would like to thank Ryosuke Kurebayashi, Koji Tsubouchi, and Toru Okugawa for their kind reviews and technical feedback.
This Appendix describes detailed processes of the proposal approach in the following types of communications.
In the current architecture, a cUPF becomes an anchor point for UEs, and all packets between UEs even which are located to the same dUPF are transferred through the anchor point. This may cause communication delay and inefficient resource usage. In the proposed procedure, packets can be transferred without through an anchor point, and low latency and efficient resource usage can be achieved.
The UE-2-UE communications include communications between UEs located to different dUPFs (Case 1), and communication between UEs located to the same dUPF (Case 2). In this section, the detailed procedures of the cases are described.
Moreover, in a mobile network, an UE may move during communications. This section describes problems and considerations about UE's handover in such case.
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) . #==========================#
. # (4) #
. # V
+-------+ +-------+ +-------+ +-------+
| dUPF#1| | xTR#1 | | dUPF#2| | xTR#2 |
| | | RLOC=X| |+------|<-----| RLOC=Y|
| [UL]| | | || [UL]| (5) | |
| [CL]|------>| | |v [CL]| | |
+-------+ (2) +-------+ +-------+ +-------+
^ |
| (1) |(6)
| v
[UE#1] [UE#2]
EID=a-1 EID=a-2
Figure 5: Procedure in Case 1
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) .
.
.
+-------+ +-------+ +-------+ +-------+
| dUPF#1| | xTR#1 | | dUPF#2| | xTR#2 |
|+------|<----- | RLOC=X| | | | RLOC=Y|
|| [UL]| (4) | | | [UL]| | |
|v [CL]|------>| | | [CL]| | |
+-------+ (2) +-------+ +-------+ +-------+
| ^
(5) | | (1)
v |
[UE#2] [UE#1]
EID=a-2 EID=a-1
Figure 6: Procedure in Case 2
When an UE moves to a serving area of another dUPF during communication with another UE, EID-to-RLOC mapping database of a Mapping System and the tables of the xTR and the peered xTR must be updated. The xTRs can't send packets to the appropriate xTR during the updating, and thus packet drop or stalling may occur.
To mitigate this problem, further consideration is needed. For example, a mechanism that immediately advertise the update of location of UEs to Mapping System and the appropriate xTRs depending on movement of each UE might be required.
The UE-2-dDN communications basically correspond the communication between an UE and neighbor dDN (Case3). On the other hand, if an UE moved under another dUPF during usage of a statefull application, or the application is not uniformly deployed in every dDN, the UE needs to continue to communicate with the previous dDN (Case4).
In such cases, in the current architecture, all packets are needed to go through the anchor point or dynamic GTP tunnel reconfiguration between dUPF is required. The former solution causes additional communication delay and inefficient resource usage. The latter solution increase the cost of 5GS control plane to dynamically update the GTP tunnel with multiple UPFs and their ULCL filter tables along with the movement of the UE. The propal approach achieves appropriate packet transfer in such cases.
In this section, the detailed procedures of communications between an UE and neighbor dDN and communications between an UE and non-neighbor dDN
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) .
.
.
+-------+ +-------+ +-------+ +-------+
| dUPF#1| | xTR#1 | | dUPF#2| | xTR#2 |
|+------|<----- | RLOC=X| | | | RLOC=Y|
|| [UL]| (6) | | | [UL]| | |
|v [CL]|------>| | | [CL]| | |
+-------+ (2) +-------+ +-------+ +-------+
| ^ | ^
(7) | | (1) (4)| | (5)
v | v |
,-------.
[UE#1] / dDN#B \
EID=a1 | | ^ |
| v | |
| [APL#1] |
\ EID=b-1 /
`-------'
Figure 7: Procedure in Case 3
+-------+
|Mapping|
|System |
+-------+
.
. (7)
. #==============================#
(3) . # #==========================# #
. # # (4) # #
. V # V #
+-------+ +-------+ +-------+ +-------+
| dUPF#1| (8) | xTR#1 | | dUPF#2| | xTR#2 |
|+------|<------| RLOC=X| | | (0) | RLOC=Y|
|| [UL]| | | | [UL]|<---->| |
|v [CL]|------>| | | [CL]| | |
+-------+ (2) +-------+ +-------+ +-------+
| ^ ^ | ^
(9) | | (1) | (0) (5)| | (6)
v | | v |
(0) v ,-------.
[UE#1] <= = = = = = = = = = = =[UE#1] / dDN#C \
EID=a-1 UE#1 moves to the serving area of | | ^ |
dUPF#1 from the serving area of UPF#2 | v | |
| [APL#2] |
\ EID=c-1 /
`-------'
Figure 8: Procedure in Case 4