Skip to main content

LISP for the Mobile Network
draft-farinacci-lisp-mobile-network-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Dino Farinacci , Padma Pillay-Esnault , Uma Chunduri
Last updated 2017-09-18
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-farinacci-lisp-mobile-network-02
Network Working Group                                       D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                          P. Pillay-Esnault
Expires: March 22, 2018                                      U. Chunduri
                                                     Huawei Technologies
                                                      September 18, 2017

                      LISP for the Mobile Network
                 draft-farinacci-lisp-mobile-network-02

Abstract

   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.

Status of This Memo

   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 March 22, 2018.

Copyright Notice

   Copyright (c) 2017 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

Farinacci, et al.        Expires March 22, 2018                 [Page 1]
Internet-Draft         LISP for the Mobile Network        September 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
   3.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Addressing and Routing  . . . . . . . . . . . . . . . . . . .  13
   5.  eNodeB LISP Functionality . . . . . . . . . . . . . . . . . .  13
   6.  pGW LISP Functionality  . . . . . . . . . . . . . . . . . . .  14
   7.  Compatible Data-Plane using GTP . . . . . . . . . . . . . . .  14
   8.  Roaming and Packet Loss . . . . . . . . . . . . . . . . . . .  15
   9.  Mobile Network LISP Mapping System  . . . . . . . . . . . . .  15
   10. Multicast Considerations  . . . . . . . . . . . . . . . . . .  15
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   13. SDO Recommendations . . . . . . . . . . . . . . . . . . . . .  17
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     14.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  21
   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  21
     B.1.  Changes to draft-farinacci-lisp-mobile-network-02.txt . .  21
     B.2.  Changes to draft-farinacci-lisp-mobile-network-01.txt . .  21
     B.3.  Changes to draft-farinacci-lisp-mobile-network-00.txt . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   The LISP architecture and protocols [RFC6830] 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 [I-D.ietf-lisp-introduction].

   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:

Farinacci, et al.        Expires March 22, 2018                 [Page 2]
Internet-Draft         LISP for the Mobile Network        September 2017

   1.  Layer-3 address mobility is provided within a mobile network RAN
       supported by a pGW region (intra-pGW) as well as across pGW
       regions (inter-pGW).

   2.  UE nodes can get layer-3 address mobility when roaming off the
       mobile network to support Fixed Mobile Convergence [FMC].

   3.  Transport layer session survivability exists while roaming
       within, across, and off of the mobile network.

   4.  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.

   5.  The design will make efficient use of radio resources thereby not
       adding extra headers to packets that traverse the RAN.

   6.  The design can support IPv4 unicast and multicast packet delivery
       and will support IPv6 unicast and multicast packet delivery.

   7.  The design will allow use of both the GTP [GTPv1-3GPP]
       [GTPv2-3GPP] and LISP [I-D.ietf-lisp-rfc6830bis] data-planes
       while using the LISP control-plane and mapping system.

   8.  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.

   9.  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 Section 2 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 eNodeB and 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

Farinacci, et al.        Expires March 22, 2018                 [Page 3]
Internet-Draft         LISP for the Mobile Network        September 2017

   [ITU-IMT2020].  The NGMN Alliance describes Locator/ID separation an
   enabler to meet Key Performance Indicator Requirements [NGMN].

2.  Definition of Terms

   xTR:  Is a LISP node in the network that runs the LISP control-plane
      and data-plane protocols according to [I-D.ietf-lisp-rfc6830bis]
      and [I-D.ietf-lisp-rfc6833bis].  A formal definition of an xTR can
      be found in [RFC6830].  In this specification, a LISP xTR is a
      node that runs the LISP control-plane with the GTP data-plane.

   EID:  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 [RFC6830].

   UE EID:  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.

   RLOC:  Is an Routing Locator.  RLOCs are assigned to eNodeBs and pGWs
      and other LISP xTRs in LISP sites.  A formal definition of an RLOC
      can be found in [RFC6830].

   Mapping System:  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 [RFC6833].

   LISP Control-Plane:  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.

   RAN:  Radio Access Network where UE nodes connect to eNodeB nodes via
      radios to get access to the Internet.

   EPC:  Evolved Packet Core [EPS-3GPP] 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.

   NGC:  Next Generation Core [EPS-3GPP] system is the part of the 5G
      mobile network that allows the RAN to connect to a data packet
      network.

