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

Versions: 00 01

INTERNET-DRAFT                                               K. Bogineni
Intended Status: Informational                                   Verizon
Expires: September 2018                                      A. Akhavain
                                              Huawei Technologies Canada
                                                              T. Herbert
                                                              Quantonium
                                                            D. Farinacci
                                                             lispers.net
                                                      A. Rodriguez-Natal
                                                                   Cisco
                                                           March 5, 2018


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


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
   [23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The
   requirements for the network functions and the relevant interfaces
   are provided.

   Reference scenarios and criteria for evaluation of various IETF
   protocols are provided.

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



K. Bogineni            Expires September 6, 2018                [Page 1]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 6, 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
   (http://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 and Problem Statement  . . . . . . . . . . . . . .  4
   2  Conventions used in this document . . . . . . . . . . . . . . .  4
   3  Overview of Existing Architecture and Protocol Stack  . . . . .  4
   4  Reference Scenario(s) for Evaluation  . . . . . . . . . . . . . 14
   5  SRv6 Based Solution . . . . . . . . . . . . . . . . . . . . . . 15
     5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.2 SRV6 as Drop-In Alternative for GTP-U  . . . . . . . . . . . 15
     5.3 SRV6 as Drop-In GTP Replacement with TE  . . . . . . . . . . 17
     5.4 UPF Chaining with SRV6 . . . . . . . . . . . . . . . . . . . 18
     5.5 SRV6 and Entropy . . . . . . . . . . . . . . . . . . . . . . 19
     5.6 SRV6 and 5G Slicing  . . . . . . . . . . . . . . . . . . . . 19
     5.7 SRV6 and Lawful Interception in 5G . . . . . . . . . . . . . 20
     5.8 SRV6 and Alternative Approaches to Advanced Mobility
         Support  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       5.8.1 SRV6 and Locator/ID Separation Paradigm for N9
             Interface  . . . . . . . . . . . . . . . . . . . . . . . 20
       5.8.2 Brief Overview of Locator-ID Separation  . . . . . . . . 20
       5.8.3 Locator-ID Separation via SRV6 for UPF connectivity  . . 21
         5.8.3.1 Overlay model with SRV6 Locators . . . . . . . . . . 21
         5.8.3.2 SRV6 Capable UPFs and RLOCs  . . . . . . . . . . . . 22
       5.8.4 Advanced Features in ID-Locator Architecture . . . . . . 23
     5.9 Areas of Concern . . . . . . . . . . . . . . . . . . . . . . 23
   6  LISP based Solution . . . . . . . . . . . . . . . . . . . . . . 24



K. Bogineni            Expires September 6, 2018                [Page 2]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


     6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     6.2 LISP Data-Plane  . . . . . . . . . . . . . . . . . . . . . . 25
     6.3 LISP Control-Plane . . . . . . . . . . . . . . . . . . . . . 25
     6.4 LISP Mobility Features . . . . . . . . . . . . . . . . . . . 25
     6.5 ILSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.6 LISP Control-Plane with ILA Data-Plane . . . . . . . . . . . 26
   7  ILNP Based Solution . . . . . . . . . . . . . . . . . . . . . . 27
   8  ILA based Solution  . . . . . . . . . . . . . . . . . . . . . . 27
     8.1 Overview of ILA  . . . . . . . . . . . . . . . . . . . . . . 28
     8.2 ILA in the 5G architecture . . . . . . . . . . . . . . . . . 29
     8.3 Protocol layering  . . . . . . . . . . . . . . . . . . . . . 31
     8.4 Control plane  . . . . . . . . . . . . . . . . . . . . . . . 32
       8.4.1 ILA-M services interface . . . . . . . . . . . . . . . . 32
       8.4.2 ILA control plane  . . . . . . . . . . . . . . . . . . . 32
     8.5 IP addressing  . . . . . . . . . . . . . . . . . . . . . . . 33
       8.5.1 Singleton address assignment . . . . . . . . . . . . . . 33
       8.5.2 Network prefix assignment  . . . . . . . . . . . . . . . 33
       8.5.3 Strong privacy addresses . . . . . . . . . . . . . . . . 34
     8.6 Traffic engineering  . . . . . . . . . . . . . . . . . . . . 34
     8.7 Locator Chaining with ILA  . . . . . . . . . . . . . . . . . 35
     8.8 ILA and network slices . . . . . . . . . . . . . . . . . . . 35
     8.9 Security considerations  . . . . . . . . . . . . . . . . . . 36
   9  No Protocol Option  . . . . . . . . . . . . . . . . . . . . . . 36
   10 Comparison of Protocols . . . . . . . . . . . . . . . . . . . . 36
   11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
   12 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 37
   13 Security Considerations . . . . . . . . . . . . . . . . . . . . 37
   14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 37
   15 References  . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     15.1 Normative References  . . . . . . . . . . . . . . . . . . . 37
     15.2 Informative References  . . . . . . . . . . . . . . . . . . 37
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 38



















K. Bogineni            Expires September 6, 2018                [Page 3]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


1  Introduction and Problem Statement

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

   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 comprehensively describes the various protocols and how
   they can be used in the 3GPP 5G architecture. Specifically Segment
   Routing v6 (SRv6), Locator Identifier Separation Protocol (LISP) and
   Identifier Locator Addressing (ILA) are described in the context of
   the 3GPP 5G architecture for several scenarios: as a replacement of
   GTP on N9; as a replacement of GTP in the whole system; integrated
   with transport; used in specific network slices, etc.

   A comparison of the various protocols is also provided.

2  Conventions used in this document

   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.

3  Overview of Existing Architecture and Protocol Stack

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



K. Bogineni            Expires September 6, 2018                [Page 4]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

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

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

          +------+ +------+     +------+
          | 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



















K. Bogineni            Expires September 6, 2018                [Page 5]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

                Figure 2: 5G Services Based Architecture

   The roaming architectures are depicted in the two figures below.

                                   VPLMN      |      HPLMN
    ----------+-------+------+------+----    N32 -------+------+----
              |       |      |      |         |         |      |
           +--+--+  +-+-+ +--+--+ +-+-+       |      +--+--+ +-+-+
           | AMF |  |PCF| | SMF | |AF |       |      | UDM | |PCF|
           +-+-+-+  +---+ +--+--+ +---+       |      +-----+ +---+
             N1|             |                |
   +-------+ | |             N4               |
   | 5G UE +-+ |             |                |
   +---+---+   N2      +-----+--+             |
       |       |       |        |             |
       |   +---+-+   +-+-+    +-+-+  +----+   |
       +---| gNB |---|UPF|-N9-|UPF|--| DN |   |
           +-----+   +-+-+    +---+  +----+   |

   Figure 3: Roaming 5G System architecture- local breakout scenario











K. Bogineni            Expires September 6, 2018                [Page 6]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


                              VPLMN   |      HPLMN
    ----------+------+------+-----  N32 --------+-------+------+-----+--
              |      |      |         |         |       |      |     |
           +--+--+ +-+-+ +--+--+      |      +--+--+ +--+--+ +-+-+ +-+-+
           | AMF | |PCF| | SMF |      |      | SMF | | UDM | |PCF| |AF |
           +-+-+-+ +---+ +--+--+      |      +--+--+ +-----+ +---+ +---+
            N1 |            |         |         |
   +-------+ | |            |         |         |
   | 5G UE |-+ |            |         |         |
   +---+---+   N2          N4         |         N4
       |       |            |                   |
       |     +-+---+     +--+--+             +--+--+      +----+
       +-----| gNB |-----| UPF |-----N9------| UPF |------| DN |
             +-----+     +--+--+             +-----+      +----+

    Figure 4: Roaming 5G System architecture - home routed scenario

   Figure 5 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
    ---------+------------+------------------+----------------------
             |            |                  |
          +--+--+      +--+--+            +--+--+
          | AMF |      | SMF |            | SMF |
          +--+-++      +--+--+            +--+--+
             N1|          |                  |
   +-------+ | |          N4                 N4
   | 5G UE |-+ |          |                  |
   +---+---+   N2      +--+--+    +----+     +-----------+
       |       |   +---| UPF |----| DN |     |           |
       |       |   |   +-----+    +----+     |           |
       |     +-+---+-+                    +--+--+     +--+--+  +----+
       +-----|  gNB  |--------------------| UPF |--N9-| UPF |--| DN |
             +-------+                    +-----+     +-----+  +----+

      Figure 5: Non-roaming architecture for multiple PDU Sessions









K. Bogineni            Expires September 6, 2018                [Page 7]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

   Figure 6: Non-roaming 5G System architecture for concurrent access
             to two (e.g. local and central) data networks
                      (single PDU Session option)

   Figure 6 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.

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

   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.

      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 the 5GS)

      o Activation and release of the UP connection of an PDU session,



K. Bogineni            Expires September 6, 2018                [Page 8]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


        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

      o Packet routing & 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 e.g. allowing SMF support for charging,
        and/or allowing the SMF to initiate a CN initiated deactivation
        of UP connection of an existing PDU session when the UPF detects
        that the PDU Session has no user plane data activity for a
        specified Inactivity period provided by the SMF

      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), 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



