dmm                                                             S. Homma
Internet-Draft                                               K. Kawakami
Intended status: Standards Track                                     NTT
Expires: September 19, 2018                                 D. Farinacci
                                                             lispers.net
                                                          March 18, 2018


  Co-existence of 3GPP 5GS and Identifier Locator Separation Solution
               draft-homma-dmm-5gs-id-loc-coexistence-00

Abstract

   This document describes an approach to introduce Identifier Locator
   Separation solution into 3GPP 5GS with low-impact on its
   specification, and shows the features and considerations of this
   approach.

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 September 19, 2018.

Copyright Notice

   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




Homma, et al.          Expires September 19, 2018               [Page 1]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   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 . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms of LISP . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Terms of 5GS  . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Mechanism on Data Plane . . . . . . . . . . . . . . . . . . .   4
   4.  Mechanisms on Control Plane . . . . . . . . . . . . . . . . .  10
     4.1.  Pattern 1: Completely Separating  . . . . . . . . . . . .  11
     4.2.  Pattern 2: Interworking with Mapping System as AF . . . .  11
     4.3.  Pattern 3: Conversing SMF to Mapping System . . . . . . .  11
   5.  Features Analysis . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Case Studies . . . . . . . . . . . . . . . . . . . .  14
     A.1.  UE-2-UE Communication . . . . . . . . . . . . . . . . . .  14
       A.1.1.  Case 1: UEs allocated different dUPF  . . . . . . . .  14
       A.1.2.  Case2: UEs allocated the same xTR . . . . . . . . . .  16
       A.1.3.  Consideration of Case that UE Moves to under Another
               xTR . . . . . . . . . . . . . . . . . . . . . . . . .  17
     A.2.  UE-2-dDN Communication  . . . . . . . . . . . . . . . . .  17
       A.2.1.  Case 3: UE communicates with neighbor dDN . . . . . .  17
       A.2.2.  Case4: UE communicates with non-neighbor dDN  . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Identifier Locator Separation (ID-LOC) solutions, including LISP,
   ILA, ILNP, etc, are technologies that provide new numbering spaces,
   identifier of end point and locator for routing, within IP framework
   and enables to make management of networks, devices, or sessions be
   easier.  ID-LOC solutions are also expected to be used for optimizing
   user-plane of mobile netowrk
   [I-D.bogineni-dmm-optimized-mobile-user-plane], and ways to introduce
   ID-LOC systems into the next generation mobile network, especially it
   often indicates 3GPP 5GS (5th Generation System), are considered in
   the related IETF WGs.

   On the other hand, the discussion of the architecture of 5GS Rel.15
   including NG-RAN and 5GC (5th Generation Core) was completed on
   December 2017, and thus it would be difficult to push an ID-LOC



Homma, et al.          Expires September 19, 2018               [Page 2]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   solution that requires major changes of the architecture or
   specifications.  From this reason, an approach that enables to
   introduce an ID-LOC mechanism into 5GS without change of its
   specifications and to support migration into ID-LOC native network
   would be required.  Here, ID-LOC native network means a network which
   functionalities of ID-LOC mechanism are integrated into as a
   fundamental forwarding mechanism.

   The goal of this document is providing one of such approaches and
   clarifying the features and benefits.

2.  Definition of Terms

   As a matter of convenience, this document uses the definitions of
   LISP (Locator Identifier Separation Protocol) to express
   functionalities regarding ID-LOC systems.  The detailed
   specifications of LISP are described in [RFC6830], [RFC6831],
   [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061], and [RFC8111].
   Moreover, definitions and specifications of another approach to
   introduce LISP into 3GPP 5GS is described in
   [I-D.farinacci-lisp-mobile-network].

   This document also referes definitions of 3GPP 5GS [TS.23.501-3GPP].
   Some of such terms which are used in this document are listed in this
   section.