Farinacci, et al.        Expires March 22, 2018                 [Page 4]
Internet-Draft         LISP for the Mobile Network        September 2017

   GTP:  GTP [GTPv1-3GPP] [GTPv2-3GPP] is the UDP tunneling mechanism
      used in the LTE/4G and 5G mobile network.

   UE:  User Equipment as defined by [GPRS-3GPP] which is typically a
      mobile phone.  The UE is connected to the network across the RAN
      to eNodeB nodes.

   eNodeB:  Is the device defined by [GPRS-3GPP] 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.

   pGW:  Is the PDN-Gateway as defined by [GPRS-3GPP] 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.

   URLLC:  Ultra-Reliable and Low-Latency provided by the 5G mobile
      network for the shortest path between UEs [NGMN].

   FMC:  Fixed Mobile Convergence [FMC] 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.

   mMTC:  Massive Machine-Type Services [mMTC] is a term used to refer
      to using the mobile network for large-scale deployment of Internet
      of Things (IoT) applications.

Farinacci, et al.        Expires March 22, 2018                 [Page 5]
Internet-Draft         LISP for the Mobile Network        September 2017

3.  Design Overview

   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 eNodeB nodes.  So any packets going to a
   UE are always encapsulated to the 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 EPC, use the RLOCs of the pGW nodes so
   the pGW can send packets into the Internet core (unencapsulated).

   The following procedures are used to incorporate LISP in the EPC:

   o  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
      [I-D.ietf-lisp-eid-anonymity].

   o  eNodeB nodes are LISP xTRs.  They have GTP, and optionally LISP,
      tunnels to the pGW nodes.  The eNodeB is the RLOC for all EIDs
      assigned to UE devices that are attached to the eNodeB.

   o  pGW nodes are LISP xTRs.  They have GTP, and optionally LISP,
      tunnels to the eNodeB nodes.  The pGW is the RLOC for all traffic
      destined for the Internet.

   o  The LISP mapping system runs in the EPC.  It maps EIDs to RLOC-
      sets.

   o  Traffic from a UE to UE within a pGW region can be encapsulated
      from eNodeB to another eNodeB or via the pGW, acting as an RTR
      [RFC6830], to provide data-plane policy.

   o  Traffic from a UE to UE across a pGW region have these options for
      data flow:

      1.  Encapsulation by a eNodeB in one region to a eNodeB in another
          region.

      2.  Encapsulation by a eNodeB in one region to a pGW in the same
          region and then the pGW reencapsulates to a eNodeB in another
          region.

      3.  Encapsulation by a eNodeB in one region to a pGW in another
          region and then the pGW reencapsulates to a eNodeB in its same
          region

Farinacci, et al.        Expires March 22, 2018                 [Page 6]
Internet-Draft         LISP for the Mobile Network        September 2017

   o  Note when encapsulation happens between a eNodeB and a pGW, GTP is
      used as the data-plane and when encapsulation between two eNodeBs
      occur, LISP can be used as the data-plane when there is no X2
      interface [X2-3GPP] between the eNodeB nodes.

   o  The pGW nodes register their RLOCs for a default EID-prefix to the
      LISP mapping system.  This is done so eNodeB nodes can find pGW
      nodes to encapsulate to.

   o  The eNodeB nodes register EIDs to the mapping system for the UE
      nodes.  The registration occurs when eNodeB nodes discover the
      layer-3 addresses of the UEs that connect to them.  The eNodeB
      nodes register multiple RLOCs associated with the EIDs to get
      multi-homing and path diversity benefits from the EPC network.

   o  When a UE moves off a eNodeB, the eNodeB node deregisters itself
      as an RLOC for the EID associated with the UE.

   o  Optionally, and for further study for future architectures, the
      eNodeB or pGW could encapsulate to an xTR that is outside of the
      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.