K. Bogineni            Expires September 6, 2018                [Page 9]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


          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 Packet Filter Set is used in the QoS rules or SDF template to
        identify a QoS flow. The Packet Filter Set may contain packet
        filters for the DL direction, the UL direction or packet filters
        that are applicable to both directions.

      o Downlink packet buffering and downlink data notification
        triggering:

        This includes the support and handling of the ARP 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.

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

      o ARP proxying as specified in IETF RFC 1027 [53] and / or IPv6
        Neighbour Solicitation Proxying as specified in IETF RFC 4861
        [54] 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)




K. Bogineni            Expires September 6, 2018               [Page 10]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


        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, comprising:
              - Source/destination IP address or IPv6 network prefix
              - Source / destination port number
              - Protocol ID of the protocol above IP/Next header type
              - Type of Service (TOS) (IPv4) / Traffic class (IPv6) and
                Mask
              - Flow Label (IPv6)
              - Security parameter index
            Application Identifier: The Application ID is an index to a
            set of application detection rules configured in UPF

            In the IP Packet Filter Set:
              - a value left unspecified in a filter matches any value
                of the corresponding information in a packet
              - an IP address or Prefix may be combined with a prefix
                mask
              - port numbers may be specified as port ranges
        For Ethernet PDU session type, the SMF may control UPF traffic
          detection capabilities based on at least any combination of:
          PDU session
          QFI
          Ethernet Packet Filter Set, comprising:
              - Source/destination MAC address
              - EtherType as defined in IEEE 802.3
              - Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-
                TAG) VID fields as defined in IEEE 802.1Q
              - Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-
                TAG) PCP/DEI fields as defined in IEEE 802.1Q
              - IP Packet Filter Set, in case Ethertype indicates
                IPv4/IPv6 payload
      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.

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

      QFI (QoS Flow Identifier), see subclause 5.7.1 of 3GPP TS 23.501:




K. Bogineni            Expires September 6, 2018               [Page 11]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


        "A QoS Flow ID (QFI) is used to identify a QoS flow in the 5G
        system. User Plane traffic with the same QFI within a PDU
        session receives the same traffic forwarding treatment (e.g.
        scheduling, admission threshold). The QFI is carried in an
        encapsulation header on N3 (and N9) i.e. without any changes to
        the e2e packet header. It can be applied to PDUs with different
        types of payload, i.e. IP packets, non-IP PDUs and Ethernet
        frames. The QFI shall be unique within a PDU session." The QFI
        is sent for both downlink and uplink user plane traffic.

   RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of 3GPP TS
   23.501:

      "When the 5GC determines to activate reflective QoS via U-plane,
      the SMF shall include a QoS rule including an indication to the
      UPF via N4 interface to activate User Plane with user plane
      reflective. When the UPF receives a DL packet matching the QoS
      rule that contains an indication to activate reflective QoS, the
      UPF shall include the RQI in the encapsulation header on N3
      reference point. The UE creates a UE derived QoS rule when the UE
      receives a DL packet with a RQI."

      The RQI is sent for downlink user plane traffic only.

   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 3GPP TS 23.501 and subclause 4.14.1
   of 3GPP TS 23.502 respectively:

      " For some other PDU sessions of an UE: Direct the DL User Plane
      traffic of some QoS flows of the PDU session to the Secondary
      (respectively Master) RAN Node while the remaining QoS flows of
      the PDU session are directed to the Master (respectively
      Secondary) RAN Node. In this case there are, irrespective of the
      number of QoS Flows, two N3 tunnel terminations at the RAN for
      such PDU session."

      " In order to assist the reordering function in the Master RAN
      node and/or Secondary RAN node, for the QFIs that are switched
      between Master RAN node and Secondary RAN node, the UPF sends one
      or more "end marker" packets along with QFI on the old tunnel
      immediately after switching the tunnel for the QFI. The UPF starts
      sending downlink packets to the Target RAN."

   GTPv1-U as defined in 3GPP TS 29.281 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



K. Bogineni            Expires September 6, 2018               [Page 12]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   3GPP TS 29.281 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. The protocol stack for the User
   Plane transport for a PDU session is depicted below in Figure 7.

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

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

      - 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



K. Bogineni            Expires September 6, 2018               [Page 13]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


        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.

      - 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 7: User Plane Protocol Stack

4  Reference Scenario(s) for Evaluation

   Different proposals will be described for the following scenarios:

      1. Non-Roaming Scenarios
         a. UE- Internet Connectivity (mobility cases)
         b. UE-UE IP Packet Flow (mobility cases)
         c. UE - 2 DNs with multiple PDU sessions
         d. UE - 2 DNs single PDU session

      2. Roaming Scenarios
         a. Local Break out
         b. Home routed

   Flows will be provided for mobility cases (UE mobility, UPF mobility)
   and session continuity cases (SSC Mode 1/2/3).

      1. UE mobility SSC Mode 1
         a. Single UPF
         b. Multiple UPF
      2. UE Mobility SSC Mode 2
         a. Single UPF
         b. Multiple UPF
      3. UE Mobility SSC Mode 3
         a. Single UPF
         b. Multiple UPF

   Each proposal will also describe how network slicing will be
   supported for the following configurations:

      o Support for independent slices using GTP and/or other protocol
        will be covered. Mobility Management will be within each slice.

      o Support for one UE connected to multiple slices using different
        mobility protocols will be described.



K. Bogineni            Expires September 6, 2018               [Page 14]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   The criteria for evaluation will be the ability to support the above
   scenarios and identifying the impacts to N2, N3, N4, gNB, AMF and
   SMF.

5  SRv6 Based Solution

5.1 Overview

   Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing]
   generalises the source routing paradigm with an ordered list of
   global and/or nodal instructions (segments) prepended in an SR header
   in order to either steer traffic flows through the network while
   confining flow states to the ingress nodes in the SR domains and/or
   to indicate functions that are performed at specific network
   locations.

   The IPV6 realisation of SR (SRV6) defines a SR Header (SRH), see [I-
   D.ietf-6man-segment-routing-header]. SRV6 encodes segments as IPV6
   addresses in the Segment List (SL) of its header. The packet
   destination address in SRV6 specifies the active segment while an
   index field in the SRH points to the next active segment in the list.
   The index field in SRH is decremented as SRV6 progressively forces
   packet flows through different segments over the IPV6 data plane.

   The versatility and adaptability of SR combined with IPV6's ample and
   flexible address space positions SRV6 as a viable data path
   technology for the next generation of mobile user plane, in
   particular the 3GPP N9 (UPF to UPF).

   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, sparing, rate
   limiting, and service chaining that are not natively available by
   GTP.

   The discussion then focuses on advanced routing with the
   Identifier/Locator paradigm and shows how SRV6 can be used to realise
   this model in the mobile back-haul in either an anchored or
   anchorless mode of operation.

   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.2 SRV6 as Drop-In Alternative for GTP-U

   Existing mobile back-haul employs GTP tunnels to carry user traffic



