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

Versions: 00 01 02 03

INTERNET-DRAFT                                                J. Mueller
Intended Status: Informational                              AT&T Foundry
Expires: January 7, 2017                                      T. Herbert
                                                                Facebook
                                                         October 3, 2016


Mobility Management for 5G Network Architectures Using Identifier-locator Addressing
                     draft-mueller-ila-mobility-01


Abstract

   This specification describes Mobility Management Architecture for 5G
   Networks Using Identifier-Locator Addressing in IPv6 for virtualized
   mobile telecommunication networks. Identifier-locator addressing
   differentiates between location and identity of a network node. The
   approach presented in this draft enables mobility management on Layer
   3, and provides a simplified and more efficient architecture with
   less core network utilization compared to traditional architecture.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Mueller, Herbert        Expires January 7. 2017                 [Page 1]


INTERNET DRAFT        <draft-mueller-ila-mobility>


   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  . . . . . . . . . . . . . .  3
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Related Work, Protocols and Concepts  . . . . . . . . . . . . .  5
     2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2. Proxy Mobile IPv6 (PMIPv6)  . . . . . . . . . . . . . . . .  5
     2.3. Host Identity Protocol (HIP)  . . . . . . . . . . . . . . .  6
     2.4. Locator/ID Separation Protocol (LISP) . . . . . . . . . . .  6
     2.5. Identifier-Locator Addressing (ILA) . . . . . . . . . . . .  6
     2.6. Comparison of ILA to alternative approaches . . . . . . . .  6
       2.6.1. Identifier Locator Network Protocol (ILNP)  . . . . . .  6
       2.6.2. Locator Identifier Separation Protocol  . . . . . . . .  7
   3. Mobility Management Architectures for 5G Networks Using ILA . .  8
     3.2. Architecture with Functional Elements and Reference
          Points  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.3. Functional Elements . . . . . . . . . . . . . . . . . . . . 10
     3.4. Signaling and Data Flow . . . . . . . . . . . . . . . . . . 12
       3.5.1. Provisioning  . . . . . . . . . . . . . . . . . . . . . 12
       3.5.2. Attachment  . . . . . . . . . . . . . . . . . . . . . . 12
       3.5.3. Five Communication Scenarios for an End-to-End Data
              Transport Session . . . . . . . . . . . . . . . . . . . 13
       3.5.4. Homogeneous Handover  . . . . . . . . . . . . . . . . . 17
       3.5.5. Heterogeneous Handover  . . . . . . . . . . . . . . . . 18
       3.5.6. Detachment  . . . . . . . . . . . . . . . . . . . . . . 19
       3.5.6. Idle-mode and paging  . . . . . . . . . . . . . . . . . 19
   4. Discussion, Evaluation and Summary  . . . . . . . . . . . . . . 19
   5. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     5.1. Normative References  . . . . . . . . . . . . . . . . . . . 20
     5.2. Informative References  . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21








Mueller, Herbert        Expires January 7. 2017                 [Page 2]


INTERNET DRAFT        <draft-mueller-ila-mobility>


1. Introduction and Problem Statement

   The Internet Protocol (IP) has been overloaded in its functionality
   in the sense that it has been used as a service locator and service
   identifier at the same time. Since changes of the associated IP
   address in a connection-oriented TCP session causes a service
   interruption, mobility has become a challenge. Mobility has been a
   challenge for IP based network since the area of smart phones began
   and has been addressed with Layer 2 and Layer 3 tunneling. One big
   challenge of mobility is to ensure seamless and transparent mobility
   for mobile devices among different locations and in between several
   Radio Access Technologies. Due to the deployment of micro-service
   architectures, another dimension in the complexity of mobility
   occurs, in which single IP addressable tasks might change their
   physical location within a (virtualized) data center architecture,
   too. Therefore mobility on both ends of the End-to-End (E2E)
   connections can be observed, which requires an large number of
   service registry (e.g. DNS) updates and the state synchronization
   between registries eventually located in different (geographical)
   locations. In regards of current research and development on Mobile
   Edge Cloud and 5G, key requirements such as high availability, low
   delay and ultra high bandwidth are required to ensure the
   reachability of the massive amount of communicating instances ranging
   from cellular's, high-definition multimedia streaming, Internet-of-
   Things (IoT), critical infrastructures among others.

   This specification describes a mobility management architecture for
   5G Networks using Identifier-Locator Addressing (ILA) ([nvo3]) in
   IPv6 for (virtualized) mobile telecommunication networks. The ILA
   concept used in this specification extends the Identifier-Locator
   Network Protocol (ILNP) ([RFC6740], [RFC6741]) defines a protocol and
   operations model for identifier-locator addressing in IPv6. The key
   advantages of the presented ILA mobility solution are:
      1) Backwards-compatibility within existing IPv6 network
        architectures such as the AT&T network,
      2) Enablement of very low-delay Mobile-Edge-Cloud (MEC) services,
      3) Tunnel-less and flatter architecture with less protocol
        overhead and less hops between,
      4) Proven applicability of ILA within the Facebook data centers
        and related networks.

