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

Versions: 00 01

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]


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