K. Bogineni            Expires September 6, 2018               [Page 15]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   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. 3GPP uses the term UPF to refer to the variety of
   functions performing different tasks on user traffic along the data
   path in 5G networks and suggests the use of GTP tunnels to carry user
   traffic between these UPFs (N9 interface).

   The Tunnel 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 user
   plane, SRV6 capable nodes use SIDs to direct user traffic between the
   UPFs.

   The simplest option is to encapsulate the entire GTP frame as a
   payload within SRV6. However, this scheme still carries the GTP
   header as the payload and as such doesn't offer significant
   advantage.

   A much more promising option however is to use SIDs to carry tunnel
   related information. 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.

   [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 data 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 data 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
   data plane where the UPFs can determine the TEID etc. by inverting
   the mapping.




K. Bogineni            Expires September 6, 2018               [Page 16]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   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-G). In this
   option, SID representing the GTP tunnel information acts as both
   start and end point of a segment within the UPF. This option
   resembles the MPLS label stacking mechanism which is widely used in
   different VPN scenarios.

   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.

                                  +-------+
                           +------+  SMF  +------+
                           |      +-------+      |
                           N4                    N4
                           |                     |
        +-------+      +---+---+             +---+---+      +-------+
        |  RAN  |--N3--|  UPF  |             |  UPF  |--N6--|  DN   |
        +-------+      +---+---+             +---+---+      +-------+
                           |       SRV6 N9       |
                           |   carries GTP info. |
                           +---------------------+

         Figure 8: SRV6 as Drop-In replacement for GTP-U in 5G

5.3 SRV6 as Drop-In GTP Replacement with TE

   The previous section discussed using SRV6 as a drop-in replacement
   for GTP tunnels in existing mobile networks. No new capabilities were
   introduced by this simple 1 to 1 replacement. We now explore
   additional possible features once SRV6 has been introduced.

   Traffic engineering is an integral 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.

   For loose paths to UPFs, a set of one or more SIDs in SRH's SID list
   identifies on or more, but not all the intermediate nodes to a
   particular UPF. Packets then follow the IGP shortest path through the
   network to each specified intermediate node till they reach the
   target UPF.




K. Bogineni            Expires September 6, 2018               [Page 17]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   In the case of strict path to UPFs, SRH contains a set of SIDs
   representing all the intermediate nodes and links that the packet
   must visit on its route to a particular UPF. The last SID in the set
   represents the target UPF itself or the last link to this UPF. Here,
   SRV6 packet processing at each node invokes the function(s) that is
   associated with SID[SL], the packet then receives the required
   treatment and gets forwarded over the SRH's specified path toward the
   target UPF.

   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 data 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 and SRV6
   traffic engineering capabilities, network programming concept, and a
   list of some of the main SR functions.

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

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

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

   [draft-gundavelli-dmm-mfa-00.txt]

5.4 UPF Chaining with SRV6

   Service or function chaining is another intrinsic feature of SR and
   its SRV6 derivative. Using this capability, operators can direct user
   traffic through a set of UPFs where each UPF performs a specific task
   or executes certain functions on the traffic.

   UPF chaining is achieved through the use of SIDs in SRV6 in the
   manner identical to what was described in the previous section
   regarding SRV6 support for traffic engineering.

   Generally speaking, 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, packets are then forwarded through the network in



K. Bogineni            Expires September 6, 2018               [Page 18]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   either loose or explicit mode toward each UPF.

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

5.5 SRV6 and Entropy

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

   SRV6 SIDs can easily accommodate entropy at either hop by hop or
   global level via reserving a set of bits in the SID construct itself;
   and hence, eliminate the need for a special entropy Segment ID in
   SRH. Here, the hashing algorithm at different nodes distribute
   traffic flows based on the SID which has been copied to IPV6 DA
   field.

   Alternatively, entropy related information can be encoded as optional
   TLV field in SRV6's SRH.

5.6 SRV6 and 5G Slicing

   Slicing is one of the main features in 5G [3GPP 23501]. 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's native features such as TE, Chaining,
   one-plus-one protection, etc. either in stand-alone or in conjunction
   with other alternatives for mobility support such as ID-LOC model
   lend themselves well to 5G slicing paradigm.


















K. Bogineni            Expires September 6, 2018               [Page 19]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


                               +--+       +--+
              +----------------+N1| . . . |Nn+----------------+
              |                ++-+       +-++                |
              |                 |           |                 |
          +---+---+             |           |             +---+---+
          | UPF-1 |      +------+           +------+      | UPF-2 |
          +---+---+      |                         |      +---+---+
                         |                         |
   Slice-A             |                         |
   --------------------|-------------------------|----------------------
   Slice-B             |                         |
            +----------+                         +----------+
              |                                               |
          +---+---+                                       +---+---+
          | UPF-1'|                                       | UPF-2'|
          +---+---+                                       +---+---+
              |                +--+       +--+                |
              +----------------+M1| . . . |Mn+----------------+
                               +--+       +--+

           Figure 9: SRV6 TE, Service Chaining, Sparing, and
                        Protection for 5G Slices

5.7 SRV6 and Lawful Interception in 5G

   To be filled.

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

5.8.1 SRV6 and Locator/ID Separation Paradigm for N9 Interface

   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 data plane
   connectivity.

5.8.2 Brief Overview of Locator-ID Separation

   Traditional routing architecture uses IP addresses as both device
   identity and its location in the network. Locator-ID Separation model
   establishes a paradigm in which a device identity and its network
   location are split into two separate namespaces: End-point
   Identifiers (EID), and Route Locators (RLOC) that are correlated via