1.1. Terminology

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




Mueller, Herbert        Expires January 7. 2017                 [Page 3]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        The following terminology will be referred to in the document.

   * SIR: As defined in ([nvo3ila]): "In order to maintain compatibility
     with existing networking stacks and applications, identifiers are
     encoded in IPv6 addresses using a standard identifier
     representation (SIR) address. A SIR address is a combination of a
     prefix which occupies what would be the locator portion of an ILA
     address, and the identifier in its usual location."


   * ILA ID or only ID: Unique identifier in ILA terms that is used for
     public routing and addressability. This ID can be generated on a
     per session basis with the effect, to secure the privacy of the end
     point. The International Mobile Subscriber Identity (IMSI) can be
     used for ID generation. The ID is comparable with the Globally
     Unique Temporary UE Identity (GUTI) in the mobile space.


   * ILA Locator (LOC): Either an International Mobile Equipment
     Identity (IMEI) or an IP address that has been assigned to a single
     UE. The locator is represented in the prefix of the SIR address.


   * ILA host: An end host that is capable of performing ILA
     translations for both sending and receiving. An ILA host uses the
     ILA resolver protocol to get identifier to locator mappings for
     destinations in communication.


   * ILA router: A network device that performs ILA translations. ILA
     routers participate in distribution protocol mapping and consists
     of the two functions: Network Virtualization Edge (NVE) and Network
     Virtualization Authority (NVA).


   * User Equipment (UE): A device with an identifier such as a mobile
     phone, IoT gateway or another SIM equipped mobile device.


   * Access Point (AP) and Base Station (BS): A network element such as
     evolved-NodeB (eNB) in 4G.


   * Gateway (GW): A network element such as Serving-Gateway (SWG) or
     Packet-Data-Network-Gateway (PGW) in 4G.


   * Application Function (AF): refers to the 3GPP terminology and



Mueller, Herbert        Expires January 7. 2017                 [Page 4]


INTERNET DRAFT        <draft-mueller-ila-mobility>


     stands for any IP addressable endpoint such as service or task.



2. Related Work, Protocols and Concepts This section provides an
     overview on the state-of-the-art on related Work, protocols and
     concepts for mobility management on mobile networks. In particular
     the 4th Generation (4G) of mobile telecommunication networks has
     been taken into comparison for this draft for functional and
     conceptual comparison.


2.1. Mobile IPv6 The IETF specified Mobile IPv6 ([MIPv6]) to ensure
     connectivity and reachability in case of client mobility within an
     IPv6 network. Mobility is solved by assigning an additional IPv6
     address - the Care-of-Address (CoA) - next to the current IPv6
     address that as been assigned in the home network. Therefore a UE
     is equipped with a home address together with a primary CoA in case
     of foreign network attachment. IPv6 is classified as host-based
     mobility protocol, due to the fact, that the UE is in charge of
     announcing its mobility to the network. In particular it is the
     client's responsibility for sending binding updates to the Home
     Agent (HA). In order to ensure reachability, the UE communicates
     its new assigned CoA(s) to the HA, which acts as a router and
     registrar for UEs. Connection requests are intercepted and re-
     routed in case CoA entries for a UE exists. A tunnel is established
     between the UE at the CoA and the HA for securely exchanging
     packets. Per default, the first packet is routed from the
     correspondent UE towards the CoA of the UE via the HA. This route
     is not always the shortest path. All consecutive packets of the
     same data stream will follow on the same path, which might include
     a detour, but hides the new location of the UE for privacy reasons.
     The feature of route optimization allows the UE to directly contact
     the correspondent UE, therefore cuts out the HA from the
     communication path and forwards packets on a shorter route.
     Security of the Mobile IPv6 is enhanced through IPSec for binding
     updates to avoid spoofing of CoA for a UE.


2.2. Proxy Mobile IPv6 (PMIPv6) The IETF specified PMIPv6 ([PMIPv6])
     provides network-based mobility management for UEs and extends the
     Mobile IPv6 in the way, that host-based mobility management
     functionalities in Mobile IPv6 are excluded from the client into
     the network in Proxy Mobile IPv6. The Local Mobility Anchor (LMA)
     acts as topological anchor point and manages the UE's binding
     state. The Mobile Access Gateway (MAG) manages the mobility-related
     signaling on behalf of the UE at the access router. It is
     responsible for tracking the UE's movements to and from the access



Mueller, Herbert        Expires January 7. 2017                 [Page 5]


INTERNET DRAFT        <draft-mueller-ila-mobility>


     link for signaling the UE's local mobility anchor.


2.3. Host Identity Protocol (HIP) HIP ([hip]) is provisioning a secure
     solution for identifier/locator-split by adding a new host identity
     layer into protocol stack. A cryptographic namespace build upon a
     host identity as public key allows scalability and multi-homing
     within the network. An extensions of DNS supports rendezvous server
     functionality for secure host identity lookup. A secure channel is
     establishment over Diffie-Hellmann-key exchange between two
     communicating entities. The communication setup is considered as
     robust against DOS, due to a riddle solved at the requestor side.
     On the other side a high overhead for the secure communication
     establishment due to key exchange has to be taken into
     consideration. HIP requires an additional protocol layer between L2
     and L3 for encapsulation.