Farinacci, et al.        Expires March 22, 2018                 [Page 7]
Internet-Draft         LISP for the Mobile Network        September 2017

   The following diagram illustrates the LTE mobile network topology and
   structure [LTE401-3GPP] [LTE402-3GPP]:

                (--------------------------------------------)
                (                                            )
                (                  Internet                  )
                (                                            )
                (--------------------------------------------)
                          |                         |
                          |                         |
                (---------|---------)     (---------|---------)
                (        pGW        )     (        pGW        )
                (                   )     (                   )
                (        EPC        )     (        EPC        )
                (                   )     (                   )
                (  eNodeB   eNodeB  )     (  eNodeB   eNodeB  )
                (---/--\-----/--\---)     (---/--\-----/--\---)
                   /    \   /    \           /    \   /    \
                  /      \ /      \         /      \ /      \
                 /                 \       /                 \
                /        RAN        \     /        RAN        \
               /                     \   /                     \
              (   UE      UE      UE  ) (  UE       UE      UE  )

                    LTE/5G Mobile Network Architecture

Farinacci, et al.        Expires March 22, 2018                 [Page 8]
Internet-Draft         LISP for the Mobile Network        September 2017

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

(1) IPv6 EIDs are assigned to UEs.
(2) RLOCs assigned to eNodeB nodes are [a1,a2], [b1,b2], [c1,c2], [d1,d2]
    on their uplink interfaces.
(3) RLOCs assigned to pGW nodes are [p1,p2], [p3,p4].
(4) RLOCs can be IPv4 or IPv6 addresses or mixed RLOC-sets.

             (--------------------------------------------)
             (                                            )
             (                  Internet                  )
             (                                            )
             (--------------------------------------------)
                       |                         |
                       |                         |
             (---------|---------)     (---------|---------)
             (        pGW        )     (        pGW        )
             (       p1 p2       )     (       p3 p4       )
             (                   )     (                   )
             (        EPC        )     (        EPC        )
             (                   )     (                   )
             (  a1  a2   b1  b2  )     (  c1  c2   d1  d2  )
             (  eNodeB   eNodeB  )     (  eNodeB   eNodeB  )
             (---/--\-----/--\---)     (---/--\-----/--\---)
                /    \   /    \           /    \   /    \
               /      \ /      \         /      \ /      \
              /                 \       /                 \
             /        RAN        \     /        RAN        \
            /                     \   /                     \
           (   UE      UE      UE  ) (  UE       UE      UE  )
    EIDs:     a::1    b::1    c::1     x::1     y::1    z::1

                  Mobile Network with EID/RLOC Assignment

Farinacci, et al.        Expires March 22, 2018                 [Page 9]
Internet-Draft         LISP for the Mobile Network        September 2017

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

EID-Record  RLOC-Record       Commentary                               Footnote
0::/0       [p1,p2,p3 p4]     eNodeBs encap to p1-p4 for Internet         (1)
                              destinations which are non-EIDs

a::1/128    [a1,a2]           pGWs load-split traffic to [a1,a2] for      (2)
                              UE a::1 and it can move to [b1,b2]

b::1/128    [a1,a2]           eNodeB tracks both UEs a::1 and b::1,       (3)
                              it can do local routing between the UEs

c::1/128    [b1,b2]           UE c::1 can roam to [c1,c2] or [d1,d2],     (4)
                              may use pGW [p1,p2] after move

x::1/128    [c1,c2]           UE x::1 can talk directly to UE y::1,       (5)
                              eNodeBs encap to each other

