| Internet-Draft | LISP for the Mobile Network | March 2023 |
| Farinacci, et al. | Expires 6 September 2023 | [Page] |
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.¶
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 6 September 2023.¶
Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The LISP architecture and protocols [RFC9300] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which provide an architecture to build overlays on top of the underlying Internet. Mapping EIDs to RLOC-sets is accomplished with a Mapping Database System. By using a level of indirection for routing and addressing, separating an address identifier from its location can allow flexible and scalable mobility. By assigning EIDs to mobile devices and RLOCs to the network nodes that support such mobile devices, LISP can provide seamless mobility.¶
For a reading audience unfamiliar with LISP, a brief tutorial level document is available at [RFC9299].¶
This specification will describe how LISP can be used to provide layer-3 mobility within and across an LTE [LTE401-3GPP] [LTE402-3GPP] and 5G [ARCH5G-3GPP] [PROC5G-3GPP] mobile network.¶
The following are the design requirements:¶
The goal of this specification is take advantage of LISP's non-disruptive incremental deployment benefits. This can be achieved by changing the fewest number of components in the mobile network. The proposal suggests adding LISP functionality only to gNB/eNodeB and UPF/pGW nodes. There are no hardware or software changes to the UE devices or the RF-based RAN to realize this architecture. The LISP mapping database system is deployed as an addition to the mobile network and does not require any coordination with existing management and provisioning systems.¶
Similar ID Oriented Networking (ION) mechanisms for the 5G [ARCH5G-3GPP] [PROC5G-3GPP] mobile network are also being considered in other standards organizations such as ETSI [ETSI-NGP] and ITU [ITU-IMT2020]. The NGMN Alliance describes Locator/ID separation as an enabler to meet Key Performance Indicator Requirements [NGMN].¶
LISP will provide layer-3 address mobility based on the procedures in [I-D.ietf-lisp-eid-mobility] where the EID and RLOCs are not co-located. In this design, the EID is assigned to the UE device and the RLOC(s) are assigned to gNB/eNodeB nodes. So any packets going to a UE are always encapsulated to the gNB/eNodeB that associates with the UE. For data flow from the UE to any EIDs (or destinations to non-LISP sites) that are outside of the NGC/EPC, use the RLOCs of the UPF/pGW nodes so the UPF/pGW can send packets into the Internet core (unencapsulated).¶
The following procedures are used to incorporate LISP in the NGC/EPC:¶
Traffic from a UE to UE across a UPF/pGW region have these options for data flow:¶
The following diagram illustrates the LTE mobile network topology and structure [LTE401-3GPP] [LTE402-3GPP]:¶
(--------------------------------------------)
( )
( Internet )
( )
(--------------------------------------------)
| |
| |
(---------|---------) (---------|---------)
( UPF-pGW ) ( UPF-pGW )
( ) ( )
( NGC/EPC ) ( NGC/EPC )
( ) ( )
( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB )
(---/--\-----/--\---) (---/--\-----/--\---)
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \
/ RAN \ / RAN \
/ \ / \
( UE UE UE ) ( UE UE UE )
The following diagram illustrates how LISP is used on the mobile network:¶
(1) IPv6 EIDs are assigned to UEs.
(2) RLOCs assigned to gNB/eNodeB nodes are [a1,a2], [b1,b2], [c1,c2], [d1,d2]
on their uplink interfaces.
(3) RLOCs assigned to UPF/pGW nodes are [p1,p2], [p3,p4].
(4) RLOCs can be IPv4 or IPv6 addresses or mixed RLOC-sets.
(--------------------------------------------)
( )
( Internet )
( )
(--------------------------------------------)
| |
| |
(---------|---------) (---------|---------)
( UPF-pGW ) ( UPF-pGW )
( p1 p2 ) ( p3 p4 )
( ) ( )
( NGC/EPC ) ( NGC/EPC )
( ) ( )
( a1 a2 b1 b2 ) ( c1 c2 d1 d2 )
( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB )
(---/--\-----/--\---) (---/--\-----/--\---)
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \
/ RAN \ / RAN \
/ \ / \
( UE UE UE ) ( UE UE UE )
EIDs: a::1 b::1 c::1 x::1 y::1 z::1
The following table lists the EID-to-RLOC entries that reside in the
LISP Mapping System when the above UEs are are attached to the 4
gNB/eNodeBs:
EID-Record RLOC-Record Commentary
0::/0 [p1,p2,p3 p4] gNB/eNodeBs encap to p1-p4 for Internet
destinations which are non-EIDs (1)
a::1/128 [a1,a2] UPF/pGWs load-split traffic to [a1,a2]
for UE a::1 and it can move to [b1,b2] (2)
b::1/128 [a1,a2] gNB/eNodeB tracks both UEs a::1 and b::1,
it can do local routing between the
UEs (3)
c::1/128 [b1,b2] UE c::1 can roam to [c1,c2] or [d1,d2],
may use UPF/pGW [p1,p2] after move (4)
x::1/128 [c1,c2] UE x::1 can talk directly to UE y::1,
gNB/eNodeBs encap to each other (5)
y::1/128 [d1,d2] UE can talk to Internet when [d1,d2],
encap to UPF/pGW [p3,p4] or use backup
[p1,p2] (6)
z::1/128 [d1,d2] UE z::1 can talk to a::1 directly where
[d1,d2] encaps to [a1,a2] (7)
¶
(1) For packets that flow from UE nodes to destinations that are not in LISP sites, the gNB/eNodeB node uses one of the RLOCs p1, p2, p3, or p4 as the destination address in the outer encapsulated header. Encapsulated packets are then routed by the NGC/EPC core to the UPF/pGW nodes. In turn, the UPF/pGW nodes, then route packets into the Internet core.¶
(2) Packets that arrive to UPF/pGW nodes from the Internet destined to UE nodes are encapsulated to one of the gNB/eNodeB RLOCs a1, a2, b1, b2. When UE, with EID a::1 is attached to the leftmost gNB/eNodeB, the EID a::1 is registered to the mapping system with RLOCs a1 and a2. When UE with EID c::1 is attached to the rightmost gNB/eNodeB (in the left region), the EID c::1 is registered to the mapping system with RLOCs b1 and b2.¶
(3) If UE with EID a::1 and UE with EID b::1 are attached to the same gNB/eNodeB node, the gNB/eNodeB node tracks what radio interface to use to route packets from one UE to the other.¶
(4) If UE with EID c::1 roams away from gNB/eNodeB with RLOCs b1 and b2, to the gNB/eNodeB with RLOCs c1 and c2 (in the rightmost region), packets destined toward the Internet, can use any UPF/pGW. Any packets that flow back from the Internet can use any UPF/pGW. In either case, the UPF/pGW is informed by the mapping system that the UE with EID c::1 has new RLOCs and should now encapsulate to either RLOC c1 or c2.¶
(5) When UE with EID x::1 is attached to gNB/eNodeB with RLOCs c1 and c2 and UE with EID y::1 is attached to gNB/eNodeB with RLOCs d1 and d2, they can talk directly, on the shortest path to each gNB/eNodeB, when each encapsulates packets to each other's RLOCs.¶
(6) When packets from UE with EID y::1 are destined for the Internet, the gNB/eNodeB with RLOCs d1 and d2 that the UE is attached to can use any exit UPF/pGWs RLOCs p1, p2, p3, or p4.¶
(7) UE with EID z::1 can talk directory to UE with EID a::1 by each gNB/eNodeB they are attached to encapsulsates to each other's RLOCs. In case (5), the two gNB/eNodeB's were in the same region. In this case, the gNB/eNodeBs are in different regions.¶
The following abbreviated diagram shows a topology that illustrates how a UE roams with LISP across UPF/pGW regions:¶
(--------------------------------------------)
( )
( Internet )
( )
(--------------------------------------------)
| |
| |
(---------|---------) (---------|---------)
( UPF-pGW ) ( UPF-pGW )
( p1 p2 ) ( p3 p4 )
( ) ( )
( NGC/EPC ) ( NGC/EPC )
( ) ( )
( a1 a2 b1 b2 ) ( c1 c2 d1 d2 )
( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB )
(---/--\-----/--\---) (---/--\-----/--\---)
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \
/ RAN \ / RAN \
/ \ / \
( UE ------------------------------> UE )
a::1 a::1
The contents of the LISP mapping database before UE moves:
EID-Record RLOC-Record Commentary
0::/0 [p1,p2,p3,p4] gNB/eNodeB [a1,a2] encaps to p1-p4 for
Internet destinations when a::1 on
gNB/eNodeB [a1,a2]
a::1/128 [a1,a2] Before UE moves to other UPF/pGW region
The contents of the LISP mapping database after UE moves:
EID-Record RLOC-Record Commentary
0::/0 [p1,p2,p3,p4] gNB/eNodeB [d1,d2] encaps to p1-p4 for
Internet destinations when a::1 moves to
gNB/eNodeB [d1,d2]
a::1/128 [d1,d2] After UE moves to new UPF/pGW region
¶
UE based EID addresses will be IPv6 addresses. It will be determined at a future time what length the IPv6 prefix will be to cover all UEs in a mobile network. This coarse IPv6 prefix is called an EID-prefix where more-specific EID-prefixes will be allocated out of it for each UPF/pGW node. Each UPF/pGW node is responsible for advertising the more-specific EID-prefix into the Internet routing system so they can attract packets from non-EIDs nodes to UE EIDs.¶
An RLOC address will either be an IPv4 or IPv6 address depending on the support for single or dual-stack address-family in the NGC/EPC network. An RLOC-set in the mapping system can have a mixed address-family locator set. There is no requirement for the NGC/EPC to change to support one address-family or the other. And there is no requirement for the NGC/EPC network to support IPv4 multicast or IPv6 multicast. The LISP overlay will support both.¶
The only requirement for RLOC addresses is that they are routable in the NGC/EPC and the Internet.¶
The requirements of the LISP and GTP data-plane overlay is to support a layer-3 overlay network only. There is no architectural requirement to support layer-2 overlays. However, operators may want to provide a layer-2 LAN service over their mobile network. Details about how LISP supports layer-2 overlays can be found in [I-D.ietf-lisp-eid-mobility].¶
The gNB/eNodeB node runs as a LISP xTR for control-plane functionality and runs GTP for data-plane functionality. Optionally, the LISP data-plane can be used to establish dynamic tunnels from one gNB/eNodeB node to another gNB/eNodeB node.¶
The gNB/eNodeB LISP xTR will follow the procedures of [I-D.ietf-lisp-eid-mobility] to discover UE based EIDs, track them by monitoring liveness, registering them when appear, and deregistering them when they move away. Since the gNB/eNodeB node is an xTR, it is acting as a layer-3 router and the GTP tunnel from the gNB/eNodeB node to the UPF/pGW node is realizing a layer-3 overlay. This will provide scaling benefits since broadcast and link-local multicast packets won't have to travel across the NGC/EPC to the UPF/pGW node.¶
A day in the life of a UE originated packet:¶
It is important to note that in [I-D.ietf-lisp-eid-mobility], EID discovery occurs when a LISP xTR receives an IP or ARP/ND packet. However, if there are other methods to discover the EID of a device, like in UE call setup, the learning and registration referenced in Section 5, Paragraph 4, Item 2 can happen before any packet is sent.¶
The UPF/pGW node runs as a LISP xTR for control-plane functionality and runs GTP for data-plane functionality. Optionally, the LISP data-plane can be used to establish dynamic tunnels from one UPF/pGW node to another UPF/pGW or gNB/eNodeB node.¶
The UPF/pGW LISP xTR does not follow the EID mobility procedures of [I-D.ietf-lisp-eid-mobility] since it is not responsible for discovering UE based EIDs. A UPF/pGW LISP xTR simply follows the procedures of a PxTR in [RFC9300] and for interworking to non-EID sites in [RFC6832].¶
A day in the life of a UPF/pGW received packet:¶
Since GTP is a UDP based encapsulating tunnel protocol, it has the same benefits as LISP encapsulation. At this time, there appears to be no urgent need to not continue to use GTP for tunnels between a gNB/eNodeB nodes and between a gNB/eNodeB node and a UPF/pGW node.¶
There are differences between GTP tunneling and LISP tunneling. GTP tunnels are setup at call initiation time. LISP tunnels are dynamically encapsulating, used on demand, and don't need setup or teardown. The two tunneling mechanisms are a hard state versus soft state tradeoff.¶
This specification recommends for early phases of deployment, to use GTP as the data-plane so a transition for it to use the LISP control-plane can be achieved more easily. At later phases, the LISP data-plane may be considered so a more dynamic way of using tunnels can be achieved to support URLLC.¶
This specification recommends the use of procedures from [I-D.ietf-lisp-eid-mobility] and NOT the use of LISP-MN [I-D.ietf-lisp-mn]. Using LISP-MN states that a LISP xTR resides on the mobile UE. This is to be avoided so extra encapsulation header overhead is NOT sent on the RAN. The LISP data-plane or control-plane will not run on the UE.¶
Using LISP for the data-plane has some advantages in terms of providing near-zero packet loss. In the current mobile network, packets are queued on the gNB/eNodeB node the UE is roaming to or rerouted on the gNB/eNodeB node the UE has left. In the LISP architecture, packets can be sent to multiple "roamed-from" and "roamed-to" nodes while the UE is moving or is off the RAN. See mechanisms in [I-D.ietf-lisp-predictive-rlocs] for details.¶
The LISP mapping system stores and maintains EID-to-RLOC mappings. There are two mapping database transport systems that are available for scale, LISP-ALT [RFC6836] and LISP-DDT [RFC8111]. The mapping system will store EIDs assigned to UE nodes and the associated RLOCs assigned to gNB/eNodeB nodes and UPF/pGW nodes. The RLOC addresses are routable addresses by the NGC/EPC network.¶
This specification recommends the use of LISP-DDT.¶
So far in this specification we have described how LISP runs on the gNB and UPF nodes in the mobile network. In the 5G architecture [ARCH5G-3GPP] definition, some key components are Access and Mobility Management Function (AMF) and the Session Management Function (SMF). These two components provide control plane functionality to off-load session anchoring by distributing state and packet flow among multiple nodes in the NGC. These functions control the data-plane anchors deployed in Branch Point Uplink Classifier (BP/ULCL) in UPF data-plane nodes.¶
Here is an illustration where a BP/ULCL-UPF node would appear in the mobile network:¶
(--------------------------------------------)
( Internet )
+-> (--------------------------------------------)
| |
N6 |
| (---------|---------)
+-> ( UPF ) <-+
NGC ( [p1,p2] ) |
( ) N9
+-> ( BP/ULCL ) |
| ( UPF [p3,p4] ) <-+
N3 ( )
| ( [a1] [a2] )
+-> ( gNB gNB )
(---/--\-----/--\---)
/ \ / \
/ \
/ RAN \
/ \
( UE UE UE )
a::1 a::2 a::3
¶
The BP/ULCL-UPF node is configured as an LISP RTR and uses the Traffic Engineering features of LISP specified in [I-D.ietf-lisp-te]. In LISP-TE an Explicit Locator Path (ELP) can be stored in the RLOC-record for any given EID thereby allowing packet flow from a UE to the Internet to traverse through the BP/UCLC-UPF node. A UE originated packet is encapsulated by the gNB to the BP/ULCL-UPF which decapsulates and reencapsulates to the UPF at the Internet border. This allows LISP to run over the 5G N3 and N9 interface with one mapping entry. And if the ELP contained an xTR outside of the mobile network, LISP could also run over the N6 interface.¶
The contents of the LISP mapping database:
EID-Record RLOC-Record Commentary
0::/0 [ELP{a1,p3,p1}, 4 RLOC-records, 2 with paths through the
ELP{a1,p4,p2}, BP-UPF and 2 directly to the border UPF
p1, p2] from UEs connected to gNB with RLOC a1
a::1/128 [a1,a2] The UPF or BP-UPF can encap directly for
UE with EID a::1 to either gNB with
optimized latency
a::2/128 [ELP{p1,p3,a2}, The UPF can encap to either RLOC p3 or p4
ELP{p1,p4,a2}] to forward traffic through the BP-UPF on
its way toward gNB with RLOC a1
a::3/128 [ELP{p1,p3,a2}, The UPF can encap to the BP-UPF or
a2] directly to gNB with RLOC a2 to reach UE
with EID a::3
¶
Since the mobile network runs the LISP control-plane, and the mapping system is available to support EIDs for unicast packet flow, it can also support multicast packet flow. Support for multicast can be provided by the LISP/GTP overlay with no changes to the NGC/EPC network.¶
Multicast (S-EID,G) entries can be stored and maintained in the same mapping database that is used to store UE based EIDs. Both Internet connected nodes, as well as UE nodes, can source multicast packets. The protocol procedures from [RFC8378] are followed to make multicast delivery available. Both multicast packet flow and UE mobility can occur at the same time.¶
A day in the life of a 1-to-many multicast packet:¶
For control-plane authentication and authorization procedures, this specification recommends the mechanisms in [RFC9301], LISP-SEC [RFC9303] and LISP-ECDSA [I-D.farinacci-lisp-ecdsa-auth].¶
For data-plane privacy procedures, this specification recommends the mechanisms in [RFC8061] When the LISP data-plane is used. Otherwise, the NGC/EPC must provide data-plane encryption support.¶
There are no specific requests for IANA.¶
The authors request other Standards Development Organizations to consider LISP as a technology for device mobility. It is recommended to start with this specification as a basis for design and develop more deployment details in the appropriate Standards Organizations. The authors are willing to facilitate this activity.¶
The authors would like to thank Gerry Foster and Peter Ashwood Smith for their expertise with 3GPP mobile networks and for their early review and contributions. The authors would also like to thank Fabio Maino, Malcolm Smith, and Marc Portoles for their expertise in both 5G and LISP as well as for their early review comments.¶
The authors would like to give a special thank you to Ryosuke Kurebayashi from NTT Docomo and Kalyani Bogineni from Verizon for their operational and practical commentary.¶