Use Cases for Identity Enabled Networks
draft-padma-ideas-use-cases-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Padma Pillay-Esnault , Dino Farinacci , Tom Herbert , Christian Jacquenet , David Lake , Michael Menth , David Meyer , Dipankar Raychadhuri | ||
| Last updated | 2017-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-padma-ideas-use-cases-00
Network Working Group P. Pillay-Esnault, Ed.
Internet-Draft Huawei
Intended status: Informational D. Farinacci
Expires: September 13, 2017 lispers.net
T. Herbert
Facebook
C. Jacquenet
Orange
D. Lake
Dell
M. Menth
U of Tuebingen
D. Meyer
Brocade
D. Raychaudhuri
Rutgers University
March 12, 2017
Use Cases for Identity Enabled Networks
draft-padma-ideas-use-cases-00
Abstract
This document describes some use cases for Identity Enabled networks
using a Generic Resilient Identity Services infrastructure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2017.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 1]
Internet-Draft March 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. Common Control Plane Infrastructure . . . . . . . . . . . . . 5
4.1. ID-Based Protocols . . . . . . . . . . . . . . . . . . . 5
4.2. Need for a Generic Resilient Identity Services in IoT . . 6
4.3. Case 1: Smart Home . . . . . . . . . . . . . . . . . . . 8
4.4. Case 2: Smart City . . . . . . . . . . . . . . . . . . . 9
4.5. Case 3: Industrial IOT Services . . . . . . . . . . . . . 9
5. Network Simplification . . . . . . . . . . . . . . . . . . . 10
5.1. Case 4: Proximity Services and Scopes . . . . . . . . . . 10
5.2. Case 5: Ease of troubleshooting and Management . . . . . 11
5.3. Case 6: Application of Common policies . . . . . . . . . 11
6. Ease of Provisioning . . . . . . . . . . . . . . . . . . . . 11
6.1. Case 7: Automatic Bootstrapping . . . . . . . . . . . . . 11
6.2. Case 8: Active User-Driven Provisioning . . . . . . . . . 12
7. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Case 9: Mobility within a single provider network . . . . 12
7.2. Case 10: Roaming across Mobile Networks . . . . . . . . . 15
7.3. Case 11: Mobility of a Subnet . . . . . . . . . . . . . . 16
8. Heterogeneous Multi-Access Environments (hetnet) . . . . . . 18
8.1. Case 12: Dynamic Mobility across Cellular and Wi-Fi . . . 18
8.2. Case 13:Ad-hoc Networks Mobility across Hetnet . . . . . 18
8.3. Case 14: Multi-network Access Support . . . . . . . . . . 19
8.4. Case 15: Disconnection-tolerant routing . . . . . . . . . 20
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Case 16: Policy Access Control . . . . . . . . . . . . . 20
10. Discovery of devices . . . . . . . . . . . . . . . . . . . . 21
10.1. Case 17: Low Cost Asset tracking . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Pillay-Esnault, et al. Expires September 13, 2017 [Page 2]
Internet-Draft March 2017
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The problem statement document for Identity Enabled Networks (IDEAS)
advocates for a standardized infrastructure, secured common control
plane with data integrity and allowing for different data-plane
solutions [IDEAS-PS].
This infrastructure is called Generic Resilient Identity Services
(GRIDS). The GRIDS will support functionalities such as traditional
mapping and resolution of Identifiers (ID), as well as secured
identifier registration, subscription, discovery, updates with data
integrity. In addition, it is designed to allow future extensions.
This memo describes some use cases for Identity-based protocols that
will benefit from such an infrastructure.
2. Specification of Requirements
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 [RFC2119].
3. Definition of Terms
This document makes use of the terms that have been already defined
in the problem statement draft of IDEAS [IDEAS-PS]. They are
included here for reader's convenience. In case of any discrepancies
between the two drafts, the problem statement draft overrides.
Entity : An entity is a communication endpoint. It can be a
device, a node, or a (software) process, that needs to be
identified. An entity may have one or multiple identifiers
simultaneously. An entity is reached by the resolution of one or
more of its identifiers to one or more locators.
Entity Collection: A set of entities with its own identifier,
e.g., a multicast group, or an ad-hoc vehicular network that needs
to be uniquely identified (e.g., a train entity may represent a
Closed User Group (CUG) and may contain all the passengers'
devices that share the same fate for connectivity).
Pillay-Esnault, et al. Expires September 13, 2017 [Page 3]
Internet-Draft March 2017
Identifier (ID): denotes information to unambiguously identify an
entity within a given scope. There is no constraint on the
format, obfuscation or routability of an ID. The ID may or may
not be present in the packet whose format is defined by ID-based
protocols.
Locator (LOC): denotes information that is topology-dependent and
which is used to forward packets to a given entity attached to a
network. An entity can be reached using one or multiple locators;
these locators may have a limited validity lifetime.
Identity: the essence of "being" of a specific entity. An
identity is not to be confused with an identifier: while an
identifier may be used to refer to an entity, an identifier's
lifecycle is not necessarily tied to the lifecycle of the identity
it is referencing. On the other hand, the identity's lifecycle is
inherently tied to the lifecycle of the entity itself.
IDentity Enabled Networks (IDEAS): IDEAS are networks that support
the identifier/locator decoupling. Reaching an entity is achieved
by the resolution of identifier(s) to locator(s).
Identifier-based (ID-based): When an entity is only reachable
through one or more communication access then a protocol or a
solution is said to be ID-based if it uses an ID-LOC decoupling
and a mapping system (MS) as base components of the architecture.
Identity-capable (ID-capable): An application is said to be ID-
capable if it makes use of an Identifier of an entity to establish
communication. For example, an application that initiates its
sessions using an ID. An application may use an IP-address as a
proxy for an ID if the network resolves this ambiguity. We regard
such an application as being ID-capable.
Generic Resilient Identity Services (GRIDS): GRIDS is a set of
services to manage the lifecycle of IDs, to map and resolve
identifiers and locators, and to associate metadata (META) with
entities and entity collections. It is a distributed system that
stores the ID, the associated LOC(s), and metadata (META) in the
form of tuples (ID, LOC, and META).
Metadata (META): is data associated with an Identity. The
metadata may contain information such as the nature of the entity
for example.
5G: Fifth generation wireless broadband technology [NEWS-3GPP].
Pillay-Esnault, et al. Expires September 13, 2017 [Page 4]
Internet-Draft March 2017
Scope: denotes the domain of applicability or usability of an ID.
A scope may be limited (e.g., considered local with geographic
proximity, or private within an administrative domain) or be
global.
User Equipment (UE): A user equipment is an entity per definition
in [IDEAS-PS]
Mapping gateway (MGW): A mapping gateway is a node in the network
which may host the GRIDS. It has access to the ID/LOC mappings.
It may also be able to update the destination address of a packet
based on the changes in the network.
4. Common Control Plane Infrastructure
4.1. ID-Based Protocols
ID-based protocols currently rely upon a customized mapping
infrastructure and they do not interoperate with each other.
Therefore, it would be difficult to deploy multiple ID-based
protocols in the same network due to the overhead generated by the
operation of various mapping functions. Hence, only one ID protocol
is usually deployed even though there exist the need to deploy
specific solutions to address various contexts.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 5]
Internet-Draft March 2017
+------------------------------------------------------+
| +--------------------------------------------------+ |
| | GRIDS | |
| | +-------------+ +---------------+ +-----------+ | |
| | | Registration| | Discovery | | ID-aware | | |
| | | | | Mapping | | Services | | |
| | | Lifecycle | | Resolution | | | | |
| | +-------------+ +---------------+ +-----------+ | |
| | | |
| | Common Control Plane | |
| +--------------------------------------------------+ |
| ^ |
| | |
| | |
| +--------------------------------------------------+ |
| | Flexible Data Plane | |
| | +--------+ +--------+ +-------+ +----------+ | |
| | | LISP | | ILA | | HIP | | New Svcs | | |
| | +--------+ +--------+ +-------+ +----------+ | |
| | | | | | | |
| | | | | | | |
| +-----|----------|----------|----------|-----------+ |
| | | | | | | |
| +-----|----------|----------|----------|-----------+ |
| | V V V V | |
| | +--------+ +---------+ +--------+ +----------+ | |
| | | Encap | |Translate| | Secure | | ID-Aware | | |
| | +--------+ +---------+ +--------+ +----------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+
Common Control Plane
4.2. Need for a Generic Resilient Identity Services in IoT
The IoT landscape is comprised of diverse devices and protocols.
Often, specific protocols are chosen due to constraints in the
deployment solution. For example, a small CPU/Memory footprint may
not allow for the formation of IPv6 packets or the battery-operated
nature of the device is not compatible with the "always-reachable"
nature of an IP stack.
In many scenarios, there is little commonality and almost no
interoperability between various IoT device technologies especially
when they are provided by different vendors. Meanwhile, the IoT
implementations are solely depended on their own network enablers.
The use of gateways within IoT solution is a common feature allowing
Pillay-Esnault, et al. Expires September 13, 2017 [Page 6]
Internet-Draft March 2017
IoT solutions to satisfy different applications. By adopting
multiple gateways in individual IoT domains, the convergent point for
global IoT interconnections is usually at a higher layer, such as
through adapting non-IP IoT protocols to IP-enabled reachability.
Whilst such an approach has allowed for rapid innovation in terms of
IoT applications, it also encourage the proliferation of siloed
networks. The ability of GRIDS to take into account various (IoT-
inferred) naming and addressing schemes is a possible solution. The
proper operation of cross-platform IoT services, that may deployed at
various scales - metro, region, country, may also encourage privately
operated mapping systems.
For example, an e-health service portfolio would include dynamic
biometric data monitoring which would involve an IoT network provider
(to forward data collected by sensor bracelets towards the nearest
dispatch emergency unit (as a function of the location of the
patient), an e-health service provider (e.g., ministry of health),
possibly associated with an e-health application service provider
(bracelet management, privacy data management, etc.). In this use
case, the different players may use specific naming schemes which may
solicit different mapping systems - one operated by the IoT network
provider (typical IP address resolution for example), the other by
the ASP or the IoT service provider.
However, it has to be realized that consolidating a vast array of IoT
datasets to a single, common form is likely to be unachievable
without compromising the quality of the data; the scope of IoT data
is too broad for them to be a single presentation that would suit
every application. In turn, this leads to the conclusion that IoT
will continue to comprise a large number of access technologies and
protocols, that are designed and optimized for their target
application, environment or devices
Pillay-Esnault, et al. Expires September 13, 2017 [Page 7]
Internet-Draft March 2017
+------------------------------------------------------+
| GRIDS |
+------------------------------------------------------+
| IP-enabled Locator for Reachability |
+------------------------------------------------------+
| Universal Adaptation Layer for Non-IP IoT |
+------------------------------------------------------+
| | | | | |
| | | | | |
RFID Wi-Fi Bluetooth LoRa NB-IoT Z-Wave
| | | | | |
| | | | | |
Supply Office Wearables Metering Monitoring Smart
Chain Building BYOD Smart City Home
Therefore, any exchange of data must happen at a layer above the
current network as illustrated in the figure 2. The solution lies in
an overlay addressing scheme to which all devices subscribe and are
aware of, but which allows for-purpose network stacks and local
addressing schemes to remain in place.
The ability to "route" between different technologies should be
enabled by the exchange of or notification of, or dynamic discovery
of the location of the GRIDS. It is expected that within a single
domain, such an ID scheme would allow data exchange between gateways
onto the existing IoT networks. A single ID solution therefore has
the ability to bind multiple, silo-ed IoT solutions into a logical
whole, allowing for the exchange of data between applications. (e.g.,
telemedicine IoT devices monitoring different health indicators).
4.3. Case 1: Smart Home
In a smart home, there usually exist heterogeneous consumer products
made by different manufacturers, such as TV, air conditioner,
refrigerator, surveillance camera, washing machine, and so forth. As
a prominent trend for those home appliances becoming smart, they are
able to be controlled in a wireless manner by respective control
applications (e.g., be installed in a Smart Phone acting as the
controller). However, one serious problem is that each specific home
product provider often request to have its customized application
with the associated protocol to enable device connectivity. This
results in siloed administration domains, and causes significant
inconvenience for customers, while tens of applications might be
needed for controlling all the appliances at home.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 8]
Internet-Draft March 2017
The management of a plethora of IoT devices regardless of underlying
technology is a challenge for the user and a common mechanism is
needed. Such a mechanism requires to have unified identifier,
interoperable protocol, compatible data format, and the like. For
example, the user may operate his/her own IoT Mapping System, with or
without the support of the network provider or the IoT service
provider. In case of support from a provider, a Customer Premise
Equipment (CPE) may function as an Internet gateway with an embedded
GRIDS. Hence, connected IoT devices may be accessed by a remote
controller.
Note that a cross-domain unified identifier and a set of management
policies upon such identifier plays an essential role in this case,
especially when every connected device at home is equipped with
intelligence for wired or wireless control in near future.
4.4. Case 2: Smart City
In current smart city constructions, lots of function-oriented
closed-loop applications have created information silos in distinct
industries, which are independent of each other. Accordingly, the
full interconnection and interoperability among various systems and
applications in smart city environment have not been extensively
realized. One of the key problems is the lack of unified identifier
service along with a resilient resolution method. As a result,
different sectors cannot mutually interoperate or need to shoulder a
heavy cost to achieve interconnection.
With the assistance of a common identifier layer and the resolution
service of fetching all relevant information of any identifier, many
vertical industries such as Transportation, Healthcare, Tourism,
Environment etc., can provide services that can be better managed
whenever participating service components share a common
communication infrastructure. For example, one traveler in a city
can request information about instant traffic, near-term weather, and
shopping guidance of one specific place of interest by issuing a
single query to the corresponding service identifier.
[SMART-CITY1][SMART-CITY2]
4.5. Case 3: Industrial IOT Services
In some scenarios, a publishing entity might not be able directly
communicate with multiple entities to send the same data due to
energy constraints. For example, a temperature sensor may send the
temperature readings to a GRIDS. Eventually, subscribers could
access the readings without direct interaction with the sensor
allowing it to save energy. In these cases, a local and private
GRIDS may act as helper by implementing a pub/sub model on the
Pillay-Esnault, et al. Expires September 13, 2017 [Page 9]
Internet-Draft March 2017
sensor's behalf. The GRIDS may receive and store the information in
the metadata associated with the entity or the data could be stored
remotely to a server referenced in the metadata. Furthermore, the
GRIDS could leverage its own access policy control features so that
the data can only be accessed by authorized users or entities. This
scheme protects the publishing entity from possible attack by
obfuscating its locator and preventing direct access to it.
GRIDS read +--------+
+------------------------+ ---->| reader |
| | | / +--------+
+--------+ write |------------------------|/ read +--------+
| Sensor |------>| Sensor's ID | metadata |------>| reader |
+--------+ once |------------------------|\ +--------+
| | | \read +--------+
+------------------------+ ---->| reader |
+--------+
5. Network Simplification
Whilst the term IoT encompasses a wide range of applications ranging
from short, low data-rate communications through to latency-sensitive
haptic control loops, the ability to reduce network overhead through
the simplification and potential removal of addresses at specific
points on the network has several benefits.
5.1. Case 4: Proximity Services and Scopes
In a system generating small amounts of data, the relative size of
the addressing which can be considered to be network operator
overhead compared to the size of the data payload which is customer
data can be very high to the point where the addressing and control
data vastly outsizes the customer data. In a traditional IT network,
this is not often the case; the address and management data is very-
much smaller than the payload and is thus an acceptable tax on the
overall communication. Small data IoT applications require a
solution to address the imbalance which now exists between the
payload and the overhead.
It is possible to imagine local services within a scope that require
only a small ID within a scope and can communicate with a local GRIDS
to resolve its mapping and location services if it is only
communicating with local devices such as local networked sensors.
Such an example could sensors be in a factory.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 10]
Internet-Draft March 2017
5.2. Case 5: Ease of troubleshooting and Management
Trouble-shooting a complex, multi-layer network where data is handed
from one encapsulation to another is complex. It is already seen in
solutions such as SIP that having embedded naming structures vastly
improves the ability to determine a data-path in a trouble-shooting
instance. Similarly, an ID-based solution would apply from the data
producer to the consumer and can also be used to improve data-
traceability thereby resulting in lower operational costs.
The presence of a GRIDS can improve on managing the data paths as
they are stored in their mappings. Such improvement can be
especially beneficial if GRIDS capabilities interact with a SDN-based
computation logic, whose service-inferred policy-based decision
making process may choose to redirect traffic onto alternate paths as
a function of the nature of the service, the load status of the
primary path, etc. Application of such dynamics can be critical for
specific IoT services, such as e-health services. Data analytics on
the GRIDS may also be logging events for easier postmortem if there
are issues.
5.3. Case 6: Application of Common policies
A Mapping System can contribute to enforce a set of common policies
for a given connectivity service by providing a global, consistent
identification and resolution service to any participating device
involved in the forwarding of the corresponding traffic.
6. Ease of Provisioning
The ease of provision becomes crucial with the foreseen deployment of
several (tens of) billions of connected devices come online. There
are two main scenarios where ID may simplify provisioning:
6.1. Case 7: Automatic Bootstrapping
Vastly improved operational efficiency is a requirement for
Industrial IoT (IIoT). The fast bring up, management and optimized
use of assets are crucial to industry automation. ( For example,
diverse entities such as industrial robots or sensors having an ID
may access the factory network and be redirected to a private GRIDS.
They may then authenticate and register themselves with the GRIDS.
If the GRIDS has some metadata for configuration stored for these
IDs, the entities could be automatically bootstrapped. Changes of
configuration need only be done on the local private GRIDS in the
future without individually accessing each device.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 11]
Internet-Draft March 2017
6.2. Case 8: Active User-Driven Provisioning
IoT devices deployed in large numbers in a given coverage area
(e.g.,Smart Agriculture for herd inventory) should be provisioned and
authenticated in bulk. Similarly, lightweight simplified device
configuration such as health monitors and Pet tracking devices would
benefit from bulk pre-provisioning.
7. Mobility
This section considers some scenarios of mobility in Identity Enabled
Networks. We assume that mobility should be seamless and transparent
to the application and user as far as possible. In particular, data
communication sessions should not be disrupted across mobility
events.
Seamless and transparent mobility in the network layer is achieved in
Identity Enabled Networks by updating the mapping database to reflect
changes.
From the perspective of user equipment (UE) (e.g., smartphone,
automobile, airplane...) there are three common mobility scenarios:
a. - Mobility of nodes within a single provider network
b. - Mobility of nodes between provider networks
c. - Mobility of subnet (within a provider network or between them)
7.1. Case 9: Mobility within a single provider network
Figure 4 provides an example of the topology of a single mobile
carrier network. UE.A, UE.B, and UE.C are devices connected to the
mobile network and are themselves mobile. UE.A and UE.B are
currently connected to base station Base1 and UE.C is currently
connected to Base2. The base stations are connected to the radio
access network (RAN) of the provider. The RAN is connected to the
Internet via a mapping gateway (MGW) which co-hosts the GRIDS for all
ID services. Host1 Host1 and Host2 are hosts in the Internet that
are communicating with the UEs. In this example we assume that ID
functionality is handled within the network and is transparent to the
UEs or hosts.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 12]
Internet-Draft March 2017
+-------+
| UE.A |-----+
+-------+ |
|
+-------+ +-----+ +-----+
| UE.B |--|Base1|-----+ __________ +--|Host1|
+-------+ +-----+ __|___ / \ | +-----+
/ \ +-----+ ( )--+
( RAN )--| MGW |-- ( Internet )
\_______/ +-----+ ( )--+
+-----+ | \__________/ | +-----+
|Base2|------+ +--|Host2|
+-----+ +-----+
|
+-------+ |
| UE.C |-----+
+-------+
The role of the MGW is to leverage the GRIDS that maps destination
addresses on ingress packets into the network to deliver packets to
the destination. The GRIDS maintain a list of ID-to-LOC mappings.
Hosts on the Internet only know the identifier of the mobile nodes.
Depending on the dataplane solution packets forwarded from the
Internet may be routed to a MGW that is able to retrieve the mapping
ID to the destination LOC to facilitate delivery.
Consider that Host1 sends a packet to UE.A. The destination address
of the packet is the identifier address of UE.A. The packet is sent
by Host1 and is forwarded across the Internet to the provider's
network based on the identifier address. A MGW receives the packet.
The destination address of a packet (identifier) is looked up in the
mapping table. The return result is the LOC for UE.A. The MGW
modifies the packet so that the destination address is the LOC for
UE.A (either by encapsulation or address translation). The packet is
then forwarded to Base1. At Base1 the destination is changed back to
the identifier address and forwarded to the UE.
In the case that two UEs need to communicate the process is similar.
Consider that UE.A sends a packet to UE.C. Again, UE.A only knows
the identifier address of UE.C. UE.A sends a packet into the network
and it is forwarded to a MGW. The MGW maps the destination address
of UE.C to its locator and forwards the packet to Base2 which
translates the destination back to an identifier address.
In order to reduce latency and improve performance, a mapping cache
may be implemented at or near the base stations. A mapping cache
would maintain a subset of mappings in the network that are being
Pillay-Esnault, et al. Expires September 13, 2017 [Page 13]
Internet-Draft March 2017
used for communications by the attached UEs to other devices in the
network. A protocol would be run between the base stations and MGWs
to populate and invalidate entries in the cache.
Now consider that UE.B changes locations so that it is now attached
to Base2 (figure 5).
+-------+
| UE.A |-----+
+-------+ |
|
+-----+ +-----+
|Base1|----+ __________ +--|Host1|
+-----+ __|___ / \ | +-----+
| / \ +-----+ ( )--+
| ( RAN )--| MGW |-- ( Internet )
V \_______/ +-----+ ( )--+
+-------+ +-----+ | \__________/ | +-----+
| UE.B |--|Base2|-----+ +--|Host2|
+-------+ +-----+ +-----+
|
+-------+ |
| UE.C |-----+
+-------+
The MGWs are updated to reflect UE.B's new location. As updating
location is not instantaneous across all the mapping gateways in the
network, it is possible that a packet is forwarded to an old
destination. Several possible solutions exist today:
1. Predictive routing. Pre-populating the (ID,LOC) tuple in the
GRIDS itself so that multiple packets may get delivered ahead of
the move as described in [LISP-PRED]. A predictive algorithm can
be used to forward packets ahead of the move with minimum
duplication.
2. Late binding. This method refers to rebinding of identifiers to
addresses after a packet enters the network. This capability
makes it possible for routers in the network to redirect packets
whose end-point address might have changed due to fast mobility
or rapid changes in radio link association or multicast group
membership. This type of dynamic rerouting can help to improve
network efficiency and reduce packet drops. Late binding
generally requires in-network elements such as routers and base
stations to be able to store data packets temporarily and access
the ID to address mapping (name resolution) service.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 14]
Internet-Draft March 2017
3. Traditional Redirection. For instance, Base1 may receive packets
for a UE.B after it has moved to Base2. A "care of address"
could be set on Base1 for some period after the move. When Base1
receives a packet for UE.B it can map the destination address to
reflect UE.B's new location and forward the packet.
7.2. Case 10: Roaming across Mobile Networks
Consider the example network topology in figure 6. In this case UE.A
and UE.B are connected to one provider network and UE.C is connected
to another. We assume that the UEs are respectively customers of
these attached networks and that they are assigned identifiers from
the pool of each carrier (their "home network"). In this
configuration connectivity to the UEs is achieved as described above.
+-------+
| UE.A |----+
+-------+ | ______ +-----+
| / \ +-----+ _______ +--|Host1|
+-------+ +-----+ ( RAN )--| MGW |---/ \ | +-----+
| UE.B |--|Base1|----\_______/ +-----+ ( )---+
+-------+ +-----+ ______ ( Internet )
/ \ +-----+ ( )---+
( RAN )--| MGW |---\________/ | +-----+
\_______/ +-----+ +--|Host2|
+-----+ | +-----+
|Base2|-------+
+-----+
|
+-------+ |
| UE.C |-----+
+-------+
When a UE moves between different carrier networks, the ID continues
to work if distinct GRIDS can share mapping information across the
networks. Consider that UE.B moves to the other carrier network
(figure 7).
Pillay-Esnault, et al. Expires September 13, 2017 [Page 15]
Internet-Draft March 2017
+-------+
| UE.A |-----+
+-------+ | ______ +-----+
| / \ +-----+ _______ +--|Host1|
+-----+ ( RAN )--| MGW |---/ \ | +-----+
|Base1|----\_______/ +-----+ ( )---+
+-----+ ______ ( Internet )
| / \ +-----+ ( )---+
| ( RAN )--| MGW |---\________/ | +-----+
V \_______/ +-----+ +--|Host2|
+-------+ +-----+ | +-----+
| UE.B |--|Base2|-------+
+-------+ +-----+
|
+-------+ |
| UE.C |-----+
+-------+
Suppose Host1 sends a packet destined to UE.B. The identifier
address for UE.B is set in the destination address of the packet.
The packet is forwarded to the home network for UE.B since the
identifier was assigned from that carrier's pool. In order to handle
this the packet can be mapped at the MGW to indicate the location of
the current carrier network for UE.B. This can be done in at least
two ways:
1. The new carrier provides the full LOC (mapping to Base_station2)
and the MGW sends the packet directly to that LOC
2. The packet is mapped so that it is forwarded to an MGW in the new
network and that MGW in turn maps the packet to its final
destination.
While #1 has the advantage of being more direct, it requires a higher
rate of sharing mappings, for instance if UE.B moves to a new base
station in the remote carrier network each change in the mapping
would need to be propagated to the MGWs UE.B's home network. In #2
movement within a remote network would be transparent to MGW in the
home network.
7.3. Case 11: Mobility of a Subnet
Figure 8 presents a topology where UE.A, UE.B, and UE.C are connected
to a subnet and the whole subnet may itself be mobile (for instance a
Wi-Fi network on a bus). To treat the subnet as an aggregate
devices, the subnet identification is reflected in the identifier
address. A single mapping entry then could then represent this
Pillay-Esnault, et al. Expires September 13, 2017 [Page 16]
Internet-Draft March 2017
subnet where the identifier is the prefix for the subnet and the
locator reflects the location of the subnet (Base1 in this case)
+------+
| UE.A |--+
+------+ |
+------+ | +-----+ +-----+
| UE.B |--+--|Base1|-----+ ________ +--|Host1|
+------+ | +-----+ __|___ / \ | +-----+
+------+ | / \ +-----+ ( )--+
| UE.C |--+ ( RAN )--| MGW |-- ( Internet )
+------+ \_______/ +-----+ ( )--+
+-----+ | \________/ | +-----+
|Base2|-----+ +--|Host2|
+-----+ +-----+
When the subnet moves the mappings to the identifier, the prefix for
the subnet is updated in the MGWs (figure 9). Note that a UE could
also move out of its subnet and attach to the network on its own, for
instance a UE might switch from using Wi-Fi to using a mobile
network. This will work if a specific mapping for UEs is allowed in
the mapping database, and that mapping is preferred over the
aggregate mapping since it has a longer identifier prefix.
| +-----+ +-----+
| |Base1|----+ ________ +--|Host1|
V +-----+ __|___ / \ | +-----+
+-------+ / \ +-----+ ( )--+
| UE.A |--+ ( RAN )--| MGW |-- ( Internet )
+-------+ | \_______/ +-----+ ( )--+
+-------+ | +-----+ | \________/ | +-----+
| UE.B |--+--|Base2|-----+ +--|Host2|
+-------+ | +-----+ +-----+
+-------+ |
| UE.C |--+
+-------+
Similar to the case of a UE moving between carrier networks, a subnet
can move between carrier networks if the networks share identifier
locator mappings that include identifier prefixes. Also, subnet
mobility can modify community management and therefore impact GRIDS
service operation: if UE.A, UE.B, and UE.C have subscribed to
Pillay-Esnault, et al. Expires September 13, 2017 [Page 17]
Internet-Draft March 2017
different services where, for example, UE.A exchanges information
with UE.B but not with UE.C, whereas, UE.C exchanges information with
UE.B but not UE.A, the mobile subnet may support different "closed
user groups" that may be serviced by different GRIDS. When the
subnet moves, other GRIDS may be invoked to make sure communication
within the said closed user groups is not disrupted.
8. Heterogeneous Multi-Access Environments (hetnet)
8.1. Case 12: Dynamic Mobility across Cellular and Wi-Fi
In this case, the UE is multi-homed and moves seamlessly between the
cellular network to a Wi-Fi network where the Wi-Fi provider may be
different from the cellular provider. In order to achieve session
continuity in this case, the UE can rely on ID/LOC mappings with the
use of GRIDS.
------
+-----+ / \
/---| enb |--| Wireless +---\
/ LTE +-----+ | \ ________
/ \ / / \
+----+ ------ ( ) +-----+
| UE | ( Internet ) +--|Host |
+----+\ -------- ( ) +-----+
\ +------ / \ \________/
Wi-Fi | hot |--+ | /
\-|spot | | Fixed +---/
+-----+ \ /
------
8.2. Case 13:Ad-hoc Networks Mobility across Hetnet
As smartphones move across various mobility domains, their points of
attachment to the Internet can change easily and rapidly. The need
for supporting mobility arises when an individual node or a group of
nodes move and reconnect to the Internet.
Frequent disconnections and IP address change on re-association to
new access points interrupt the data transmission sessions.
Solutions like transparent handover between base stations in cellular
networks, which let users retain their static IP address, are
practical only for intra-network mobility purposes.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 18]
Internet-Draft March 2017
Furthermore, there are opportunities for a network to be formed
between groups of vehicles on the highway, and these networks should
be able to quickly peer along the edge with different networks
encountered during mobility. As another emerging use-case consider
Google's Project Loon, which proposes to beam LTE access in
developing countries from a network of aerial balloons. The
Facebook's Internet provider drones that aims to provide online
access with wireless antennas, lasers, and satellites.
Managing a global scale of unmanned and highly mobile base-stations
is challenging, despite the partial solution that BGP currently
provides for airline connectivity. Decoupling identity from location
provides inherent support for mobility, provided the mapping system
is scalable and supports fast query and minimum lookup latencies.
Optimizations such as "late binding", in which identity of in-transit
packets can be bound to a locator closer to the edge of the network
to account for highly mobile vehicular scenarios can be further
developed based on the GRIDS.
The Ad-hoc networks of the future such as driverless cars will need
secured services and communications. Today, the cost of
reestablishing both the session and any security association is
prohibitive in real-time applications. The local and proximity
services on the GRIDS could be leveraged to provide the session
continuity and security features.
8.3. Case 14: Multi-network Access Support
A typical mobile device (smartphones, cars, ..) can see multiple
available networks at the same time and can be multi-homed. Although
the majority of current business models generally restrict a user to
a single cellular network provider, with the increasing popularity of
"hetnet" mobile services, mobile device might be soon able to
simultaneously connect to a dynamically changing set of cellular,
WiFi and future 5G networks.
It is possible to consider a variety of service objectives for this
scenario, ranging from "most cost-effective" to "highest throughput
interface" to "all interfaces".
End-to-end solutions to support multi-path connectivity do exist, but
supporting network-wide multi-homing has a very broad architectural
implication. This implication stems from having more fine-grained
control over network resources, complete information regarding
forwarding path quality and load conditions and more adaptive
response to congestion/loss. Since these networks will in general be
in different Internet domains, autonomous systems need to support
independent paths of connectivity for a single end-to-end flow.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 19]
Internet-Draft March 2017
Furthermore, there is a high cost associated with session continuity
and security features for seamless and transparent switching between
different networks. It is possible to create redundant connections
(like MPTCP) over redundant networks. However, it is a very static
solution and difficult to predict which network is being used if the
switch is in the order of seconds. ID-based solutions may benefit
use cases where cars trying to use V2V, V2X, 5G, 802.11p, etc. all at
the same time.
8.4. Case 15: Disconnection-tolerant routing
While disconnection-tolerant (DTN) routing has been principally
considered for ad-hoc disaster-relief, vehicular and tactical network
scenarios, temporary disconnections during mobility also require
support for store and forward capabilities of DTN.
Session-oriented transport protocols like TCP react adversely to
disconnections and have a slow re-connection and end-to-end setup
delays, whereas unreliable protocols like UDP simply drops packet on
disconnection. Having in-network routers store in-transit packets
while allowing a "rebinding" of identity to location would improve
end-to-end transport and enable newer mobility-centric transport
protocols for 5G.
9. Security
9.1. Case 16: Policy Access Control
For privacy or security reasons, an entity may only want a designated
list of authorized entities to look up its locators and access it.
To this end, the entity can specify an access control list in the
GRIDS and let the GRIDS enforce the access control at the locator
resolution phase. For example, when Alice wants to communicate with
Bob, she has to look for the Bob's ID in the GRIDS to get his
locator. The GRIDS verifies Alice's ID and checks the ID against
Bob's access control list. If Alice is authorized, the GRIDS returns
Bob's up-to-date locators; otherwise the GRIDS returns an error.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 20]
Internet-Draft March 2017
GRIDS
+---------------------+
set ACL | | lookup
+-------+ set LOC |---------------------| Alice +-----+
| Alice |-------->| Alice's ID | ACL |<-------| Bob |
+-------+ |---------------------| +-----+
| yes| no| | access ^ ^
| | | | denied | |
| | --|---------- |
| v | |
|---------------------| Alice's LOC |
| Alice's ID | LOC |--------------
|---------------------|
| |
+---------------------+
10. Discovery of devices
10.1. Case 17: Low Cost Asset tracking
Asset tracking with extremely low cost has become popular with
offerings like bike sharing services. There is a need to track the
exact location of individual bikes with low cost in long time span.
In this case, there must have a module with a secure identifier of
the bike and can be set up communications whenever needed. The
information associated with the identifier should be maintained with
efficient resolution capability for tracking the labeled asset.
[ASSET1][ASSET2]
11. Security Considerations
This document does not introduce any new security concerns.
12. IANA Considerations
This document has no actions for IANA.
13. Contributors
This present document is based on an extract of the first version of
the draft. The authors and their affiliations on the original
document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D.
Lake (Cisco Systems), T. Herbert (Facebook), M. Menthe (University
of Tuebingen), Dipenkar Raychaudhuri (Rutgers University), Julius
Mueller (ATT) and Padma Pillay-Esnault (Huawei).
Pillay-Esnault, et al. Expires September 13, 2017 [Page 21]
Internet-Draft March 2017
There are two companion documents also extracted from the -00 version
of the document above: Problem Statement for Identity Enabled
Networks [IDEAS-PS] and GRIDS Requirements [IDEAS-REQ] which regroups
all the authors above.
The authors would like to acknowledge the contributions of
Rutgers University: Parishad Karimi and Shreyasee Mukherjee
Huawei: Da Bin and Liu Binyang.
14. Acknowledgments
The authors would like to thank Kevin Smith, Alex Clemm, Uma Chunduri
and Yingzhen Qu for their review and input on this document.
This document was produced using Marshall Rose's xml2rfc tool.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
15.2. Informative References
[ASSET1] OFO, , <http://www.ofo.so/>.
[ASSET2] ITU, , <http://tracknet.net/1>.
[IDEAS-PS]
Pillay-Esnault, P., Boucadair, M., Jacquenet, C.,
Fioccola, G., and A. Nennker, "Problem Statement for
Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-
problem-statement/>.
[IDEAS-REQ]
Pillay-Esnault, P., Clemm, A., Farinacci, D., and D.
Meyer, "Requirements for Generic Resilient Identity
Services in Identity Enabled Networks", March 2017,
<https://datatracker.ietf.org/doc/draft-padma-ideas-req-
grids/>.
Pillay-Esnault, et al. Expires September 13, 2017 [Page 22]
Internet-Draft March 2017
[LISP-PRED]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", November 2016, <https://datatracker.ietf.org/doc/
draft-farinacci-lisp-predictive-rlocs/>.
[NEWS-3GPP]
3GPP, "3GPP News",
<http://www.3gpp.org/news-events/3gpp-news>.
[SMART-CITY1]
Libellium, "Libelium Smart World Infographic - Sensors for
Smart Cities, Internet of Things and beyond",
<http://www.libelium.com/libelium-smart-world-infographic-
smart-cities-internet-of-things/>.
[SMART-CITY2]
ITU, "Identifier service for the interoperability of Smart
City", <http://www.itu.int/ITU-T/workprog/
wp_item.aspx?isn=13671>.
Authors' Addresses
Padma Pillay-Esnault (editor)
Huawei
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: padma.ietf@gmail.com
Dino Farinacci
lispers.net
San Jose California
USA
Email: farinacci@gmail.com
Tom Herbert
Facebook
Email: tom@herbertland.com
Pillay-Esnault, et al. Expires September 13, 2017 [Page 23]
Internet-Draft March 2017
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
David Lake
Dell
Email: d.lake@surrey.ac.uk
Michael Menth
U of Tuebingen
Email: menth@uni-tuebingen.de
Dave Meyer
Brocade
Email: dmm@1-4-5.net
Dipenkar (Ray) Raychaudhuri
Rutgers University
Email: ray@winlab.rutgers.edu
Pillay-Esnault, et al. Expires September 13, 2017 [Page 24]