y::1/128    [d1,d2]           UE can talk to Internet when [d1,d2],       (6)
                              encap to pGW [p3,p4] or use backup [p1,p2]

z::1/128    [d1,d2]           UE z::1 can talk to a::1 directly           (7)
                              where [d1,d2] encaps to [a1,a2]

   (1) For packets that flow from UE nodes to destinations that are not
   in LISP sites, the eNodeB node use 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 EPC core to the pGW
   nodes.  In turn, the pGW nodes, then route packets into the Internet
   core.

   (2) Packets that arrive to pGW nodes from the Internet destined to UE
   nodes are encapsulated to one of the eNodeB RLOCs a1, a2, b1, b2.
   When UE, with EID a::1 is attached to the leftmost 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 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
   eNodeB node, the 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 eNodeB with RLOCs b1 and b2,
   to the eNodeB with RLOCs c1 and c2 (in the rightmost region), packets
   destined toward the Internet, can use any pGW.  Any packets that flow
   back from the Internet can use any pGW.  In either case, the pGW is

Farinacci, et al.        Expires March 22, 2018                [Page 10]
Internet-Draft         LISP for the Mobile Network        September 2017

   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 eNodeB with RLOCs c1 and c2
   and UE with EID y::1 is attached to eNodeB with RLOCs d1 and d2, they
   can talk directly, on the shortest path to each eNodeB, when each
   encapsulate packets to each other's RLOCs.

   (6) When packets from UE with EID y::1 are destined for the Internet,
   the eNodeB with RLOCs d1 and d2 that the UE is attached to can use
   any exit pGWs RLOCs p1, p2, p3, or p4.

   (7) UE with EID z::1 can talk directory to UE with EID a::1 by each
   eNodeB they are attached to encapsulsates to each other's RLOCs.  In
   case (5), the two eNodeB's were in the same region.  In this case,
   the eNodeBs are in different regions.

Farinacci, et al.        Expires March 22, 2018                [Page 11]
Internet-Draft         LISP for the Mobile Network        September 2017

   The following abbreviated diagram shows a topology that illustrates
   how a UE roams with LISP across pGW regions:

                (--------------------------------------------)
                (                                            )
                (                  Internet                  )
                (                                            )
                (--------------------------------------------)
                          |                         |
                          |                         |
                (---------|---------)     (---------|---------)
                (        pGW        )     (        pGW        )
                (       p1 p2       )     (       p3 p4       )
                (                   )     (                   )
                (        EPC        )     (        EPC        )
                (                   )     (                   )
                (  a1  a2   b1  b2  )     (  c1  c2   d1  d2  )
                (  eNodeB   eNodeB  )     (  eNodeB   eNodeB  )
                (---/--\-----/--\---)     (---/--\-----/--\---)
                   /    \   /    \           /    \   /    \
                  /      \ /      \         /      \ /      \
                 /                 \       /                 \
                /        RAN        \     /        RAN        \
               /                     \   /                     \
              (   UE    ------------------------------>  UE     )
                 a::1                                   a::1

                              UE EID Mobility

The contents of the LISP mapping database before UE moves:

EID-Record  RLOC-Record       Commentary
0::/0       [p1,p2,p3,p4]     eNodeB [a1,a2] encaps to p1-p4 for Internet
                              destinations when a::1 on eNodeB [a1,a2]

a::1/128    [a1,a2]           Before UE moves to other pGW region

The contents of the LISP mapping database after UE moves:

EID-Record  RLOC-Record       Commentary
0::/0       [p1,p2,p3,p4]     eNodeB [d1,d2] encaps to p1-p4 for Internet
                              destinations when a::1 moves to eNodeB [d1,d2]

a::1/128    [d1,d2]           After UE moves to new pGW region

Farinacci, et al.        Expires March 22, 2018                [Page 12]
Internet-Draft         LISP for the Mobile Network        September 2017

