[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

dmm                                                          K. Bogineni
Internet-Draft                                                   Verizon
Intended status: Informational                               A. Akhavain
Expires: December 31, 2018                 Huawei Canada Research Centre
                                                              T. Herbert
                                                              Quantonium
                                                            D. Farinacci
                                                             lispers.net
                                                      A. Rodriguez-Natal
                                                           G. Carofiglio
                                                                 J. Auge
                                                          L. Muscariello
                                                            P. Camarillo
                                                     Cisco Systems, Inc.
                                                                S. Homma
                                                                     NTT
                                                           June 29, 2018


              Optimized Mobile User Plane Solutions for 5G
           draft-bogineni-dmm-optimized-mobile-user-plane-01

Abstract

   3GPP CT4 has approved a study item to study different mobility
   management protocols for potential replacement of GTP tunnels between
   UPFs (N9 Interface) in the 3GPP 5G system architecture.

   This document provides an overview of 5G system architecture in the
   context of N9 Interface which is the scope of the 3GPP CT4 study item
   [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP],
   [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and
   [TS.38.401-3GPP].

   Architecture requirements for evaluation of candidate protocols are
   provided.  Optimization of the user plane can be in different ways -
   packet overhead, transport integration, etc.

   Several IETF protocols are considered for comparison: SRv6, LISP, ILA
   and several combinations of control plane and user plane protocols.

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



Bogineni, et al.        Expires December 31, 2018               [Page 1]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   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 December 31, 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Scope of 3GPP Study Items . . . . . . . . . . . . . . . .   5
     1.2.  Relevance to IETF . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Rationale for GTP replacement . . . . . . . . . . . . . .   6
     1.4.  Usage of GTP  . . . . . . . . . . . . . . . . . . . . . .   7
     1.5.  Document Structure  . . . . . . . . . . . . . . . . . . .   7
   2.  Conventions and terminology . . . . . . . . . . . . . . . . .   7
   3.  Overview of 3GPP Release 15 5G Architecture . . . . . . . . .   8
     3.1.  Non-Roaming Reference Architecture  . . . . . . . . . . .   8
     3.2.  End-to-end Protocol Stack . . . . . . . . . . . . . . . .  10
     3.3.  Mobility Architecture with reference to N9  . . . . . . .  11
       3.3.1.  User Plane Function (UPF) Functionalities . . . . . .  12
       3.3.2.  N9 Interface  . . . . . . . . . . . . . . . . . . . .  15
     3.4.  Roaming Architectures . . . . . . . . . . . . . . . . . .  16
       3.4.1.  Roaming and policy management . . . . . . . . . . . .  17
       3.4.2.  Local Break Out Model . . . . . . . . . . . . . . . .  18
       3.4.3.  Home Routed Model . . . . . . . . . . . . . . . . . .  18
     3.5.  Support for Multiple PDU Sessions . . . . . . . . . . . .  19
     3.6.  Service and Session Continuity Modes  . . . . . . . . . .  21
   4.  Architectural requirements  . . . . . . . . . . . . . . . . .  22
   5.  Data plane architecture models for N9 . . . . . . . . . . . .  23



Bogineni, et al.        Expires December 31, 2018               [Page 2]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.2.  Forwarding and mobility paradigms . . . . . . . . . . . .  23
     5.3.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
       5.3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  25
       5.3.2.  SRv6 with Traffic Engineering . . . . . . . . . . . .  26
       5.3.3.  Service Programming with SRv6 . . . . . . . . . . . .  27
       5.3.4.  SRv6 and Entropy  . . . . . . . . . . . . . . . . . .  28
       5.3.5.  SRv6 and transport slicing  . . . . . . . . . . . . .  28
       5.3.6.  SRv6 and Alternative Approaches to Advanced Mobility
               Support . . . . . . . . . . . . . . . . . . . . . . .  28
       5.3.7.  Areas of Concerns . . . . . . . . . . . . . . . . . .  29
     5.4.  LISP  . . . . . . . . . . . . . . . . . . . . . . . . . .  30
       5.4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  30
       5.4.2.  LISP Encapsulation  . . . . . . . . . . . . . . . . .  30
       5.4.3.  LISP Mapping Systems  . . . . . . . . . . . . . . . .  30
       5.4.4.  LISP Mobility Features  . . . . . . . . . . . . . . .  31
       5.4.5.  ILSR  . . . . . . . . . . . . . . . . . . . . . . . .  31
     5.5.  ILA . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
       5.5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  32
       5.5.2.  Protocol Layering . . . . . . . . . . . . . . . . . .  33
       5.5.3.  Control plane . . . . . . . . . . . . . . . . . . . .  33
       5.5.4.  IP addressing . . . . . . . . . . . . . . . . . . . .  34
       5.5.5.  Traffic engineering . . . . . . . . . . . . . . . . .  36
       5.5.6.  Locator Chaining with ILA . . . . . . . . . . . . . .  36
       5.5.7.  Security considerations . . . . . . . . . . . . . . .  36
     5.6.  Hybrid ICN (hICN) . . . . . . . . . . . . . . . . . . . .  37
       5.6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . .  37
       5.6.2.  Consumer and Producer mobility  . . . . . . . . . . .  37
       5.6.3.  Anchorless mobility support . . . . . . . . . . . . .  38
       5.6.4.  Benefits  . . . . . . . . . . . . . . . . . . . . . .  38
       5.6.5.  Deployment considerations . . . . . . . . . . . . . .  39
       5.6.6.  hICN with SRv6  . . . . . . . . . . . . . . . . . . .  40
       5.6.7.  Summary . . . . . . . . . . . . . . . . . . . . . . .  41
   6.  Integration into the 5G framework . . . . . . . . . . . . . .  41
     6.1.  Locator based - SRv6  . . . . . . . . . . . . . . . . . .  41
       6.1.1.  Insertion in N9 interface . . . . . . . . . . . . . .  41
       6.1.2.  Control Plane considerations  . . . . . . . . . . . .  42
       6.1.3.  Extensions to N3/F1-U/Xn-U interface  . . . . . . . .  43
       6.1.4.  Coexistence with GTP-based architecture . . . . . . .  43
     6.2.  ID-LOC split  . . . . . . . . . . . . . . . . . . . . . .  44
       6.2.1.  Insertion in N9 interface . . . . . . . . . . . . . .  44
       6.2.2.  LISP control plane  . . . . . . . . . . . . . . . . .  46
       6.2.3.  ILA control plane . . . . . . . . . . . . . . . . . .  47
       6.2.4.  Extensions to N3/F1-U/Xn-U interface  . . . . . . . .  47
       6.2.5.  Coexistence with GTP-based architecture . . . . . . .  48
     6.3.  ID-based - hICN . . . . . . . . . . . . . . . . . . . . .  50
       6.3.1.  Insertion in N9 interface . . . . . . . . . . . . . .  50
       6.3.2.  Control plane considerations  . . . . . . . . . . . .  51



Bogineni, et al.        Expires December 31, 2018               [Page 3]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


       6.3.3.  Extensions to N3/F1-U/Xn-U interface  . . . . . . . .  52
       6.3.4.  Coexistence with GTP-based architecture . . . . . . .  52
     6.4.  Coexistence of multiple protocols in network slices . . .  53
     6.5.  Interoperability/Roaming considerations . . . . . . . . .  54
   7.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  55
   8.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  55
   9.  Security Consideration  . . . . . . . . . . . . . . . . . . .  56
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  56
   11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  56
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  56
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  56
     12.2.  Informative References . . . . . . . . . . . . . . . . .  58
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  63

1.  Introduction

   Release 15 of the 3GPP specifications provide the 5G System
   Architecture in [TS.23.501-3GPP], [TS.23.502-3GPP], and
   [TS.23.503-3GPP].  They come with significant changes to the radio
   and core architectures with respect to previous generations, with the
   objective of enabling new use case requirements expected from 5G
   networks.  The user plane is however still based on GTP-U, and
   tunnelling user-traffic to anchor points in the core network.  User,
   data and forwarding plane are used with the same meaning in this
   context.

   3GPP CT4 is in charge of specifying the user plane interface named
   N9, and has approved a study item [CP-173160-1] to study possible
   candidates for user plane protocol for the 5GC in Release 16.

   This document comprehensively describes the various user plane
   protocols and how they can be used in the 3GPP 5G architecture.
   Specifically Segment Routing v6 (SRv6), Locator Identifier Separation
   Protocol (LISP), Identifier Locator Addressing (ILA) and Hybrid
   Information-Centric Networking (hICN) are introduced and their use as
   replacement of GTP for N9 is further described.

   Analysis work for clarifying the specifications of GTP-U as the
   current mobile user plane protocol and the architectural requirements
   of the 5G system is provided in [I-D.hmm-dmm-5g-uplane-analysis].
   That provides observations of GTP-U, the architectural requirements
   for UP protocol, and some evaluation criteria based on the
   requirements.

   Optimization of the user plane can be in one more more of the
   following:

   o  reduction/elimination of encapsulation;



Bogineni, et al.        Expires December 31, 2018               [Page 4]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   o  use of native routing mechanisms;

   o  efficient forwarding during, and in between mobility events;

   o  support of anchor-less mobility management and offloading of local
      traffic;

   o  reduction of session state and signaling associated with mobility
      management;

   o  convergence towards a flatter architecture, consistent with other
      mobility proposals.

1.1.  Scope of 3GPP Study Items

   3GPP CT4 WG has approved a Release 16 study item [CP-173160-1] to
   study user-plane protocol for N9 in 5GC architecture as specified in
   [TS.23.501-3GPP] and [TS.23.502-3GPP].  This provides an opportunity
   to investigate potential limits of the existing user plane solution
   and potential benefits of alternative user plane solutions.

   The following is extracted from the CT4 study item [CP-173160-1].

   The expected work in CT4 will include:

   o  Identify the possible candidate protocols for user-plane including
      existing protocol;

   o  Define a list of evaluation criteria based on Rel-16 stage 2
      requirements to evaluate the candidate protocols;

   o  Evaluate the candidate solutions against the list of requirements
      and the potential benefits against the existing user plane
      solution in 5GS.

   CT4 will coordinate with RAN3 for selecting the user plane protocols
   for N3 and F1-U interfaces in RAN.  CT4 will also coordinate with CT3
   Working Group for potential impacts to N6 interface and with SA2 for
   potential impacts on stage 2 specifications.

   Coordination will also be required with CT3 for potential impacts on
   N6, and with SA2 if the work has possible impacts on the stage 2
   specifications.

   Extracted from [SP-180231-1], the work in SA2 Study item will study
   the feasibility of extending the service concept from 5GC control
   plane to the user plane function(s).  Impact to User plane traffic
   processing is not expected in this study.



Bogineni, et al.        Expires December 31, 2018               [Page 5]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


1.2.  Relevance to IETF

   IETF has some protocols for potential consideration as candidates.
   These protocols have the potential to simplify the architecture
   through reduction/elimination of encapsulation; use of native routing
   mechanisms; support of anchor-less mobility management; reduction of
   session state and reduction of signaling associated with mobility
   management.

   This document provides an overview of the various protocols and how
   they can be used in the 3GPP 5G architecture.  Details of the
   protocols will be provided as references in the respective sections,
   then described in the context of the 3GPP 5G architecture.  ILNP is
   an end-to-end protocol and is not included in this document.  The
   scenario of replacing GTP on N9 as the focus of CT4 study is
   discussed for each protocol.  Additional scenarios are related to N3/
   F1-U; integration of mobility with transport; support for different
   mobility protocols on different slices of the 5G system, etc.

1.3.  Rationale for GTP replacement

   Although being different in terms of architecture or implementations,
   common objectives emerge from the different proposals and their
   positioning with respect to the GTP-U tunnel-based architecture.  We
   succintly discuss those aspects here, that will be detailed in the
   sections dedicated to each protocol, clarifying some terminology at
   the same occasion.

   _Simplification_ : simplify the management of networks, flat and
   converge architecture with other mobility proposals.

   _Efficiency_ : performance of the proposal for both packet
   forwarding, and handling of traffic during mobility events.

   _Overhead_ : remove encapsulation overhead due to tunneling.

   _Data plane anchors_ : remove anchoring of all communications in a
   central core location, and opt for distributed/decentralized/full
   removal of anchors.

   _Offloading of local communications_ : a direct consequence on the
   distribution/removal of user plane anchors is the ability to offload
   local traffic from the core.

   _Control plane anchors_ : remove dependency on additional control
   plane anchors, and interoperability with the SMF.





Bogineni, et al.        Expires December 31, 2018               [Page 6]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   _Transport_ : Relieve transport and application layers from the
   impact of mobility and related management protocols.

1.4.  Usage of GTP

   The main focus of the study is on the N9 interfaces that interconnect
   UPFs and could span over the mobile backhaul.  However, GTP is used
   at multiple interfaces beyond N9.

   N3 and N9 interfaces are tightly coupled and Section 6 discusses the
   possibility to extend the deployment of new user planes to N3.  The
   impact on N3, F1-U, and Xn-U interfaces is still TBD.

1.5.  Document Structure

   Section 3 provides a high level overview of the 5G system
   architecture and the relevant scenarios like roaming, support fo
   multiple PDU sessions, etc.  Section 4 provides a list of
   architectural requirements that candidate solutions should address
   are provided.  Section 5 provides an overview of the various
   protocols.  Section 6 discusses how various approaches can be
   integrated into the 5G framework.  A summary is provided in
   Section 7.

2.  Conventions and terminology

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying significance described in RFC 2119.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a statement using the key words listed above.  This
   convention aids reviewers in quickly identifying or finding the
   portions of this RFC covered by these keywords.

   Acronyms

   _AF_: Application Function

   _AUSF_: Authentication Server Function




Bogineni, et al.        Expires December 31, 2018               [Page 7]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   _AMF_: Access and Mobility Management Function

   _DN_: Data Network, e.g. operator services, Internet access or 3rd
   party services

   _NEF_: Network Exposure Function

   _NRF_: Network Repository Function

   _NSSF_: Network Slice Selection Function

   _PCF_: Policy Control Function

   _RAN_: (Radio) Access Network

   _SMF_: Session Management Function

   _UDM_: Unified Data Management

   _UDR_: Unified Data Repository

   _UE_: User Equipment

   _UPF_: User Plane Function

3.  Overview of 3GPP Release 15 5G Architecture

   This section briefly describes the 5G system architecture as
   specified in [TS.23.501-3GPP].  The key relevant features for session
   management and mobility management are:

   o  Separate the User Plane (UP) functions from the Control Plane (CP)
      functions, allowing independent scalability, evolution and
      flexible deployments e.g.  centralized location or distributed
      (remote) location.

   o  Support concurrent access to local and centralized services.  To
      support low latency services and access to local data networks, UP
      functions can be deployed close to the Access Network.

   o  Support roaming with both Home routed traffic as well as Local
      breakout traffic in the visited PLMN.

3.1.  Non-Roaming Reference Architecture

   This section briefly describes the 5G system architecture as
   specified in 3GPP TS 23.501, and represented in Figure 1 and
   Figure 2.



Bogineni, et al.        Expires December 31, 2018               [Page 8]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


         +------+ +------+     +------+
         | NSSF | | AUSF +-N13-+ UDM  |
         +------+ +------+     +------+
               \      |      /      \
                N22  N12   N8        N10
                 \    |    /          \
                 +----+----+       +-------+      +------+      +------+
     +-----------+   AMF   +- N11 -+  SMF  +- N7 -+  PCF +- N5 -+  AF  |
     |           +++-----+++       +---+---+      +--+---+      +------+
     |            ||     ||            |             |
     |            ||     |+------------|----- N15 ---+
     N1         N2|+-N14-+            N4
     |            |                    |
  +--+--+        ++-------+        +---+---+        +------+
  |  UE +-- NR --+ (R)AN  +-- N3 --+  UPF  +-- N6 --+  DN  |
  +-----+        +--------+        ++-----++        +------+
                                    |     |
                                    +--N9-+

    Figure 1: 5G System Architecture in Reference Point Representation

   A short description of the network functions is provided below.
   Details are in [TS.23.501-3GPP].

   Access and Mobility Management Function (AMF) interfaces with the
   Radio access network and provides management of
   registration/connection/reachability/mobility, access authentication
   and authorization, etc.

   Session Management function (SMF) handles session management, UE IP
   address allocation & management, DHCP, ARP proxying, selection and
   control of UP function, traffic steering, interface to PCF,charging
   data collection, roaming, etc.

   User Plane Function (UPF) is the anchor point mobility, packet
   routing/forwarding/marking, packet inspection, policy rule
   enforcement, lawful intercept, QoS handling,etc.

   Policy Control Function (PCF) provides policy rules to Control Plane
   function(s) to enforce them.

   Network Exposure Function (NEF) supports exposure of capabilities and
   events between network functions, to 3rd party, Application
   Functions, Edge Computing, etc.

   Network Repository Function (NRF) supports service discovery
   function.




Bogineni, et al.        Expires December 31, 2018               [Page 9]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Unified Data Management (UDM) supports access authorization,
   subscription management, etc.

   Authentication Server Function (AUSF) supports authentication for
   3GPP access and untrusted non-3GPP access.

   Network Slice Selection Function (NSSF) selects the set of Network
   Slice instances serving the UE, determines the allowed slices, etc.

   Application Function (AF)

                        Service Based Interfaces
    ----+-----+-----+----+----+---------+--------+-----+----+----
        |     |     |    |    |         |        |     |    |
    +---+---+ |  +--+--+ | +--+---+  +--+--+  +--+--+  |  +----+
    | NSSF  | |  | NRF | | | AUSF |  | UDM |  | NEF |  |  | AF |
    +-------+ |  +-----+ | +------+  +-----+  +-----+  |  +----+
          +---+----+  +--+--+            +-------------+--+
          |  AMF   |  | PCF |            |      SMF       |
          +---+--+-+  +-----+            +-+-----------+--+
             N1  |                         |           |
   +-------+  |  |                         N4          N4
   | 5G UE |--+  |                         |           |
   +---+---+     N2                  +-----+-+     +---+---+      +----+
       |         |      +----N3------+  UPF  +-N9--+  UPF  +--N6--+ DN |
       |         |      |            ++----+-+     +-------+      +----+
       |         |      |             |    |
       |     +---+------+-+           +-N9-+
       +-----|    gNB     |
             +------------+

                  Figure 2: 5G Service Based Architecture

3.2.  End-to-end Protocol Stack

   The protocol stack for the User Plane transport for a PDU session is
   depicted below in Figure 3.














Bogineni, et al.        Expires December 31, 2018              [Page 10]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   +-----+                     |                       |          |
   | App +---------------------|-----------------------|----------|
   +-----+                     |                       | +------+ |
   | PDU +---------------------|-----------------------|-+ PDU  | |
   +-----+  +---------------+  |  +-----------------+  | +------+ |
   |     |  |\             /|  |  |\               /|  | |      | |
   |     |  |  \  Relay  /  |  |  |  \    Relay  /  |  | |      | |
   |     |  |    \     /    |  |  |    \       /    |  | |5G UP | |
   | AN  |  |     --+--     |  |  |     ---+---     |  | | Enc  | |
   | Pro |  |AN Pro | GTP-U +--|--+ GTP-U  |5GUP Enc+--|-+      | |
   | Lyrs|  | Lyrs  +-------+  |  +--------+--------+  | +------+ |
   |     +--+       |UDP/IP +--|--+ UDP/IP | UDP/IP +--|-+UDP/IP| |
   |     |  |       +-------+  |  +--------+--------+  | +------+ |
   |     |  |       |  L2   +--|--+  L2    |   L2   +--|-+  L2  | |
   |     |  |       +-------+  |  +--------+--------+  | +------+ |
   |     |  |       |  L1   +--|--+  L1    |   L1   +--|-+  L1  | |
   +-----+  +-------+-------+  |  +--------+--------+  | +------+ |
     UE            AN          N3         UPF        N9          N6
                                                             UPF
                                                    (PDU Session Anchor)


   Legend:
   o PDU layer: This layer corresponds to the PDU carried between the UE
       and the DN over the PDU session. When the PDU session Type is
       IPV6, it corresponds to IPv6 packets; When the PDU session Type
       is Ethernet, it corresponds to Ethernet frames; etc.
   o GPRS Tunnelling Protocol for the user plane (GTP U): This protocol
       supports multiplexing traffic of different PDU sessions (possibly
       corresponding to different PDU session Types) by tunnelling user
       data over N3 (i.e. between the AN node and the UPF) in the
       backbone network. GTP shall encapsulate all end user PDUs. It
       provides encapsulation on a per PDU session level. This layer
       carries also the marking associated with a QoS Flow.
   o 5G Encapsulation: This layer supports multiplexing traffic of
       different PDU sessions (possibly corresponding to different PDU
       session Types) over N9 (i.e. between different UPF of the 5GC).
       It provides encapsulation on a per PDU session level. This layer
       carries also the marking associated with a QoS Flow.

           Figure 3: Non-roaming 5G SA for multiple PDU Sessions

3.3.  Mobility Architecture with reference to N9

   This document focuses on the N9 interface which represents the user
   user plane between UPFs in 5G architecture.  Figure 4 shows the
   relevant functions and interfaces.




Bogineni, et al.        Expires December 31, 2018              [Page 11]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                                 +-----------------+
                                 |       SMF       |
                                 +-+-------------+-+
                                   |             |
                                   N4            N4
                                   |             |
        +-----------+        +------+-+         +-+------+        +----+
        |  gNB/RAN  |---N3---+  UPF   |---N9----|  UPF   +---N6---| DN |
        +-----------+        +--------+         +--------+        +----+

        Figure 4: N3, N4, N9, and N6 interfaces in 5G Service Based
                               Architecture

3.3.1.  User Plane Function (UPF) Functionalities

   The User plane function (UPF) is the function relevant to this
   evaluation and the N9 interface between two UPFs.

   The User Plane Function (UPF) handles the user plane path of PDU
   sessions.  The UPF transmits the PDUs of the PDU session in a single
   tunnel between 5GC and (R)AN.  The UPF includes the following
   functionality.  Some or all of the UPF functionalities may be
   supported in a single instance of a UPF.  Not all of the UPF
   functionalities are required to be supported in an instance of user
   plane function of a Network Slice.

   The following provides a brief list of main UPF functionalities.
   Please refer to section 6.2.3 of [TS.23.501-3GPP] for detailed
   description of UPF and its functionalities.

   o  Anchor point for Intra-/Inter-RAT mobility (when applicable)"

   o  Sending and forwarding of one or more end marker to the source NG-
      RAN node

   o  External PDU Session point of interconnect to Data Network.

   o  PDU session type: IPv4, IPv6, Ethernet, Unstructured (type of PDU
      totally transparent to 5GS)

   o  Activation and release of the UP connection of an PDU session,
      upon UE transition between the CM-IDLE and CM-CONNECTED
      states(i.e. activation and release of N3 tunnelling towards the
      access network)

   o  Data forwarding between the SMF and the UE or DN (e.g.  IP address
      allocation or DN authorization during the establishment of a PDU
      session)



Bogineni, et al.        Expires December 31, 2018              [Page 12]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   o  Packet routing and forwarding (e.g. support of Uplink classifier
      to route traffic flows to an instance of a data network, support
      of Branching point to support IPv6 multi-homed PDU session>

   o  Branching Point to support routing of traffic flows of an IPv6
      multi-homed PDU session to a data network, based on the source
      Prefix of the PDU

   o  User Plane part of policy rule enforcement (e.g.  Gating,
      Redirection, Traffic steering)

   o  Uplink Classifier enforcement to support routing traffic flows to
      a data network, e.g. based on the destination IP address/Prefix of
      the UL PDU

   o  Lawful intercept (UP collection)

   o  Traffic usage reporting

   o  QoS handling for user plane including:

      *  packet filtering, gating, UL/DL rate enforcement, UL/DL
         Session-AMBR enforcement (with the Session-AMBR computed by the
         UPF over the Averaging window provisioned over N4, see
         subclause 5.7.3 of 3GPP [TS.23.501-3GPP]), UL/DL Guaranteed
         Flow Bit Rate (GFBR) enforcement, UL/DL Maximum Flow Bit Rate
         (MFBR) enforcement, etc

      *  marking packets with the QoS Flow ID (QFI) in an encapsulation
         header on N3 (the QoS flow is the finest granularity of QoS
         differentiation in the PDU session)

      *  enabling/disabling reflective QoS activation via the User
         Plane, i.e.  marking DL packets with the Reflective QoS
         Indication (RQI) in the encapsulation header on N3, for DL
         packets matching a QoS Rule that contains an indication to
         activate reflective QoS

   o  Uplink Traffic verification (SDF to QoS flow mapping, i.e.
      checking that QFIs in the UL PDUs are aligned with the QoS Rules
      provided to the UE or implicitly derived by the UE e.g. when using
      reflective QoS)

   o  Transport level packet marking in the uplink and downlink, e.g.
      based on 5QI and ARP of the associated QoS flow.

   o  Downlink packet buffering and downlink data notification
      triggering: This includes the support and handling of the ARP



Bogineni, et al.        Expires December 31, 2018              [Page 13]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


      priority of QoS Flows over the N4 interface, to support priority
      mechanism:

      *  "For a UE that is not configured for priority treatment, upon
         receiving the "N7 PDU-CAN Session Modification" message from
         the PCF with an ARP priority level that is entitled for
         priority use, the SMF sends an "N4 Session Modification
         Request" to update the ARP for the Signalling QoS Flows, and
         sends an "N11 SM Request with PDU Session Modification Command"
         message to the AMF, as specified in clause 4.3.3.2 of
         [TS.23.502-3GPP].

      *  "If an IP packet arrives at the UPF for a UE that is CM-IDLE
         over a QoS Flow which has an ARP priority level value that is
         entitled for priority use, delivery of priority indication
         during the Paging procedure is provided by inclusion of the ARP
         in the N4 interface "Downlink Data Notification" message, as
         specified in clause 4.2.3.4 of [TS.23.502-3GPP]."

   o  ARP proxying as specified in [RFC1027] and / or IPv6 Neighbour
      Solicitation Proxying as specified in [RFC4861] functionality for
      the Ethernet PDUs.  The UPF responds to the ARP and / or the IPv6
      Neighbour Solicitation Request by providing the MAC address
      corresponding to the IP address sent in the request.

   o  Packet inspection (e.g.  Application detection based on service
      data flow template and the optional PFDs received from the SMF in
      addition)

   o  Traffic detection capabilities.

      *  For IP PDU session type, the UPF traffic detection capabilities
         may detect traffic using traffic pattern based on at least any
         combination of:

         +  PDU session

         +  QFI

         +  IP Packet Filter Set. Please refer to section 5.7.6.2 of
            3GPP TS 23.501 for further details.

      *  For Ethernet PDU session type, the SMF may control UPF traffic
         detection capabilities based on at least any combination of:

         +  PDU session

         +  QFI



Bogineni, et al.        Expires December 31, 2018              [Page 14]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


         +  Ethernet Packet Filter Set. Please refer to section 5.7.6.3
            of 3GPP TS 23.501 for further details.

   o  Network slicing Requirements for different MM mechanisms on
      different slice.  The selection mechanism for SMF to select UPF
      based on the selected network slice instance, DNN and other
      information e.g.  UE subscription and local operator policies.

3.3.2.  N9 Interface

   The details of N9 interface are extracted from [TR.29.891-3GPP].

   The following information is sent in an encapsulation header over the
   N3 interface.  N9 needs to support that.

   o  QFI (QoS Flow Identifier), see subclause 5.7.1 of
      [TS.23.501-3GPP].

   o  RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of
      [TS.23.501-3GPP].

   o  Support of RAN initiated QoS Flow mobility, when using Dual
      connectivity, also requires the QFI to be sent within End Marker
      packets.  See subclause 5.11.1 of [TS.23.501-3GPP] and subclause
      4.14.1 of [TS.23.502-3GPP] respectively.

   GTPv1-U as defined in [TS.29.281-3GPP] is used over the N3 and N9
   interfaces in Release 15.  Release 15 is still work-in-progress and
   RAN3 will specify the contents of the 5GS Container.  It is to be
   decided whether CT4 needs to specify new GTP-U extension header(s) in
   [TS.29.281-3GPP] for the 5GS Container.

   A GTP-U tunnel is used per PDU session to encapsulate T-PDUs and
   GTP-U signaling messages (e.g.  End Marker, Echo Request, Error
   Indication) between GTP-U peers.

   A 5GS Container is defined as a new single GTP-U Extension Header
   over the N3 and N9 interfaces and the elements are added to this
   container as they appear with the forthcoming features and releases.
   This approach would allow to design the 5GS information elements
   independently from the tunneling protocol used within the 5GS, i.e.
   it would achieve the separation of the Transport Network Layer (TNL)
   and Radio Network Layer (RNL) as required in 3GPP TR 38.801 subclause
   7.3.2.  This would allow to not impact the RNL if in a future release
   a new transport network layer (TNL) other than GTP-U/UDP/IP (e.g.
   GRE/IP) was decided to be supported.





Bogineni, et al.        Expires December 31, 2018              [Page 15]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


3.4.  Roaming Architectures

   3GPP specifies two roaming models in [TS.23.501-3GPP], namely the
   Local Break Out (LBO) and the Home Routed (HR) model.

   o  Local Break Out Model: This model enables traffic to be offloaded
      locally in the visited network.

   o  Home Routed Model: In this model, the traffic is always routed to
      the home network.

   A given UE can have multiple simultaneous PDU sessions with different
   roaming models.  In these scenarios, the HPLMN uses subscription data
   per Data Network Name(DNN) and per Single Network Slice Selection
   Assistance Information(S-NSSAI) to determine PDU sessions's roaming
   model.

   They are represented in Figure 5 and Figure 6 to the extent relevant
   to N9.

                                      VPLMN      |     HPLMN
            +-----+         +-------+            |        +-------+
            | AF  |----N5---| V-PCF |-----------N24-------| H-PCF |
            +-----+         +-------+            |        +-------+
                                |                |
                               N7                |
                                |                |
                             +--+--+             |
                             | SMF |             |
                             +--+--+             |
                                |                |
      +-------+                N4                |
      | 5G UE +                 |                |
      +---+---+           +-----+--+             |
          |               |        |             |
          |   +---+-+   +-+-+    +-+-+  +----+   |
          +---| gNB |---|UPF|-N9-|UPF|--| DN |   |
              +-----+   +-+-+    +---+  +----+   |

    Figure 5: Roaming 5G System Architecture - Local Breakout Scenario











Bogineni, et al.        Expires December 31, 2018              [Page 16]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                                 VPLMN   |      HPLMN
                  --------------------  N32 ----------------------------
                     |                   |               |
                     |     +-------+     |     +-------+ |      +-----+
                     |     | V-PCF |--- N24 ---| H-PCF |---N5---| AF  |
                     |     +-------+     |     +-------+ |      +-----+
                     |                   |         |     |
                     |                   |        N7     |
                     |                   |         |     |
                     |      +--+--+      |      +--+--+  |
                     +------|V-SMF|      |      |H-SMF|--+
                            +--+--+      |      +--+--+
                               |         |         |
      +-------+                |         |         |
      | 5G UE |                |         |         |
      +---+---+               N4         |         N4
          |                    |         |         |
          |     +-+---+     +--+--+      |      +--+--+      +----+
          +-----| gNB |-----| UPF |-----N9------| UPF |------| DN |
                +-----+     +--+--+      |      +-----+      +----+

      Figure 6: Roaming 5G System Architecture- Home Routed Scenario

3.4.1.  Roaming and policy management

   In general, the Policy Control Functions (PCF)s in Home PLMN (HPLMN)
   and Visited PLMN (VPLMN) interact with their respective SMFs as well
   as one another to support roaming.

   The interface between the PCF and SMF allows the PCF to have dynamic
   control over policy and charging decisions at SMF.  More
   specifically, the interface

   o  Enables the SMF to establish PDU session,

   o  Allows policy and charging control decisions to be requested from
      the SMF to the PCF direction or to be provisioned from the
      opposite direction.

   o  Provides a mean for SMF to deliver network events and PDU session
      parameters to PCF.

   o  Provides for PDU session termination at either PCF or SMF end.

   The N24 interface betweeen V-PCF and H-PCF provides a communication
   path between these two entities.  The interface enables H-PCF to
   provision access and mobility management related policies to V-PCF,
   and allows V-PCF to send Policy Association Establishmenent and



Bogineni, et al.        Expires December 31, 2018              [Page 17]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Termination requests to H-PCF during UE registration and
   deregistration procedures.

3.4.2.  Local Break Out Model

   In the LBO model, visited operator routes user traffic locally
   through UPFs that are local to the visited operator.  In this model,
   the SMF and all UPF(s) involved by the PDU Session are located and
   are under the control of the VPLMN.

   In this model, the V-PCF generates Policy and Charging Control (PCC)
   rules from the local configuration data that are based on the roaming
   agreement with the HPLMN.  The V-PCF might also use information from
   Application Function(AF) to generate PCC rules for VPLMN delivered
   services.  Here, the H-PCF uses the N24 interface to deliver UE
   access selection, and PDU session selection policies to the V-PCF.
   The V-PCF can either provide access and mobility policy information
   on its own, or alternatively obtain the required information from the
   H-PCF via the N24 interface.

3.4.3.  Home Routed Model

   In the HR model, user traffic is routed to the UPF in HPLMN via the
   UPF in the visited network.  In this scenario, the SMF in HPLMN
   (H-SMF) selects the UPF(s) in the HPLMN and the SMF in VPLMN(V-SMF)
   selects the UPF(s) in the VPLMN.  In this model, the UE obtains
   services from its home network.  Here, the UPF acting as PGW resides
   in home network, and can directly communicate with policy and billing
   system.

   In the HR roaming model:

   o  The NAS SM terminates at the V-SMF.

   o  The V-SMF forwards SM related informaton to the SMF in the HPLMN.

   o  The V-SMF sends UE's Subscription Permanent Identifier(SUPI) to
      the H-SMF during the PDU session establishment procedure.

   o  The V-SMF sends the PDU Session Establishment Request message to
      the H-SMF along with the S-NSSAI with the value from the HPLMN.

   o  The H-SMF obtains subscription data directly from the Unified Data
      Management(UDM) and is responsible for checking the UE request
      with regard to the user subscription, and may reject the request
      in case of mismatch.





Bogineni, et al.        Expires December 31, 2018              [Page 18]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   o  The H-SMF may send QoS requirements associated with a PDU Session
      to the V-SMF.  This may happen at PDU Session establishment and
      after the PDU Session is established.  The interface between H-SMF
      and V-SMF is also able to carry (N9) User Plane forwarding
      information exchanged between H-SMF and V-SMF.  The V-SMF may
      check QoS requests from the H-SMF with respect to roaming
      agreements.At the user plane, the ecapsulation header carries QoS
      flow ID (QFI) over N3, and N9 without any changes to the end to
      end packet header.

   o  The AMF selects a V-SMF and a H-SMF, and provides the identifier
      of the selected H-SMF to the selected V-SMF.

   o  The H-SMF performs IP address management procedure based on the
      selected PDU session type.

3.5.  Support for Multiple PDU Sessions

   Figure 7 depicts the non-roaming architecture for UEs concurrently
   accessing two (e.g. local and central) data networks using multiple
   PDU Sessions, using the reference point representation.  This figure
   shows the architecture for multiple PDU Sessions where two SMFs are
   selected for the two different PDU Sessions.  However, each SMF may
   also have the capability to control both a local and a central UPF
   within a PDU Session.

                           Service Based Interfaces
       ---------+------------+------------------+----------------------
                             |                  |
                          +--+--+            +--+--+
                          | SMF |            | SMF |
                          +--+--+            +--+--+
                             |                  |
      +-------+             N4                 N4
      | 5G UE |              |                  |
      +---+---+           +--+--+    +----+     +-----------+
          |           +---| UPF |----| DN |     |           |
          |           |   +-----+    +----+     |           |
          |     +-+---+-+                    +--+--+     +--+--+  +----+
          +-----|  gNB  |--------------------| UPF |--N9-| UPF |--| DN |
                +-------+                    +-----+     +-----+  +----+

       Figure 7: Non-roaming 5G System Architecture for multiple PDU
                     Sessions Service Based Interface

   Figure 8 depicts the non-roaming architecture in case concurrent
   access to two (e.g. local and central) data networks is provided
   within a single PDU Session.



Bogineni, et al.        Expires December 31, 2018              [Page 19]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                           Service Based Interfaces
       ---------+-----------------------+-----------------------
                                        |
                                     +--+--+
                                     | SMF |
                                     +--+--+
                                        |
      +-------+                  +------+-------+
      | 5G UE |                  |              |
      +---+---+                  N4             N4
          |     +-+---+       +--+--+        +--+--+    +----+
          +-----| gNB |-------| UPF |----N9--| UPF |----| DN |
                +-----+       +--+--+        +-----+    +----+
                                 |
                              +--+--+
                              |  DN |
                              +-----+

    Figure 8: Non-roaming 5G System Architecture for Current Access to
   Two (e.g. local and central) Data Networks (single PDU Session option

   Figure 9 depicts overview of a network model where multiple UPFs are
   distributed geographically.  Such networks have two types of UPFs:
   central UPF (cUPF) deployed for covering wide area, and local/
   distributed UPF (dUPF) deployed close to UEs' access points.  UPFs
   are connected via N9 interfaces over transport network.

























Bogineni, et al.        Expires December 31, 2018              [Page 20]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                              +----------+
                              |   cDN/   |
                              | Internet |
                              +----------+
                                   |N6
                             +-----+-----+
                             |   cUPF    |
                             +-----+-----+
                                   |N9
           ,-----------------------+-----------------------.
          /                                                 \
          |              Transport Network                  |
          \                                                 /
           `----+---------------------------+--------------'
                |N9                         |N9
          +-----+-----+               +-----+-----+
          |   dUPF#1  |N6 +-------+   |   dUPF#2  |N6 +-------+
          |  [UL/CL]  +---| dDN#A |   |   [UL/CL] +---| dDN#B |
          +-----------+   +-------+   +-----------+   +-------+
                |N3                         |N3
             +-----+                     +-----+
             | gNB |                     | gNB |
             +-----+                     +-----+
                |                           |
              +----+                     +----+
              | UE |                     | UE |
              +----+                     +----+

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


         Figure 9: Overview of Network Model with Distributed UPFs

3.6.  Service and Session Continuity Modes

   The 5G System supports different session and service continuity (SSC)
   modes.

   _SSC mode 1_: the network preserves the connectivity service provided
   to the UE.

   _SSC mode 2_: the network may release the connectivity service
   delivered to the UE and release the corresponding PDU Session.





Bogineni, et al.        Expires December 31, 2018              [Page 21]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   _SSC mode 3_: changes to the user plane can be visible to the UE,
   while the network ensures that the UE suffers no loss of
   connectivity.  A connection through new PDU Session Anchor point is
   established before the previous connection is terminated in order to
   allow for better service continuity.

4.  Architectural requirements

   [I-D.hmm-dmm-5g-uplane-analysis] provides a comprehensive summary of
   GTP architecture, and architectural requirements related to user
   plane collected from 3GPP specifications that we summarize here:

   ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU

   The 5G system defines four types of PDU session as IPv4, IPv6,
   Ethernet, and Unstractured, and UP protocol would be required to
   support to convey all of these PDUs session type.

   ARCH-Req-2: Supporting IP Connectivity over N3, N6, and N9

   The 5G system provides IP connectivity over N3, N6, and N9
   interfaces.

   ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a
   single PDU session

   The 5G system allows to deploy multiple UPFs as anchors for a single
   PDU session, and suupports multihoming of a single PDU session for
   such anchor UPFs.

   ARCH-Req-4: Supporting flexible UPF selection for PDU

   The appropriate UPFs are selected for a PDU session based on
   parameters and information such as UPF's dynamic load or UE location
   information.

   ARCH-Req-5: No limitation for number of UPFs in a user plane path

   The number of UPF in the data path is not constrained by 3GPP
   specifications.

   ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated
   with QFI into a PDU Session

   In the 5G system, a single tunnel/data-path includes multiple QFIs
   contrast to just one QoS Flow (a bearer) to one tunnel/data-path





Bogineni, et al.        Expires December 31, 2018              [Page 22]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   User plane protocol needs to support fundamentally these
   requirements.  In addition, [I-D.hmm-dmm-5g-uplane-analysis] provides
   evaluation aspects for user plane protocol that are mainly derived
   from the architectural requirements, such as Supporting PDU Session
   Type Variations, Nature of Data Path, Data Path Management, etc.  The
   details are described in [I-D.hmm-dmm-5g-uplane-analysis].

   For each protocol, we will attempt in the next section to discuss to
   what extent those architectural requirements are addressed.  However,
   it is worth noticing that it is not mandatory that all those
   requirements are supported by the user plane protocol itself, as they
   might be realized through complementary mechanisms Section 6.6.

5.  Data plane architecture models for N9

5.1.  Overview

   The user plane architectures considered for UPF connectivity in
   mobile packet core fall into two categories:

   o  Interworking model:

      *  This model uses GWs.

      *  UPFs and 3GPP control remain unchanged.

      *  3GPP user plane becomes an overlay on top of new user planes

      *  GWs convert GTP traffic to underlying user plane format.

   o  Integrated model:

      *  In this model UPFs transmit/receive packets in accordance with
         the new user plane format.

      *  UPFs and 3GPP control will be modified.

      *  3GPP and transport user plane are collapsed into one user
         plane.

5.2.  Forwarding and mobility paradigms

   Based on their use of identifiers and locators, mobility approaches
   can be broadly categorized in the three following classes:

   *Locator-based*





Bogineni, et al.        Expires December 31, 2018              [Page 23]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   IP communication relies solely on locators (host interfaces'
   addresses) that are also used as node/service identifiers at network
   layer.  Such semantic overloading of IP addresses as both identifiers
   and locators does not allow to disentangle locators from location-
   independent traffic identifiers, thus complexifying mobility
   management.

   As a result, traffic anchors and tunnels have been introduced to
   handle mobility while preserving the identifier exposed to the
   transport layer.

   *Locator-ID separation*

   To overcome the limitations of purely locator-based architectures,
   "locator/identifier separation" (or Loc/ID split) schemes have been
   proposed, that use separate namespaces for so-called End-point
   Identifiers (EID) and Route Locators (RLOC), bound together through a
   mapping system.  This service can be centralized, decentralized or
   distributed and offers control plane protocols for storage, update or
   retrieval of the correspondence between EIDs and RLOCs.

   Loc/ID split has been originally proposed by LISP to solve the
   scalability challenges of Internet routing, and further adapted as a
   mobility management solution.  This category includes most of the
   approaches reviewed in this document, namely ILA, ILSR and a
   SRv6-based solution, which all share the requirement for a mapping
   system.

   *ID-based*

   A third class of approaches exists that redefines IP communication
   principles (i.e. network and transport layers) around location-
   independent identifiers [I-D.vonhugo-5gangip-ip-issues].

   Information-Centric Networking (ICN) approaches fall into such class
   of approaches that we refer to as purely ID-based, or in that
   specific case, as name-based [I-D.irtf-icnrg-terminology].  Previous
   work has highlighted the interest of ICN for mobility management
   [RFC7476].

   The rest of this section details the set of reviewed approaches,
   namely SRv6, LISP, ILSR, ILA and hICN, as summarized in Figure 10.
   Each proposal consists in an overview with pointers to reference
   material for a more in depth description.  The focus is then given to
   a discussion on its integration at N9 interface, as well as the
   benefits with respect to GTP-U.  Extensions to N3 interface as well
   as alternative deployments preserving GTP tunnels as discussed later
   in this document in Section 6.



Bogineni, et al.        Expires December 31, 2018              [Page 24]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   *Reviewed approaches*

   |_ Mobility Management
      |_ Locator-based
         |_ Tunnelling
            |_ 3GPP / GTP-U                Sec. 4
         |_ Packet steering
            |_ SRv6 (backwards-compatible) Sec. 5.2.1
      |_ Loc/ID split
         |_ Packet steering
            |_ SRv6                        Sec 5.2.2
         |_ Encapsulation
            |_ LISP, LISP-MN, ILSR         Sec. 5.3
         |_ Address rewrite
            |_ Network-based translation
               |_ ILA                      Sec. 5.5
      |_ ID-based
         |_ Information-Centric Networking
            |_ ID-based mobility / IPv6
               |_ Hybrid ICN               Sec. 5.6

                Figure 10: Overview of reviewed approaches

5.3.  SRv6

5.3.1.  Overview

   SRv6 [I-D.filsfils-spring-srv6-network-programming] is the IPv6
   dataplane instantiation of Segment Routing
   [I-D.ietf-spring-segment-routing].  Segment Routing is a network
   architecture based on source-routing (the headend inserts the nodes
   that a packet must traverse for TE, NFV and VPN purposes).  Thus
   confining flow states to the ingress nodes in the SR domain.

   The SRv6 dataplane consists on leveraging the IPv6 extension headers,
   defined in RFC8200, to include in the IPv6 header a new "Segment
   Routing Header" [I-D.ietf-6man-segment-routing-header] (SRH).

   SRv6 encodes segments (SIDs) as IPv6 addresses in the Segment List of
   its header.  The IPv6 Destination Address (DA) specifies the active
   segment in the Segment List, while the Segments Left (SL) field of
   the SRH points to the next active segment in the Segment List.  SRv6
   routes over the shortest ECMP-aware path in the network up the the
   node instantiating the active segment.  Once the packet has reached
   this node, the segment is executed.  This implies running its
   associated function on the router, decrementing the SL value and
   updating the IPv6 DA to the next active segment.  Notice that transit




Bogineni, et al.        Expires December 31, 2018              [Page 25]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   routers neither inspect the SRH nor process it.  Thus they only need
   to be IPv6 capable.

   The main benefit of SRv6 overlays is the reduction of state in the
   network (there is no state in the forwarding fabric), with optimized
   MTU overhead, and its capability to integrate with the underlay (SLA;
   Traffic Engineering) and distributed NFVi.  Hence there is no need
   NSH for NVF, RSVP for TE, or UDP for ECMP.  SR also supports natively
   network slicing, which implies that SRv6 can offer end-to-end network
   slices that spans all those elements (overlay, underlay, NFV).

   The versatility and adaptability of SR combined with IPv6's ample and
   flexible address space positions SRv6 as a viable user plane for the
   next generation of mobile user-plane, in particular the 3GPP N3 and
   N9 interfaces.  Notice that SRv6 applicability does not require a new
   mobility control-plane.  SRv6 can be combined with other control-
   planes such as LISP, hICN described later in this document or others
   such as DHT, propietary CP, etc.

   The applicability of SRv6 to mobility is described in
   [I-D.ietf-dmm-srv6-mobile-uplane].

   SRv6 counts with three open-source implementations (Linux Kernel,
   FD.io VPP, P4) and several propietary implementations (4xCisco,
   1xBarefoot Networks, 1xUTStarcom) which have publicly participated in
   interops and all execute at linecard rate.

   This section starts by summarising the use of SRv6 as a drop-in
   alternative for GTP-U over the N9 interface connecting different User
   Plane Functions (UPF).  It then shows how SRv6 as a GTP-U replacement
   can then provide additional features such as TE, IP session
   aggregation, rate limiting, and distributed NFVi that are not
   natively available by GTP.

   It must be noted that the SRv6 models discussed in this document can
   follow either of the interworking or the integration model mentioned
   earlier depending on operator's requirements.

   SRv6 appears well placed as a mechanism to replace GTP-U with
   initially no control plane changes, but to then offer a progressive
   path towards many innovations in routing.

5.3.2.  SRv6 with Traffic Engineering

   SRv6 can be applied as a drop-in replacement for GTP without changes
   in the control-plane.  This is a simple 1 to 1 replacement discussed
   in section 6.1.  However, SRv6 offers much richer possibilities.




Bogineni, et al.        Expires December 31, 2018              [Page 26]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Traffic engineering is a native feature of SR.  The SRv6 variant of
   SR of course supports both strict and loose models of source routing.
   Here, the SID list in SRH can represent a loose or strict path to
   UPFs.  Therefore, traffic engineering can easily be supported
   regardless of any of the aforementioned approaches.

   The main benefit of leveraging SRv6 for TE is the natural ability to
   create end-to-end network slices that spans both the UPFs and the
   underlaying transport network with TE optimization objectives (i.e.
   low-latency).

   It must be noted that the SRH could contain multiple sets of SIDs
   each representing a TE path between a pair of UPFs.  Alternatively,
   the SRH can contain a fully resolved end to end TE path that covers
   every intermediate node and UPF along the user plane.

   SR considers segments to be instructions.  Therefore each SID can
   represent a function that enforces a specific nodal or global packet
   treatment.  Attributes such as jitter and delay requirement, rate
   limiting factors, etc. can be easily encoded in to SIDs in order to
   apply the desired treatment as packets traverse the network from UPF
   to UPF.  [I-D.ietf-dmm-srv6-mobile-uplane] suggests a SID encoding
   mechanism for rate limiting purposes.

   Please refer to the followings for further details about SR traffic
   engineering capabilities, the network programming concept, and some
   of the main SRv6 functions.

   o  [I-D.ietf-spring-segment-routing]

   o  [I-D.ietf-spring-segment-routing-policy]

   o  [I-D.filsfils-spring-srv6-network-programming]

   o  [I-D.ietf-6man-segment-routing-header]

5.3.3.  Service Programming with SRv6

   Service programming -or distributed NFVi- is another intrinsic
   feature of SR.  Leveraging this capability, operators can steer user
   traffic through a set of UPFs where each UPF performs a specific
   service on the traffic.

   Service programming is achieved through the use of SIDs in an
   identical manner to what was described in the previous section: the
   SRH is populated with a set of SIDs with each SID identifying a
   specific UPF in the network.  Starting from the ingress SRv6 node,




Bogineni, et al.        Expires December 31, 2018              [Page 27]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   packets are then forwarded through the network visiting the set of
   UPFs listed as SIDs in the SRH.

   Please refer to [I-D.xuclad-spring-sr-service-chaining] for further
   detail.

5.3.4.  SRv6 and Entropy

   Ability to provide a good level of entropy is an important aspect of
   user plane protocols.  If included in network node's hashing, the
   TEID field in GTP tunnels algorithms can result in good load
   balancing.  Therefore, any new user plane proposal should be able to
   deal with entropy in an efficient manner.

   SRv6 natively supports entropy by using the IPv6 Flow Label.
   Additionally, SRv6 SIDs can easily accommodate entropy at a hop by
   hop level by reserving a set of bits in the SID construct itself.  In
   this way, the hashing algorithm at different nodes distribute traffic
   flows based on the SID which has been copied to IPv6 DA field.

5.3.5.  SRv6 and transport slicing

   Slicing is one of the main features in 5G [TS.23.501-3GPP].  Several
   Slices with different requirements can coexist on top of the common
   network infrastructure.  Diverse flows belonging to different 5G
   slices can be completely disjoint or can share different parts of the
   network infrastructure.  SRv6 has native support for network slicing
   spanning the UPFs, underlay -transport network- and NFVi.  Also, SRv6
   creates network slices without per-flow state in the fabric, hence
   simplifying the slicing paradigm.

   Please refer to [I-D.ietf-spring-segment-routing-policy] for further
   detail.

5.3.6.  SRv6 and Alternative Approaches to Advanced Mobility Support

   SRv6 flexibility enables it to support different methods of providing
   mobility in the network.  ID-LOC for mobility support is one such
   option.

   The previous sections discussed how SRv6 could be employed as a
   replacement for GTP tunnels while leaving the existing control plane
   intact.  This section describes the use of SRv6 as a vehicle to
   implement Locator/ID Separation model for UPF user plane
   connectivity.  It must be ntoed that SRv6 implementation of the ID-
   LOC architecture can employ a variety of different control planes
   including LISP, , different variety of DHT, proprietary, etc.




Bogineni, et al.        Expires December 31, 2018              [Page 28]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


5.3.6.1.  UPF connectivity via SRv6 with Loc-ID separation (Interworking
          model)

   SRv6 can easily implement ID-LOC Separation model for UPF
   connectivity.  The SIDs are once again the main vehicle here.  In
   this model, UPFs are considered to be the IDs while the nodes where
   the UPFs attach to take on the role of the Locators.

   In this approach, UPFs connect to SRv6 capable Locators.  UPFs use
   IPv4/IPv6 transport either in conjunction with GTP or without any GTP
   tunnel and send the packets to their associated Locator at the near
   end (Ingress SRv6 Locator).

   It must be noted that use of GTP at UPFs allows us to leave the 3GPP
   control plane intact and hence provides a smooth migration path
   toward SRv6 with ID-Locator model.

5.3.6.2.  SRv6 Capable UPFs and RLOCs (Integration model)

   In this model, the head-end UPF (Ingress UPF) is the ingress node and
   the entity that constructs the SRH in the SRv6 domain.

   The 3GPP control plane is responsible for distributing UPF's endpoint
   information.  But it requires some modifications to be able to convey
   endpoint information to interested parties.

   The SMF can provide a fully resolved SID list by communicating with a
   centralised or distributed ID-LOC mapping system containing all the
   relevant data regarding the UPF-Locator relationship.

5.3.6.3.  Advanced Features in ID-Locator Architecture

   SRv6's native features such as Traffic Engineering, QoS support, UPF
   Chaining, network slicing, etc. can be easily added to ID-Locator
   support.  As it was noted earlier, these features are not readily
   available by GTP.

5.3.7.  Areas of Concerns

   Support for IPv6 is a precondition for SRv6.  Although SRv6 can
   support hybrid IPv4/IPv6 mobile user plane through an interworking
   node, support of UPFs with IPv4 address is rather complex.

   Due to IPv6 128-bit address space, large SRH size can have a negative
   impact on MTU.  Large SRH size can also exert undesirable header tax
   especially in the case of small payload size.





Bogineni, et al.        Expires December 31, 2018              [Page 29]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   ID-LOC architecture relies on high performance mapping systems.  The
   SRv6 support of ID-LOC as described earlier can employ different
   control planes.  Distributed mapping systems using some form
   Distributed Hash Table(DHT) however, exhibit very promising results.
   But further investigation is needed to ensure comformance with
   performance metrics required by the mobile networks, specially for
   slice types supporting high speed mobility.

5.4.  LISP

5.4.1.  Overview

   The Locator/Identifier Separation Protocol (LISP), which provides a
   set of functions for routers to exchange information used to map from
   Endpoint Identifiers (EIDs) that are not globally routable to
   routable Routing Locators (RLOCs).  It also defines a mechanism for
   these LISP routers to encapsulate IP packets addressed with EIDs for
   transmission across a network infrastructure that uses RLOCs for
   routing and forwarding.

   An introduction to LISP can be found in [I-D.ietf-lisp-introduction].

   A complete RFC-set of specifications can be found in [RFC6830],
   [RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061],
   [RFC8111].  They describe support and mechanisms for all combinations
   of inner and outer IPv4 and IPv6 packet headers for unicast and
   multicast packet flows that also interwork with non-LISP sites as
   well as two designs to realize a scalable mapping system.

   A standards-track based set of drafts [I-D.ietf-lisp-rfc6830bis]
   [I-D.ietf-lisp-rfc6833bis] are products and work in progress of the
   LISP Working Group.

5.4.2.  LISP Encapsulation

   LISP uses dynamic tunnel encapsulation as its fundadmental mechanism
   for the data-plane.  Fixed headers are used between the outer and
   inner IP headers which are 16 bytes in length.  Details can be found
   in [RFC6830].

5.4.3.  LISP Mapping Systems

   Many years of research dating back to 2007 have gone into LISP
   scalable mapping systems.  They can be found at [LISP-WG] and
   [IRTF-RRG].  The two that show promise and have deployment experience
   are LISP-DDT [RFC8111] and LISP-ALT [RFC6836].





Bogineni, et al.        Expires December 31, 2018              [Page 30]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   The control-plane API which LISP xTRs are the clients of is
   documented in [RFC6833].  Various mapping system and control-plane
   tools are available [RFC6835] [RFC8112] and are in operational use.

5.4.4.  LISP Mobility Features

   LISP supports multi-homed shortest-path session survivable mobility.
   An EID can remain fixed for a node that roams while its dynamic
   binding changes to the RLOCs it uses when it reconnect to the new
   network location.

   When the roaming node supports LISP, its EIDs and RLOCs are local to
   the node.  This form of mobility is call LISP Mobile-Node.  Details
   can be found in [I-D.ietf-lisp-mn].

   When the roaming node does not support LISP, but LISP runs in the
   network the node roams to, the EIDs and RLOCs are not co-located in
   the same device.  In this case, EIDs are assigned to the roaming node
   and RLOCs are assigned to LISP xTRs.  So when the roaming node
   attaches to the network, its EIDs are mapped to the RLOCs of the LISP
   xTRs in the network.  This form of mobility is called LISP EID-
   Mobility.  Details can be found in [I-D.ietf-lisp-eid-mobility].

   For a 3GGP mobile network, the LISP EID-Mobility form of mobility is
   recommended and is specified in the use-case document
   [I-D.farinacci-lisp-mobile-network].

5.4.5.  ILSR

   ILSR is a specific recommendation for using LISP in the 3GPP 5G
   mobile network architecture.  A detailed whitepaper can be found at
   [ILSR-WP].  The recommendation is to use the mechanisms in
   [I-D.farinacci-lisp-mobile-network].

5.5.  ILA

   Identifier-Locator Addressing [I-D.herbert-intarea-ila] is a protocol
   to implement transparent network overlays without encapsulation.  It
   addresses the need for network overlays in virtualization and
   mobility that are efficient, lightweight, performant, scalable,
   secure, provide seamless mobility, leverage and encourage use of
   IPv6, provide strong privacy, are interoperable with existing
   infrastructure, applicable to a variety of use cases, and have
   simplified control and management.







Bogineni, et al.        Expires December 31, 2018              [Page 31]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


5.5.1.  Overview

   ILA is a form of identifier/locator split where IPv6 addresses are
   transformed from application-visible, non-topological "identifier"
   addresses to topological "locator" addresses.  Locator addresses
   allow packets to be forwarded to the network location where a logical
   or mobile node currently resides or is attached.  Before delivery to
   the ultimate destination, locator addresses are reverse transformed
   back to the original application visible addresses.  ILA does address
   "transformation" as opposed to "translation" since address
   modifications are always undone.  ILA is conceptually similar to ILNP
   and 8+8, however ILA is contained in the network layer.  It is not
   limited to end node deployment, does not require any changes to
   transport layer protocols, and does not use extension headers.

   ILA includes both a user plane and control plane.  The user plane
   defines the address structure and mechanisms for transforming
   application visible identifier addresses to locator addresses.  The
   control plane's primary focus is a mapping system that includes a
   database of identifier to locator mappings.  This mapping database
   drives ILA transformations.  Control plane protocols disseminate
   identifier to locator mappings amongst ILA nodes.

   The use cases of ILA include mobile networks, datacenter
   virtualization, and network virtualization.  A recent trend in the
   industry is to build converged networks containing all three of these
   to provide low latency and high availability.  A single network
   overlay solution that works across multiple use cases is appealing.

   Benefits of ILA include:

   o  Facilitates node mobility and virtualization

   o  Multiple use cases (mobile, datacenter, cloud)

   o  Super efficient and performant user plane

   o  Allows strong privacy in addressing

   o  Promotes anchorless mobility

   o  No typical tunneling issues (e.g.  MTU) or management related to
      encapsulation

   o  Flexible control plane that splits data and control

   o  Modern "SDN" control protocols (e.g.  RPC/TCP)




Bogineni, et al.        Expires December 31, 2018              [Page 32]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   o  Scale number of nodes to billions for 5G, DC virtualization

   o  Upstream Linux kernel data path and open source ctrl plane
      [ILACONTROL].

   The ILA user plane protocol is described in
   [I-D.herbert-intarea-ila], motivation and problems areas are
   described in [ILAMOTIVE], ILA in the mobile user-plane is described
   in detail in [I-D.herbert-ila-mobile].

5.5.2.  Protocol Layering

   Figure 11 illustrates the protocol layers of packets packets sent
   over various user plane interfaces in the downlink direction of data
   network to a mobile node.  Note that this assumes the topology shown
   in Figure 2 where GTP-U is used over N3 and ILA is used on N9.

                    -             -            -
       DN to ILA-R      ILA-R to ILA-N   ILA-N to gNB     gNB to UE
      +------------+   +------------+   +------------+   +------------+
      | Application|   | Application|   | Application|   | Application|
      +------------+   +------------+   +------------+   +------------+
      |     L4     |   |     L4     |   |     L4     |   |     L4     |
      +------------+   +------------+   +------------+   +------------+
      |    IPv6    |   | IPv6 (ILA) |   |    IPv6    |   |  PDU Layer |
      +------------+ | +------------+ | +------------+   +------------+
      |     L2     | | |     L2     | | |   GTP-U    |   | AN Protocol|
      +------------+ | +------------+ | +------------+   |   Layers   |
                     |                | |   UDP/IP   |   |            |
                    N6   <--N9    N3 +------------+   +------------+
                                        |    L2      |
                                        +------------+

                  Figure 11: ILA and protocol layer in 5G

5.5.3.  Control plane

   ILA-M provides the interface between the 5G services architecture and
   the common ILA control plane.

5.5.3.1.  ILA-M services interface

   The control interface into ILA is via an ILA-M that interacts with 5G
   network services.  ILA-M uses RESTful APIs to make requests to
   network services.  An ILA-M receives notifications when devices enter
   the network, leave it, or move within the network.  The ILA-M writes
   the ILA mapping entries accordingly.




Bogineni, et al.        Expires December 31, 2018              [Page 33]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   ILA is a consumer of several 5G network services.  The service
   operations of interest to ILA are:

   o  Nudm (Unified Data Management): Provides subscriber information.

   o  Nsmf (Service Managment Function): Provides information about PDU
      sessions.

   o  Namf (Core Access and Mobility Function): Provides notifications
      of mobility events.

5.5.3.2.  ILA control plane

   The ILA control plane is composed of mapping protocols that manage
   and disseminate information about the mapping database.  There are
   two levels of mapping protocols: one used by ILA routers that require
   the full set of ILA mappings for a domain, and one used by ILA nodes
   that maintain a caches of mappings.

   The ILA mapping system is effectively a key/value datastore that maps
   identifiers to locators.  The protocol for sharing mapping
   information amongst ILA routers can thus be implemented by a
   distributed database [I-D.herbert-ila-ilamp].  ILA separates the
   control plane from the user plane, so alternative control plane
   protocols may be used with a common user plane
   [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp].

   The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA
   forwarding nodes and ILA mapping routers.  The purpose of the
   protocol is to populate and maintain the ILA mapping cache in
   forwarding nodes.  ILAMP defines redirects, a request/response
   protocol, and a push mechanism to populate the mapping table.  Unlike
   traditional routing protocols that run over UDP, this protocol is
   intended to be run over TCP and may be RPC oriented.  TCP provides
   reliability, statefulness implied by established connections,
   ordering, and security in the form of TLS.  Secure redirects are
   facilitated by the use of TCP.  RPC facilities such REST, Thrift, or
   GRPC leverage widely deployed models that are popular in SDN.

5.5.4.  IP addressing

   ILA supports single address assignments as well as prefix
   assignments.  ILA will also support strong privacy in addressing.








Bogineni, et al.        Expires December 31, 2018              [Page 34]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


5.5.4.1.  Singleton address assignment

   Singleton addresses can use a canonical 64/64 locator/identifier
   split.  Singleton addresses can be assigned by DHCPv6.

5.5.4.2.  Network prefix assignment

   Prefix assignment can be done via SLAAC or DHCPv6-PD.

   To support /64 prefix assignment with ILA, the ILA identifier can be
   encoded in the upper sixty-four bits of an address.  A level of
   indirection is used so that ILA transforms the upper sixty four bits
   to contain both a locator and an index into a locator (ILA-N)
   specific table.  The entry in the table provides the original sixty-
   four bit prefix so that locator to identifier address transformation
   can be done.

   As an example of this scheme, suppose network has a /24 prefix.  The
   identifier address format for /64 assignment might be:

   +-------------+---------------------|------------------------------+
   |  24 bits    |       40 bits       |          64 bits             |
   +-------------+---------------------|------------------------------+
   | Network     |      Identifier     |             IID              |
   +-------------+---------------------+------------------------------+

   The IID part is arbitrarily assigned by the device, so that is
   ignored by ILA.  All routing, lookups, and transformations (excepting
   checksum neutral mapping) are based on the upper sixty-four bits.

   For identifier to locator address transformation, a lookup is done on
   the upper sixty-four bits.  That returns a value that contains a
   locator and a locator table index.  The resulting packet format may
   be something like:

   +-------------+---------------------|------------------------------+
   |   24 bits   | 20 bits | 20 bits   |          64 bits             |
   +-------------+---------------------|------------------------------+
   |  Network    | Locator | Loc index |             IID              |
   +-------------+---------+-----------+------------------------------+

   The packet is forwarded and routed to the ILA-N addressed by locator
   (/44 route in this case).  At the ILA forwarding node, the locator
   index is used as a key to an ILA-N specific table that returns a 40
   bit Identifier.  This value is then written in the packet do ILA to
   identifier address transformation thereby restoring the original
   destination address.




Bogineni, et al.        Expires December 31, 2018              [Page 35]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   The locator index is not globally unique, it is specific to each ILA-
   N.  When a node attaches to an ILA-N, an index is chosen so that the
   table is populated at the ILA-N and the ILA mapping includes the
   locator and index.  When a node detaches from on ILA, it's entry in
   the table is removed and the index can be reused after a hold-down
   period to allow stale mappings to be purged.

5.5.4.3.  Strong privacy addresses

   Note that when a /64 is assigned to UEs, the assigned prefix may
   become a persistent identifier for a device.  This is a potential
   privacy issue.

5.5.5.  Traffic engineering

   ILA is primarily a mechanism for mobility and network virtualization.
   Transport mechanisms for traffic engineering such as MPLS, network
   slices, encapsulation, routing based on flow hash(flow label) can be
   applied independently of ILA.  This separation allows any discussion
   related to transport to be left to operator deployment.

5.5.6.  Locator Chaining with ILA

   ILA transformations can be performed on a hop-by-hop bases.  In this
   manner a packet can be source routed through a sequence of nodes.  At
   each hop a determination is made as to the next hop the packet should
   visit.  The locator for the target is then written into the
   destination.  Eventually, the packet will be forwarded to an ILA
   forwarding node that will restore the original address before
   delivery to the final destination.

5.5.7.  Security considerations

   A mobile public infrastructure has many considerations in security as
   well as privacy.  Fundamentally, a system must protect against
   misdirection for the purposes of hijacking traffic, spoofing,
   revealing user identities, exposing accurate geo-location, and Denial
   of Service attacks on the infrastructure.

   The ILA mapping system contains personally identifiable information
   (PII) including user identities and geo-location.  The information
   must be safeguarded.  An ILA domain is confined to one administrative
   domain, only trusted parties entities in the domain participate in
   ILA.  There is no concept of a global, public mapping system and UEs
   in public networks generally do not participate in ILA protocols
   since they are untrusted.  ILA control protocols, include ILA
   redirects, use TCP.  TLS or other protocols can be applied for strong
   security.



Bogineni, et al.        Expires December 31, 2018              [Page 36]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Privacy in addressing is a consideration.  ILA endeavors to provide a
   mechanism of address assignment that prevents inference of user
   identity or location.

5.6.  Hybrid ICN (hICN)

5.6.1.  Overview

   hICN Anchorless Mobility Management (hICN-AMM) refers to a novel
   mobility management approach, introduced in
   [I-D.auge-dmm-hicn-mobility], that leverages routable location-
   independent identifiers (IDs) and an Information-Centric Networking
   (ICN) communication model integrated in IPv6, (also referred to as
   Hybrid ICN, or hICN) [I-D.muscariello-intarea-hicn].

   Such approach belongs to the category of pure ID-based mobility
   management schemes whose objective is (i) to overcome the limitations
   of traditional locator-based solutions like Mobile IP (conf)using
   locators as identifiers, (ii) to remove the need for a global mapping
   system as the one required by locator-identifier separation
   solutions.

5.6.2.  Consumer and Producer mobility

   In ICN and hICN endpoints can act as consumers and/or producers.
   Consumers when they emit requests for named data packets (so called
   Interests), producers when they send data packets in response to
   consumers request (pull-based transport model).  Clearly a node can
   be a consumer and a producer at the same time (e.g.  in a voice
   conversation).

   Consumer and producer mobility are handled in a different way due to
   the pull-based request model.  More specifically, consumer mobility
   is natively supported: consumers pull traffic by sending Interest
   packets towards named content (wherever produced/stored, the source
   is a priori unknown by the consumer).  Interests are named-based
   forwarded using the information found in traversed routers' FIBs.

   In case of consumer mobility, i.e. mobility of the endpoint issuing
   the requests, selection of a new available output interface and
   retransmission of not-yet-satisfied Interests is sufficient for data
   delivery to continue, independently from the underlying change of
   locators.  Consumer mobility is fully anchorless with hICN, and does
   not incur any signalization nor tunneling overhead.

   Producer mobility is not natively supported by ICN architecture,
   rather handled in different ways according to the selected producer
   mobility management scheme.



Bogineni, et al.        Expires December 31, 2018              [Page 37]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


5.6.3.  Anchorless mobility support

   The selected mobility management scheme for hICN is MAP-Me, an
   anchorless producer mobility management solution originally proposed
   for ICN [I-D.irtf-icnrg-mapme] [MAPME] and further extended to hICN
   in [I-D.auge-dmm-hicn-mobility].

   MAP-Me belongs to the class of anchorless approaches that relies on
   scope-limited forwarding updates triggered by producer mobility
   events to keep locally up-to-date FIB information for a low-latency
   guaranteed reroute of consumer Interests towards changing location of
   the producer.  Forwarding and mobility management operations in hICN
   are based only location-independent identifiers, preserving
   coexistence with IP locators whose existence may be required by non-
   hICN services and by control/management plane operations specific to
   the considered network architecture.

   Signaling of mobility is only required upon producer movements and
   limited in scope to current-to-previous network hops.  Unlike routing
   updates, it is not necessary to update all routers' FIBs after a node
   has moved, but only those located on the path between the new and a
   former position of the producer.  Scalability of producer mobility is
   guaranteed by an efficient and secure FIB update process with minimal
   and bounded path stretch.

   The difference w.r.t. to other classes of approaches is that it does
   not require an anchor neither in forwarding plane (no tunnel, traffic
   does not need to pass through a specific network node), nor in the
   control plane (no rendez-vous point, no mapping system).

5.6.4.  Benefits

   The appeal of purely ID-based architectures is that they move Loc/ID
   split one step further by embedding ID-awareness in the network and
   transport layer by default and as such completely decoupling data
   delivery from underlying network connectivity.  The resulting
   mobility management solution is fully anchorless for both consumer
   and producer mobility.  Forwarding is performed directly based on
   identifiers stored in routers' FIBs and no mapping of ID into
   locators is required.  In this way, purely ID-based architectures
   remove the need to maintain a global mapping system at scale, and its
   intrinsic management complexity.

   Additional benefits brought specifically by ICN principles motivate
   the consideration of ICN solutions for next generation mobility
   architectures, like for instance:





Bogineni, et al.        Expires December 31, 2018              [Page 38]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   o  the flexibility of multi-source/multi-path connectionless pull-
      based transport.  An example is the native support for consumer
      mobility, i.e. the transparent emission of data requests over
      multiple and varying available network interfaces during node
      mobility;

   o  the opportunity to define fine-grained per-application forwarding
      and security policies (in the network, and in-between UPFs);

   o  low-latency and multicast capabilities by means of in-path edge
      caching;

   o  network-assisted transport.

   An in depth analysis of benefits originating from the coupling
   between a purely identifier-based approach and from specific hICN
   properties can be found in
   [I-D.auge-dmm-hicn-mobility-deployment-options] along with some
   illustrative examples.

5.6.5.  Deployment considerations

   *Partial insertion*

   The benefits previously described can be obtained by an upgrade of
   only a few selected routers at the network edge.  The design of hICN
   allows the rest of the infrastructure to remain unmodified, and to
   leverage existing management and monitoring tools.  There exists thus
   a tradeoff between incremental deployment and benefits which are
   proportionally related to the degree of hICN penetration.

   *End-to-end deployment*

   The deployment of an hICN stack in endpoints is the preferred option
   and offers the full range of benefits.  Both the hICN forwarder and
   the transport stack are available as reference implementations based
   on the CICN project [CICN].  They are both designed to facilitate
   insertion on routers and end-user devices thanks to implementation in
   user space, one targetting high-performance, the other aiming at wide
   support from major vendors including iOS, Android, Linux, MacOSX and
   Windows.

   *Network-contained deployment*

   It is not always possible nor desirable to affect endpoints, and a
   deployment fully contained in the network is possible through the
   deployment of proxies.  An example would be the deployment of HTTP
   proxies at the ingress and egress (resp.  first and last UPFs), in



Bogineni, et al.        Expires December 31, 2018              [Page 39]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   order to benefit from content awareness in the network.  Such
   configuration however reduces the flexibility and dynamic forwarding
   capabilities in endpoints.  In particular, existing transport
   protocols have limited support for dynamically changing paths or
   network conditions.

   Traffic that is not handled though hICN mechanisms can still benefit
   from the lower overhead and anchorless mobility capabilities coming
   from the removal of GTP tunnels, as well as dynamic forwarding
   capabilities that are inherent to the forwarding pipeline.  This
   results from the ability to assign location-independent identifiers
   to endpoints.  It preserves the advantage of removing the mapping
   system, and of a lightweight FIB update process.  No encapsulation is
   required and packet headers are not modified, which allows the
   network to have visibility in the source and/or destination
   identifiers.

   *hICN in a slice*

   The use of hICN does not impose any specific slicing of the network.
   Rather, it can assist a transition of services towards hICN, and/or
   the coexistence of different hICN deployment options.

   As an example of use of hICN in a slice, a service provider might for
   instance decide to use an hICN-enabled slice dedicated to video
   delivery, with appropriate mobility management, and dedicated hICN
   nodes with appropriate caching/forwarding strategies at places
   aggregating considerable number of user requests.

5.6.6.  hICN with SRv6

   The association of hICN with other user planes technologies, such as
   SRv6, is investigated as a possibility to overcome the above-
   mentioned tradeoff yielding to a selective, yet fully beneficial
   insertion of hICN in IP networks.  This would inherit all SRv6
   advantages for underlay (TE, FRR) and service programming (NFV), but
   also extend the reach of hICN on regular IP routers with SRv6
   functionality.

   One realization consists in creating SRv6 domains in between hICN
   nodes.  The hICN router (through forwarding strategies) would then
   act as a control plane for SRv6 by specifying the list of SIDs to
   insert in the packet.








Bogineni, et al.        Expires December 31, 2018              [Page 40]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


5.6.7.  Summary

   hICN proposes a general purpose network architecture that combines
   the benefits of a pure-ID architecture with those of ICN.  While a
   full deployment is recommended to make efficient use of available
   network resources, it is still possible to opt for a partial or
   phased deployment, with the associated tradeoffs that we have
   reviewed here.

   An hICN enabled network offers native offloading capabilities thanks
   to the anchorless properties resulting from the pure-ID communication
   scheme.  It does so without the need for a third party mapping
   system, and further requires no change in the 5G architecture nor in
   its control plane.  The architecture will further leverage the
   incremental insertion of information centric functionalities through
   proxies or direct insertion in user devices as the technology gets
   adopted and deployed.

6.  Integration into the 5G framework

6.1.  Locator based - SRv6

6.1.1.  Insertion in N9 interface

   Existing mobile backhaul employs GTP tunnels to carry user traffic
   flows in the network.  These tunnels are unidirectional, are
   established via the control plane for a particular QoS level, and run
   on links between access and the different anchor nodes all the way to
   DN gateways.

   The Tunnel Endpoint Id (TEID) field in the GTP tunnel plays a crucial
   role in stitching the data path between the above mentioned network
   nodes for a particular user flow.  In other words, TEIDs are used to
   coordinate traffic hand off between different UPFs.

   In its most basic form, SRv6 can be used as a simple drop-in
   alternative for GTP tunnels.  The control plane in this approach
   remains the same, and still attempts to establish GTP-U tunnels and
   communicate TEIDs between the tunnel end points.  However, at the
   next level, SRv6 capable nodes use SIDs to direct user traffic
   between the UPFs.

   The simplest option here is to encapsulate the entire GTP frame as a
   payload within SRv6.  This scheme still carries the GTP header as the
   payload and as such doesn't offer any significant advantage.

   A much more promising and efficient option however is to use SIDs to
   carry tunnel related information.  This is commonly known as the



Bogineni, et al.        Expires December 31, 2018              [Page 41]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Traditional Mode for SRv6 support for mobility.  Here, TEIDs and
   other relevant data can be encoded into SRv6 SIDs which can be mapped
   back to TEID's at the intermediate UPFs thus requiring no changes
   except at the encapsulation and de-encapsulation points in the UPF
   chains.

   Note that this is a direct replacement of GTP by SRv6.  It's also
   worth noting that in this case the MTU overhead in the N9 interface
   is reduced.

   [I-D.ietf-dmm-srv6-mobile-uplane] discusses the details of leveraging
   the existing control plane for distributing GTP tunnel information
   between the end nodes and employing SRv6 in user plane for UPF
   connectivity.  The document defines a SID structure for conveying
   TEID, DA, and SA of GTP tunnels, shows how hybrid IPV4/IPV6 networks
   are supported by this model and in doing so, it paves a migration
   path toward a full SRv6 user plane.

   Another alternative that can provide for a smooth migration toward
   SRv6 data plane between UPFs is via the use of "Tag", and optional
   TLV fields in SRH.  Similar to the previously described method, this
   approach takes advantage of the existing control plane to deliver GTP
   tunnel information to the UPF endpoints.  "Tag" and optional TLV
   fields in SRH are then used to encode tunnel information in the SRv6
   user plane where the UPFs can determine the TEID etc. by inverting
   the mapping.

   In yet another option, GTP tunnel information can be encoded as a
   separate SID either within the same SRH after the SID that identifies
   the UPF itself (SRH-UPF) or inside a separate SRH (SRH-GTP).  This
   option resembles the MPLS label stacking mechanism which is widely
   used in different VPN scenarios.  Here, we use one SID to carry
   traffic to the target UPF and use the other to encode and decode GTP
   related information.

   It must be noted that in any of the above mentioned approaches, the
   ingress UPF in SRv6 domain can insert a SRH containing the list of
   SIDs that corresponds to all UPFs along the path.  Alternatively,
   UPFs can stack a new SRH on top of the one inserted by the previous
   one as packets traverse network paths between different pairs of UPFs
   in the network.

6.1.2.  Control Plane considerations

   SRv6, when applied in Tradditional Mode follows the inteworking model
   and as such does not require control-plane changes.  It still attemps
   to establish GTP-U tunnels and communicate TEIDs between the tunnel




Bogineni, et al.        Expires December 31, 2018              [Page 42]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   endpoints.  AT the next level of user plane however, SRv6 capable
   nodes use SIDs to direct user traffic between the UPFs.

6.1.3.  Extensions to N3/F1-U/Xn-U interface

   Although not strictly the object of study by 3GPP, previous solutions
   can (and would gain to) be extended beyond N9 to cover N3 interface
   too.

   The immediate benefit is the complete removal of all GTP tunnels,
   along with associated mangement complexity and traffic overhead.  In
   particular, this removes the need for internetworking between N3 and
   N9 technologies, and offers a uniform user plane as recommended in
   the specification.

   Potential gains can result for an early handling of traffic right
   from the RAN and thus possibly closer to the UE.  The result is a
   simpler and lighter architecture, allowing convergence with other
   non-3GPP accesses.

   The mobile network would benefit of the application of SRv6 to both,
   N3 and N9 interfaces.  The intrinsic ability of SRv6 to integrate, in
   a single protocol, the control of the overlay, underlay and NFV
   implies that if applied to the N3 interface the end-to-end SRv6-based
   network slice can start on the NodeB itself.

   In addition, SRv6 could be applied to the F1-U interface for cloud-
   RAN and TE purposes.

6.1.4.  Coexistence with GTP-based architecture

   An alternative vision, although not recommended, would be to preserve
   the current architecture as is, and deploy alternative user planes on
   top.

   As explained in section 5.3.1, SRv6 can co-exist with the current
   GTP-based control plane.  Additionally, the current control plane can
   be extended to suport TE as defined in 5.3.2.

   From a dataplane perspective, SRv6 can coexist on the N9 interface
   together with GTP-U traffic.

   This is important towards a slow migration from a GTP-based
   architecture into different architectures.







Bogineni, et al.        Expires December 31, 2018              [Page 43]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


6.2.  ID-LOC split

6.2.1.  Insertion in N9 interface

   An ID-LOC network architecture is able to decouple the identity of
   endpoints (ID) from their location in the network (LOC).  Common ID-
   LOC architectures are based on two main components, ID-LOC data-plane
   nodes and an ID-LOC mapping system.

   ID-LOC data-plane nodes act upon received data traffic and perform
   ID-LOC data-plane operation.  The specific operation that these ID-
   LOC data-plane nodes perform is based on the particular ID-LOC data-
   plane protocol that they implement.  ID-LOC data-plane protocols are
   usually divided in two categories, (1) those that encapsulate ID-
   based data-plane packets into LOC-based data-plane packets and (2)
   those that transform the addresses on the data-plane packets from ID-
   based addresses to LOC-based addresses.  SRv6 and LISP-DP protocols
   are examples of the former while the ILA protocol is an example of
   the latter.

   The ID-LOC mapping system is a database that provides mappings of
   Identity to Location for ID-LOC data-plane nodes to use.  Usually,
   ID-LOC architectures use an ID-LOC control plane protocol to make
   available at the data-plane nodes the ID-LOC mappings that they need
   to operate.  Examples of such ID-LOC control plane protocols are
   LISP-CP and ILAMP, which are discussed later in this section.

   When integrating ID-LOC architecture into the 5G framework there are
   several aspects to take into account.  One is that the ID-LOC data-
   plane function needs to be performed in the data-plane path as the
   packets enter and leave the ID-LOC domain.  On option for this is to
   deploy ID-LOC data-plane nodes adjacent to UPFs to perform the ID-LOC
   operation on the traffic as it leaves or enters the UPFs (as shown in
   Fig. Figure 12).  In this case the ID-LOC data-plane protocol will be
   part of the N9 interface along with current GTP.
















Bogineni, et al.        Expires December 31, 2018              [Page 44]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                                 +----+----+
         +-------------N4--------+   SMF   +--------N4-----------+
         |                       +----+----+                     |
         |                            |                          |
         |                       +----+----+                     |
         |                       | ID-LOC  |                     |
         |                       | Mapping |      ID-LOC         |
         |               +------>| System  |<--control-plane     |
         |               |       +----+----+     |               |
         |               V                       V               |
     +---+---+      +----+----+             +----+----+      +---+---+
--N3-+ UPF-A +--N9--+ID-L Node+<--ID-LOC--->+ID-L Node+--N9--+ UPF-B +-N6--
     +-------+  GTP +----+----+ data-plane  +----+----+  GTP +-------+

        Figure 12: 5G Integration with ID-LOC (Interworking model)

   Another option is to implement the ID-LOC data-plane function
   directly in the UPFs (as shown in Fig. Figure 13).  In this case,
   these ID-LOC enabled UPFs will directly generate packets encapsulated
   or transformed and will be able to directly process packets
   encapsulated or transformed.  In this case the ID-LOC protocol will
   completely replace GTP in the N9 interface.

                                 +----+----+
         +-------------N4--------+   SMF   +--------N4-----------+
         |                       +----+----+                     |
         |                            |                          |
         |                       +----+----+                     |
         |                       | ID-LOC  |                     |
         |                       | Mapping |      ID-LOC         |
         |  +------------------->| System  |<--control-plane--+  |
         |  |                    +----+----+                  |  |
         |  V                                                 V  |
     +---+---+                                               +---+---+
--N3-+ UPF-A +<---------- N9 - ID-LOC data-plane ----------->+ UPF-B +-N6--
     +-------+                                               +-------+

         Figure 13: 5G Integration with ID-LOC (Integrated model)

   Finally, another aspect to consider when integrating the ID-LOC
   architecture into the 5G framework is that the Mapping System needs
   to contain the appropriate ID-LOC mappings in coordination with the
   SMF.  In order to do so, the mappings in the Mapping System are
   populated either by the SMF directly or by the LOC-nodes that should
   be in synch with the SMF.  In the former case, an interface from the
   SMF to the Mapping System is needed (as shown in Figs.  Figure 12 and
   Figure 13).




Bogineni, et al.        Expires December 31, 2018              [Page 45]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


6.2.2.  LISP control plane

   The current LISP control-plane (LISP-CP) specification
   [I-D.ietf-lisp-rfc6833bis] is data-plane agnostic and can serve as
   control plane for different data-plane protocols (beyond the LISP
   data-plane).  LISP-CP offers different mechanisms to register,
   request, notify and update ID-Loc mappings between ID-LOC data-plane
   elements and the ID-LOC Mapping System.  In the sections below we
   describe how LISP-CP can serve to enable the operation of the ILA
   data-plane and the SRv6 data-plane.

   It should be noted that the LISP-CP can run over TCP or UDP.  The
   same signaling and logic applies independently of the transport.
   Additionally, when running over TCP, the optimizations specified in
   [I-D.kouvelas-lisp-map-server-reliable-transport] can be applied.

6.2.2.1.  LISP-CP for ILA

   The LISP-CP can serve to resolve the Identifier-to-Locator mappings
   required for the operation of an ILA data-plane.  The required ILA
   control plane operations of "request/response" and "push" are
   implemented via the LISP mechanisms defined in
   [I-D.ietf-lisp-rfc6833bis] and [I-D.ietf-lisp-pubsub] respectively.
   In addition, the ILA "redirect" operation is implemented via the
   mapping notifications described in [I-D.ietf-lisp-pubsub] triggered
   as response to data-plane events.

   Furthermore, the LISP-CP can also be used to obtain the ILA
   Identifier when it is not possible to locally derivate it from the
   endpoint address.  These two mapping operations, Endpoint-to-
   Identifier and Identifier-to-Locator, can be combined into one
   mapping operation to obtain the ILA Identifier and associated
   Locators in a single round of signaling.

   The complete specification of how to use the LISP-CP in conjunction
   with an ILA data-plane can be found in [I-D.rodrigueznatal-ila-lisp].

6.2.2.2.  LISP-CP for SRv6

   The LISP-CP can be used by an ingress SRv6 node to obtain the egress
   node SRv6 VPN SID and its corresponding SLA associated with such
   endpoint.  Alternatively, an ingress SRv6 node can use the LISP-CP to
   obtain not only the egress SRv6 VPN segment for a particular endpoint
   but also the SRv6 SID list to steer the traffic to that egress SRv6
   node.






Bogineni, et al.        Expires December 31, 2018              [Page 46]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   The complete specification of how to use the LISP-CP in conjunction
   with an SRv6 data-plane can be found in
   [I-D.rodrigueznatal-lisp-srv6].

6.2.3.  ILA control plane

   The ILA control plane is composed of mapping protocols that manage
   and disseminate information about the mapping database.  There are
   two levels of mapping protocols: one used by ILA routers that require
   the full set of ILA mappings for a domain, and one used by ILA nodes
   that maintain a caches of mappings.

   The ILA mapping system is effectively a key/value datastore that maps
   identifiers to locators.  The protocol for sharing mapping
   information amongst ILA routers can thus be implemented by a
   distributed database [I-D.herbert-ila-ilamp].  ILA separates the
   control plane from the user plane, so alternative control plane
   protocols may be used with a common user plane
   [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp].

   The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA
   forwarding nodes and ILA mapping routers.  The purpose of the
   protocol is to populate and maintain the ILA mapping cache in
   forwarding nodes.  ILAMP defines redirects, a request/response
   protocol, and a push mechanism to populate the mapping table.  Unlike
   traditional routing protocols that run over UDP, this protocol is
   intended to be run over TCP and may be RPC oriented.  TCP provides
   reliability, statefulness implied by established connections,
   ordering, and security in the form of TLS.  Secure redirects are
   facilitated by the use of TCP.  RPC facilities such REST, Thrift, or
   GRPC leverage widely deployed models that are popular in SDN.

6.2.4.  Extensions to N3/F1-U/Xn-U interface

   While not the main focus of this document, it is worth noting that it
   is also possible to enable an ID-LOC data-plane over the N3 interface
   and to instantiate the ID-LOC overlay directly at the NodeB.  In this
   case, the NodeB will implement the functionality of an ID-LOC node,
   i.e. it will retrieve ID-LOC mappings using an ID-LOC control
   protocol and will encapsulate/transform ID packets into LOC packets.
   Bringing the ID-LOC data-plane to the NodeB (closer to the UE) has
   several advantages: (1) complete removal of GTP tunnels, (2) unified
   management of the ID-LOC data-plane across the network, (3) improved
   data-plane latency due to traffic being forwarded to the destination
   ID-LOC node directly from the NodeB, and (4) lower handover time
   since the ID-LOC mobility event can start at the NodeB itself.





Bogineni, et al.        Expires December 31, 2018              [Page 47]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


6.2.5.  Coexistence with GTP-based architecture

   ID-Locator separation architecture can be implemented by control
   plane of a dedicated protocol such as LISP, ILA, etc., however, it
   may cause major impact to the specifications of 3GPP 5GS.  The
   approach, described in [I-D.homma-dmm-5gs-id-loc-coexistence],
   enables to introduce such ID-Locator separation protocols into 5GS
   with no or low impacts.  It would also support a migration path
   toward a network which an ID-Locator separation protocol is
   completely incorporated.

   This approach establishes an individual domain/slice in which an ID-
   Locator

   separation protocol works as packet forwarding mechanism, and divert
   the appropriate packets (e.g., packets for UE-to-UE communication) to
   the domain at local/distributed UPFs by using Up-Link Classifier
   (ULCL).  ULCL is a fundamental function of UPF, and it diverts uplink
   traffic based on filter rules indicated by SMF.  The other packets to
   a central UPF (e.g., packets for Internet access) are forwarded with
   GTP-U via N9 interface.

   The architecture is shown in Figure 14.




























Bogineni, et al.        Expires December 31, 2018              [Page 48]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


               +-----------------------------+
               |              SMF            +<-------------+
               +--+----------------------+---+              |
                  N4                     N4                 |
                  |                      |                  |
               +--+---+               +--+---+    +-----+   |
    ---- N3 ---+ dUPF +---N9(GTP-U)---+ cUPF +-N6-+ cDN |   |
               |[ULCL]|               |      |    |     |   |
               +--+---+               +------+    +-----+   |
                  |                                        Sync
                  N6                                        |
              . . | . . . . . . . . . . . . . . .           |
    +-----+  . +--+---+              +---------+ .          |
    | dDN +-N6-+ ID-L +--ID-LOC CP---+ ID-LOC  | .          |
    |     |  . | Node |              | Mapping |<-----------+
    +-----+  . |      +--ID-LOC UP   | System  | .
             . +------+         |    +---+-----+ .
             .                  |        |       .
             . +------+         |        |       .
           -N6-+ ID-L +---------+        |       .
             . | Node |                  |       .
             . |      +--ID-LOC CP-------+       .
             . +--+---+                          .
              . . N6 . . . . . . . . . . . . . .
                  |       ID-LOC Domain

           Figure 14: Architecture of 5GS and ID-LOC Coexistence

   Coexistence approach allows to use GTP-U or any other forwarding
   protocol described in this document as user plane mechanism.
   However, each LOC-Node must be connected to the all other LOC-Nodes,
   and thus it may cause complexity of path management if you use a
   protocol which needs session establishment.

   Regarding to control plane of this approach, every dedicated ID-
   Locator separation protocol described in this document can be used.
   For management of mobility of UEs in ID-Locator separation domain,
   some cooperation between SMF and mapping system is needed.  In this
   approach, a UE is attached to a LOC-Node only when it communicates to
   another UE or an NF in a dDN.  In 5GS, SMF manages sessions, and thus
   SMF may be required to update mapping database when an UE moves to
   under another UPF or an NF is moved to another dDN.  The impact
   caused by such cooperation can be reduced by using Naf interface
   which is defined in 5GS specifications.

   This approach provides a mechanism for introducing ID-Locator
   separation architecture into 5GS with no or nominal impact, and
   achieves optimization of forwarding path and session continuity.



Bogineni, et al.        Expires December 31, 2018              [Page 49]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Moreover, this can keep scalability on forwarding on down link from
   cDN/Internet because it can use the current GTP-based mechanism.

   Meanwhile, this approach causes an extra hop when diverting packets
   to ID-Locator separation domain, and it may leads to increase of
   latency.

6.3.  ID-based - hICN

   By operating directly on routers' FIBs for mobility updates, dynamic
   hop-by-hop forwarding strategies etc., hICN inherits the simplicity
   of IP forwarding and reuses IP routing protocols for ID prefixes
   advertisement and routing.  In this way it removes the challenges of
   managing a distributed mapping service at scale (cache update/
   refresh, etc.).  In addition it remains compatible with the exiting
   control plane architecture as proposed in the 3GPP standard, with no
   change required to N1, N2 or N4.

   MAP-Me anchorless producer mobility management does not imply SMF
   interaction, but does not exclude neither to use SMF signaling to
   trigger MAP-Me updates or to handle FIB updates, at the condition to
   follow the same procedure described for MAP-Me.  However, the absence
   of SMF interaction might be beneficial in case of dense deployments
   or failure of the central control entities (infrastructure-less
   communication scenarios) to empower distributed control of local
   mobility within an area.

6.3.1.  Insertion in N9 interface

   Insertion of hICN in 5G IP infrastructure is facilitated by its
   design allowing a selective insertion of hICN capabilities in a few
   network nodes at the edge (no need for pervasive fully hICN network
   enablement), and to guarantee a transparent interconnection with
   hICN-unaware IP nodes, without using overlays.

   The deployment of hICN routers allow to avoid the reliance on GTP
   tunnels, and to provide an agile transport and native anchorless
   mobility natively.  The resulting protocol stack is showin in
   Figure 15.  We remark that in the protocol layer, hICN is associated
   to IPv6 PDU layer, transported in N9 directly over L2.











Bogineni, et al.        Expires December 31, 2018              [Page 50]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


       UE            5G-AN        N3         UPF        N9   UPF    N6
                                  |                     |            |
   +--------+                     |                     |            |
   |  App.  |--------------------------------------------------------|
   +--------+                     |                     | +--------+ |
   | IP PDU |                     |                     | | IP PDU | |
   | (hICN) |---------------------------------------------| (hICN) | |
   +--------+ +-----------------+ | +-----------------+ | |        | |
   |        | |\     relay     /| | |\     decap     /  | |        | |
   |        | | \_____________/ |-|-| \_____________/   | |        | |
   |        | |        | GTP-U  | | | GTP-U  |          | |        | |
   |        | |        +--------+ | +--------+          | |        | |
   |   5G   | |   5G   |  UDP   |-|-|  UDP   |          | |        | |
   |   AN   |-|   AN   +--------+ | +--------+          | |        | |
   |protocol| |protocol|   IP   |-|-|   IP   |          | |        | |
   | layers | | layers +--------+ | +--------+--------+ | +--------+ |
   |        | |        |   L2   |-|-|   L2   |   L2   |-|-|   L2   | |
   |        | |        +--------+ | +--------+--------+ | +--------+ |
   |        | |        |   L1   |-|-|   L1   |   L1   |-|-|   L1   | |
   +--------+ +-----------------+ | +-----------------+ | +--------+ |
                                  |                     |            |

         Figure 15: Replacement of N9 interface - Protocol layers

6.3.2.  Control plane considerations

   By operating directly on routersa&#128;&#153; FIBs for mobility
   updates, dynamic hop-by-hop forwarding strategies etc., hICN inherits
   the simplicity of IP forwarding and reuses IP routing protocols for
   ID prefixes advertisement and routing.  In this way it removes the
   challenges of managing a distributed mapping service at scale (cache
   update/refresh, etc.).  In addition it remains compatible with the
   exiting control plane architecture as proposed in the 3GPP standard,
   with no change required to N1, N2 or N4.

   MAP-Me anchorless producer mobility management does not imply SMF
   interaction, but does not exclude neither to use SMF signaling to
   trigger MAP-Me updates or to handle FIB updates, at the condition to
   follow the same procedure described for MAP-Me.  However, the absence
   of SMF interaction might be beneficial in case of dense deployments
   or failure of the central control entities (infrastructure-less
   communication scenarios) to empower distributed control of local
   mobility within an area.








Bogineni, et al.        Expires December 31, 2018              [Page 51]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


6.3.3.  Extensions to N3/F1-U/Xn-U interface

   This option ensures that forwarding beyond the radio access is
   directly managed through hICN.  As a consequence, no additional state
   nor signaling is required for static and mobile consumers, nor for
   static producers.  The impact of producer mobility is low because of
   the small number of impacted routers.

   Dynamic forwarding capabilities are extended in this configuration to
   the selection of the first UPF, with the potential of additional
   performance improvement and higher traffic offload because of the
   deployment of hICN functionalities closer to the UE.  A significant
   advantage arises in dense deployments scenarios where it becomes
   possible to isolate the core network from the locally-management
   mobility (a design objective of the mobile architecture), while
   allowing distributed selection of ingress UPFs, and dynamic per-
   packet load balancing of traffic across them.

6.3.4.  Coexistence with GTP-based architecture

   This section discusses the insertion of hICN-AMM in an unmodified
   3GPP 5G reference architecture, where GTP tunnels are preserved.  As
   previously stated, maintaining GTP tunnels does not allow to overcome
   limitations of anchor-based approaches.  However, a transparent
   integration of hICN-AMM limits to the minimum deployment costs and
   already brings advantages over the baseline architecture presented
   earlier.

   The first option shares some similarities with the previous situation
   and proposes to deploy hICN-AMM within Mobile Edge Computing (MEC)
   platforms.  It relies on the local breakout capability introduced in
   5G through the UL/CL.  This function is used to realize the hICN
   punting function described in [I-D.muscariello-intarea-hicn], i.e. to
   identify hICN traffic (Interest and Data packets) and forward it to
   the local MEC hICN instance.  Although it preserves tunnels and
   anchor points, this option permits an early termination of tunnels
   and the distribution of hICN capabilities close to the edge like in
   path caching and rate/loss/congestion control which may be leveraged
   for efficient low-latency content distribution especially in presence
   of consumer mobility.

   The second option consists in the deployment of hICN-AMM as User
   Plane Function (UPF) inside mobile user plane.  It has the advantage
   of preserving hICN benefits in terms of consumer mobility and
   flexible transport.

   A more in depth presentation of those alternative deployments can be
   found in [I-D.auge-dmm-hicn-mobility-deployment-options].



Bogineni, et al.        Expires December 31, 2018              [Page 52]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


6.4.  Coexistence of multiple protocols in network slices

   Slicing is one of the main features in 5G.  Several Slices with
   different requirements can coexist on top of the common network
   infrastructure.  Diverse flows belonging to different 5G slices can
   be completely disjoint or can share different parts of the network
   infrastructure.

   All proposals reviewed in this draft lend themselves well to 5G
   slicing paradigm, that can assist a transition of services towards
   these new user plane protocols, or allow the coexistence of different
   deployment options.

   Figure 16 illustrates the use of network slices with the different
   proposals.  All categories of approach can coexist in separate
   slices, so as different deployments of the same approach.  We refer
   to previous sections for more details about the possible
   configurations for ID-LOC, and limit our discussion here to the
   possibility for different slices to deploy their own mapping system,
   or share it as illustrated here.

Locator-based                   ID-LOC split              ID-based
(GTP, SRv6-T)             (LISP, ILSR, ILA, SRv6-E)        (hICN)
 ----+-------------------------------+-----------------------+----------
     |                               |                       |
+---------------------+ +-----------------------+ +--------------------+
| +-------+  Slice #1 | | +----------+ Slice #2 | | +-------+ Slice #4 |
| | SMF   |---+   GTP | | | Mapping  +---+      | | | SMF   |---+ hICN |
| +--+----+   |       | | +---+-----++   |      | | +--+----+   |  AMM |
| N4 |        | N4    | |     |     |    |      | | N4 |        | N4   |
| +--+--+  +--+----+  | | +---+---+ | +--+----+ | | +--+--+  +--+----+ |
| | UPF |  | UPF   |  | | | LOC-A | | | LOC-B | | | | UPF |  | UPF   | |
| +-----+  +-------+  | | +-------+ | +-------+ | | +-----+  +-------+ |
+----------- ---------+ +-----------|-----------+ +--------------------+
                  |                 |       |           |          |
               +--+-+               |    +--+-+      +--+--+    +--+-+
               | DN |               |    | DN |      | MEC |    | DN |
               +----+               |    +----+      +-----+    +----+
                       +------------|------------+
                       |            |   Slice #3 |
                       |     +------+---+        |
                       |     |          |        |
                       | +---+---+    +-+-----+  |   +----+
              +-----+  | | LOC-A |    | LOC-B |  |---| DN |
              | MEC |--| +-------+    +-------+  |   +----+
              +-----+  +-------------------------+

                      Figure 16: Network slices in 5G



Bogineni, et al.        Expires December 31, 2018              [Page 53]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   *Locator-based*

   Slice #1 illustrates legacy use of UPFs with GTP in a slice.  New
   approaches can be deployed incrementally or in parts of the network.
   As demonstrated, the use of network slices can provide domain
   isolation for this.

   *ID-LOC split*

   Slice #2 and #3 support ID-LOC.  We illustrate in slice #2 a typical
   deployment with ILA.  Mapping then corresponds to ILA-M, LOC-A to
   ILA-N and LOC-B to ILA-R.

   Some number of ILA-Ns and ILA-Rs are deployed.  ILA transformations
   are performed over the N9 interface.  ILA-Rs would be deployed at the
   N6 interface to perform transformations on packets received from a
   data network.  ILA-Ns will be deployed deeper in the network at one
   side of the N3 interface.  ILA-Ns may be supplemented by ILA-Rs that
   are deployed in the network.  ILA-M manages the ILA nodes and mapping
   database within the slice.

   Slice #3 shows another slice that supports ILA.  In this scenario,
   the slice is for Mobile Edge Computing.  The slice contains ILA-Rs
   and ILA-Ns, and as illustrated, it may also contain ILA_Hs that run
   directly on edge computing servers.  Note in this example, one ILA-M,
   and hence one ILA domain, is shared between slice #2 and slice #3.
   Alternatively, the two slices could each have their own ILA-M and
   define separate ILA domains.

   *ID-based*

   Finally, in slice #4, a slice using hICN-AMM is shown, that does not
   require any mapping system nor changes in N4.

6.5.  Interoperability/Roaming considerations

   Different situations including roaming scenarios might require the
   coexistence of different mobility protocols for the same user plane.
   In Figure 17 and Figure 18, we illustrate two possible deployments
   for the Home-Routed Roaming Scenario, respectively using a UPF
   supporting several protocols, and relying on an exchange service
   point for interconnection.









Bogineni, et al.        Expires December 31, 2018              [Page 54]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


                              VPLMN   |      HPLMN
                       -----+-----  N32 --------+--------
                            |         |         |
                         +--+--+      |      +--+--+
                         | SMF |      |      | SMF |
                         +--+--+      |      +--+--+
                            |         |         |
   +-------+                |         |         |
   | 5G UE |                |         |         |
   +---+---+               N4         |         N4
       |                    |                   |
       |     +-----+     +--+--+             +--+--+      +----+
       +-----| gNB |-----| UPF |-----N9------| UPF |------| DN |
             +-----+     +-----+             +-----+      +----+

   Figure 17: Direct Connectivity between operators with UPFs supporting
                     more than one mobility protocols

                              VPLMN   |      HPLMN
                       -----+-----  N32 --------+--------
                            |         |         |
                         +--+--+      |      +--+--+
                         | SMF |      |      | SMF |
                         +--+--+      |      +--+--+
                            |         |         |
   +-------+                |         |         |
   | 5G UE |                |         |         |
   +---+---+               N4         |         N4
       |                    |                   |
       |     +-----+     +--+--+   +-----+    +--+--+      +----+
       +-----| gNB |-----| UPF |---| Exc |----| UPF |------| DN |
             +-----+     +-----+   +-----+    +-----+      +----+

     Figure 18: Connectivity between operators using an Exchange that
                   supports multiple mobility protocols

7.  Summary

   This document summarizes the various IETF protocol options for GTP
   replacement on N9 interface of 3GPP 5G architecture.  The document
   also proposes optional raplacemets of GTP in N3 interface.

8.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [RFC2234].





Bogineni, et al.        Expires December 31, 2018              [Page 55]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


9.  Security Consideration

   All 3GPP security aspects apply to all the protocols discussed in
   this document.

10.  IANA Considerations

   There are no IANA considerations in this specification.

11.  Acknowledgement

   The authors would like to thank Farooq Bari, Devaki Chandramouli,
   Ravi Guntupalli, Sri Gundavelli, Peter Ashwood Smith, Satoru
   Matsushima, Michael Mayer, Vina Ermagan, Fabio Maino, Albert
   Cabellos, Cameron Byrne for reviewing various iterations of the
   document and for providing content into various sections.

12.  References

12.1.  Normative References

   [RFC1027]  Carl-Mitchell, S. and J. Quarterman, "Using ARP to
              implement transparent subnet gateways", RFC 1027,
              DOI 10.17487/RFC1027, October 1987,
              <https://www.rfc-editor.org/info/rfc1027>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
              November 1997, <https://www.rfc-editor.org/info/rfc2234>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

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







Bogineni, et al.        Expires December 31, 2018              [Page 56]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


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

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835,
              DOI 10.17487/RFC6835, January 2013,
              <https://www.rfc-editor.org/info/rfc6835>.

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

   [RFC7476]  Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
              Tyson, G., Davies, E., Molinaro, A., and S. Eum,
              "Information-Centric Networking: Baseline Scenarios",
              RFC 7476, DOI 10.17487/RFC7476, March 2015,
              <https://www.rfc-editor.org/info/rfc7476>.

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




Bogineni, et al.        Expires December 31, 2018              [Page 57]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   [RFC8112]  Farinacci, D., Jain, A., Kouvelas, I., and D. Lewis,
              "Locator/ID Separation Protocol Delegated Database Tree
              (LISP-DDT) Referral Internet Groper (RIG)", RFC 8112,
              DOI 10.17487/RFC8112, May 2017,
              <https://www.rfc-editor.org/info/rfc8112>.

12.2.  Informative References

   [CICN]     Linux Foundation fd.io, "CICN project", 2018.

   [CP-173160-1]
              3rd Generation Partnership Project (3GPP), "New Study Item
              on User Plane Protocol in 5GC", December 2017.

   [I-D.auge-dmm-hicn-mobility]
              Auge, J., Carofiglio, G., Muscariello, L., and M.
              Papalini, "Anchorless mobility through hICN", draft-auge-
              dmm-hicn-mobility-00 (work in progress), June 2018.

   [I-D.auge-dmm-hicn-mobility-deployment-options]
              Auge, J., Carofiglio, G., Muscariello, L., and M.
              Papalini, "Anchorless mobility management through hICN
              (hICN-AMM): Deployment options", draft-auge-dmm-hicn-
              mobility-deployment-options-00 (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-03 (work in progress), March 2018.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and
              M. Sharif, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-04 (work in progress),
              March 2018.

   [I-D.herbert-ila-ilamp]
              Herbert, T., "Identifier Locator Addressing Mapping
              Protocol", draft-herbert-ila-ilamp-00 (work in progress),
              December 2017.







Bogineni, et al.        Expires December 31, 2018              [Page 58]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   [I-D.herbert-ila-mobile]
              Herbert, T. and K. Bogineni, "Identifier Locator
              Addressing for Mobile User-Plane", draft-herbert-ila-
              mobile-01 (work in progress), March 2018.

   [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.hmm-dmm-5g-uplane-analysis]
              Homma, S., Miyasaka, T., and S. Matsushima, "User Plane
              Protocol and Architectural Analysis on 3GPP 5G System",
              2018.

   [I-D.homma-dmm-5gs-id-loc-coexistence]
              Homma, S., Kawakami, K., and A. Akhavain, "Co-existence of
              3GPP 5GS and Identifier Locator Separation Architecture",
              draft-homma-dmm-5gs-id-loc-coexistence-01 (work in
              progress), May 2018.

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

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
              daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
              IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
              uplane-01 (work in progress), 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-02
              (work in progress), May 2018.

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







Bogineni, et al.        Expires December 31, 2018              [Page 59]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


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

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

   [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-12 (work in progress),
              March 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-10 (work in progress), March
              2018.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-01 (work in progress), June 2018.

   [I-D.irtf-icnrg-mapme]
              Auge, J., Carofiglio, G., Muscariello, L., and M.
              Papalini, "MAP-Me : Managing Anchorless Mobility in
              Content Centric Networking", draft-irtf-icnrg-mapme-00
              (work in progress), March 2018.

   [I-D.irtf-icnrg-terminology]
              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
              D., and C. Tschudin, "Information-Centric Networking
              (ICN): CCN and NDN Terminology", draft-irtf-icnrg-
              terminology-00 (work in progress), December 2017.




Bogineni, et al.        Expires December 31, 2018              [Page 60]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   [I-D.kouvelas-lisp-map-server-reliable-transport]
              Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J.
              Arango, "LISP Map Server Reliable Transport", draft-
              kouvelas-lisp-map-server-reliable-transport-04 (work in
              progress), September 2017.

   [I-D.lapukhov-bgp-ila-afi]
              Lapukhov, P., "Use of BGP for dissemination of ILA mapping
              information", draft-lapukhov-bgp-ila-afi-02 (work in
              progress), October 2016.

   [I-D.muscariello-intarea-hicn]
              Muscariello, L., Carofiglio, G., Auge, J., and M.
              Papalini, "Hybrid Information-Centric Networking", draft-
              muscariello-intarea-hicn-00 (work in progress), June 2018.

   [I-D.rodrigueznatal-ila-lisp]
              Rodriguez-Natal, A., Ermagan, V., Maino, F., and A.
              Cabellos-Aparicio, "LISP control-plane for Identifier
              Locator Addressing (ILA)", draft-rodrigueznatal-ila-
              lisp-01 (work in progress), April 2018.

   [I-D.rodrigueznatal-lisp-srv6]
              Rodriguez-Natal, A., et al., "LISP Control Plane for SRv6
              Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00
              (work in progress) , June 2018.

   [I-D.vonhugo-5gangip-ip-issues]
              Hugo, D. and B. Sarikaya, "Review on issues in discussion
              of next generation converged networks (5G) from an IP
              point of view", draft-vonhugo-5gangip-ip-issues-03 (work
              in progress), March 2017.

   [I-D.xuclad-spring-sr-service-chaining]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
              Henderickx, W., and S. Salsano, "Segment Routing for
              Service Chaining", draft-xuclad-spring-sr-service-
              chaining-01 (work in progress), March 2018.

   [ILACONTROL]
              Herbert, T., "Identifier Locator Addressing Mapping
              Protocol draft-herbert-ila-ilamp-00", December 2017.

   [ILAGRPS]  Herbert, T., "Identifier Groups draft-herbert-idgroups-
              00", February 2018.





Bogineni, et al.        Expires December 31, 2018              [Page 61]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   [ILAMOTIVE]
              Herbert, T., "Identifier Locator Addressing: Problem
              Areas, Motivation, and Use Cases draft-herbert-ila-
              motivation-00", January 2018.

   [ILSR-WP]  Kurebayashi, R., Ashwood-Smith, P., and D. Farinacci,
              "Evolving 5G Routing", December 2017.

   [IRTF-RRG]
              Li, T., "IRTF Routing Research Group (rrg)", November
              2012.

   [LISP-WG]  Halrpen, J. and L. Iannone, "IETF Locator/ID Separation
              Protocol (lisp) Working Group", June 2018.

   [MAPME]    Auge, J., Carofiglio, G., Grassi, G., Muscariello, L.,
              Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
              Producer Mobility in Content-Centric Networks", IEEE
              Transactions on Network and Service Management Vol. 15,
              pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018.

   [SP-180231-1]
              3rd Generation Partnership Project (3GPP), "New Study on
              Enhancements to the Service-Based 5G System Architecture",
              March 2018.

   [TR.29.891-3GPP]
              3rd Generation Partnership Project (3GPP), "5G System ?
              Phase 1, CT WG4 Aspects, 3GPP TR 29.891 v15.0.0", December
              2017.

   [TS.23.203-3GPP]
              3rd Generation Partnership Project (3GPP), "Policy and
              Charging Control Architecture, 3GPP TS 23.203 v2.0.1",
              December 2017.

   [TS.23.501-3GPP]
              3rd Generation Partnership Project (3GPP), "System
              ARchitecture for the 5G System; Stage 2, 3GPP TS 23.501,
              v15.2.0", June 2018.

   [TS.23.502-3GPP]
              3rd Generation Partnership Project (3GPP), "Procedures for
              5G System; Stage 2, 3GPP TS 23.502, v15.2.0", June 2018.







Bogineni, et al.        Expires December 31, 2018              [Page 62]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   [TS.23.503-3GPP]
              3rd Generation Partnership Project (3GPP), "Policy and
              Charging Control System for 5G Framework; Stage 2, 3GPP TS
              23.503 v15.2.0", June 2018.

   [TS.29.244-3GPP]
              3rd Generation Partnership Project (3GPP), "Interface
              between the Control Plane and the User Plane Nodes; Stage
              3, 3GPP TS 29.244 v15.2.0", June 2018.

   [TS.29.281-3GPP]
              3rd Generation Partnership Project (3GPP), "GPRS Tunneling
              Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.3.0",
              June 2018.

   [TS.38.300-3GPP]
              3rd Generation Partnership Project (3GPP), "NR and NG-RAN
              Overall Description: Stage 2, 3GPP TS 38.300 v15.2.0",
              June 2018.

   [TS.38.401-3GPP]
              3rd Generation Partnership Project (3GPP), "NG-RAN:
              Architecture Description, 3GPP TS 38.401 v15.2.0", June
              2018.

   [TS.38.801-3GPP]
              3rd Generation Partnership Project (3GPP), "Study on new
              radio access technology: Radio access architecture and
              interfaces", March 2017.

   [WLDR]     Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,
              N., and X. Zeng, "Leveraging ICN In-network Control for
              Loss Detection and Recovery in Wireless Mobile networks",
              Proceedings of the 2016 conference on 3rd ACM Conference
              on Information-Centric Networking - ACM-ICN '16,
              DOI 10.1145/2984356.2984361, 2016.

Authors' Addresses

   Kalyani Bogineni
   Verizon

   Email: kalyani.bogineni@verizon.com








Bogineni, et al.        Expires December 31, 2018              [Page 63]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Arashmid Akhavain
   Huawei Canada Research Centre

   Email: arashmid.akhavain@huawei.com


   Tom Herbert
   Quantonium

   Email: tom@quantonium.net


   Dino Farinacci
   lispers.net

   Email: farinacci@gmail.com


   Alberto Rodriguez-Natal
   Cisco Systems, Inc.

   Email: natal@cisco.com


   Giovanna Carofiglio
   Cisco Systems, Inc.

   Email: gcarofig@cisco.com


   Jordan Auge
   Cisco Systems, Inc.

   Email: jordan.auge@cisco.com


   Luca Muscariello
   Cisco Systems, Inc.

   Email: lumuscar@cisco.com


   Pablo Camarillo Garvia
   Cisco Systems, Inc.

   Email: pcamaril@cisco.com





Bogineni, et al.        Expires December 31, 2018              [Page 64]


Internet-Draft   draft-bogineni-dmm-optimized-mobile-up        June 2018


   Shunsuke Homma
   NTT

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















































Bogineni, et al.        Expires December 31, 2018              [Page 65]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/