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

Document Type Active Internet-Draft (individual)
Last updated 2019-04-23
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
dmm                                                             S. Homma
Internet-Draft                                               K. Kawakami
Intended status: Standards Track                                     NTT
Expires: October 25, 2019                                    A. Akhavain
                                           Huawei Canada Research Centre
                                                      A. Rodriguez-Natal
                                                              R. Shekhar
                                                      Cisco Systems Inc.
                                                          April 23, 2019

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

Abstract

   This document describes an approach to introduce Identifier Locator
   Separation architecture into 3GPP 5GS with low-impact on its
   specifications, 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 October 25, 2019.

Copyright Notice

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

Homma, et al.           Expires October 25, 2019                [Page 1]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms of ID-LOC Protocols . . . . . . . . . . . . . . . .   4
     2.2.  Terms of 5GS  . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Mechanism on Data Plane . . . . . . . . . . . . . . . . . . .   5
   4.  Mechanisms on Control Plane . . . . . . . . . . . . . . . . .  10
     4.1.  Model 1: Independent Control Planes . . . . . . . . . . .  11
     4.2.  Model 2: Interworking Control Planes  . . . . . . . . . .  11
     4.3.  Model 3: Integrated Control Planes  . . . . . . . . . . .  12
   5.  Features Analysis . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Appendix A.  Case Studies on Use of LISP  . . . . . . . . . . . .  15
     A.1.  UE-to-UE Communication  . . . . . . . . . . . . . . . . .  16
       A.1.1.  Case A-1: UEs allocated different dUPF  . . . . . . .  16
       A.1.2.  Case A-2: UEs allocated the same xTR  . . . . . . . .  18
       A.1.3.  Consideration of Case that UE Moves to under Another
               xTR . . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  UE-to-dDN Communication . . . . . . . . . . . . . . . . .  19
       A.2.1.  Case A-3: UE communicates with neighbor dDN . . . . .  19
       A.2.2.  Case A-4: UE communicates with non-neighbor dDN . . .  21
     A.3.  UE-to-cDN/Internet Communication  . . . . . . . . . . . .  22
       A.3.1.  Case A-5: UE communicates with cDN  . . . . . . . . .  23
   Appendix B.  Case Studies on Use of ILA . . . . . . . . . . . . .  24
     B.1.  UE-to-UE Communications . . . . . . . . . . . . . . . . .  25
       B.1.1.  Case B-1: UEs allocated different dUPF  . . . . . . .  25
       B.1.2.  Case B-2: UEs allocated the same ILA node . . . . . .  26
     B.2.  UE-to-dDN Communication . . . . . . . . . . . . . . . . .  28
       B.2.1.  Case B-3: UE communicates with neighbor dDN . . . . .  28
       B.2.2.  Case B-4: UE communicates with non-neighbor dDN . . .  30
     B.3.  UE-to-cDN/Internet Communication  . . . . . . . . . . . .  32
       B.3.1.  Case B-5: Internet Communication  . . . . . . . . . .  33
       B.3.2.  Case B-6: Internet Communication  . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

Homma, et al.           Expires October 25, 2019                [Page 2]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

1.  Introduction

   Identifier-Locator Separation (ID-LOC) architectures aim to simplify
   management of network, devices, and sessions by employing two
   namespaces: Identifier for device's identity, and Locator for its
   location in the network.

   An ID-LOC architecture can be implemented by a dedicated protocol
   such as LISP [I-D.ietf-lisp-rfc6833bis], ILA
   [I-D.herbert-intarea-ila], ILNP [RFC6740], etc.  The control plane of
   such ID-LOC protocols can be combined with one of different
   encapsulation techniques such as GTP-U [TS.29281], SRv6
   [I-D.filsfils-spring-srv6-network-programming], MPLS [RFC3031], VXLAN
   [RFC7348], etc. at data plane to provide a customized solution.
   Furthermore, regarding control plane of ID-LOC, it can optionally
   even take advantage of enhanced PUB/SUB capable distributed databases
   to store ID-LOC mappings.

   ID-LOC protocols are also expected to be used for optimizing user-
   plane of mobile network
   [I-D.bogineni-dmm-optimized-mobile-user-plane].  Different
   alternatives to introduce ID-LOC architecture into 3GPP 5GS(5th
   Generation System), are under consideration in related IETF WG such
   as DMM WG.

   Introducing ID-LOC architecture into mobile network can involve
   modifications to 5GS architecture and specifications that might span
   over several 5GS releases.

   Therefore, an approach that enables the introduction of ID-LOC
   architecture into 5GS without change of its specifications and
   supports migration path toward a native ID-LOC network can be useful
   to operators.  Here, ID-LOC native network refers to a network that
   employs the ID-LOC architecture as only mechanism for packet
   forwarding.

   The document aims to describe one such approach and clarify different
   features, and benefits.