4.  Addressing and Routing

   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
   pGW node.  Each 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 EPC
   network.  An RLOC-set in the mapping system can have a mixed address-
   family locator set.  There is no requirement for the EPC to change to
   support one address-family or the other.  And there is no requirement
   for the 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 EPC and the Internet core network.

   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].

5.  eNodeB LISP Functionality

   The 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 eNodeB
   node to another eNodeB node.

   The 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 eNodeB node is an xTR, it is
   acting as a layer-3 router and the GTP tunnel from the eNodeB node to
   the 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 EPC to the pGW node.

   A day in the life of a UE originated packet:

   1.  The UE node originates an IP packet over the RAN.

Farinacci, et al.        Expires March 22, 2018                [Page 13]
Internet-Draft         LISP for the Mobile Network        September 2017

   2.  The eNodeB receives the packet, 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.

   3.  The eNodeB extracts the destination address, looks up the address
       in the mapping system.  The lookup returns the RLOC of a pGW node
       if the destination is not an EID or an RLOC eNodeB node if the
       destination is a UE based EID.

   4.  The eNodeB node encapsulates the packet to the RLOC using GTP or
       optionally the LISP data-plane.

   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
   Paragraph 2 can happen before any packet is sent.

6.  pGW LISP Functionality

   The 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 pGW node to
   another pGW or eNodeB node.

   The 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 pGW LISP xTR simply follows the
   procedures of a PxTR in [RFC6830] and for interworking to non-EID
   sites in [RFC6832].

   A day in the life of a pGW received packet:

   1.  The pGW node receives a IP packet from the Internet core.

   2.  The 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 eNodeB node.  Optionally, the RLOC could be another pGW
       node.

   3.  The pGW node encapsulates the packet to the RLOC using GTP or
       optionally the LISP data-plane.

7.  Compatible Data-Plane using GTP

   Since GTP is a UDP based encapsulating tunnel protocol, it has the
   same benefits as LISP encapsulation.  At this time, there appears to

Farinacci, et al.        Expires March 22, 2018                [Page 14]
Internet-Draft         LISP for the Mobile Network        September 2017

   be no urgent need to not continue to use GTP for tunnels between a
   eNodeB nodes and between a eNodeB node and a 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 reside 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.

8.  Roaming and Packet Loss

   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 eNodeB node the UE is roaming to or
   rerouted on the 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.

9.  Mobile Network LISP Mapping System

   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 eNodeB nodes and pGW nodes.  The RLOC addresses are
   routable addresses by the EPC network.

   This specification recommends the use of LISP-DDT.

10.  Multicast Considerations

   Since the mobile network runs the LISP control-plane, and the mapping
   system is available to support EIDs for unicast packet flow, it can

Farinacci, et al.        Expires March 22, 2018                [Page 15]
Internet-Draft         LISP for the Mobile Network        September 2017

   also support multicast packet flow.  Support for multicast can be
   provided by the LISP/GTP overlay with no changes to the 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 [I-D.ietf-lisp-signal-free-multicast]
   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:

   1.  A UE node joins an (S,G) multicast flow by using IGMPv2 or
       IGMPv3.

   2.  The eNodeB node records which UE on the RAN should get packets
       sourced by S and destined for group G.

   3.  The eNodeB node registers the (S,G) entry to the mapping system
       with its RLOC according to the receiver site procedures in
       [I-D.ietf-lisp-signal-free-multicast].  The eNodeB does this to
       show interest in joining the multicast flow.

   4.  When other UE nodes join the same (S,G), their associated eNodeB
       nodes will follow the procedures in steps 1 through 3.

   5.  The (S,G) entry stored in the mapping database has an RLOC-set
       which contains a replication list of all the eNodeB RLOCs that
       registered.

   6.  A multicast packet from source S to destination group G arrives
       at the pGW.  The pGW node looks up (S,G), gets returned the
       replication list of all joined eNodeB nodes and replicates the
       multicast packet by encapsulating the packet to each of them.

   7.  Each eNodeB node decapsulates the packet and delivers the
       multicast packet to one or more IGMP-joined UEs on the RAN.