2.4. Locator/ID Separation Protocol (LISP) LISP is a network-layer-based
     protocol that enables separation of IP addresses into two new
     numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators
     (RLOCs). Tunnel router encapsulates and encapsulates packets.


2.5. Identifier-Locator Addressing (ILA) ILA is outlined in detail in
     ([nvo3]), ([nvo3ila]) as well as in this document. In a nutshell,
     the concept of ILA splits IPv6 addresses into a locator and an
     identifier, eliminates the need for tunneling and therefore reduces
     the header size. Network Virtualization Edges (NVE) creates and
     maintains local state about each Virtual Network for which it is
     providing service on behalf of a tenant system.


2.6. Comparison of ILA to alternative approaches This section compares
     the ILA approach to some alternatives that have been discussed in
     5gangip list.


2.6.1. Identifier Locator Network Protocol (ILNP) ILNP ([rfc6741]) is an
     experimental protocol that splits and IPv6 address into a locator
     and identifier. ILA is fundamentally based on ILNP.

     The key differences between ILA and ILNP are:

      * ILNP requires changes to the transport layer. This limits ILNP
        to be used only on hosts and every transport protocol
        implementation would need to be modified to use ILNP. Presumably



Mueller, Herbert        Expires January 7. 2017                 [Page 6]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        to overcome the limitation above, some sort of ILNP proxy could
        be defined to perform ILNP in a middlebox.

      * ILA does not require changes to the transport layer.

      * Checksum neutral translation means that transport layer does not
        need to be parsed to perform ILA. This also ensures that
        existing device offloads (like checksum offload) work
        seamlessly.

      * ILNP employs IPv6 extension headers which are mostly considered
        non-deployable. ILA does not use these.

      * Core support for ILA is in upstream Linux, to date there is no
        publicly available source code for ILNP.

      * ILNP involves DNS to distribute mapping information, ILA assumes
        mapping information is not part of naming.

2.6.2. Locator Identifier Separation Protocol

   Locator Identifier Separation Protocol (LISP ([rfc6830)) is an IP
   encapsulation protocol where the destination address in the outer IP
   header is a locator and the destination address in the inner header
   is an identifier.

   The key differences between ILA and LISP are:

      * ILA is not encapsulation so there is not associate encapsulation
        overhead. For instance IPv6/IPv6 in LISP would have 52 bytes of
        overhead whereas ILA translation has zero.

      * LISP may not work with some network device offloads whereas ILA
        works with all stateless offloads (ILA is transparent to the
        network so that it would just see TCP/IP packets for instance).

      * ILA has been accepted into Linux, LISP has not been accepted.

      * ILA can run either on end hosts (ILA hosts) or in the network
        (ILA routers). In ILA hosts the mapping database is a cache to
        optimize communications.

      * ILA defines locators and identifiers to be 64 bits whereas LISP
        allows them to be full 128 bit address making for for memory
        needed in mapping table.

      * ILA is not encapsulation so there is not associate encapsulation
        overhead. For instance IPv6/IPv6 in LISP would have fifty-six



Mueller, Herbert        Expires January 7. 2017                 [Page 7]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        bytes of overhead whereas ILA translation has zero.

      * The process of ILA translation is much more efficient than
        performing LISP. The translation path is:

        1) Parse IP header and extract the destination address

        2) Lookup destination in a hash table (obviated with cached
           route for ILA hosts)

        3) Write new destination address (16 byte copy)

        4) Forward to new destination (or receive at final destination).

        LISP processing is more involved. To do encapsulation, 1) outer
        IP header, 2) UDP header and 3) LISP header need to be inserted.
        Tunnel fragmentation and MTU need to be considered [RFCXXXX]
        (i.e. increasing the size of a packet may exceed tunnel MTU). At
        the remote tunnel end point, the outer IP header must be
        validated and a lookup done on the destination address to see if
        it is a local address. A lookup must be done on the destination
        UDP port to find that it is a LISP port. If the UDP checksum is
        not zero that must also be validated. The LISP header must also
        be processed. Once the encapsulation is verified, the headers
        are removed and the inner packet is either forwarded or
        received.





3. Mobility Management Architectures for 5G Networks Using ILA This
        section outlines the ILA protocol structure and architecture
        supporting ILA in mobile networks. The main functional blocks
        for connectivity, mobility support, security and charging are
        presented. Message flows for basic use cases executed by the
        mobile UE such as attachment, data transport with session
        handover and detachment are outlined.


        3.1. Address format for ILA mobile

        The address format is derived out of the ILA draft in ([nvo3])
        and is used without modifications.

        The IPv6 canonical address format is:

                +-----------------------------+-------------------------+



Mueller, Herbert        Expires January 7. 2017                 [Page 8]


