lispers.net

San Jose CA USA farinacci@gmail.com

Independent

Santa Clara CA USA padma.ietf@gmail.com

Intel Corporation

Santa Clara CA USA umac.ietf@gmail.com

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.

The LISP architecture and protocols 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 . This specification will describe how LISP can be used to provide layer-3 mobility within and across an LTE and 5G mobile network. The following are the design requirements: Layer-3 address mobility is provided within a mobile network RAN supported by a UPF/pGW region (intra-UPF/pGW) as well as across UPF/pGW regions (inter-UPF/pGW). UE nodes can get layer-3 address mobility when roaming off the mobile network to support Fixed Mobile Convergence . Transport layer session survivability exists while roaming within, across, and off of the mobile network. No address management is required when UEs roam. EID addresses are assigned to UEs at subscription time. EIDs can be reassigned when UE ownership changes. The design will make efficient use of radio resources thereby not adding extra headers to packets that traverse the RAN. The design can support IPv4 unicast and multicast packet delivery and will support IPv6 unicast and multicast packet delivery. The design will allow use of both the GTP and LISP data-planes while using the LISP control-plane and mapping system. The design can be used for either 4G/LTE and 5G mobile networks and may be able to support interworking between the different mobile networks. The LISP architecture provides a level of indirection for routing and addressing. From a mobile operator's perspective, these mechanisms provide advantages and efficiencies for the URLLC, FMC, and mMTC use cases. See for definitions and references of these use cases. 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 mobile network are also being considered in other standards organizations such as ETSI and ITU . The NGMN Alliance describes Locator/ID separation as an enabler to meet Key Performance Indicator Requirements .

Is a LISP node in the network that runs the LISP control-plane and data-plane protocols according to and . A formal definition of an xTR can be found in . In this specification, a LISP xTR is a node that runs the LISP control-plane with the GTP data-plane. Is an Endpoint Identifier. EIDs are assigned to UEs and other Internet nodes in LISP sites. A formal definition of an EID can be found in . A UE can be assigned an IPv4 and/or an IPv6 address either statically, or dynamically as is the procedure in the mobile network today. These IP addresses are known as LISP EIDs and are registered to the LISP mapping system. These EIDs are used as the source address in packets that the UE originates. Is an Routing Locator. RLOCs are assigned to gNB/eNodeBs and UPF/pGWs and other LISP xTRs in LISP sites. A formal definition of an RLOC can be found in . Is the LISP mapping database system that stores EID-to-RLOC mappings. The mapping system is centralized for use and distributed to scale and secure deployment. LISP Map-Register messages are used to publish mappings and LISP Map-Requests messages are used to lookup mappings. LISP Map-Reply messages are used to return mappings. EID-records are used as lookup keys, and RLOC-records are returned as a result of the lookup. Details can be found in . In this specification, a LISP xTR runs the LISP control-plane which originates, consumes, and processes Map-Request, Map-Register, Map-Reply, and Map-Notify messages. Radio Access Network where UE nodes connect to gNB/eNodeB nodes via radios to get access to the Internet. Evolved Packet Core system is the part of the mobile network that allows the RAN to connect to a data packet network. The EPC is a term used for the 4G/LTE mobile network. Next Generation Core system is the part of the 5G mobile network that allows the RAN to connect to a data packet network. The NGC is roughly equivalent to the 4G EPC. GTP is the UDP tunneling mechanism used in the LTE/4G and 5G mobile network. User Equipment as defined by which is typically a mobile phone. The UE is connected to the network across the RAN to gNB/eNodeB nodes. Is the device defined by which borders the RAN and connects UEs to the EPC in a 4G/LTE mobile network. The eNodeB nodes are termination point for a GTP tunnel and are LISP xTRs. The equivalent term in the 5G mobile network is "(R)AN" and "5G-NR", or simply "gNB". In this document, the two terms are used interchangeably. Is the PDN-Gateway as defined by which connects the EPC in a 4G/LTE mobile network to the Internet. The pGW nodes are termination point for a GTP tunnel and is a LISP xTR. The equivalent user/data-plane term in the 5G mobile network is the "UPF", which also has the capability to chain network functions. In this document, the two terms are used interchangeably to mean the border point from the EPC/NGC to the Internet. Ultra-Reliable and Low-Latency provided by the 5G mobile network for the shortest path between UEs . Fixed Mobile Convergence is a term used that allows a UE device to move to and from the mobile network. By assigning a fixed EID to a UE device, LISP supports transport layer continuity between the mobile network and a fixed infrastructure such as a WiFi network. Massive Machine-Type Services is a term used to refer to using the mobile network for large-scale deployment of Internet of Things (IoT) applications.