2.1.  Terms of LISP

   Ingress/Egress Tunnel Router (xTR):  An xTR is a LISP node that has
      both Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR)
      functionalities.  An ITR is a router which forwards packets to the
      ETR, which is assigned the appropriate RLOC, with some
      encapsulation (such as LISP header) depending on the result of
      EID-to-RLOC mapping.  An ETR is a router and it has an RLOC.  An
      ETR strips the encapsulation attached by an ITR and forwards
      packets depending on their EIDs.  An xTR has interface to EID-to-
      RLOC mapping system.

   Endpoint Identifier (EID):  An EID is an identifier of end point such
      as UE or VM instance.  An EID is a 32-bit (for IPv4) or 128-bit
      (for IPv6) value used in the source and destination IP address
      fields of an IP packet sent from an UE or a VM instance.

   Routing Locator (RLOC):  An RLOC is an IPv4 or IPv6 address of an xTR
      (ETR).

   Mapping System:  A Mapping System is a system which stores EID-to-
      RLOC mapping database.  This system uses Map-Register, Map-



Homma, et al.          Expires September 19, 2018               [Page 3]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


      Request, Map-Reply, and Map-Notify messages from xTRs to talk to
      Map-Resolvers and Map-Servers that make up the Mapping System.
      More details are described in [RFC6833].

   EID-to-RLOC Cache:  The EID-to-RLOC Cache is a short-lived, ondemand
      table in an xTR (ITR) that stores, tracks, and is responsible for
      timing out and otherwise validating EID-to-RLOC mappings.

   EID-to-RLOC Database:  The EID-to-RLOC Database is a global
      distributed database that contains all known EID-to-RLOC mappings.
      Each xTR (ETR) typically contains a small piece of the database.
      In this document, each Mapping System has full of the database.

2.2.  Terms of 5GS

   User Plane Function (UPF):  An UPF handles the user plane paths.  An
      UPF is connected to SMF with N4 interface.  More detailed
      information is described in [TS.23.501-3GPP].  This document
      defines two types of UPF, Central UPF (cUPF) and Distributed UPF
      (dUPF).  Their features are described in Section 3

   Uplink Classifier (ULCL):  An ULCL is an UPF functionality that aims
      at diverting Uplink traffic, based on filter rules provided by
      SMF, towards Data Network (DN).

   Data Network (DN):  A DN is a network where network functions and
      entities, including operator or 3rd party services, are deployed.
      This document defines two types of DN, Central DN (cDN) and
      Distributed DN (dDN).  Their features are described in Section 3.

   Radio Access Network (RAN):  A RAN is an access network where radio
      baarer sent by UEs traverse.  A RAN encupsulate users' packets
      with GTP-U.

   Session Management Function (SMF):  An SMF is a function which
      provides control plane functionalities for handling user traffic.

   Application Function (AF):  An AF is a control plane functionality
      and connected to SMF with Naf interfaces.

3.  Mechanism on Data Plane

   This approach achieves traffic forwarding with optimized path and
   session continuity by using ID-LOC and ULCL for particular
   communication including UE-2-UE or MEC (Mobile Edge Computing)
   communication.  ULCL is one of fundamental functions of 5GC Rel.15
   and it provides functionalities of packet filtering and divert for
   uplink packets sent by UEs.



Homma, et al.          Expires September 19, 2018               [Page 4]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   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