INTERNET DRAFT        <draft-mueller-ila-mobility>


                |           64 bits           |           64 bits       |
                +-----------------------------+-------------------------+
                | IPv6 Unicast Routing Prefix |  Interface Identifier   |
                +-----------------------------+-------------------------+

        The address format using ILA is:

                +--------------------------------------------------------+
                |            64 bits         |3 bits|1|    60 bits       |
                +-----------------------------+--------------------------+
                |          Locator           | Type |C|    Identifier    |
                +--------------------------------------------------------+

        The C bit is used to indicate that checksum-neutral mapping has
        been performed ([nvo3]).

3.2. Architecture with Functional Elements and Reference Points

        The presented architecture in Fig 1 is aligned on the 3GPP
        Evolved Packet System (EPS) ([23401], [23402]) following the
        separation of control plane and data plane. Whereas 3GPP EPS
        addresses mobility through Layer 2 tunneling with GTP, this
        approach provides a Layer 3 mobility approach utilizing the ILA
        concepts for mobility.




                 +--------------------+ +--------------------+
                 |    Access Network  | |  Policy Charging   |
          +------+    Discovery and   | | and Rules Function |
          |      | Selection Function | |                    |
          |      +------------+-------+ +---------+--------+-+
          |                   |                   |        |
          |                   |                   |        |
          |            +------+-----+   +---------+--+     |
          |            |  Mobility  |   |    Home    |     |
          |            | Management +---+ Subscriber |     |
          |            |   Entity   |   |   Server   |     |
          |            +---------+--+   +------------+     |
          |                 |       |                      |
          |          +------+       +------+               |
          |          |                     |               |
        +-+--+    +--+-----------+    +----+----+    +-----+------+
        | UE |----| Base Station |----| Gateway |----| IP Service |
        +----+    +--------------+    +---------+    +------------+

                Fig 1: ILA-Based Architecture for Improved Mobility



Mueller, Herbert        Expires January 7. 2017                 [Page 9]


