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]