2.  Definition of Terms

   This section describes general terms of ID-LOC architecture.  This
   document also refers definitions of 3GPP 5GS [TS.23.501-3GPP], and
   some of such terms which are used in this document are listed in this
   section.

   The LISP terms are described in [I-D.ietf-lisp-rfc6833bis].

Homma, et al.           Expires October 25, 2019                [Page 3]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   The ILA terms are described in [I-D.herbert-intarea-ila].

   The SRv6 terms are described in
   [I-D.ietf-6man-segment-routing-header].

2.1.  Terms of ID-LOC Protocols

   Device Identifier (ID):  An ID is an identifier of host or end point
      such as UE or network function including VM instance, container,
      etc.  In ID-LOC architectures, an IP or MAC address is generally
      assigned to an end device as identifier.  In this case, IDs are
      used as values for the source and destination IP/MAC address
      fields of packets sent from end points.  Alternatively, other
      attributes of the end point, such as its Fully Qualified Domain
      Name (FQDN), can also be used as IDs.

   Locator (LOC):  A LOC is generally an address (e.g.  IPv4, IPv6, MAC,
      etc) of the ID-LOC node.  In the case of SRv6 it can be the ID-LOC
      node's local SID representing the segment for which the ID-LOC
      node is the segment termination node.

   ID-LOC node;  An ID-LOC node is a node that has at least one unique
      locator within a network domain, and has functionalities to obtain
      destination locator and to forward packets to the ID-LOC node
      which has the destination locator.  This node has an ID-LOC
      mapping cache and obtains destination locator by looking up
      destination ID (destination address of a data packet) from the
      mapping cache.  If ID of the received packet is not present in its
      own mapping cache, an ID-LOC node requests mapping information of
      the ID and the assigned locator to ID-to-LOC mapping system.  Also
      an ID-LOC node forwards packet to a peered LOC node by
      encapsulation or conversion of the IP header field such as IP
      address field, and decapsulates or reconverts packets received
      from another ID-LOC node.  Different implementations of ID-LOC
      architecture use different forwarding mechanisms.  LISP data-
      plane, for example, uses IPv4/v6 header and LISP header for
      encapsulation, whereas ILA tightly couples itself with IPv6, and
      SRv6 uses IPv6 and SIDs (Segment Identifiers).

   ID-to-LOC Mapping System:  An ID-to-LOC mapping system is a database
      which contains all known ID-to-LOC mappings within an ID-LOC
      domain.  The mapping information is updated when an end point
      moves to under another ID-LOC node.  This database can be
      logically centralized, distributed across the ID-LOC nodes, or a
      combination of both.  If the database is logically centralized,
      each ID-LOC node has an interface to the system to send a request
      and receive mapping information.

Homma, et al.           Expires October 25, 2019                [Page 4]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   ID-to-LOC Mapping Cache:  An ID-LOC mapping cache is a table in an
      ID-LOC node that stores ID-to-LOC mapping information and it is
      used for obtaining destination LOC from ID of received packet.
      ID-to-LOC mapping cache typically contains a small piece of
      database.  The cache is updated when the ID-LOC node receives a
      new ID-to-LOC mapping information from ID-to-LOC mapping system.

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
      bearer sent by UEs traverse.  A RAN encapsulate 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-to-UE or MEC (Mobile Edge Computing)
   communication.  ULCL is one of fundamental functions of 5GC Rel.15
   and it provides functionalities of packet filtering and divert for
   uplink packets sent by UEs.

   The overview of the assumed 5GC architecture of data plane where the
   proposal approach works is shown in Figure 1.  The details of
   numbered interfaces in the figure are described in [TS.23.501-3GPP].