INTERNET DRAFT        <draft-mueller-ila-mobility>


            +--------+                                             +--------+
            | Tenant +--+                                     +----| Tenant |
            | System |  |                                    (')   | System |
            +--------+  |          ................         (   )  +--------+
                        |  +-+--+  .              .  +--+-+  (_)
                        |  | NVE|--.              .--| NVE|   |
                        +--|    |  .              .  |    |---+
                           +-+--+  .              .  +--+-+
                           /       .              .
                          /        . Ipv6 Overlay .   +--+-++--------+
            +--------+   /         .    Network   .   | NVE|| Tenant |
            | Tenant +--+          .              .- -|    || System |
            | System |             .              .   +--+-++--------+
            +--------+             ................

                Fig 2: Distributed ILA Network Architecture [nvo3ila]

3.3. Functional Elements

        This subsection summarizes the key functional elements of the
        ILA Mobility architecture.

        * The User Equipment (UE) is the SIM enabled mobile device
        (cellular, gateway, etc.) executing services such as apps on the
        device, binding apps to the ID as communication endpoints,
        handling the bindings of all associated LOC/ID's and performing
        mobility as described below. The UE performs security related
        functions via its (embedded) SIM handing at least one or
        multiple identifiers provisioned by one or multiple network
        operators. Security related functions include authentication of
        the UE towards the network (more specifically the BS) and
        certificate management for establishing secure transport
        connections. Either the UE supports IPv6 or ILA for handling
        locator and ID bindings and updates or the network is handling
        ILA functionality on behalf of the UE. Storage and management of
        multiple locators for multi-path and multi-homing is supported
        by the UE support.


        * The Base Station (BS) or Access Point (AP) is the first point
        of contact from the UE when attaching over radio to the network.
        Its main purpose is routing, gating and forwarding data and
        control packets. The Radio Access Technology (RAT) is
        independent of the proposed concept and therefore out of scope
        of this document. 3G, 4G, 5G or WiFi are applicable RATs. The BS
        is also capable of caching of content and state as close as
        possible to the user at the edge of the network. Another aspect
        of the cache is to support transparent handovers, during which



Mueller, Herbert        Expires January 7. 2017                [Page 10]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        buffering of packets at the target BS is required. Therefore a
        X2-like connection between BSs is required. The BS supports a
        support a policy enforcement function (PEF) as well as a Event
        Reporting Function (ERF) aligned on the 3GPP defined Policy
        Control and Charging (PCC) functionality for the EPS in
        ([23203], [29212]). Uplink QoS management is handled by the BS,
        too. In order to differentiate between multiple types of data
        traffic, signaling, high-priority, real-time and non-real-time
        connections can be distinguished and the order of packet
        processing in the BS can be influenced for uplink. The same
        concept applies for downlink in the GW. Forward Error Correction
        (FEC), IP header compression, encryption of user data stream are
        supported by the BS, too. Traffic filtering, gating, legal
        interception on the BS, to include the case, in which traffic
        re-routed only by the BS and is not traversing the GW.


        * The Gateway (GW) encompasses management and policy enforcement
        functions as well. Its main purpose is routing, gating and
        forwarding data and control packets. Therefore functionalities
        such as downlink QoS enforcement, APN management and charging is
        performed by each GW.


        * The Application function (AF) or IP Service is an example of
        any IP addressable service in network. Other than in the 3GPP
        defined architecture, the IP service does not need to reside in
        the SGi LAN reachable only after terminating the GTP tunnel in
        the PGW. Furthermore services can be reached directly after the
        RAN connection is terminated within the BS.


        * The Mobility Management Entity (MME) handles the initial
        authentication, authorization and mobility management of UE's
        over the control plane. The MME is responsible for tracking the
        UE's mobility and is in charge for updating the registries with
        near real-time status updates for LOC/ID mapping. ID and LOC
        assignment are performed by the MME.


        * The Home Subscriber Server (HSS) stores and manages user
        profile information. These include the static information such
        as the assigned ID, security credentials as well as dynamic
        information LOC and the current Tracking Area.


        * The Policy Charging and Rules Function (PCRF) controls data
        flows in the network architecture according to pre-defined



Mueller, Herbert        Expires January 7. 2017                [Page 11]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        rules. Such rules can be created by the network operator such as
        an upper limited for the data rate or total bytes transferred
        given a time interval (e.g. 2GB per month data plane with
        unlimited speed and a reduction of bandwidth after reaching the
        limit of 2G). Other rules differentiate between class of
        services for various traffic flow types identified on their
        Traffic Flow Template (TFT) characteristics such as source,
        destination, port and protocol information. The PCRF is handling
        charging for traffic flows using online (pre-paid) and offline
        (post-paid) charging. Both charging modes include a charging
        based on metrics such as service invocations, online time, data
        transferred, or no-charging. Out of credit events may influence
        the current connectivity for online charging, whereas offline
        charging is accumulating charging records which are usually
        processed in a monthly period.


        * The Access Network Discovery and Selection Function (ANDSF) is
        a database used for mapping the user location with available
        access networks. With this information, the ANDSF is capable of
        signaling suggestions for handovers to UE's. A UE is therefore
        able to operate only on one interface at a time to save
        resources. In case of the availability of adjacent RAT and after
        reception of a handover suggestion from the ANDSF, the UE is
        able to enable the suggested interface, perform a scan and
        finally decide whether or not to attach to the new targeted RAT.
        The database can be filled using device monitoring/telemetry
        statistics signaled from the UE to the network or by active
        measurements of the environment.



3.4. Signaling and Data Flow

3.5.1. Provisioning A Subscriber Identity Module (SIM)-card is
        provisioned by the network operator with a unique and secure
        identifier that is comparable to the IMSI in 3GPP telco
        architectures (2G, 3G and 4G). This draft is no differentiating
        between a physical or an embedded SIM. In addition, security
        credentials and preferred network identifier are provisioned for
        authentication as well as network selection are provisioned. The
        matching information to the SIM card is stored in the HSS.


3.5.2. Attachment After powering on the device, a scan for available
        networks is performed on the device, which selects the network
        (e.g. with the strongest signal) and performs a network
        attachment procedure aligned on ([23401], [23401]) towards the



Mueller, Herbert        Expires January 7. 2017                [Page 12]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        BS using security parameters, ID, last MME associated with
        (GUMMEI) and last GUTI assigned by MME with ID GUMMEI - the
        Packet Temporary International Mobile Subscriber Identity (M-
        TSMI). A secure identifier on the SIM is used to generate a
        temporarily ID (the ILA ID), which is only valid for one
        session, hides the privacy of the UE in the network and
        unambiguous identifies the UE within the global network, is used
        for identification, authentication, authorization and charging
        purposes.

        For each network attachment and due to privacy concerns for not
        revealing the identify of the UE towards the public, a new ID is
        generated.

        The BS derives the last MME association out of the network
        attachment request sent by the UE and queries the last or a new
        MME based on availability of information for UE authentication.
        The MME performs a lookup in the user database of the network
        operator, which is the Home Subscriber Server (HSS) and/or Home
        Location Register (HLR) and receives a profile in return. Hereby
        the MME is able to query the NVA for existing mappings or to
        retrieve a unique ID for the UE.

        In the following, the MME selects and configures the BS and GW
        according to the profile received and signals the profile
        including the ID towards the BSs of a certain tracking area and
        GW.

        The BS allocates a LOC for the UE, binds the ID-LOC combination
        locally in a cache, publishes its binding in the MME/NVA and
        signals the ID-LOC towards the client.

        Quality of Service (QoS) and charging related policies are
        installed in the BS and GW. The BS handled uplink and the GW
        downlink related traffic shaping functions. Charging can be
        performed in both functional elements (BS or GW), whereas a
        centralized charging in case of multi-path streaming is
        preferred.

        After the successful attachment, a service can be invoked.

3.5.3. Five Communication Scenarios for an End-to-End Data Transport
        Session

        After the attachment, applications can start communicating in
        the network using its assigned ILA by constructing IPv6 packets
        with the SIR source information (ID+LOC) and the mandatory
        target ID. The target LOC can be either set directly or can be



Mueller, Herbert        Expires January 7. 2017                [Page 13]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        defined as a broadcast message, in which the target LOC will be
        determined at the edge of the target.

        5 main high level use cases have been defined. The use cases can
        be distinguished into the following cases:
        1) UE accessing a service in the AF,
        2) UE is communicating with another UE attached to the same base
        station,
        3) UE is communicating with another UE attached to a different
        base station,
        4) Mobile-Edge-Computing,
        5) Gateway mobility

        The five example use cases are outlined below in details and the
        differences compared to today's networks are discussed. The
        communication form can be multicast, broadcast, anycast or
        unicast.

        TODO: Include schema as in nvo3 - 5.3 Reference network for
        scenarios


     1) E2E connection between the UE to AF

        Considering a communication scenario in which a UE (source)
        queries a website (target) e.g.
        "http://about.att.com/innovation/foundry" in a browser. A
        target_ID is retrieved in return from the DNS or NVA.

            UE[Task UE_T1] -> DNS // request ID and LOC for a given URL

            DNS -> UE[Task UE_T1] // retrieve a target_ID and optional
        target_LOC associated with the given URI

        The sequence for traversing the network looks as follows for an
        example that Task UE_T1 is communicating with Task AF_T1.

            UE:[Task UE_T1] <-> BS <-> GW <-> AF[Task AF_T1]

        The request is forwarded to the BS, which performs ILA router
        functionality. In case a broadcast address has been selected as
        a target LOC, a cache lookup in a local lookup table is
        performed. Depending on finding an entry in the local cached
        lookup table, the routing is influenced and the packet is
        redirected. Otherwise the packet is routed on to the destination
        ILA SIR address (LOC/ID).