11.  Security Considerations

   For control-plane authentication and authorization procedures, this
   specification recommends the mechanisms in
   [I-D.ietf-lisp-rfc6833bis], LISP-SEC [I-D.ietf-lisp-sec] 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 EPC must provide data-plane encryption support.

Farinacci, et al.        Expires March 22, 2018                [Page 16]
Internet-Draft         LISP for the Mobile Network        September 2017

12.  IANA Considerations

   There are no specific requests for IANA.

13.  SDO Recommendations

   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.

14.  References

14.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              DOI 10.17487/RFC1700, October 1994,
              <https://www.rfc-editor.org/info/rfc1700>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <https://www.rfc-editor.org/info/rfc6830>.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832,
              DOI 10.17487/RFC6832, January 2013,
              <https://www.rfc-editor.org/info/rfc6832>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013,
              <https://www.rfc-editor.org/info/rfc6833>.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013, <https://www.rfc-editor.org/info/rfc6836>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <https://www.rfc-editor.org/info/rfc8060>.

Farinacci, et al.        Expires March 22, 2018                [Page 17]
Internet-Draft         LISP for the Mobile Network        September 2017

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,
              <https://www.rfc-editor.org/info/rfc8061>.

   [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
              Smirnov, "Locator/ID Separation Protocol Delegated
              Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
              May 2017, <https://www.rfc-editor.org/info/rfc8111>.

14.2.  Informative References

   [ARCH5G-3GPP]
              3GPP, "System Architecture for the 5G System", TS.23.501
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3144, December
              2016.

   [EPS-3GPP]
              3GPP, "Non-Access-Stratum (NAS) Protocol for Evolved
              Packet System (EPS); Stage 3", TS.23.501
              https://portal.3gpp.org/desktopmodules/specifications/
              specificationdetails.aspx?specificationid=1072, January
              2015.

   [ETSI-NGP]
              ETSI-NGP, "NGP Evolved Architecture for mobility using
              Identity Oriented Networks", NGP-004, version 0.0.3
              https://portal.etsi.org/webapp/WorkProgram/
              Report_WorkItem.asp?WKI_ID=50531, May 2017.

   [FMC]      ipv6.com, "FIXED MOBILE CONVERGENCE",
              https://www.ipv6.com/mobile/fixed-mobile-convergence/,
              November 2006.

   [GPRS-3GPP]
              3GPP, "General Packet Radio Service (GPRS) for Evolved
              Universal Terrestrial Radio Access Network (E-UTRAN)
              Access", TS23.401 Release 8
              https://portal.3gpp.org/desktopmodules/specifications/
              specificationdetails.aspx?specificationid=849, January
              2015.

Farinacci, et al.        Expires March 22, 2018                [Page 18]
Internet-Draft         LISP for the Mobile Network        September 2017

   [GTPv1-3GPP]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", TS.29.281
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=1699, January
              2015.

   [GTPv2-3GPP]
              3GPP, "3GPP Evolved Packet System (EPS); Evolved General
              Packet Radio Service (GPRS) Tunnelling Protocol for
              Control plane (GTPv2-C); Stage 3", TS.29.274
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=1692, January
              2015.

   [I-D.farinacci-lisp-ecdsa-auth]
              Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
              Authentication and Authorization", draft-farinacci-lisp-
              ecdsa-auth-00 (work in progress), July 2017.

   [I-D.ietf-lisp-eid-anonymity]
              Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
              EID Anonymity", draft-ietf-lisp-eid-anonymity-00 (work in
              progress), August 2017.

   [I-D.ietf-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
              F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", draft-ietf-lisp-eid-mobility-00
              (work in progress), May 2017.

   [I-D.ietf-lisp-introduction]
              Cabellos-Aparicio, A. and D. Saucez, "An Architectural
              Introduction to the Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-introduction-13 (work in
              progress), April 2015.

   [I-D.ietf-lisp-mn]
              Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", draft-ietf-lisp-mn-00 (work in progress),
              April 2017.

   [I-D.ietf-lisp-predictive-rlocs]
              Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
              RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in
              progress), June 2017.