Homma, et al.           Expires October 25, 2019                [Page 5]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

                             .--.
                            (    )-.
                          .'  cDN/  '
                         (  Internet )
                          (         -'
                           '-(     )
                              '---'
                                |N6
                          +-----+-----+
                          |   cUPF    |                           ===
                          +-----+-----+                            ^
                                |N9                                |
        ,-----------------------+-----------------------.          |
       /                                                 \         |
       |              Transport Network                  |         |
       \                                                 /         |
        `----+---------------------------+--------------'
             |N9                         |N9                   Connected
       +-----+-----+    ,-----.    +-----+-----+    ,-----.       with
       |   dUPF#1  |N6 /       \   |   dUPF#2  |N6 /       \     GTP-U
       |       [UL]+---| dDN#A |   |       [UL]+---| dDN#B |..
       |       [CL]|   \       /   |       [CL]|   \       /       |
       +-----+-----+    `-----'    +-----+-----+    `-----'        |
             |N3                         |N3                       |
                                                                   |
          (( o ))                     (( o ))                      |
             A                           A                         v
            /-\  RAN                    /-\  RAN                  ===
           /-|-\                       /-|-\

             |                           |

          [ UE ] ..                   [ UE ] ..

                                                dUPF: Distributed UPF
                                                cUPF: Central UPF
                                                 dDN: Distributed DN
                                                 cDN: Central DN

                Figure 1: Assumed 5GC Network Architecture

   This network has following features;

   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

Homma, et al.           Expires October 25, 2019                [Page 6]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

      addresses (IDs) 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 a 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 October 25, 2019                [Page 7]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

         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 proposed approach, IDs are assumed to be IP addresses and an
   ID-LOC node is installed between dUPF and dDN.  ID-LOC nodes are
   connected with a IP mechanism such as IP tunnels or translation of
   destination IP field.  As examples of such data plane protocols for
   providing connectivity between ID-LOC nodes, IPv4/v6 header with LISP
   header or SRv6 ([I-D.ietf-6man-segment-routing-header]) can be used.
   In addition, each ID-LOC node has connectivity with one or more
   Mapping Systems.  The overview is shown in Figure 3.

Homma, et al.           Expires October 25, 2019                [Page 8]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

          |                           |

       [ UE ] ..                   [ UE ] ..

                                   =====  : Connection between LOC nodes
                                   . . .  : IF to Mapping System

                  Figure 3: Proposal Network Architecture

   Each dUPF has a filter table of ULCL.  Each filter table is
   configured to match the addresses of UEs within the network domain
   (i.e., addresses for UEs assigned by the cUPF).  Filter tables can
   also be configured to match the address corresponding to the address
   space (or part of) corresponding with the dDNs in the network domain.
   UPFs monitor each uplink GTP-U packet with its ULCL and divert it to
   the connected ID-LOC node with decapsulation of GTP-U if the

Homma, et al.           Expires October 25, 2019                [Page 9]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   destination address of the inner packet (payload) matches the
   filtering table.  When ID-LOC node receives a packet from the dUPF,
   it obtains LOC which the destination of the packet (ID) belongs to by
   looking up its own ID-to-LOC mapping table or querying it from the
   Mapping System according ID-LOC mechanism.  Then it sends the packet
   to peered ID-LOC node indicated by the LOC.  The peered ID-LOC node
   converts the received packet to appropriate form and forwards them
   the destination by following its own forwarding table.

   From such processes, forwarding paths of user traffic diverted by
   ULCL from 5GC to ID-LOC node are optimized.

   A cUPF is connected with dUPFs via N9 interface and packets are
   forwarded with GTP-U encapsulation between cUPF and dUPF.

   Some case studies of ID-LOC protocols are described in Appendix A and
   Appendix B.

4.  Mechanisms on Control Plane

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

   Model 1:  Independent Control Planes

   Model 2:  Interworking Control Planes

   Model 3:  Integrated Control Planes

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

Homma, et al.           Expires October 25, 2019               [Page 10]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

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

          Figure 4: 5GS Architecture and Service-based Interfaces

4.1.  Model 1: Independent Control Planes

   In this model, control plane of 5GC and ID-to-LOC mapping mechanism
   are completely separated.  Information of a UE and an ID-LOC node
   which the UE is attached is sent to a mapping system and registered
   in the mapping database only when the ID-LOC node receives a packet
   from the UE and the UE is not registered yet.

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

4.2.  Model 2: Interworking Control Planes

   In this model, a mapping system interworks with an SMF which manages
   sessions of each UE.  A scheme to inform, that a 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.

Homma, et al.           Expires October 25, 2019               [Page 11]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

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

4.3.  Model 3: Integrated Control Planes

   In this model, SMF functionalities are integrated into a mapping
   system.  In other words, the mapping system becomes a part of 5GS.
   In 5GS architecture, an SMF has a role of session management of UEs,
   and it updates its own mapping database depending on movement of a
   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 provides a mechanism for introducing ID-LOC
      architecture into 5GS with no or nominal impact, and achieves
      optimized forwarding with session continuity in the assumed use
      cases such as UE-to-UE or UE-to-dDN communications.

   o  Regarding communication to the cDN, this approach can keep
      scalability because it does not change the current mechanism of
      5GS.

5.2.  Issues

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

6.  Security Considerations

   TBD

7.  IANA Considerations

   This memo includes no request to IANA.

Homma, et al.           Expires October 25, 2019               [Page 12]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

8.  Acknowledgement

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

9.  Informative References

   [I-D.bogineni-dmm-optimized-mobile-user-plane]
              Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
              Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
              Muscariello, L., Camarillo, P., and S. Homma, "Optimized
              Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
              optimized-mobile-user-plane-01 (work in progress), June
              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-05 (work in progress), March 2019.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-filsfils-spring-srv6-network-
              programming-07 (work in progress), February 2019.

   [I-D.herbert-intarea-ila]
              Herbert, T. and P. Lapukhov, "Identifier-locator
              addressing for IPv6", draft-herbert-intarea-ila-01 (work
              in progress), March 2018.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
              progress), April 2019.

   [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-03
              (work in progress), November 2018.

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

Homma, et al.           Expires October 25, 2019               [Page 13]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   [I-D.ietf-lisp-pubsub]
              Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
              Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
              Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
              Subscribe Functionality for LISP", draft-ietf-lisp-
              pubsub-03 (work in progress), March 2019.

   [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-26 (work in progress),
              November 2018.

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

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <https://www.rfc-editor.org/info/rfc6740>.

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

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

Homma, et al.           Expires October 25, 2019               [Page 14]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

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

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

   [TS.29281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
              December 2017.

Appendix A.  Case Studies on Use of LISP

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

   1. UE-to-UE Communication

   2. UE-to-dDN Communication

   3. UE-to-cDN/Internet Communication

   In the following description of case studies, ID and Locator are
   called EID (End-point Identifier) and RLOC (Routing Locator) in LISP
   terms.  Mapping Server has the master of EID-to-RLOC mapping
   database, and each xTR (Ingress/Egress Tunnel Router) has EID-to-RLOC
   mapping cache.  An xTR obtains the destination RLOC from its own

Homma, et al.           Expires October 25, 2019               [Page 15]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   cache by looking up the destination EID of received packet.  They
   obtain mappings from the mapping system if an EID looked up is not
   registered in the cache.  Packets are passed between xTRs with some
   tunnel protocols.

A.1.  UE-to-UE Communication

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

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

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

A.1.1.  Case A-1: UEs allocated different dUPF

Homma, et al.           Expires October 25, 2019               [Page 16]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

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

                      Figure 5: Procedure in Case A-1

   (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 cache 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 October 25, 2019               [Page 17]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

A.1.2.  Case A-2: UEs allocated the same xTR

                       +-------+
                       |Mapping|
                       |System |
                       +-------+

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

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

                      Figure 6: Procedure in Case A-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 received GTP-U traffic and
      divert it to xTR#1 with decapsulation if the destination address
      is one of address space [A].

   (3)  Since xTR#1 serves UE#2, it locally routes the traffic for
      EID=a-2. xTR#1 sends the received packets back to dUPF#1.

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

Homma, et al.           Expires October 25, 2019               [Page 18]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

   When a 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.  Unless some of the mechanism described below are in place,
   the xTRs can't send packets to the appropriate xTR during the
   updating, and thus packet drop or stalling may occur.

   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.  Some documents (e.g.,
   [I-D.ietf-lisp-eid-mobility], [I-D.ietf-lisp-pubsub]) discuss such
   mechanisms.  Alternatively, a mechanism that replicates packets to
   both the old and new location while the UE is in transit could also
   be used.  This approach is discussed in detail in
   [I-D.ietf-lisp-predictive-rlocs].

A.2.  UE-to-dDN Communication

   The UE-to-dDN communications basically correspond the communication
   between a UE and neighbor dDN (Case3).  On the other hand, if a UE
   moved under another dUPF during usage of a stateful 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 proposed approach achieves
   appropriate packet transfer in such cases.

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

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

Homma, et al.           Expires October 25, 2019               [Page 19]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

                      Figure 7: Procedure in Case A-3

   (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 received 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 October 25, 2019               [Page 20]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (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)  Since xTR#1 serves dDN#B, it locally routes the traffic for
      EID=b-1. 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)  Since xTR#1 serves UE#1, it locally routes the traffic for
      EID=a-1. xTR#1 sends packets to dUPF#1.

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

A.2.2.  Case A-4: UE communicates with non-neighbor dDN

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

                      Figure 8: Procedure in Case A-4

Homma, et al.           Expires October 25, 2019               [Page 21]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (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 moved to 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 address
      is one of address space [C].

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

A.3.  UE-to-cDN/Internet Communication

   UE-to-cDN/Internet communication is achieved by GTP-U mechanism
   originally equipped in 3GPP 5GS architecture.  In this section, we

Homma, et al.           Expires October 25, 2019               [Page 22]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   describe processes of UE-to-cDN communication in the proposal
   architecture as an example.

A.3.1.  Case A-5: UE communicates with cDN

                             ,------------.
                            /     cDN      \
                            |              |
                            |    EID=d-1   |
                            |    [APL#3]   |
                            |     |  ^     |
                            \     |  |     /
                             `------------'
                              (4) |  | (3)
                                  v  |
                             +-----------+
                             |   cUPF    |
                             +-----------+
                                  |  ^
                        (5)       |  |
             +--------------------+  |
             |  +--------------------+
             |  |       (2)
             V  |
          +-------+       +-------+
          | dUPF#1|       | xTR#1 |
          |       |       | RLOC=X|
          |   [UL]|       |       |
          |   [CL]|       |       |
          +-------+       +-------+
            |  ^
        (6) |  | (1)
            v  |

           [UE#1]
           EID=a-1

                      Figure 9: Procedure in Case A-5

   (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 cDN are assigned their addresses
      from an address space [D].  These addresses are described as d-n
      (n=1,2,..).  EID=a-1 and d-1 assigned to UE#1 and APL#3 which is
      located in cDN.

Homma, et al.           Expires October 25, 2019               [Page 23]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   [Uplink Processes]

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

   (2)  dUPF#1 monitors inner of received GTP-U packets.  Since the
      destination IP address (EID=d-1) does not hit the filter of ULCL,
      dUPF#1 re-encapsulates the packet to another GTP-U connecting to
      cUPF and forwards to cUPF.

   (3)  cUPF decapusalates GTP-U packets and forwards them to APL#3 in
      cDN depending on its own forwarding table.

   [Downlink Processes]

   (4)  APL#3 in cDN sends packets to UE#1 with setting EID=a-1 as the
      destination IP address.

   (5)  cUPF encapsulates the packets received from APL#3 and forwards
      them to dUPF#1 depending on its own forwarding table.

   (6)  dUPF re-encapsulates the packets to another GTP-U and forwards
      to UE#1.

Appendix B.  Case Studies on Use of ILA

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

   1. UE-to-UE Communication

   2. UE-to-dDN Communication

   3. UE-to-cDN/Internet Communication

   Each ILA node has ID-to-LOC mapping table.  Mappings are propagated
   amongst ILA routers or hosts in a network using mapping propagation
   protocols.

   In the following description of case studies, a mapping system,
   called ILA resolver in ILA terms, has the master of ID-to-LOC mapping
   database, and each ILA node obtains mappings from the mapping system.
   In some cases, each ILA node has an ID-to-LOC mapping database.

   In ILA, an SIR address expressed by composition of SIR prefix and
   identifier is assigned to each UE or VM instance.  An SIR prefix and
   an identifier are described SIR_prefix_n and id_m (n=1,2,...,
   m=1,2,...), and an SIR address is expressed as SIR_addr_x =[n,m]

Homma, et al.           Expires October 25, 2019               [Page 24]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (x=1,2,...) in the following description.  Also, each ILA-Nodes are
   assigned unique Locators, which is a network prefix that routes to a
   host.  Locators are described as loc_n (n=1,2,..).

B.1.  UE-to-UE Communications

   The overview of this communication type is described in A.1.

B.1.1.  Case B-1: UEs allocated different dUPF

                          +-------+
                          |Mapping|
                          |System |
                          +-------+
                            .
                            .
                            .
                        (3) .   #==========================#
                            .   #           (4)            #
                            .   #                          V
          +-------+       +-------+      +-------+      +-------+
          | dUPF#1|       | ILA-  |      | dUPF#2|      | ILA-  |
          |       |       | Node#1|      |+------|<-----| Node#2|
          |   [UL]|       |       |      ||  [UL]|  (5) |       |
          |   [CL]|------>| loc_1 |      |v  [CL]|      | loc_2 |
          +-------+  (2)  +-------+      +-------+      +-------+
               ^                          |
               | (1)                      |(6)
               |                          v

             [UE#1]                     [UE#2]
       SIR_addr_1=[1,1]             SIR_addr_2=[1,2]

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 10: Procedure in Case B-1

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix is assigned to UEs.  SIR_addr_1=[1,1] and
      SIR_addr_2=[1,2] are assigned to UE#1 and UE#2.

   (1)  UE#1 sends packets to UE#2 with setting SIR_addr_2 as the
      destination IP address.

Homma, et al.           Expires October 25, 2019               [Page 25]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (2)  dUPF#1 monitors inner packet of received GTP-U packet and
      diverts it to ILA-Node#1 with decapsulation if the prefix of the
      destination address is SIR_prefix_1.

   (3)  ILA-Node#1 updates own ID-to-LOC mapping table by interaction
      with the mapping system (if needed).

   (4)  ILA-Node#1 obtains loc_2 as Locator of the ILA node#2 from the
      ID-to-LOC mapping table.  ILA-Node#1 converts the prefixes of the
      source and destination addresses to loc_1 (Locator of id_1) and
      loc_2 (Locator of id_2).  ILA-Node#1 sends the packet to the ILA-
      Node#2.

   (5)  ILA-Node#2 receives the packet and converts the prefixes of the
      source and destination addresses to SIR_prefix_1, and then sends
      packets to dUPF#2.

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

B.1.2.  Case B-2: UEs allocated the same ILA node

Homma, et al.           Expires October 25, 2019               [Page 26]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

                          +-------+
                          |Mapping|
                          |System |
                          +-------+
                            .
                            .
                            .
                        (3) .
                            .
                            .
          +-------+       +-------+      +-------+      +-------+
          | dUPF#1|  (4)  | ILA-  |      | dUPF#2|      | ILA-  |
          |+------|<----- | Node#1|      |       |      | Node#2|
          ||  [UL]|       |       |      |   [UL]|      |       |
          |v  [CL]|------>| loc_1 |      |   [CL]|      | loc_2 |
          +-------+  (2)  +-------+      +-------+      +-------+
           |     ^
       (5) |     | (1)
           v     |

       [UE#2]    [UE#1]
   SIR_addr_2   SIR_addr_1
   =[1,2]       =[1,1]

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 11: Procedure in Case B-2

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix is assigned to UEs.  SIR_addr_1=[1,1] and
      SIR_addr_2=[1,2] are assigned to UE#1 and UE#2.

   (1)  UE#1 sends packets to UE#2 with setting SIR_addr_2 as the
      destination IP address.

   (2)  dUPF#1 monitors inner packet of received GTP-U packet and
      diverts it to ILA-Node#1 with decapsulation if the prefix of the
      destination address is SIR_prefix_1.

   (3)  ILA-node#1 updates own ID-to-LOC mapping table by interaction
      with Mapping System (if needed).

Homma, et al.           Expires October 25, 2019               [Page 27]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (4)  ILA-Node#1 obtains loc_1 as Locator of ILA node#2 from the ID-
      to-LOC mapping table.  Since loc_1 indicates itself, ILA-Node#1
      sends the packets back to dUPF#1.

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

B.2.  UE-to-dDN Communication

   The overview of this communication type is described in A.2.

B.2.1.  Case B-3: UE communicates with neighbor dDN

Homma, et al.           Expires October 25, 2019               [Page 28]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

                          +-------+
                          |Mapping|
                          |System |
                          +-------+
                            .
                            .
                            .
                        (3) .
                            .
                            .
          +-------+       +-------+      +-------+      +-------+
          | dUPF#1|  (6)  | ILA-  |      | dUPF#2|      | ILA-  |
          |+------|<----- | Node#1|      |       |      | Node#2|
          ||  [UL]|       |       |      |   [UL]|      |       |
          |v  [CL]|------>| loc_1 |      |   [CL]|      | loc_2 |
          +-------+  (2)  +-------+      +-------+      +-------+
           |    ^           |  ^
       (7) |    | (1)    (4)|  | (5)
           v    |           v  |
                         ,---------.
           [UE#1]       /  dDN#B    \
      SIR_addr_1=[1,1]  |  |   ^    |
                        |  v   |    |
                        | [APL#1]   |
                        |SIR_addr_2 |
                        \ =[2,2]   /
                         `---------'

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 12: Procedure in Case B-3

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix (SIR_prefix_1) are assigned to UEs.
      Applications in dDN#B are belonged to different ILA domain. and
      different SIR prefix (SIR_prefix_2) is assigned to these
      applications.  SIR_addr_1=[1,1] and SIR_addr_2=[2,2] are assigned
      to UE#1 and APL#1.  APL#1 is located in dDN#B.

   Uplink Processes

   (1)  UE#1 sends packets to APL#1 with setting SIR_addr_2 as the
      destination IP address.

Homma, et al.           Expires October 25, 2019               [Page 29]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (2)  dUPF#1 monitors inner packet of received GTP-U packet and
      diverts it to ILA-Node#1 with decapsulation if the prefix of the
      destination address is SIR_prefix_2.

   (3)  ILA-Node#1 updates own ID-to-LOC mapping table by interaction
      with a mapping system (if needed).  Or ILA-Node#1 may update its
      own table by a Map-Notify message when an APL is deployed or
      deleted in dDB#B.

   (4)  ILA-Node#1 obtains loc_1 as Locator of id_2 from the ID-to-LOC
      mapping table.  Since loc_1 indicates itself, ILA-Node#1 sends the
      packets to the dDN#B.

   Downlink Processes

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

   (6)  ILA-Node#1 obtains loc_1 as Locator of id_1 from the ID-to-LOC
      mapping table.  Since loc=1 indicates itself, ILA-Node#1 sends
      packets to dUPF#1.

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

B.2.2.  Case B-4: UE communicates with non-neighbor dDN

Homma, et al.           Expires October 25, 2019               [Page 30]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

                          +-------+
                          |Mapping|
                          |System |
                          +-------+
                            .
                            .                (7)
                            . #================================#
                        (3) . # #============================# #
                            . # #            (4)             # #
                            . V #                            V #
          +-------+       +-------+        +-------+      +-------+
          | dUPF#1|  (8)  | ILA-  |        | dUPF#2|      | ILA-  |
          |+------|<------| Node#1|        |       | (0)  | Node#2|
          ||  [UL]|       |       |        |   [UL]|<---->|       |
          |v  [CL]|------>| loc_1 |        |   [CL]|      | loc_2 |
          +-------+  (2)  +-------+        +-------+      +-------+
           |    ^                             ^             |  ^
       (9) |    | (1)                         | (0)      (5)|  | (6)
           v    |                             |             v  |
                            (0)               v          ,--------.
           [UE#1] <= = = = = = = = = = = = =[UE#1]      /  dDN#C   \
       SIR_addr_1  UE#1 moves to the serving area of    |  |   ^   |
       =[1,1]     dUPF#1 from the serving area of UPF#2 |  v   |   |
                                                        | [APL#2]  |
                                                        |SIR_adrr_3|
                                                        \ =[3,3]   /
                                                         `--------'

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 13: Procedure in Case B-4

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix (SIR_prefix_1) are assigned to UEs.
      Applications in dDN#C are belonged to different ILA domain. and
      different SIR prefix (SIR_prefix_3) is assigned to these
      applications.  SIR_addr_1=[1,1] and SIR_addr_3=[3,3] are assigned
      to UE#1 and APL#2.  APL#2 is located in dDN#C.  UE#1 has moved to
      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 SIR_addr_3 as the
      destination IP address.

Homma, et al.           Expires October 25, 2019               [Page 31]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (2)  dUPF#1 monitors inner packet of received GTP-U packet and
      diverts it to ILA-Node#1 with decapsulation if the prefix of the
      destination address is SIR_prefix_3.

   (3)  ILA-Node#1 updates own ID-to-LOC mapping table by interaction
      with Mapping System (if needed).

   (4)  ILA-Node#1 obtains loc_2 as Locator of id_3 from the ID-to-LOC
      mapping table.  ILA-Node#1 converts the prefix of the source
      address to loc_1 (Locator of id_1), and the prefix of the
      destination address to loc_2 (Locator of id_3).  ILA-Node#1 sends
      the packet to the ILA-Node#2.

   (5)  ILA-Node#2 converts the prefix of the source address to
      SIR_prefix_1, and the prefix of the destination address to
      SIR_prefix_3, and then sends packets to dDN#C depending on its
      forwarding table.

   Downlink Processes

   (6)  APL#2 sends packets to UE#1 with setting SIR_address_1 as the
      destination IP address.

   (7)  ILA-Node#2 obtains loc_1 as Locator of id_1 from the ID-to-LOC
      mapping table.  ILA-Node#2 converts the prefix of the source
      address to loc_2 (Locator of id_3), and the prefix of the
      destination address to loc_1 (Locator of id_1).  ILA-Node#1 sends
      the packet to the ILA-Node#1.

   (8)  ILA-Node#1 converts the prefix of the source address to
      SIR_prefix_3, and the prefix of the destination address to
      SIR_prefix_1, and then sends packets to d#UPF1 depending on its
      forwarding table.

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

B.3.  UE-to-cDN/Internet Communication

   UE-to-cDN/Internet communication are basically achieved by GTP-U
   mechanism originally equipped in 3GPP 5GS architecture.  ILA causes
   some limitation on IP addressing to UEs (e.g., all UEs in an ILA
   domain have the same SIR prefix), and thus some IP translation node
   such as NAT (Network Address Translation) may be required to enable
   UEs to access to external network.  In this section, we describe
   processes of UE-to-cDN/Internet communication in the proposal
   architecture.  In Internet communication, from aspect of privacy or
   routing with external network, SIR addresses assigned to UEs are

Homma, et al.           Expires October 25, 2019               [Page 32]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   translated by NAT function deployed between dUPF and connection
   point.

B.3.1.  Case B-5: Internet Communication

                             ,------------.
                            /     cDN      \
                            |              |
                            |SIR_addr_4=[4,4]
                            |    [APL#3]   |
                            |     |  ^     |
                            \     |  |     /
                             `------------'
                              (4) |  | (3)
                                  v  |
                             +-----------+
                             |   cUPF    |
                             +-----------+
                                  |  ^
                        (5)       |  |
             +--------------------+  |
             |  +--------------------+
             |  |       (2)
             v  |
          +-------+       +-------+
          | dUPF#1|       | ILA-  |
          |       |       | Node#1|
          |   [UL]|       |       |
          |   [CL]|       | loc_1 |
          +-------+       +-------+
            |  ^
        (6) |  | (1)
            v  |

           [UE#1]
     SIR_addr_1=[1,1]

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 14: Procedure in Case B-5

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix (SIR_prefix_1) are assigned to UEs.
      Applications in cDN are belonged to different ILA domain. and

Homma, et al.           Expires October 25, 2019               [Page 33]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

      different SIR prefix (SIR_prefix_4) is assigned to these
      applications.  SIR_addr_1=[1,1] and SIR_addr_4=[4,4] are assigned
      to UE#1 and APL#3.  APL#3 is located in cDN.

   Uplink Processes

   (1)  UE#1 sends packets to APL#3 with setting SIR_adrr_4 as the
      destination IP address.

   (2)  dUPF#1 monitors inner of received GTP-U packets.  Since the
      destination IP address (SIR_adder_4) does not hit the filter of
      ULCL, dUPF#1 re-encapsulates the packet to another GTP-U
      connecting to cUPF and forwards to cUPF.

   (3)  cUPF decapusalates GTP-U packets and forwards them to APL#3 in
      cDN depending on its own forwarding table.

   Downlink Processes

   (4)  APL#3 in cDN sends packets to UE#1 with setting SIR_addr_1 as
      the destination IP address.

   (5)  cUPF encapsulates the packets received from APL#3 and forwards
      them to dUPF#1 with GTP-U encapsulation depending on its own
      forwarding table.

   (6)  dUPF re-encapsulates the packets to another GTP-U and forwards
      to UE#1.

B.3.2.  Case B-6: Internet Communication

Homma, et al.           Expires October 25, 2019               [Page 34]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

                              IP_Addr_5
                              [Server#1]
                                  |  ^
                              (5) v  | (4)
                                .--.
                               (    )-.
                             .'        '
                            (  Internet  )
                             (         -'
                              '-(     )
                                 '---'
                              (5) |  ^ (4)
                                  v  |
                             +-----------+
                             |    NAT    | SIR_Addr_1 <-> IP_Addr_10
                             +----+-+----+
                                  |  |
                              (6) v  | (3)
                             +-----------+
                             |   cUPF    |
                             +-----------+
                                  |  ^
                        (7)       |  |
             +--------------------+  |
             |  +--------------------+
             |  |       (2)
             v  |
          +-------+       +-------+
          | dUPF#1|       | ILA-  |
          |       |       | Node#1|
          |   [UL]|       |       |
          |   [CL]|       | loc_1 |
          +-------+       +-------+
            |  ^
        (8) |  | (1)
            v  |

           [UE#1]
   SIR_addr_1=[1,1]

                  Legend: SIR_addr_x=[(SIR_Prefix), (Identifier)]

                     Figure 15: Procedure in Case B-6

Homma, et al.           Expires October 25, 2019               [Page 35]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

   (0)  Within this network, UEs are belonged to the same ILA domain,
      and the same SIR prefix (SIR_prefix_1) are assigned to UEs.
      SIR_addr_1=[1,1] assigned to UE#1 and server#1 has IP_addr_5.
      UE#1 communicate with server#1 over Internet.

   Uplink Processes

   (1)  UE#1 sends packets to server#1 with setting IP_adrr_5 as the
      destination IP address.

   (2)  dUPF#1 monitors inner of received GTP-U packets.  Since the
      destination IP address (SIR_adder_4) does not hit the filter of
      ULCL, dUPF#1 re-encapsulates the packet to another GTP-U
      connecting to cUPF and forwards to cUPF.

   (3)  cUPF decapusalates GTP-U packets and forwards them to Internet
      depending on its own forwarding table.

   (4)  NAT translates SIR_addr_1 of received packets to IP_addr_10 and
      the packets are forwarded to server#1 over Internet.

   Downlink Processes

   (5)  Server#1 sends packets to UE#1 with setting IP_addr_1 as the
      destination IP address.

   (6)  NAT translates IP_addr_10 of received packets to SIR_addr_1, and
      packets are sent to cUPF.

   (7)  cUPF encapsulates the packets with GTP-U and sends them to
      dUPF#1 depending on its own forwarding table.

   (8)  dUPF re-encapsulates the packets to another GTP-U and forwards
      to UE#1.

Authors' Addresses

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

   Email: shunsuke.homma.fp@hco.ntt.co.jp

Homma, et al.           Expires October 25, 2019               [Page 36]
Internet-Draft   draft-homma-dmm-5gs-id-loc-coexicetence      April 2019

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

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

   Arashmid Akhavain
   Huawei Canada Research Centre
   Canada

   Email: arashmid.akhavain@huawei.com

   Alberto Rodriguez-Natal
   Cisco Systems Inc.
   USA

   Email: natal@cisco.com

   Ravi Shekhar
   Cisco Systems Inc.
   India

   Email: ravishek@cisco.com

Homma, et al.           Expires October 25, 2019               [Page 37]