Homma, et al.          Expires September 19, 2018               [Page 5]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   This network has following features;

   o  A Central UPF (cUPF) is deployed at a connecting point to Central
      DN (cDN).  A cUPF becomes anchor point for UEs and it assigns IP
      addresses for each UE.  The traffic transmitted from UEs are
      basically sent to the cUPF.

   o  Distributed UPFs (dUPFs) and Distributed DNs (dDNs) are deployed
      and geographically distributed at user edge side.  A unique
      address space (it's not necessarily globally unique) is assigned
      to dDN.  When a dUPF forwards an UE's uplink packet, and if the
      subnet of the destination address is the same as the one assigned
      to dDN at proximity, then dUPF, with the help of ULCL, may divert
      the packet to that dDN.  Here, the ULCL identifies each
      encapsulated uplink packet to be diverted, by checking if the
      destination of the inner packet is one of IP addresses assigned
      the dDN.  A dUPF removes GTP-U header from the packets, and sends
      them to dDN via N6.  When dUPF receives packets from dDN, dUPF
      encapsulates them with GTP-U header, and merges them into downlink
      packets from cUPF.  An overview of behaviors of dUPF and ULCL is
      shown in Figure 2.

   o  Network topology between RAN and dUPF/cUPF adopts tree structure
      and the section between RAN and dUPF and the section between dUPF
      and cUPF are connected with GTP-U.


























Homma, et al.          Expires September 19, 2018               [Page 6]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


         GTP-U packets    GTP-U packets
          from cUPF        to cUPF

               |            ^
               |     N9     |
               |            |
          +----|------------|-----+
          |    |    dUPF    |     |            ,---------.
          |    v            |     | IP packet /           \
          |    o<-----------------------------|           |
          |    |            |     |           |           |
          |    |            |     |    N6     |   dDN     |
          |    |        +------+  |           |           |
          |    |        | ULCL |------------->|           |
          |    |        +------+  | IP packet |           |
          |    |            ^     |           \           /
          +----|------------|-----+            `---------'
               |            |
               |            |
               |    N3      |
               v            |

         GTP-U packets   GTP-U packets
          to UE           from UE



                   Figure 2: Behaviors of dUPF and ULCL

   In the proposal approach, an xTR is installed between dUPF and dDN.
   xTRs are connected with a tunneling protocol (it may be LISP header
   or other protocol such as SRv6
   [I-D.ietf-6man-segment-routing-header]) and each xTR has connectivity
   with one or more Mapping Systems.  The overview is shown in Figure 3.

















Homma, et al.          Expires September 19, 2018               [Page 7]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


                             .--.
                            (    )-.
                          .'  cDN/  '
                         (  Internet )
                          (         -'
                           '-(     )
                              '---'
                                |N6         ,---------.
                          +-----+-----+     | Mapping |
                          |   cUPF    |     | System  |
                          +-----+-----+     `---------'
                                |N9              .
        ,-----------------------+----------------.---------.
       / Transport Network   . . . . . . . . . . . . . . .  \
       |                     .                           .  |
       \                  #===========================#===  /
        `----+------------#--.-----------+------------#--.-'
             |N9          #  .           |N9          #  .
       +-----+-----+   +-------+   +-----+-----+   +-------+
       |   dUPF#1  |N6 |       |   |   dUPF#2  |N6 |       |
       |       [UL]+---+ xTR#1 |   |       [UL]+---| xTR#2 |..
       |       [CL]|   |       |   |       [CL]|   |       |
       +-----+-----+   +---+---+   +-----+-----+   +---+---+
             |N3           |             |N3           |
                        ,-----.                     ,-----.
          (( o ))      /       \      (( o ))      /       \
             A         | dDN#A |         A         | dDN#B |
            /-\  RAN   \       /        /-\  RAN   \       /
           /-|-\        `-----'        /-|-\        `-----'

             |                           |

          [ UE ] ..                   [ UE ] ..


                                      =====  : Tunnel connects xTRs
                                      . . .  : IF to Mapping System


                  Figure 3: Proposal Network Architecture

   Each dUPF has a filter table of ULCL.  Each filter table is
   configured to mach addresses assigned within own network domain
   (i.e., addresses for UEs assigned by cUPF) or assigned corresponding
   with address space of some of dDN.  UPFs monitor each uplink GTP-U
   packet with its ULCL and divert it to the connected xTR with
   decapsulation if the destination address of the inner packet matches
   the table.  When xTR receives a packet from the dUPF, it obtains RLOC



Homma, et al.          Expires September 19, 2018               [Page 8]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   which the destination of the packet (EID) belongs to by looking up
   its own EID-to-RLOC mapping cache or querying it from the Mapping
   System according ID-LOC mechanism.  Then it sends the packet to
   peered xTR indicated by the RLOC.

   The detailed processing flow with LISP below as an example.  In this
   example, a Mapping System obtains location of each UE from SMF and
   keeps its own EID-to-RLOC mapping database up to date.  Each xTR
   obtains EID-to-RLOC map information which isn't stored in the cache
   by sending Map-Request to a Mapping System.

   1. xTR (source xTR) receives a packet and identify the EID.

   2. The source xTR looks up the EID from its own EID-to-RLOC mapping
      cache.

   3. If there is an entry which matches to the EID, the source xTR
      sends the packet to the destination indicated by the RLOC of the
      entry.

   4. If there are no entries matches to the EID, xTR sends a request
      mapping information of the EID (Map-Request) to the Mapping System
      depending on its own forwarding table.

   5. Mapping System receives the request and detect the RLOC which the
      EID is allocated from its own EID-to-RLOC mapping database.

   6. Mapping System sends the request to the xTR assigned the RLOC
      (peered xTR).

   7. The peered xTR recieves the request and registers the EID and
      RLOC, and sends a reply (Map-reply) to the source xTR.

   8. The source xTR receives the reply and register the opponent xTR
      into own EID-to-RLOC mapping cache.

   9. If the peered xTR is the same as Source xTR itself, the source xTR
      sends the packet to either dDN or dUPF according to the
      destination of the packets.  Otherwise, the source xTR sends the
      packet to the peered xTR with necessary encapsulation.

   10.  When an xTR receives packets from other xTRs, it sends them with
      decapsulation to the appropriate destinations depending on its
      forwarding table.

   From the above processes, forwarding paths of user traffic diverted
   by ULCL from 5GC to xTR are optimized without changing their IP
   address (EID).



Homma, et al.          Expires September 19, 2018               [Page 9]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   Further case studies are described in Appendix A.

4.  Mechanisms on Control Plane

   For ID-LOC mechanism in mobile networks, a control plane mechanism to
   manage location information of UEs is required.  There are mainly
   three patterns to realize control plane mechanism for ID-LOC as
   follows:

   Pattern 1:  Completely Separating

   Pattern 2:  Interworking with Mapping System as AF

   Pattern 3:  Conversing SMF to Mapping System

   Some of patterns may require to use 5GS interfaces or add some
   functionalities to functions of 5GC.  5GS architecture and the
   service-based interfaces are shown in Figure 4.  The details of
   functions and interfaces are described in [TS.23.501-3GPP].



      +-----+  +-----+  +-----+     +-----+  +-----+  +-----+
      |NSSF |  | NEF |  | NRF |     | PCF |  | UDM |  | AF  |
      +--+--+  +--+--+  +--+--+     +--+--+  +--+--+  +--+--+
    Nnssf|    Nnef|    Nnrf|       Npcf|    Nudm|        |Naf
      ---+--------+--+-----+--+--------+--+-----+--------+-
                Nausf|    Namf|       Nsmf|
                  +--+--+  +--+--+     +--+--+
                  |AUSR |  | AMF |     | SMF |
                  +-----+  +--+--+     +-----+
                             /|           |
   C-plane                N1/ |N2         |N4

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   D-plane               /    |           |
                     N1 /     |N2         |N4
                       /      |           |
                    +-+-+  +--+--+ N3  +--+--+ N6  +----+
                    |UE +--+(R)AN+-----+ UPF +-----+ DN |
                    +---+  +-----+     +-----+     +----+



          Figure 4: 5GS Architecture and Service-based Interfaces






Homma, et al.          Expires September 19, 2018              [Page 10]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


4.1.  Pattern 1: Completely Separating

   In this pattern, control plane of 5GC and EID-to-RLOC mapping
   mechanism are completely separated.  Information of an UE and an xTR
   which the UE is attached is sent to a Mapping System and registered
   in the mapping database only when the xTR receives a packet from the
   UE and the UE is not registered yet.

   This pattern does not cause any impacts on 5GC architecture.
   However, in this pattern, an UE cannot be accessed from other UEs
   within the same network domain until a packet from the UE is diverted
   to the xTR by the UPF which the UE is located and the EID and RLOC
   are registered to the Mapping System.

4.2.  Pattern 2: Interworking with Mapping System as AF

   In this pattern, a Mapping System interworks with an SMF which
   manages sessions of each UE.  A scheme to inform, that an UE moves
   and is relocated to another UPF, from SMF to AF via Naf interface is
   defined in 5GS ([TS.23.502-3GPP])*.  A Mapping System is installed as
   an AF and obtains mobility information of UEs with the above scheme.

   * The stage 3 of discussion of 5GS has not been fixed yet and the
   specification may be changed.

   This pattern would not cause any impacts on 5GS architecture, and a
   Mapping System can always keep the current mobility information of
   each UE.

4.3.  Pattern 3: Conversing SMF to Mapping System

   In this pattern, a Mapping System has functionalities of SMF and acts
   as a part of 5GS.  In 5GS architecture, an SMF has a role of session
   management of UEs, and it updates its own mapping database depending
   on movement of an UE.

   This approach enables to always keep mapping databases the latest
   status, however, it obviously requires extension or replacement of
   SMF actually deployed in 5GS network.

5.  Features Analysis

5.1.  Benefits

   o  This approach enables to introduce ID-LOC mechanism into 5GC
      Rel.15 without any impact, and achieves optimized forwarding with
      session continuity in the assumed use cases such as UE-2-UE or UE-
      2-dDN communications.



Homma, et al.          Expires September 19, 2018              [Page 11]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   o  Regarding communication to the cDN, this approach can keep
      scalability because it does not change the current mechanism of
      5GS.  (ID-LOC-native network or full-overlay approaches need to
      deploy xTR at the cUPF, and thus the EID-to-RLOC mapping cache may
      not scale up enough in that cases.  Here, a full-overlay approach
      means making an ID-LOC system run over the whole 5GC network.)

5.2.  Issues

   o  dUPF and xTR are separated, and thus an extra hop may occur
      against the optimized forwarding.  However, it can be resolved by
      implementing dUPF and xTR within a same box or application.

6.  Security Considerations

   TBD

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Acknowledgement

   The authors would like to thank Ryosuke Kurebayashi, Koji Tsubouchi,
   and Toru Okugawa for their kind reviews and technical feedback.

9.  Informative References

   [I-D.bogineni-dmm-optimized-mobile-user-plane]
              Bogineni, K. and A. Rodriguez-Natal, "Optimized Mobile
              User Plane Solutions for 5G", draft-bogineni-dmm-
              optimized-mobile-user-plane-00 (work in progress), March
              2018.

   [I-D.farinacci-lisp-mobile-network]
              Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
              for the Mobile Network", draft-farinacci-lisp-mobile-
              network-02 (work in progress), September 2017.

   [I-D.ietf-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
              Field, B., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
              Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
              D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
              Header (SRH)", draft-ietf-6man-segment-routing-header-08
              (work in progress), January 2018.




Homma, et al.          Expires September 19, 2018              [Page 12]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


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

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

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, DOI 10.17487/RFC6831, January
              2013, <https://www.rfc-editor.org/info/rfc6831>.

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

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "Locator/Identifier Separation
              Protocol (LISP) Network Element Deployment
              Considerations", RFC 7215, DOI 10.17487/RFC7215, April
              2014, <https://www.rfc-editor.org/info/rfc7215>.

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




Homma, et al.          Expires September 19, 2018              [Page 13]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   [TS.23.501-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS
              23.501", December 2017,
              <http://www.3gpp.org/ftp//Specs/archive/23_series/23.501>.

   [TS.23.502-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS
              23.502", December 2017,
              <http://www.3gpp.org/ftp//Specs/archive/23_series/23.502>.

Appendix A.  Case Studies

   This Appendix describes detailed processes of the proposal approach
   in the following types of communications.

   1. UE-2-UE Communication

   2. UE-2-dDN Communication

A.1.  UE-2-UE Communication

   In the current architecture, a cUPF becomes an anchor point for UEs,
   and all packets between UEs even which are located to the same dUPF
   are transferred through the anchor point.  This may cause
   communication delay and inefficient resource usage.  In the proposed
   procedure, packets can be transferred without through an anchor
   point, and low latency and efficient resource usage can be achieved.

   The UE-2-UE communications include communications between UEs located
   to different dUPFs (Case 1), and communication between UEs located to
   the same dUPF (Case 2).  In this section, the detailed procedures of
   the cases are described.

   Moreover, in a mobile network, an UE may move during communications.
   This section describes problems and considerations about UE's
   handover in such case.

A.1.1.  Case 1: UEs allocated different dUPF













Homma, et al.          Expires September 19, 2018              [Page 14]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


                       +-------+
                       |Mapping|
                       |System |
                       +-------+
                         .
                         .
                         .
                     (3) .   #==========================#
                         .   #           (4)            #
                         .   #                          V
       +-------+       +-------+      +-------+      +-------+
       | dUPF#1|       | xTR#1 |      | dUPF#2|      | xTR#2 |
       |       |       | RLOC=X|      |+------|<-----| RLOC=Y|
       |   [UL]|       |       |      ||  [UL]|  (5) |       |
       |   [CL]|------>|       |      |v  [CL]|      |       |
       +-------+  (2)  +-------+      +-------+      +-------+
            ^                          |
            | (1)                      |(6)
            |                          v

          [UE#1]                     [UE#2]
          EID=a-1                    EID=a-2


                       Figure 5: Procedure in Case 1

   (0)  Within this network, addresses are assigned to UEs from a
      address space [A].  These addresses are described as a-n
      (n=1,2,..).  EID=a-1 and a-2 are assigned to UE#1 and UE#2.

   (1)  UE#1 sends packets to UE#2 with setting EID=a-2 as the
      destination IP address.

   (2)  dUPF#1 monitors inner packet of received GTP-U packet and divert
      it to xTR#1 with decapsulation if the destination address is one
      of address space [A].

   (3)  xTR#1 updates own EID-to-RLOC mapping chace by interaction with
      Mapping System (if needed).

   (4)  xTR#1 obtains the RLOC(=Y) of EID=a-2 from the EID-to-RLOC
      mapping cache, and sends the packets to the xTR#2 with a tunnel
      with RLOC=Y as the destination address.

   (5)  xTR#2 decapsulate the packets, and sends them to dUPF#2.

   (6)  dUPF#2 encapsulate packets with GTP-U header, and sends them to
      UE#2.



Homma, et al.          Expires September 19, 2018              [Page 15]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


A.1.2.  Case2: UEs allocated the same xTR


                       +-------+
                       |Mapping|
                       |System |
                       +-------+
                         .
                         .
                         .
                     (3) .
                         .
                         .
       +-------+       +-------+      +-------+      +-------+
       | dUPF#1|       | xTR#1 |      | dUPF#2|      | xTR#2 |
       |+------|<----- | RLOC=X|      |       |      | RLOC=Y|
       ||  [UL]|  (4)  |       |      |   [UL]|      |       |
       |v  [CL]|------>|       |      |   [CL]|      |       |
       +-------+  (2)  +-------+      +-------+      +-------+
        |     ^
    (5) |     | (1)
        v     |

     [UE#2]  [UE#1]
    EID=a-2  EID=a-1


                       Figure 6: Procedure in Case 2

   (0)  Within this network, addresses are assigned to UEs from a
      address space [A] These addresses are described as a-n (n=1,2,..).
      EID=a-1 and a-2 are assigned to UE#1 and UE#2.

   (1)  UE#1 sends packets to UE#2 with setting EID=a-2 as the
      destination IP address.

   (2)  dUPF#1 monitors inner packets of recieved GTP-U traffic and
      divert it to xTR#1 with decapsulation if the destination address
      is one of address space [A].

   (3)  xTR#1 updates own EID-to-RLOC mapping cache by interaction with
      Mapping System (if needed).

   (4)  xTR#1 obtains the RLOC(=X) from the EID-to-RLOC mapping cache.
      Since RLOC=X indicates itself, xTR#1 sends the packets back to
      dUPF#1.

   (5)  dUPF#2 encapsulate packets with GTP-U, and sends them to UE#2.



Homma, et al.          Expires September 19, 2018              [Page 16]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


A.1.3.  Consideration of Case that UE Moves to under Another xTR

   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.

A.2.  UE-2-dDN Communication

   The UE-2-dDN communications basically correspond the communication
   between an UE and neighbor dDN (Case3).  On the other hand, if an UE
   moved under another dUPF during usage of a statefull application, or
   the application is not uniformly deployed in every dDN, the UE needs
   to continue to communicate with the previous dDN (Case4).

   In such cases, in the current architecture, all packets are needed to
   go through the anchor point or dynamic GTP tunnel reconfiguration
   between dUPF is required.  The former solution causes additional
   communication delay and inefficient resource usage.  The latter
   solution increase the cost of 5GS control plane to dynamically update
   the GTP tunnel with multiple UPFs and their ULCL filter tables along
   with the movement of the UE.  The propal approach achieves
   appropriate packet transfer in such cases.

   In this section, the detailed procedures of communications between an
   UE and neighbor dDN and communications between an UE and non-neighbor
   dDN

A.2.1.  Case 3: UE communicates with neighbor dDN
















Homma, et al.          Expires September 19, 2018              [Page 17]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


                       +-------+
                       |Mapping|
                       |System |
                       +-------+
                         .
                         .
                         .
                     (3) .
                         .
                         .
       +-------+       +-------+      +-------+      +-------+
       | dUPF#1|       | xTR#1 |      | dUPF#2|      | xTR#2 |
       |+------|<----- | RLOC=X|      |       |      | RLOC=Y|
       ||  [UL]|  (6)  |       |      |   [UL]|      |       |
       |v  [CL]|------>|       |      |   [CL]|      |       |
       +-------+  (2)  +-------+      +-------+      +-------+
        |    ^           |  ^
    (7) |    | (1)    (4)|  | (5)
        v    |           v  |
                       ,-------.
        [UE#1]        /  dDN#B  \
        EID=a1        |  |  ^   |
                      |  v  |   |
                      | [APL#1] |
                      \ EID=b-1 /
                       `-------'


                       Figure 7: Procedure in Case 3

   (0)  Within this network, UEs are assigned their addresses from an
      address space [A].  These addresses are described as a-n
      (n=1,2,...).  Also, applications in dDN#B are assigned their
      addresses from a address space [B].  These addresses are described
      as b-n (n=1,2,..).  EID=a-1 and b-1 assigned to UE#1 and APL#1
      which is located in dDN#B.

   [Uplink Processes]

   (1)  UE#1 sends packets to dDN#B with setting EID=b-1 as the
      destination IP address.

   (2)  dUPF#1 monitors inner of recieved GTP-U packets and divert it to
      xTR#1 with decapsulation if the destination IP address is one of
      address space [B].






Homma, et al.          Expires September 19, 2018              [Page 18]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   (3)  xTR#1 updates own EID-to-RLOC mapping cache by interaction with
      Mapping System (if needed).  Or xTR#1 may update its own cache by
      a Map-Notify message when an APL is deployed or deleted in dDB#B.

   (4)  xTR#1 obtains RLOC(=X) of EID=b-1 from the EID-to-RLOC mapping
      cache.  Since RLOC=X indicates itself and EID=b-1 is within [B],
      xTR#1 sends the packets to the dDN#B.

   [Downlink Processes]

   (5)  APL#1 in dDN#B sends packets to UE#1 with setting EID=a-1 as the
      destination IP address.

   (6)  xTR#1 obtains RLOC of EID=a-1 (i.e., RLOC=X) from the EID-to-
      RLOC mapping cache.  Since RLOC=X indicates xTR#1 itself, xTR#1
      sends packets to dUPF#1.

   (7)  dUPF#2 encapsulates packets with GTP-U, and sends them to UE#1.

A.2.2.  Case4: UE communicates with non-neighbor dDN































Homma, et al.          Expires September 19, 2018              [Page 19]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


                       +-------+
                       |Mapping|
                       |System |
                       +-------+
                         .
                         .               (7)
                         . #==============================#
                     (3) . # #==========================# #
                         . # #           (4)            # #
                         . V #                          V #
       +-------+       +-------+      +-------+      +-------+
       | dUPF#1|  (8)  | xTR#1 |      | dUPF#2|      | xTR#2 |
       |+------|<------| RLOC=X|      |       | (0)  | RLOC=Y|
       ||  [UL]|       |       |      |   [UL]|<---->|       |
       |v  [CL]|------>|       |      |   [CL]|      |       |
       +-------+  (2)  +-------+      +-------+      +-------+
        |    ^                           ^             |  ^
    (9) |    | (1)                       | (0)      (5)|  | (6)
        v    |                           |             v  |
                         (0)             v           ,-------.
        [UE#1] <= = = = = = = = = = = =[UE#1]       /  dDN#C  \
        EID=a-1 UE#1 moves to the serving area of   |  |  ^   |
              dUPF#1 from the serving area of UPF#2 |  v  |   |
                                                    | [APL#2] |
                                                    \ EID=c-1 /
                                                     `-------'

                       Figure 8: Procedure in Case 4

   (0)  Within this network, UEs are assigned their addresses from an
      address space [A].  These addresses are described as a-n
      (n=1,2,..).  And applications in dDN#C are assigned their
      addresses from an address space [C].  These addresses are
      described as c-n (n=1,2,..).  EID=a-1 and c-1 assigned to UE#1 and
      APL#2 which is located in dDN#C.  UE#1 has movedto the serving
      area of dUPF#1 from the serving area of UPF#2 while communicating
      to APL#2.

   [Uplink Processes]

   (1)  UE#1 sends packets to APL#2 with setting EID=c-1 as the
      destination IP address.

   (2)  dUPF#1 monitors each inner packet of received GTP-U traffic and
      divert it to xTR#1 with decapsulation if the destination addressis
      one of address space [C].





Homma, et al.          Expires September 19, 2018              [Page 20]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   (3)  xTR#1 updates own EID-to-RLOC mapping cache by interaction with
      Mapping System (if needed).

   (4)  xTR#1 obtains RLOC(=Y) of EID=c-1 from the EID-to-RLOC mapping
      cache, and sends the packet to the xTR#2 with a tunnel with RLOC=Y
      as the destination address.

   (5)  xTR#2 decapsulates the packets received from xTR#1, and sends
      them to dDN#C depending on its forwarding table.

   [Downlink Processes]

   (6)  APL#2 sends packets to UE#1 with setting EID=a-1 as the
      destination IP address.

   (7)  xTR#2 obtains RLOC(=X) of EID=a-1 from the EID-to-RLOC mapping
      cache, and sends the packets to the xTR#1 with a tunnel with
      RLOC=X as the destination address.

   (8)  xTR#1 decapsulates the packets received from xTR#2m and sends
      them to the dUPF#1 depending on its forwarding table.

   (9)  dUPF#1 encapsulates the packets with GTP-U and sends packets to
      UE#1.

Authors' Addresses

   Shunsuke Homma
   NTT, Corp.
   3-9-11, Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: homma.shunsuke@lab.ntt.co.jp


   Kenta Kawakami
   NTT, Corp.
   3-9-11, Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: kawakami.kenta@lab.ntt.co.jp








Homma, et al.          Expires September 19, 2018              [Page 21]


Internet-Draft   draft-homma-dmm-5gs-id-loc-coexistence       March 2018


   Dino Farinacci
   lispers.net
   San Jose, CA
   USA

   Email: farinacci@gmail.com













































Homma, et al.          Expires September 19, 2018              [Page 22]