K. Bogineni            Expires September 6, 2018               [Page 20]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   a control plane, or a dynamic (centralised or distributed) mapping
   system.

   RLOCs are tied to network topology. They represent network devices
   that are reachable via traditional routing. EIDs, on the other hand,
   represent mobile or stationary devices, functions, etc. that are
   reachable via different RLOCs based on the network location where
   they get instantiated, activated or moved.

   Using this model, as long as EID-RLOC relationship remains up to
   date, EIDs can easily move between the RLOCs. That is the EID
   namespace can freely move without any impact to the routing paths and
   connectivity between the Route Locators.

   This type of multi encapsulation and routing has been employed in
   fixed networks (IP, VPN, MPLS, etc.). The use of this paradigm in
   mobile data plane, therefore, offers an approach that takes advantage
   of a mature and proven technology to implement the N9 interface for
   UPF connectivity.

5.8.3 Locator-ID Separation via SRV6 for UPF connectivity

   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. Multiple UPFs are
   allowed to attach to the same Locator. It is also possible for a UPF
   to connect to multiple Locators. There are several implementation
   options. The followings highlights a few possibilities.

5.8.3.1 Overlay model with SRV6 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).

   In either case, the ingress SRV6 Locator uses the DA field in
   arriving packets to identify the far end Locator (Egress SRV6
   Locator) where the target UPF is attached and obtains its associated
   SID.

   For GTP encapsulated traffic from UPFs, the ingress SRV6 Locator must
   also deliver GTP information to the far end Locator. Please see
   section 5.2. for more information on different methods of conveying
   GTP information in SRV6 domains.

   The ingress SRV6 Locator then constructs the SRH and sends the



K. Bogineni            Expires September 6, 2018               [Page 21]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   traffic through the SRV6 network toward the egress SRV6 Locator.
   Egress Locator marks the end of the segment and ships the traffic to
   the target UPF.

   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. For inter UPF traffic that doesn't
   use GTP, the control plane requires some modifications in order to be
   able to convey endpoint information to interested parties.
                                 +----+----+
            +----------N4--------+   SMF   +--------N4--------+
            |                    +----+----+                  |
            |                                                 |
            |                                                 |
            |                    +----+----+                  |
            |                    |  ID-Loc |                  |
            |             +----->| Mapping |<----+            |
            |             |      +----+----+     |            |
            |             V                      V            |
        +---+---+    +----+----+            +----+----+   +---+---+
   --N3-+ UPF-A +----+  RLOC-A +<---SRV6--->+  RLOC-B +---+ UPF-B +-N6--
        +---+---+    +----+----+            +----+----+   +---+---+
            <----------------------N9-GTP----------------------->

            Figure 10: Overlay Model with SRV6 Locator in 5G

5.8.3.2 SRV6 Capable UPFs and RLOCs

   In this model, the head end UPF (Ingress UPF) is the ingress node and
   the entity that constructs the SRH in the SRV6 domain. Here, both
   UPFs (IDs) and Locators are represented by SIDs in the SRH. The SID
   list establishes either a partial or the full path to a target or a
   set of UPFs that traffic is required to traverse.

   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.

   In its simplest form, the SMF using policy information prepares a set
   of one or more UPFs along the traffic path and distributes this set
   in the form a SID list to the ingress UPF. This SID list of UPFs is
   then gets augmented with a set of SIDs identifying the Locators
   representing the current point of attachment for each UPF along the
   data path.

   Alternatively, 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



K. Bogineni            Expires September 6, 2018               [Page 22]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   relationship.

   In yet another approach, the SMF can provide a partial SID list
   representing the segment between each pair of UPFs to individual UPFs
   along the path.

   Regardless of the approach, any changes to UPF's point of attachment
   must be reflected in the mapping system and communicated to the SMF
   for distribution to the appropriate set of UPFs. Keeping the mapping
   system current is essential to proper operation. As long as the
   mapping database is up-to-date, UPFs can be easily moved in the
   network. Design of ID-Locator mapping system is beyond the scope of
   this document. However, experiment with distributed mapping systems
   offered by today's public clouds has shown very promising results
   which can be further improved and tailored to mobile network
   requirements.

   The following figure shows the use of SRV6 UPFs and RLOCs in 5G.

                                                          +----+----+
                                                          |  ID-Loc |
                                                   +----->+ Mapping |
                                 +----+----+       |      |         |
                                 +         +<------+      +----+----+
                                 |   SMF   |
            +----------N4--------+         +--------N4--------+
            |                    +----+----+                  |
     SID-UA |            SID-RA              SID-RB           | SID-UB
        +---+---+     +----+----+         +----+----+     +---+---+
   --N3-+ UPF-A +-----+  RLOC-A +---------+  RLOC-B +-----+ UPF-B +-N6--
        +---+---+     +----+----+         +----+----+     +---+---+
            <---------------------N9-SRV6--------------------->

            Figure 11: SRV6 Capable UPFs and Locators in 5G

5.8.4 Advanced Features in ID-Locator Architecture

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

5.9 Areas of Concern

   Support for IPV6 is a precondition for SRV6. Although SRV6 can
   support hybrid IPV4/IPV6 mobile data 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



K. Bogineni            Expires September 6, 2018               [Page 23]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   impact on MTU. Large SRH size can also exert undesirable header tax
   especially in the case of small payload size. Furthermore, compound
   SID processing at each node might affect line rate.

   ID-LOC architecture relies on high performance mapping systems.
   Distributed mapping systems using some form Distributed Hash
   Table(DHT) exhibit very promising results. But further investigation
   is required to ensure mobility requirements in mobile data plane.