Farinacci, et al.        Expires March 22, 2018                [Page 19]
Internet-Draft         LISP for the Mobile Network        September 2017

   [I-D.ietf-lisp-rfc6830bis]
              Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos-Aparicio, "The Locator/ID Separation Protocol
              (LISP)", draft-ietf-lisp-rfc6830bis-05 (work in progress),
              August 2017.

   [I-D.ietf-lisp-rfc6833bis]
              Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
              "Locator/ID Separation Protocol (LISP) Control-Plane",
              draft-ietf-lisp-rfc6833bis-05 (work in progress), May
              2017.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
              (work in progress), November 2016.

   [I-D.ietf-lisp-signal-free-multicast]
              Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
              draft-ietf-lisp-signal-free-multicast-06 (work in
              progress), August 2017.

   [ITU-IMT2020]
              ITU-FG, "Focus Group on IMT-2020",
              https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-
              M.687-2-199702-I!!PDF-E.pdf.

   [LTE401-3GPP]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", TS.23.401
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=849, January
              2015.

   [LTE402-3GPP]
              3GPP, "Architecture enhancements for non-3GPP accesses",
              TS.23.402
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=850, January
              2015.

   [mMTC]     NGMN Alliance, "NGMN KPIs and Deployment Scenarios for
              Consideration for IMT2020",  https://www.ngmn.org/uploads/
              media/151204_NGMN_KPIs_and_Deployment_Scenarios_for_Consid
              eration_for_IMT_2020_-_LS_Annex_V1_approved.pdf, December
              2015.

Farinacci, et al.        Expires March 22, 2018                [Page 20]
Internet-Draft         LISP for the Mobile Network        September 2017

   [NGMN]     NGMN Alliance, "5G End-to-End Architecture Framework",
              NGMN https://www.ngmn.org/uploads/
              media/170511_NGMN_E2EArchFramework_v0.6.5.pdf, March 2016.

   [PROC5G-3GPP]
              3GPP, "Procedures for the 5G System", TS.23.502
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=3145, December
              2016.

   [X2-3GPP]  3GPP, "Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN); X2 Application Protocol (X2AP)", TS.36.423
              https://portal.3gpp.org/desktopmodules/Specifications/
              SpecificationDetails.aspx?specificationId=2452, June 2017.

Appendix A.  Acknowledgments

   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 for his operational and practical
   commentary.

Appendix B.  Document Change Log

B.1.  Changes to draft-farinacci-lisp-mobile-network-02.txt

   o  Posted mid September 2017.

   o  Editorial fixes from draft -01.

B.2.  Changes to draft-farinacci-lisp-mobile-network-01.txt

   o  Posted September 2017.

   o  Explain each EID case illustrated in the "Mobile Network with EID/
      RLOC Assignment" diagram.

   o  Make a reference to mMTC as a 3GPP use-case for 5G.

   o  Add to the requirements section how mobile operators believe that
      using Locator/ID separation mechanisms provide for more efficient
      mobile netwowks.

Farinacci, et al.        Expires March 22, 2018                [Page 21]
Internet-Draft         LISP for the Mobile Network        September 2017

   o  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.

B.3.  Changes to draft-farinacci-lisp-mobile-network-00.txt

   o  Initial draft posted August 2017.

Authors' Addresses

   Dino Farinacci
   lispers.net
   San Jose, CA
   USA

   Email: farinacci@gmail.com

   Padma Pillay-Esnault
   Huawei Technologies
   Santa Clara, CA
   USA

   Email: padma@huawei.com

   Uma Chunduri
   Huawei Technologies
   Santa Clara, CA
   USA

   Email: uma.chunduri@huawei.com

Farinacci, et al.        Expires March 22, 2018                [Page 22]