Mueller, Herbert        Expires January 7. 2017                [Page 14]


INTERNET DRAFT        <draft-mueller-ila-mobility>


     2) UE_1 to UE_2 attached to distinct BSs

        Considering a communication scenario in which one mobile device
        (UE1) is contacting a second mobile device (UE2). Both UEs are
        connected to different BSs. ILA routing is done in the BS.

        Two communication path are possible. Either the connection
        between the two UEs is routed via a GA or in-between the
        respective BSs directly. A direct connection between BS_1 and
        BS_2 is required.

        UE1[Task UE1_T1] <-> BS_1 <-> GW <-> BS_2 <-> UE2[Task UE2_T1]

        UE1[Task UE1_T1] <-> BS_1 <-> BS_2 <-> UE2[Task UE2_T1]

     3) UE_1 to UE_2 attached to the same BS

        Considering a communication scenario in which two communicating
        entities are attached to the same BS and therefore are in close
        proximity. The solution for routing traffic in today's network
        is the establishment of the data path from the UE over the
        access network (e.g. eNB) through the core network (e.g. EPC)
        into the AF (any IP addressable service or task) and backwards
        to the access network and finally terminated at the UE. Charging
        needs to be performed in the BS for this data flow. This
        communication pattern in today's networks creates a delay caused
        by the bearer concept of 3GPP network, which encapsulate and de-
        capsulate data in Layer 2 tunnels between the eNB and the PGW.

        A practical use case is the communication between autonomous
        vehicles (e.g. self-driving cars or self-organized and
        autonomous drone swarms) through a telecommunication
        infrastructure. A very low delay is required for the interaction
        and precise management. In order to reach such a low delay, the
        communication needs to stay local in order to result in a low
        delay.

        The presented solution on ILA mobility allows to keep traffic
        local for the case in which the communicating parties attached
        to the same BS.

            UE_1[Task UE1_Tx] <-> BS <-> UE_2[Task UE2_Ty]

        Due to a lower amount of hops between UE_1 and UE_2, a lower
        latency can be achieved which results in a lower delay.


     4) UE to Mobile Edge Cloud (MEC) Service