LISP will provide layer-3 address mobility based on the procedures in 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: UEs are assigned EIDs. They usually never change. They identify the mobile device and are used for transport connections. If privacy for EIDs is desired, refer to details in . gNB/eNodeB nodes are LISP xTRs. They have GTP, and optionally LISP, tunnels to the UPF/pGW nodes. The gNB/eNodeB is the RLOC for all EIDs assigned to UE devices that are attached to the gNB/eNodeB. UPF/pGW nodes are LISP xTRs. They have GTP, and optionally LISP, tunnels to the gNB/eNodeB nodes. The UPF/pGW is the RLOC for all traffic destined for the Internet. The LISP mapping system runs in the NGC/EPC. It maps EIDs to RLOC-sets. Traffic from a UE to UE within a UPF/pGW region can be encapsulated from gNB/eNodeB to another gNB/eNodeB or via the UPF/pGW, acting as an RTR , to provide data-plane policy. Traffic from a UE to UE across a UPF/pGW region have these options for data flow: Encapsulation by a gNB/eNodeB in one region to a gNB/eNodeB in another region. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in the same region and then the UPF/pGW reencapsulates to a gNB/eNodeB in another region. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in another region and then the UPF/pGW reencapsulates to a gNB/eNodeB in its same region Encapsulation by the gNB/eNodeB to a LISP xTR outside of the mobile network. An xTR outside of the mobile network could be a router in a data-center, a router at the edge of a WAN at a remote branch, or a WiFi access-point, and even a gNB/eNodeB in another carrier's mobile network. All these deployment options are to be considered for future architectures. Note when encapsulation happens between a gNB/eNodeB and a UPF/pGW, GTP is used as the data-plane and when encapsulation between two gNB/eNodeBs occur, LISP can be used as the data-plane when there is no X2 interface between the gNB/eNodeB nodes. The UPF/pGW nodes register their RLOCs for a default EID-prefix to the LISP mapping system. This is done so gNB/eNodeB nodes can find UPF/pGW nodes to encapsulate to. The gNB/eNodeB nodes register EIDs to the mapping system for the UE nodes. The registration occurs when gNB/eNodeB nodes discover the layer-3 addresses of the UEs that connect to them. The gNB/eNodeB nodes register multiple RLOCs associated with the EIDs to get multi-homing and path diversity benefits from the NGC/EPC network. When a UE moves off a gNB/eNodeB, the gNB/eNodeB node deregisters itself as an RLOC for the EID associated with the UE. Optionally, and for further study for future architectures, the gNB/eNodeB or UPF/pGW could encapsulate to an xTR that is outside of the NGC/EPC network. They could encapsulate to a LISP CPE router at a branch office, a LISP top-of-rack router in a data center, a LISP wifi access-point, LISP border routers at a hub site, and even a LISP router running in a VM or container on a server. The following diagram illustrates the LTE mobile network topology and structure :

The following diagram illustrates how LISP is used on the mobile network:

(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:

UE ) a::1 a::1 ]]>

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 .

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 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: The UE node originates an IP packet over the RAN. The gNB/eNodeB receives an IPv4/IPv6 packet, it extracts the source address from the packet, learns the UE based EID, stores its RAN location locally and registers the EID to the mapping system. The gNB/eNodeB extracts the destination address, looks up the address in the mapping system. The lookup returns the RLOC of a UPF/pGW node if the destination is not an EID or an RLOC gNB/eNodeB node if the destination is a UE based EID. The gNB/eNodeB node encapsulates the packet to the RLOC using GTP or optionally the LISP data-plane. It is important to note that in , 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 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 since it is not responsible for discovering UE based EIDs. A UPF/pGW LISP xTR simply follows the procedures of a PxTR in and for interworking to non-EID sites in . A day in the life of a UPF/pGW received packet: The UPF/pGW node receives a IP packet from the Internet core. The UPF/pGW node extracts the destination address from the packet and looks it up in the LISP mapping system. The lookup returns an RLOC of a gNB/eNodeB node. Optionally, the RLOC could be another UPF/pGW node. The UPF/pGW node encapsulates the packet to the RLOC using GTP or optionally the LISP data-plane.

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 and NOT the use of 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 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 and LISP-DDT . 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 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:

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

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 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: A UE node joins an (S,G) multicast flow by using IGMPv2 or IGMPv3. The gNB/eNodeB node records which UE on the RAN should get packets sourced by S and destined for group G. The gNB/eNodeB node registers the (S,G) entry to the mapping system with its RLOC according to the receiver site procedures in . The gNB/eNodeB does this to show interest in joining the multicast flow. When other UE nodes join the same (S,G), their associated gNB/eNodeB nodes will follow the procedures in steps 1 through 3. The (S,G) entry stored in the mapping database has an RLOC-set which contains a replication list of all the gNB/eNodeB RLOCs that registered. A multicast packet from source S to destination group G arrives at the UPF/pGW. The UPF/pGW node looks up (S,G), gets returned the replication list of all joined gNB/eNodeB nodes and replicates the multicast packet by encapsulating the packet to each of them. Each gNB/eNodeB node decapsulates the packet and delivers the multicast packet to one or more IGMP-joined UEs on the RAN.

For control-plane authentication and authorization procedures, this specification recommends the mechanisms in , LISP-SEC and LISP-ECDSA . For data-plane privacy procedures, this specification recommends the mechanisms in 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.

Posted March 2023. Update references (to propsed standard documents) and document timer.

Posted September 2022. Update references and document timer.

Posted March 2022. Update references and document timer.

Posted September 2021. Updated Uma's affliation.

Posted September 2021. Update references and document timer.

Posted March 2021. Changes to reflect editorial comments from Dirk von-Hugo. Updated ITU and 5G references (manually).

Posted March 2021. Update references and document timer.

Posted September 2020. Update references and document timer.

Posted March 2020. Change author affliations.

Posted March 2020. Update references and document timer.

Posted September 2019. Update references and document timer.

Posted March 2019. Update references and document timer.

Posted September 2018. Update document timer.

Posted March 2018. Make the spec more 5G user-friendly. That is, the design has always worked for either 4G or 5G but we make it more clear about 5G by using some basic 5G node terminlogy. Add a section how LISP can work on the N3, N6, and N9 5G spec interfaces. Describe how LISP-TE can allow BP-UPF offload functionality.

Posted mid September 2017. Editorial fixes from draft -01.

Posted September 2017. Explain each EID case illustrated in the "Mobile Network with EID/RLOC Assignment" diagram. Make a reference to mMTC as a 3GPP use-case for 5G. Add to the requirements section how mobile operators believe that using Locator/ID separation mechanisms provide for more efficient mobile netwowks. Indicate that L2-overlays is not recommended by this specification as the LISP mobile network architeture but how operators may want to deploy a layer-2 overlay service.

Initial draft posted August 2017.