6  LISP based Solution

         +------------------------------------------------------+
         |                         SMF                          |
         +-+-----------+- - - - - - - - - - - - - +---+-------+-+
           |           |      Mapping System      |   |       |
           |           +--+----+---------------+--+   |       |
           N4             |    |               |      N4      N4
           |              |  LISP-CP           |      |       |
           |              |    |               |      |       |
        +--+---+          |    | +------+      |      |   +---+--+
        | UPF  |          |    | | UPF  +-------------+   | UPF  |
   --N3-+------+          |    | +------+      |          +------+-N6--
        | XTR  +--LISP-CP-+    +-+ XTR  |      +--LISP-CP-+ XTR  |
        +--+-+-+                 +-+--+-+                 +-+-+--+
           | |                     |  |                     | |
           | +-------LISP-DP-------+  +--------LISP-DP------+ |
           |                                                  |
           +----------------------LISP-DP---------------------+

                 Figure 12: LISP in the 5G architecture

6.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],
   [RFC.8111]. 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



K. Bogineni            Expires September 6, 2018               [Page 24]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   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.

6.2 LISP Data-Plane

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

6.3 LISP Control-Plane

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

   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.

6.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.ietf-
   farinacci-lisp-mobile-network].




K. Bogineni            Expires September 6, 2018               [Page 25]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


6.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.ietf-
   farinacci-lisp-mobile-network].

6.6 LISP Control-Plane with ILA Data-Plane

   In the LISP WG re-charter of 2016, consensus was reached to separate
   the data-plane and control-plane aspects of the protocol. 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. In this section we describe how LISP-CP can
   serve to enable the operation of an ILA data-plane. A similar
   approach can be followed to use LISP-CP as control-plane for other
   data-plane protocols (e.g. VXLAN, SRv6, etc).

         +------------------------------------------------------+
         |                         SMF                          |
         +-+-----------+- - - - - - - - - - - - - +---+-------+-+
           |           |      Mapping System      |   |       |
           |           +--+----+---------------+--+   |       |
           N4             |    |               |      N4      N4
           |              |  LISP-CP           |      |       |
           |              |    |               |      |       |
        +--+---+          |    | +------+      |      |   +---+--+
        | UPF  |          |    | | UPF  +-------------+   | UPF  |
   --N3-+------+          |    | +------+      |          +------+-N6--
        | XTR  +--LISP-CP-+    +-+ XTR  |      +--LISP-CP-+ XTR  |
        +--+-+-+                 +-+--+-+                 +-+-+--+
           | |                     |  |                     | |
           | +---------ILA---------+  +----------ILA--------+ |
           |                                                  |
           +------------------------ILA-----------------------+

            Figure 13: LISP-CP + ILA in the 5G architecture

   Please refer to Section 8 for description of the ILA data-plane. 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].
   Below are summarized the major points to take into account when
   running LISP-CP as control-plane for ILA.
      o Leveraging on the flexible LISP-CP address encoding defined in
        [RFC8060], different ILA address types are defined in [I-
        D.rodrigueznatal-ila-lisp] to carry ILA metadata over the LISP-
        CP.




K. Bogineni            Expires September 6, 2018               [Page 26]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


      o XTRs can serve as both ILA-Ns (when their map-cache is
        incomplete) or ILA-Rs (when their map-cache is complete). XTRs
        serving as ILA-Rs subscribe to the Mapping System to populate
        their map-cache with all the mappings in the domain (or its
        shard) using [I-D.rodrigueznatal-lisp-pubsub].

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

      o The ILA control-plane operations "request/response" and "push"
        are implemented via the LISP mechanisms defined in [I-D.ietf-
        lisp-rfc6833bis] and [I-D.rodrigueznatal-lisp-pubsub]
        respectively. When the Mapping System is co-located with the
        XTRs serving as ILA-Rs, the ILA "redirect" operation is
        implemented via the mapping notifications described in [I-
        D.rodrigueznatal-lisp-pubsub].

      o XTRs serving as ILA-Ns can use LISP-CP as described in [I-
        D.ietf-lisp-rfc6833bis] to register and keep updated in the
        Mapping System the information regarding their local mappings.

      o When using ILA as data-plane, the mobility features and benefits
        discussed in Section 8 and in [I-D.ietf-lisp-eid-mobility] still
        apply.

      o As discussed in [I-D.rodrigueznatal-ila-lisp], the LISP-CP can
        be used not only to resolve ID-Loc mappings but also to obtain
        the ILA Identifier when it is not possible to locally derivate
        it from the endpoint address. These two mapping operations can
        be combined into one to obtain the ILA Identifier and associated
        locators in a single round of signaling.

7  ILNP Based Solution

   <Text to be Included>.

