| dmm | S. Homma |
| Internet-Draft | K. Kawakami |
| Intended status: Standards Track | NTT |
| Expires: November 16, 2018 | A. Akhavain |
| Huawei Canada Research Centre | |
| May 15, 2018 |
Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture
draft-homma-dmm-5gs-id-loc-coexistence-01
This document describes an approach to introduce Identifier Locator Separation architecture 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 November 16, 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) architecture aims to simplify management of network, devices, and sessions by employing two namespaces: Identifier for device's identity, and Locator for its location in the network.
ID-LOC architecture can be implemented by a dedicated protocol such as LISP, ILA, ILNP, etc. The control plane of such ID-LOC protocols can be combined with one of different encapsulation techniques such as GTP-U, SRv6, MPLS, etc. at data plane to provide a customized solution. Furthermore, regarding control plane of ID-LOC, it can optionally even take advantage of enhanced PUB/SUB capable distributed databases to circulate ID-LOC mapping relationships in the network.
ID-LOC protocols are also expected to be used for optimizing user-plane of mobile network [I-D.bogineni-dmm-optimized-mobile-user-plane]. Different alternatives to introduce ID-LOC architecture into 3GPP 5GS(5th Generation System), are under consideration in related IETF WG such as DMM WG.
Introducing ID-LOC architecture into mobile network can involve modifications to 5GS architecture and specifications that might span over several 5GS releases.
Therefore, an approach that enables the introduction of ID-LOC architecture into 5GS without change of its specifications and supports migration path toward a native ID-LOC native network can be useful to operators. Here, ID-LOC native network refers to a network that employs the ID-LOC architecture as only mechanism for packet forwarding.
The document aims to describe one such approach and clarify different features, and benefits.
This section describes general terms of ID-LOC architecture. This document also refers definitions of 3GPP 5GS [TS.23.501-3GPP], and some of such terms which are used in this document are listed in this section.
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].
The detailed specification of ILA are described in [I-D.herbert-intarea-ila].
The detailed specification of SRv6 are described in [I-D.ietf-6man-segment-routing-header].
This approach achieves traffic forwarding with optimized path and session continuity by using ID-LOC and ULCL for particular communication including UE-to-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, a LOC-node is installed between dUPF and dDN. LOC-nodes are connected with a IP mechanism such as IP tunnels or translation of destination IP field. As examples of such data plane protocols for providing connectivity between LOC-nodes, IPv4/v6 header with LISP header or SRv6 ([I-D.ietf-6man-segment-routing-header]) can be used. In addition, each LOC-node 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 | LOC- | | dUPF#2 |N6 | LOC- |
| [UL]+---+ Node#1| | [UL]+---| Node#2|..
| [CL]| | | | [CL]| | |
+-----+-----+ +---+---+ +-----+-----+ +---+---+
|N3 | |N3 |
,-----. ,-----.
(( o )) / \ (( o )) / \
A | dDN#A | A | dDN#B |
/-\ RAN \ / /-\ RAN \ /
/-|-\ `-----' /-|-\ `-----'
| |
[ UE ] .. [ UE ] ..
===== : Connection between LOC nodes
. . . : IF to Mapping System
Figure 3: Proposal Network Architecture
Each dUPF has a filter table of ULCL. Each filter table is configured to match 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 LOC-node with decapsulation of GTP-U if the destination address of the inner packet (payload) matches the filtering table. When LOC-node receives a packet from the dUPF, it obtains LOC which the destination of the packet (ID) belongs to by looking up its own ID-to-LOC mapping table or querying it from the Mapping System according ID-LOC mechanism. Then it sends the packet to peered LOC-node indicated by the LOC. The peered LOC-node converts the received packet to appropriate form and forwards them the destination by following its own forwarding table.
From such processes, forwarding paths of user traffic diverted by ULCL from 5GC to LOC-node are optimized.
A cUPF is connected with dUPFs via N9 interface and packets are forwarded with GTP-U encapsulation between cUPF and dUPF.
Some case studies of ID-LOC protocols are described in Appendix A and Appendix B.
For ID-LOC mechanism in mobile networks, a control plane mechanism to manage location information of UEs is required. There are mainly three models to realize control plane mechanism for ID-LOC as follows:
Some of models 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 model, control plane of 5GC and ID-to-LOC mapping mechanism are completely separated. Information of an UE and a LOC-node which the UE is attached is sent to a mapping system and registered in the mapping database only when the LOC-node receives a packet from the UE and the UE is not registered yet.
This model does not cause any impacts on 5GC architecture. However, in this model, an UE cannot be accessed from other UEs within the same network domain until a packet from the UE is diverted to the LOC-node by the UPF which the UE is located and the EID and RLOC are registered to the Mapping System.
In this model, 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 model would not cause any impacts on 5GS architecture, and a mapping system can always keep the current mobility information of each UE.
In this model, SMF functionalities are integrated into a mapping system. In other words, the mapping system becomes 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, Toru Okugawa, and Dino Farinacci for their kind reviews and technical feedback.
This Appendix describes detailed processes of the proposal approach with LISP mechanism in the following types of communications.
In the following description of case studies, ID and Locator are called EID (End-point Identifier) and RLOC (Routing Locator) in LISP terms. Mapping Server has the master of EID-to-RLOC mapping database, and each xTR (Ingress/Egress Tunnel Router) has EID-to-RLOC mapping cache. An xTR obtains the destination RLOC from its own cache by looking up the destination EID of received packet. They obtain mappings from the mapping system if an EID looked up is not registered in the cache. Packets are passed between xTRs with some tunnel protocols.
In the current architecture, a cUPF becomes an anchor point for UEs, and all packets between UEs even those 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 going through an anchor point, and low latency and efficient resource usage can be achieved.
The UE-to-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 A-1
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) .
.
.
+-------+ +-------+ +-------+ +-------+
| dUPF#1| (4) | xTR#1 | | dUPF#2| | xTR#2 |
|+------|<----- | RLOC=X| | | | RLOC=Y|
|| [UL]| | | | [UL]| | |
|v [CL]|------>| | | [CL]| | |
+-------+ (2) +-------+ +-------+ +-------+
| ^
(5) | | (1)
v |
[UE#2] [UE#1]
EID=a-2 EID=a-1
Figure 6: Procedure in Case A-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. Also, some documents (e.g., [I-D.ietf-lisp-eid-mobility]) discuss this problem.
The UE-to-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| (6) | xTR#1 | | dUPF#2| | xTR#2 |
|+------|<----- | RLOC=X| | | | RLOC=Y|
|| [UL]| | | | [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 A-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 A-4
UE-to-cDN/Internet communication is achieved by GTP-U mechanism originally equipped in 3GPP 5GS architecture. In this section, we describe processes of UE-to-cDN communication in the proposal architecture as an example.
,------------.
/ cDN \
| |
| EID=d-1 |
| [APL#3] |
| | ^ |
\ | | /
`------------'
(4) | | (3)
v |
+-----------+
| cUPF |
+-----------+
| ^
(5) | |
+--------------------+ |
| |
| +--------------------+
| | (2)
V |
+-------+ +-------+
| dUPF#1| | xTR#1 |
| | | RLOC=X|
| [UL]| | |
| [CL]| | |
+-------+ +-------+
| ^
(6) | | (1)
v |
[UE#1]
EID=a-1
Figure 9: Procedure in Case A-5
This Appendix describes detailed processes of the proposal approach with ILA mechanism in the following types of communications.
Each ILA node has ID-to-LOC mapping table. Mappings are propagated amongst ILA routers or hosts in a network using mapping propagation protocols.
In the following description of case studies, a mapping system, called ILA resolver in ILA terms, has the master of ID-to-LOC mapping database, and each ILA node obtains mappings from the mapping system. In some cases, each ILA node has an ID-to-LOC mapping database.
In ILA, an SIR address expressed by composition of SIR prefix and identifier is assigned to each UE or VM instance. An SIR prefix and an identifier are described SIR_prefix_n and id_m (n=1,2,..., m=1,2,...), and an SIR address is expressed as SIR_addr_x =[n,m] (x=1,2,...) in the following description. Also, each ILA- Nodes are assigned unique Locators, which is a network prefix that routes to a host. Locators are described as loc_n (n=1,2,..).
The overview of this communication type is described in A.1.
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) . #==========================#
. # (4) #
. # V
+-------+ +-------+ +-------+ +-------+
| dUPF#1| | ILA- | | dUPF#2| | ILA- |
| | | Node#1| |+------|<-----| Node#2|
| [UL]| | | || [UL]| (5) | |
| [CL]|------>| loc_1 | |v [CL]| | loc_2 |
+-------+ (2) +-------+ +-------+ +-------+
^ |
| (1) |(6)
| v
[UE#1] [UE#2]
SIR_addr_1=[1,1] SIR_addr_2=[1,2]
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 10: Procedure in Case B-1
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) .
.
.
+-------+ +-------+ +-------+ +-------+
| dUPF#1| (4) | ILA- | | dUPF#2| | ILA- |
|+------|<----- | Node#1| | | | Node#2|
|| [UL]| | | | [UL]| | |
|v [CL]|------>| loc_1 | | [CL]| | loc_2 |
+-------+ (2) +-------+ +-------+ +-------+
| ^
(5) | | (1)
v |
[UE#2] [UE#1]
SIR_addr_2 SIR_addr_1
=[1,2] =[1,1]
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 11: Procedure in Case B-2
The overview of this communication type is described in A.2.
+-------+
|Mapping|
|System |
+-------+
.
.
.
(3) .
.
.
+-------+ +-------+ +-------+ +-------+
| dUPF#1| (6) | ILA- | | dUPF#2| | ILA- |
|+------|<----- | Node#1| | | | Node#2|
|| [UL]| | | | [UL]| | |
|v [CL]|------>| loc_1 | | [CL]| | loc_2 |
+-------+ (2) +-------+ +-------+ +-------+
| ^ | ^
(7) | | (1) (4)| | (5)
v | v |
,---------.
[UE#1] / dDN#B \
SIR_addr_1=[1,1] | | ^ |
| v | |
| [APL#1] |
|SIR_addr_2 |
\ =[2,2] /
`---------'
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 12: Procedure in Case B-3
+-------+
|Mapping|
|System |
+-------+
.
. (7)
. #================================#
(3) . # #============================# #
. # # (4) # #
. V # V #
+-------+ +-------+ +-------+ +-------+
| dUPF#1| (8) | ILA- | | dUPF#2| | ILA- |
|+------|<------| Node#1| | | (0) | Node#2|
|| [UL]| | | | [UL]|<---->| |
|v [CL]|------>| loc_1 | | [CL]| | loc_2 |
+-------+ (2) +-------+ +-------+ +-------+
| ^ ^ | ^
(9) | | (1) | (0) (5)| | (6)
v | | v |
(0) v ,--------.
[UE#1] <= = = = = = = = = = = = =[UE#1] / dDN#C \
SIR_addr_1 UE#1 moves to the serving area of | | ^ |
=[1,1] dUPF#1 from the serving area of UPF#2 | v | |
| [APL#2] |
|SIR_adrr_3|
\ =[3,3] /
`--------'
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 13: Procedure in Case B-4
UE-to-cDN/Internet communication are basically achieved by GTP-U mechanism originally equipped in 3GPP 5GS architecture. ILA causes some limitation on IP addressing to UEs (e.g., all UEs in an ILA domain have the same SIR prefix), and thus some IP translation node such as NAT (Network Address Translation) may be required to enable UEs to access to external network. In this section, we describe processes of UE-to-cDN/Internet communication in the proposal architecture. In Internet communication, from aspect of privacy or routing with external network, SIR addresses assigned to UEs are translated by NAT function deployed between dUPF and connection point.
,------------.
/ cDN \
| |
|SIR_addr_4=[4,4]
| [APL#3] |
| | ^ |
\ | | /
`------------'
(4) | | (3)
v |
+-----------+
| cUPF |
+-----------+
| ^
(5) | |
+--------------------+ |
| |
| +--------------------+
| | (2)
v |
+-------+ +-------+
| dUPF#1| | ILA- |
| | | Node#1|
| [UL]| | |
| [CL]| | loc_1 |
+-------+ +-------+
| ^
(6) | | (1)
v |
[UE#1]
SIR_addr_1=[1,1]
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 14: Procedure in Case B-5
IP_Addr_5
[Server#1]
| ^
(5) v | (4)
.--.
( )-.
.' '
( Internet )
( -'
'-( )
'---'
(5) | ^ (4)
v |
+-----------+
| NAT | SIR_Addr_1 <-> IP_Addr_10
+----+-+----+
| |
(6) v | (3)
+-----------+
| cUPF |
+-----------+
| ^
(7) | |
+--------------------+ |
| |
| +--------------------+
| | (2)
v |
+-------+ +-------+
| dUPF#1| | ILA- |
| | | Node#1|
| [UL]| | |
| [CL]| | loc_1 |
+-------+ +-------+
| ^
(8) | | (1)
v |
[UE#1]
SIR_addr_1=[1,1]
Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]
Figure 15: Procedure in Case B-6