Mueller, Herbert        Expires January 7. 2017                [Page 15]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        Considering a use case in which a UE is accessing a service with
        ultra-low latency requirements in the network such as image
        recognition, Virtual Reality (VR) or 5G services. Other examples
        include vehicle control (drone or truck-fleet, traffic
        information, robot or power grid). In order to provide a high
        quality of experience for the user and customer, latency in the
        communication between the mobile device and the service has to
        be reduced in order to achieve a lower delay. Where multimedia
        streaming has an acceptable latency requirement of ~100ms,
        ultra-low latency services have strict requirements on the
        communication with under 10ms or even close to 1ms. Classic
        cloud approaches that concentrate services centralized in the
        network are not applicable for ultra-low delay services due to
        the fact, that E2E latency is even too high. Violations of
        latency requirements result in motion sickness for VR users,
        outdated traffic information for autonomous self-driving cars,
        accidents with robotics in factories and the development of a
        new type of MEC services is hindered.

            UE[Task UE_T1] <-> DNS // request ILA SIR (ID and LOC) for a
        given URL

        Firstly, a DNS lookup resolves the URL into a ID to identify the
        closest service instance. The lookup process may be resolve to a
        service co-located at the BS or trigger the deployment of that
        service instance within a data center co-located or attached to
        the BS.

            * DNS <-> MEC_orchestrator // retrieve the ILA SIR mapped to
        the URI and closest to the UE. Eventually a new service is
        deploy and its endpoint is returned.

        Finally a request is created and addressed with the source
        LOC/ID and targeted towards the destination LOC/ID.

            UE[Task UE_T1] <-> AF[Instance I_1 Task AF_T1]

        The innovative point in this use case is the fact that the URL
        invocation may trigger a service deployment at the network edge
        instructed by the MEC_orchestrator and a policy decision. The
        policy decision is the outcome of the reasoning process within
        the MEC_orchestrator which takes context, user behavior, system
        load (throughput, latency, packet-loss, etc.), network topology
        map, distance between UE and service measured in hops, and other
        available metrics into account. Geographical load-balancing is
        therefore possible and enabled. Even when the first set packets
        of the connection are exchanged with a remote service, a context
        handover towards a closer service instance (out of the same type



Mueller, Herbert        Expires January 7. 2017                [Page 16]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        or load-balancing group) can be applied.

            UE[Task UE_T1] <-> AF[Instance I_2 Task AF_T1]

        Therefore the number of hops in the network are reduced and a
        lower delay on the data path is achieved.


     5) Gateway Mobility This use case covers situations in which the
        user stays connected to a BS but the core network is mobile. One
        example would be a BS that is attached to a vehicle (drone,
        car/bus, train, cargo ship, etc). The user facing side provides
        cellular service, backhaul is either WLAN, satellite, laser,
        MMWave or temporary a fixed connection.

        Gateway mobility requires the update of forwarding entries in
        related BS and AF to continuously forward the packets on the
        data path.

        The network setup looks as follows in which both gateways (GW_1
        and GW_2) both have connections to the same BS and AF.

                          UE <-> BS <-> GW_1 <-> AF
                                         ^->   GW_2   <-^


        Service interruptions may occur during the time of detaching
        from GW_a and attaching to GW_b when using a single radio
        interface for wireless backhauling. The capabilities of the 3GPP
        MME are extended with the ability to select the target GW for
        the BS, management of the BS-GW handover by reserving resources
        on the target GW_b and releasing resources on the source GW_a.
        GW_a caches packets during handover and forwards them to GW_b
        until packets are transported on the new uplink and downlink
        paths.


3.5.4. Homogeneous Handover Client mobility using the same access
        network technology caused by physical location changes is
        referred to as homogeneous handover. Triggers for homogeneous
        handovers may be variations in signal strength received at the
        UE or network based handover due to network policies such as UE
        load balancing on the BSs.

        The status information (the list of signals received from
        adjacent BSs including their signal strength) signaled from the
        UE towards the BS indicates enables positioning via
        triangulation as well as the selection of alternative BS's to



Mueller, Herbert        Expires January 7. 2017                [Page 17]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        which the UE may connect to.

        Reasons for handovers may be evacuation/preemption of resources
        on the BS due to emergency scenarios or higher priority calls,
        UE/BS/service load balancing or physical mobility of the UE
        among the network. Current resource utilization (e.g. data
        rates) of the UE or historical traffic pattern may influence the
        handover and the BS selection process.

        Mainly the MME selects a target BS (BS_target) as target for the
        handover of the UE away from the current BS (BS_source). The
        decision is signaled to related BS's and the UE. BS_source
        starts de-allocating resource blocked by the UE and BS_target
        blocks resources required by the UE. Since most UE's are
        considered to have only a single RAT of each type (one WLAN or
        one LTE interface) an interruption in the connection while
        handover is to be expected. In order to avoid packet loss at the
        UE, buffering at the BS_target as well as packet forwarding from
        BS_source to BS_target are supported. Only after UE successfully
        establishes connectivity at the BS_target, previously blocked
        resources at BS_source are freed up, which are used as handover
        role-back in case of failure. Finally the MME announces the new
        ILA ID (BS_target_LOC)/ID for the UE as an update at GW and in
        the DNS.

        New incoming connections are forwards directly towards the UE
        over BS_target using the proclaimed ILA ID (LOC/ID).

        Homogenous handovers with one radio technology interface
        supported have interruptions during the handover. Nevertheless
        those interruptions are relatively small due to techniques such
        as improved handovers (802.11x, 802.11k, 802.11r, and 802.11v)
        or context handover via X2 in 4G.


3.5.5. Heterogeneous Handover Client mobility may involve various Radio
        Access Technologies (RAT), in which the client is handed off
        from RAT_1 to RAT_2. The client is not required to move
        physically for heterogeneous mobility. Instead measurements on
        the UE or suggestion from the network (signaled over the ANDSF)
        may trigger handovers to alternative networks even when the UE
        is physically not moving. Such a handover can be done between
        WiFi, 4G and 5G.

        Heterogeneous handover are motivated for optimizing connectivity
        between UE and AF/service to move a multimedia connection with
        high bandwidth requirements from cellular (4G/5G) towards WLAN
        or a security sensitive bank transaction from WLAN towards