8  ILA based Solution

   Identifier-Locator Addressing [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.



K. Bogineni            Expires September 6, 2018               [Page 27]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


8.1 Overview of ILA


   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 data plane and control plane. The data 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 data plane

      o Allows strong privacy in addressing [ADDRPRIV]

      o Promotes anchorless mobility

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

      o Flexible control plane that splits data & control

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



K. Bogineni            Expires September 6, 2018               [Page 28]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

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

   The ILA data plane protocol is described in [ILA], motivation and
   problems areas are described in [ILAMOTIVE], ILA in the mobile user-
   plane is described in detail in [ILAMOBILE].

8.2 ILA in the 5G architecture

   ILA is a proposed alternative to GTP-U and encapsulation. It does not
   require anchors and simplifies both the data plane and control plane.
   ILA is a general network overlay protocol can be used to meet the
   requirements of use cases in a converged network. User Plane
   Functions (UPF) with ILA are lightweight and stateless such that they
   can be brought up quickly as needed.

   Figures 13 and 14 depict two architectural options for the use of ILA
   in a 5G architecture. ILA is logically a network function and ILA
   interfaces to the 5G control plane via service based interfaces. In
   this architecture, ILA replaces GTP use over the N9 interface.
   Identifier address to locator address transformations in the downlink
   from the data network are done by an ILA-R. Transformations for intra
   domain traffic can be done by an ILA-N close to the gNB or by an ILA-
   R in the case of a cache miss. Locator address to identifier address
   transformation happen at ILA-Ns. ILA could be supported on a gNB. In
   this case, an ILA-N would be co- resident at a gNB and ILA is used
   over N3 interface in lieu GTP-U. Figures 14 and 15 depict two options
   of how ILA can be used in the 5G architecture. The control plane
   functions can be implemented as standalone network functions or can
   be implemented with other network functions. The control plane
   protocol can be implemented as enhancement to N4, as APIs or as
   independent protocol. Use of ILA in roaming scenarios is still TBD.

















K. Bogineni            Expires September 6, 2018               [Page 29]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   Service Based Interfaces
      ----+-----+-----+----+----+----+----+--------+-----+--------
          |     |     |    |    |    |    |        |     |
      +---+---+ |  +--+--+ | +--+--+ | +--+--+  +--+--+  |
      | NSSF  | |  | NRF | | | DSF | | | UDM |  | NEF |  |
      +-------+ |  +-----+ | +-----+ | +-----+  +-----+  |
                |          |         |                   |
            +---+----+  +--+--+  +---+--+  +-------------+--+
            |  AMF   |  | PCF |  | AUSF |  |     ILA-M      |
            +---+--+-+  +-----+  +------+  +-+-----------+--+
     +-------+  |  |                         |           |
     | 5G UE |--+  |                         |           |
     +---+---+     | N2                +-----+----+  +---+---+    +----+
         |         |      +------------|  ILA-N   |--| ILA-R |----| DN |
         |         |      |    N3      +-+---+--+-+  +-+-----+    +----+
         |         |      |                |   |  |      |
         |     +---+------+-+              +---+  +------+
         +-----|    gNB     |               N9       N9
               +------------+

              Figure 14: ILA in 5G architecture - Option 1

   Service Based Interfaces
      ----+-----+-----+----+----+----+------+----+----+----+--------+--
          |     |     |    |    |    |      |    |    |    |        |
      +---+---+ |  +--+--+ | +--+--+ |      |    |    | +--+--+  +--+--+
      | NSSF  | |  | NRF | | | DSF | |      |    |    | | UDM |  | NEF |
      +-------+ |  +-----+ | +-----+ |      |    |    | +-----+  +-----+
                |          |         |      |    |    |
            +---+----+  +--+--+  +---+--+   | +--+--+ |
            |  AMF   |  | PCF |  | AUSF |   | |ILA-M| |
            +---+--+-+  +-----+  +------+   | +--+--+ |
     +-------+  |  |                        |         |
     | 5G UE |--+  |                        |         |
     +---+---+     | N2                +----+--+  +---+---+      +----+
         |         |      +------------| ILA-N |--| ILA-R |------| DN |
         |         |      |    N3      ++--+-+-+  +-+-----+      +----+
         |         |      |             |  | |      |
         |     +---+------+-+           +--+ +------+
         +-----|    gNB     |            N9     N9
               +------------+

              Figure 15: ILA in 5G architecture - Option 2








K. Bogineni            Expires September 6, 2018               [Page 30]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


                        Service Based Interfaces
    ---------+-------+------------------+----------------------
             |       |                  |
          +--+--+ +--+--+           +---+---+
          | AMF | | SMF |           | ILA-M |
          +--+-++ +--+--+           +---+---+
             N1|                        |
   +-------+ | |          +-------------+----+
   | 5G UE |-+ |          |                  |
   +---+---+   N2     +---+---+    +----+    +-----------+
       |       |   +--| ILAN/R|----| DN |    |           |
       |       |   |  +-------+    +----+    |           |
       |     +-+---+-+                    +--+--+     +--+--+  +----+
       +-----|  gNB  |--------------------|ILAN |--N9-|ILAR |--| DN |
             +-------+                    +-----+     +-----+  +----+

Figure 16: Non-roaming ILA-based architecture for multiple PDU Sessions

                        Service Based Interfaces
    ---------+----------+------------+-----------
              |         |            |
          +--+---+   +--+--+     +---+---+
          | AMF  |   | SMF |     | ILA-M |
          +--+-+-+   +--+--+     +---+---+
            N1 |                     |
   +-------+ | |              +------+-------+
   | 5G UE |-+ |              |              |
   +---+---+   N2             |              |
       |     +-+---+      +---+---+       +--+--+    +----+
       +-----| gNB |------| ILAN/R|---N9--| ILAR|----| DN |
             +-----+      +---+---+       +-----+    +----+
                              |
                           +--+--+
                           |  DN |
                           +-----+

 Figure 17: Non-roaming 5G ILA-based System architecture for concurrent
          access to two (e.g. local and central) data networks
                      (single PDU Session option)

8.3 Protocol layering

   Figure 3 illustrates the protocol layers of packets packets sent over
   various data 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.





K. Bogineni            Expires September 6, 2018               [Page 31]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


                    --->             --->            --->
       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 18: ILA and protocol layer in 5G

8.4 Control plane

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

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

   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.

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




K. Bogineni            Expires September 6, 2018               [Page 32]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   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
   [ILAMP]. ILA separates the control plane from the data plane, so
   alternative control plane protocols may be used with a common data
   plane [ILABGP],[ILALISP].

   The ILA Mapping Protocol [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.

8.5 IP addressing

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

8.5.1 Singleton address assignment

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

8.5.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:







K. Bogineni            Expires September 6, 2018               [Page 33]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

   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.

8.5.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. [ADDPRIV] describes this problem and suggests some
   solutions that may be used with ILA.

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




K. Bogineni            Expires September 6, 2018               [Page 34]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

8.8 ILA and network slices

   Figure 19 illustrates the use of network slices with ILA.

       ----+--------------------------------+--------------------
           |                                |
      +----------------------+ +------------------------+
      | +-------+   Slice #1 | | +-----------+ Slice #2 |
      | | SMF   |----+   GTP | | |  ILA-M    |---+  ILA |
      | +--+----+    |       | | +---------+-+   |      |
      | N4 |         | N4    | |     |     |     |      |
      | +--+--+   +--+----+  | | +-------+ |  +--+----+ |   +----+
      | | UPF |   | UPF   |  | | | ILA-N | |  | ILA-R | |---| DN |
      | +-----+   +-------+  | | +-------+ |  +-------+ |   +----+
      +------------ ---------+ +-----------|------------+
                         |                 |
                      +--+-+  +------------|-------------+
                      | DN |  |            |    Slice #3 |
                      +----+  |     +------+----+    ILA |
                              |     |           |        |
                              | +-------+     +-------+  |   +----+
                     +-----+  | | ILA-N |     | ILA-R |  |---| DN |
                     | MEC |--| +-------+     +-------+  |   +----+
                     +-----+  +--------------------------+

                Figure 19: ILA and network slices in 5G

   In this figure, slice #1 illustrates legacy use of UPFs without ILA
   in a slice. ILA can be deployed incrementally or in parts of the
   network. As demonstrated, the use of network slices can provide
   domain isolation for this.

   Slice #2 supports ILA. 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



K. Bogineni            Expires September 6, 2018               [Page 35]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   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.

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

   Privacy in addressing is a consideration. ILA endeavors to provide a
   mechanism of address assignment that prevents inference of user
   identity or location. This problem is described in [ADDRPRIV].

9  No Protocol Option

   In this option, mobility is handled nomadically by the app.

10 Comparison of Protocols

   This section will compare the different protocols with reference to
   how they will support the requirements for UPF and N9 interface; how
   the various scenarios identified in Sections 3 and 4 will be
   supported and impacts to other interfaces and functions of the
   architecture (e.g. N3, N4, SMF, AMF, etc).

11 Summary

   This document summarized the various IETF protocol options for GTP
   replacement on N9 interface of 3GPP 5G architecture.



K. Bogineni            Expires September 6, 2018               [Page 36]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


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

   <Define your formal syntax here.>
13 Security Considerations

   <Add any security considerations>

14 IANA Considerations

   <Add any IANA considerations>

15 References

15.1 Normative References

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

15.2 Informative References

   [ILA]     Herbert, T., and Lapukhov, P., "Identifier Locator
             Addressing for IPv6" draft-herbert-intarea-ila-00

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

   [29891]   5G System - Phase 1, CT WG4 Aspects, 3GPP TR 29891 v15.0.0,
             December 2017

   [29244]   Interface between the Control Plane and the User Plane
             Nodes; Stage 3, 3GPP TS 29.244 v15.0.0, December 2017

   [29281]   GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS
             29.281 v15.1.0, December 2017

   [23501]   System Architecture for 5G System; Stage 2, 3GPP TS 23.501
             v2.0.1, December 2017

   [23502]   Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.0,
             December 2017

   [23503]   Policy and Charging Control System for 5G Framework; Stage
             2, 3GPP TS 23.503 v1.0.0, December 2017

   [38300]   NR and NG-RAN Overall Description: Stage 2, 3GPP TS 38.300
             v2.0.0, December 2017




K. Bogineni            Expires September 6, 2018               [Page 37]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   [38401]   NG-RAN: Architecture Description, 3GPP TS 38.401 v1.0.0,
             December 2017

   [CT4SID] Study on User Plane Protocol in 5GC, 3GPP CP-173037,
             December 2017

   [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
             (IPv6) Addressing Architecture", RFC 3513, DOI
             10.17487/RFC3513, April 2003, <https://www.rfc-
             editor.org/info/rfc3513>.

   [RFC4941] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
             RFC 4641, DOI 10.17487/RFC4641, September 2006,
             https://www.rfc-editor.org/info/rfc4641

   [ILAGRPS] Herbert, T., "Identifier Groups in ILA", To be published

   [BGPILA]  Lapukhov, P., "Use of BGP for dissemination of ILA mapping
             information" draft-lapukhov-bgp-ila-afi-02

   [3GPPTS]  3rd Generation Partnership Project (3GPP), "3GPP TS
             23.502", http://www.3gpp.org/DynaReport/23-series.htm

Acknowledgments

   The author 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, and
   Cameron Byrne for reviewing various iterations of the document and
   for providing content into various sections.


   Authors' Addresses

   K. Bogineni Verizon

   Email: kalyani.bogineni@verizon.com

   A, Akhavain Huawei Technologies Canada

   Email: arashmid.akhavain@huawei.com

   T. Herbert Quantonium         Email: tom@quantonium.net

   D. Farinacci lispers.net      Email: farinacci@gmail.com


   A. Rodriguez-Natal Cisco



K. Bogineni            Expires September 6, 2018               [Page 38]


INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018


   Email: natal@cisco.com


















































K. Bogineni            Expires September 6, 2018               [Page 39]


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