Mueller, Herbert        Expires January 7. 2017                [Page 18]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        cellular.

        Heterogeneous (compared to homogenous) handovers may be
        performed seamlessly with establishing a second alternative
        connection in parallel to the existing active connection and
        tearing down the old connection only, after successfully
        establishing the new connection. In order to provide higher
        bandwidth over multi-path, both connections may be kept open in
        parallel. In this regard, the MME adds another LOC'/ID as update
        to the existing entry LOC/ID in the registry on the gateways and
        DNS.


3.5.6. Detachment A detachment from the network can happen gracefully by
        shutting down the phone and de-registering it from the BS or
        suddenly due to a loss of connection. In both situations, a de-
        registration from the UE out of the list of active users
        attached to the BS is done directly or indirectly (after
        inactivity for a predefined timeframe). Resource reservations
        are freed up again after detachment.



3.5.6. Idle-mode and paging Power saving methods are working transparent
        to the ILA mobility concept such as in ([23401], [23402]) The
        device toggles from active to inactive mode in idle-mode in
        order to reduce the communication interval between device and
        antenna. Resource reservations in the network are kept alive in
        order to allow a fast weak-up and connection re-establishment
        caused by paging of the BS towards the device.


4. Discussion, Evaluation and Summary New low-delay services are
        appearing with AR/VR, drone communication, self-driving cars and
        robot control that have requirements, which cannot be fulfilled
        by todays network and cloud architectures. New ultra-low latency
        is a key requirement on connectivity that is enabling a new
        services. One way of improving the End-to-End (E2E) connectivity
        is to improve the underlying technology and to make it more
        efficient. Part of this improvement is described in Moore's-law,
        which highlights that the number of components per integrated
        circuit is doubling every 18 month. Another approach is to
        reduce the E2E latency by reducing the physical distance between
        device and service measured in number of hops and at the same
        time provide a backwards compatible solution for WiFi and 4G
        networks.

        This draft is addressing the above mentioned challenges and



Mueller, Herbert        Expires January 7. 2017                [Page 19]


INTERNET DRAFT        <draft-mueller-ila-mobility>


        provides a solution in form of an Identifier-Location Addressing
        (ILA) mobility based architecture. ILA decouples the identity
        from locator within an IPv6 address. Therefore mobility can be
        achieved by presuming the same ID at the endpoint and only
        adapting the locator used routing.

        ILA mobility enables multiple new and innovative use cases
        compared to legacy telecommunication networks. Summarizing, the
        above presented "Five communication scenarios for data transport
        for an End-to-End session" outlines ways to improve
        connectivity, optimize routing and enable a new type of service:
        MEC services. Firstly, the improved data path has less hops to
        traverse between UE <-> AF enabled by edge computing or locally
        between UE_1 <-> UE_2 due to the flatter architecture. Secondly,
        less overhead is created due to the reduction of GTP tunnels
        between network elements. Thirdly, the presented approach of ILA
        mobility is backwards compatible with todays IPv6 based fixed
        and mobile telecommunication networks.


5. References


5.1. Normative References

   [rfc6741] Identifier-Locator Network Protocol (ILNP) Engineering
        Considerations, Jan 2013, https://tools.ietf.org/html/rfc6741

   [nvo3ila] Identifier-locator addressing for network virtualization,
        draft-herbert-nvo3-ila-02, Tom Herbert, Mar 2016,
        https://tools.ietf.org/html/draft-herbert-nvo3-ila-02#page-17


5.2. Informative References

   [rfc6830] The Locator/ID Separation Protocol (LISP), D. Farinacci,
        Jan 2013

   [MIPv6], Mobility Support in IPv6, C. Perkins, Ed. et al., Jul 2011,
        https://tools.ietf.org/html/rfc6275

   [PMIPv6] S. Gundavelli, Ed. et al., Aug 2008,
        https://tools.ietf.org/html/rfc5213

   [23401] 3GPP TS 23.401 V13.7.0 (2016-06), General Packet Radio
        Service (GPRS) enhancements for Evolved Universal Terrestrial
        Radio Access Network (E-UTRAN) access (Release 13)




Mueller, Herbert        Expires January 7. 2017                [Page 20]


INTERNET DRAFT        <draft-mueller-ila-mobility>


   [23402] 3GPP TS 23.402 V14.0.0 (2016-06), Architecture enhancements
        for non-3GPP accesses (Release 14)

   [23203] 3GPP TS 23.203 V14.0.0 (2016-06), Policy and charging control
        architecture (Release 14)

   [29212] 3GPP TS 29.212 V14.0.0 (2016-06), Policy and Charging Control
        (PCC); Reference points (Release 14)



Authors' Addresses


           Dr.-Ing. Julius Mueller
           260 Homer Ave
           Palo Alto, CA 94301
           US

           EMail: jmu@att.com
        and
           Tom Herbert
           Facebook
           1 Hacker Way
           Menlo Park, CA 94052
           US

           Email: tom@herbertland.com























Mueller, Herbert        Expires January 7. 2017                [Page 21]


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