Network Working Group                             P. Pillay-Esnault, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                              D. Farinacci
Expires: March 18, 2017                                      lispers.net
                                                                D. Meyer
                                                                 Brocade
                                                                 D. Lake
                                                           Cisco Systems
                                                              T. Herbert
                                                                Facebook
                                                               M. Menthe
                                                 University of Tuebingen
                                                         D. Raychaudhuri
                                                      Rutgers University
                                                              J. Mueller
                                                                     ATT
                                                      September 14, 2016


   Problem Statement for Mapping Systems in Identity Enabled Networks
                 draft-padma-ideas-problem-statement-00

Abstract

   This document provides a brief overview of Identity Enabled Networks
   (IDEAS) and discusses the need for a standardized network mapping
   system that is scalable, robust and flexible for future networks.
   This memo also identifies several key areas that should be
   investigated for the architecture design of these network mapping
   systems and their protocol interfaces.

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 March 18, 2017.




Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 1]


Internet-Draft                                            September 2016


Copyright Notice

   Copyright (c) 2016 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 . . . . . . . . . . . . . . . .   4
   3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
   4.  Problem Statement for Network Mapping Systems (NMS) . . . . .   5
     4.1.  The Need for a Common Control Plane Infrastructure  . . .   5
     4.2.  Flexible, Open and Efficient Mapping System Interfaces  .   5
     4.3.  Identifier Structure and Life Span  . . . . . . . . . . .   5
     4.4.  Confidentiality . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Security  . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.6.  Automatic Bootstrapping . . . . . . . . . . . . . . . . .   6
   5.  Impact of ID Characteristics on Mapping Systems . . . . . . .   6
     5.1.  Identifier Allocation . . . . . . . . . . . . . . . . . .   8
     5.2.  Identifier Groups, Range and Scope  . . . . . . . . . . .   9
   6.  Network Mapping System (NMS) Requirements . . . . . . . . . .   9
     6.1.  Mapping Responsibility  . . . . . . . . . . . . . . . . .   9
     6.2.  Distribution and Redundancy . . . . . . . . . . . . . . .  10
     6.3.  Scale and Performance . . . . . . . . . . . . . . . . . .  10
     6.4.  Mapping System Security . . . . . . . . . . . . . . . . .  10
     6.5.  Flexibility for Next Generation Apps  . . . . . . . . . .  11
   7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Mobility  . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.1.  Mobility within a single provider network . . . . . .  12
       7.1.2.  Mobility between Provider Networks  . . . . . . . . .  14
       7.1.3.  Mobility of a Subnet  . . . . . . . . . . . . . . . .  16
       7.1.4.  Transport Layer Mobility  . . . . . . . . . . . . . .  17
     7.2.  Session Continuity in Heterogeneous Multi-Access
           Environments  . . . . . . . . . . . . . . . . . . . . . .  18
       7.2.1.  Dynamic Mobility across Heterogeneous Access Networks  18
       7.2.2.  Multi-network Access Support  . . . . . . . . . . . .  19
       7.2.3.  Late Binding Capability . . . . . . . . . . . . . . .  19
       7.2.4.  Disconnection-tolerant routing  . . . . . . . . . . .  20



Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 2]


Internet-Draft                                            September 2016


     7.3.  Cross-Silo Communication  . . . . . . . . . . . . . . . .  20
     7.4.  Network simplification  . . . . . . . . . . . . . . . . .  21
     7.5.  Ease of Provisioning  . . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  23
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     12.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   The current Internet architecture with Internet Protocol (IP) was
   designed for a very different environment from today's networks.  The
   October 2006 IAB Routing and Addressing Workshop [RFC4984] identified
   several future trends in Section 5 and foreseeable problems in
   Section 7.  As predicted, the number of users using mobile devices
   has exploded over the years.  While mobility and security were
   identified as concerns in the report they were not the primary focus.
   Fast-forward 10 years, mobility security, and hyper-connectivity with
   IoT have now emerged as major challenges for the network
   infrastructure.  This document proposes to compile a concise problem
   statement and use cases as an input for future work.

   Internet Protocols were originally designed for fixed networks.  At
   the time, the size of the headers was a concern and the solution
   adopted was to overload the IP address semantic by using it to define
   both the identifier(ID) and location (LOC) of an entity . A side-
   effect of this optimization was that session continuity with TCP/IP
   would require retaining the same IP addresses at both endpoints
   across a movement.  [RFC4984] suggests that a generic identifier-
   locator separation would be a possible solution to support billions
   of mobile gadgets without "bringing undue impact on global routing
   scalability and stability".  Multiple mobility solutions have been
   explored and among them the identifier-based solutions such as Host
   Identity Protocol (HIP) [RFC7401], Location Identifier Separation
   Protocol (LISP) [RFC6830], Identifier Locator Network Protocol
   [RFC6740], and Identifier Locator Addressing[ILA].  The basic premise
   behind these solutions was to make changes of location transparent to
   the upper layers above including TCP/IP.  The technique used to mask
   the change of location to higher layers was to decouple the
   identifier and location.

   With the hyper-connectivity and scale expected in 2020, the static
   Internet architecture is an added constraint to build robust,
   efficient, simple, flexible and scalable solutions.  The decoupling



Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 3]


Internet-Draft                                            September 2016


   of ID and LOC will enable newer breeds of applications with
   integrated security and privacy without expectations to be tethered
   to any fixed point.  While Identity Enabled Networks have often been
   associated with mobility, the latter is just one of the many use
   cases of ID Enabled networks.  Section 7 of this document describes
   others.

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

      Entity: An entity can be a device, node or a process, which need
      to be identified in a network.  An entity can also be a collection
      of entities, for example a multicast group, or an ad-hoc vehicular
      network that needs to be uniquely identified.  An entity can have
      one or multiple identifiers to identify it.

      Identifier (ID): An identifier is a name which can be used to
      identify an entity unambiguously within a scope.

      Locator (LOC): A locator is a routable address in a network.  It
      is used for reachability to an entity.

      Identity Enabled Networks (IDEAS): Identity Enabled Networks are
      networks that support the identifier and location decoupling.  The
      reachability to an entity is achieved by mapping its identifier(s)
      to a location.

      Identifier-based or ID-based: A protocol or a solution is ID-based
      if they use an ID-LOC decoupling and a Mapping system as base
      architecture.

      Identity-aware or ID-aware: An application is ID-aware if it makes
      use of the Identifier of an entity to establish communication.

      Network Mapping Systems (NMS): A network mapping system is a
      network database that stores the ID and the associated LOC(s).  It
      may also contain metadata specific to the ID.

      Binding: The process of binding an ID to its associated LOC(s),
      based on a lookup/query of the NMS.

      5G: Fifth Generation mobile networks.




Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 4]


Internet-Draft                                            September 2016


4.  Problem Statement for Network Mapping Systems (NMS)

4.1.  The Need for a Common Control Plane Infrastructure

   Today, most locator/identifier separation solutions rely on a mapping
   system control plane that maps an ID to one or multiple locators.
   Currently, these solutions implements their own mapping system.  The
   mapping system may leverage push-based protocols (traditional routing
   protocols), pull based control-planes (Domain Name Service and LISP),
   or Software Defined Network (SDN) controllers.  The ID-based
   protocols can be considered to provide efficient solutions for
   mobility and the Internet of Things.

   While many ID-enabled data plane mechanisms serve fundamentally
   different objectives and do not need to interoperate there is a
   potential benefit in providing them a common mapping interface.  A
   common mapping system infrastructure may facilitate cross-platform
   synergy.  Furthermore, the lack of a standardized mapping system will
   be an impediment for the deployment of ID-enabled solutions and a
   high diversity of mapping system variants will create silos that are
   expensive to maintain both from a CAPEX and OPEX point of view.

   In addition, future ID-aware application spanning over multiple ID-
   based protocols will have a huge complexity at application level

4.2.  Flexible, Open and Efficient Mapping System Interfaces

   Newer ID-aware applications or ID-based protocols will define their
   own ID allocation scheme and mapping if they do not need
   compatibility or operability with today's systems.  Therefore, the
   mapping system must be flexible and extensible towards novel ID and
   mapping types.  Furthermore, mapping resolution must be fast to
   support low delay requirements of future communication.

4.3.  Identifier Structure and Life Span

   Currently, there is no guidance or allocation scheme for public IDs.
   Furthermore, the ID format varies by protocol.  An agreed upon ID
   format and scope may facilitate interoperability and simplify the
   implementation of some use cases.  The administrative boundaries are
   a reflection of how the world is connected and ease of deployment
   should become an inherent requirement in recommendations for the
   allocation of IDs.

   Many entities are expected to have a "life span", therefore,
   recycling their IDs seems a valid desire.  However, the IPv6 address
   space is huge (2^128 ~ 10^38) and will suffice for a long time even




Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 5]


Internet-Draft                                            September 2016


   without recycling.  Thus, at this time, the requirements for
   recycling of IDs is beyond the scope of this document.

4.4.  Confidentiality

   The access to a mapping system may reveal the location of an ID and
   therefore any breach is considered a security risk.  In the future it
   would be best to use standardized methods or recommendations for
   secured access to mapping systems.

4.5.  Security

   In the current Internet architecture, each network-connected device
   must establish a TCP/IP connection, before a client can perform
   authentication.  During a cyber attack vulnerability scanning tools
   are able to identify what network applications are present and, in
   many cases, develop signatures of the network-connected devices,
   which includes the operating system, network applications, and their
   release and patch levels.  This information can then be used to
   develop strategies to attack the network-connected device.  However,
   a mechanism that requires authentication before establishing a TCP/
   IP, closes this security hole and denies attackers information.

   In identity enabled networks, an initial authentication of the ID
   related to the network-connected device is performed before a session
   is established.  This may block a cyber-attack before the connection
   is established and reduces the burden of deep packet inspection and
   the consequent overhead and latency.

4.6.  Automatic Bootstrapping

   Automatic bootstrapping is required in advanced communication because
   the diversity of communication will be so massive that a user cannot
   be expected to cope with the configuration of each and every
   application.  5G, IoT, and machine-to-machine (M2M) communication are
   just emerging examples.  In the future, it is highly desirable that
   there should be minimal or Zero Touch Provisioning (ZTP) on new
   devices coming online.  Automatic bootstrapping is particularly
   pertinent for the industrial Internet where M2M is expected to be
   functional with minimum human intervention.  The ease of provisioning
   use case is described in the Section 7 of this document.

5.  Impact of ID Characteristics on Mapping Systems

   ID may have multiple characteristics.  The table below attempts to
   capture some of their pros and cons.





Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 6]


Internet-Draft                                            September 2016


   +----------------+----------------+-------------------+-------------+
   | Characteristics| Pros Technical | Pros Non-technical| Cons        |
   +----------------+----------------+-------------------+-------------+
   | Large Name     |Need to account | Scalable          | Very large  |
   | Space          |for billions of |                   | space       |
   |                |devices,Scalable|                   | Unmanageable|
   +----------------+----------------+-------------------+-------------+
   | Global ID      |Easier to create| Requires access   | Location    |
   |                |a unique mapping| to mapping        | is known    |
   |                |service         | services          | to all      |
   |                |Uniqueness      |                   | Lack of     |
   |                |                |                   | privacy     |
   |                |                | User identifies   | Security    |
   |                |                | easily with ID    | Risk        |
   |                |                | (e.g. phone #)    |             |
   +----------------+----------------+-------------------+-------------+
   | Multiple ID    |Allows multiple | Privacy, some can | Complexity  |
   |                |identities.     | be ephemeral      |             |
   |                |Poss. multiple  | or not            |             |
   |                |class of service|                   |             |
   +----------------+----------------+-------------------+-------------+
   | Mappable       |Backward        | Cost Effective.   |             |
   | Translatable   |compatible with |                   |             |
   | to IP          |existing apps   | No change of base |             |
   |                |                | infrastructure    |             |
   +----------------+----------------+-------------------+-------------+
   | Variable Length| Backward       | Cost Effective.   |Implementa-  |
   |                | compatible with|                   |tion cost    |
   |                | existing apps  | Can work with     |             |
   |                |                | IPv4, ipv6 and    |             |
   |                |                | as non-ip         |             |
   +----------------+----------------+-------------------+-------------+
   | Non-Encrypted  |                | Ease of use and   | Security    |
   |                |                | troubleshooting   |  Risk       |
   +----------------+----------------+-------------------+-------------+
   | Encrypted      | Security       |                   | Not Human   |
   |                |                |                   | Readable    |
   |                |                |                   | hard to use |
   +----------------+----------------+-------------------+-------------+
   | Human          |                | Human Manageable  | Security    |
   | Readable       |                | Ease of use       | Risk        |
   +----------------+----------------+-------------------+-------------+
   | Hierarchical   | Easier to      | Easy Assignment   | Need ID     |
   |                | look up        |                   | Structure ID|
   |                |                |                   | Lack of     |
   |                |                |                   | Privacy,    |
   +----------------+----------------+-------------------+-------------+
   | Not            | Need to ensure | Complete Freedom  |May be harder|



Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 7]


Internet-Draft                                            September 2016


   | Structured     | no collision   |                   |to manage    |
   |                | can use crypto |                   | look-up     |
   |                |  key           |                   | scale       |
   +----------------+----------------+-------------------+-------------+
   | Range          | Easier to have | Administrative    | Confident-  |
   | or scope       | hierarchy in   |Domain             | iality      |
   |                | mapping systems|control easier     |             |
   |                |                |Lawful Interception|             |
   +----------------+----------------+-------------------+-------------+
   | Geographical   | Easier for     | Admin Ctrl.       | Privacy,    |
   | Awareness      | incremental    | per AS or ISP.    | Confident-  |
   |                | deployment     | Policy possible   | iality      |
   |                |                | per admin Domain  | Tracking    |
   +----------------+----------------+-------------------+-------------+
   | Provider       |                |                   | Locked in?  |
   | Dependency     |                |                   | Migration   |
   +----------------+----------------+-------------------+-------------+
   | Structured     | Distributed    | Customization     | Masquerading|
   |                | systems that   | services or apps  | Misconfig   |
   |                | identifies     | If name identifies| Maliciously |
   |                | different types| types of objects. | Misrepresent|
   |                | of devices     | E.g. a Fridge     |             |
   |                |  -Mobile       | is not mobile and |             |
   |                |  -Home         | belong to smart   |             |
   |                |  -Human ID     | home              |             |
   |                |  -Ephemeral    |                   |             |
   |                | Apps/Process   |                   |             |
   |                | Slice          |                   |             |
   +----------------+----------------+-------------------+-------------+
   | Context        | Instantiation  | Customization     | Privacy     |
   | Aware          |                | services or apps  | Net         |
   |                |                | based on ID aware | Neutrality  |
   |                |                | Billing           |             |
   +----------------+----------------+-------------------+-------------+

                         Identifier pros and Cons

5.1.  Identifier Allocation

   Ideally, IDs should be unique and have an easy allocation scheme with
   minimal overhead for the administrators.  It would be desirable to
   support public and private IDs for various use case requirements.  A
   public ID may be visible to the external world or not.  A private ID
   MUST still be unique in order to avoid issues during merges.  IDs may
   be assigned automatically or administratively by configuration.  For
   example, a mobile phone ID may be derived from its IMEI.  Automatic
   ID allocation for an industrial robot coming online for the first
   time will be expected in industrial Internet.  In contrast, other IDs



Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 8]


Internet-Draft                                            September 2016


   may need to be assigned individually depending on the device (health
   monitoring).

5.2.  Identifier Groups, Range and Scope

   Currently, there are various types of IDs with different format and
   meaning across different protocols.  If some entities have similar
   properties such as mobility scope, it may be desirable to allocate
   and manage them as a group, e.g., from the same "address" block" to
   enable aggregation.  Grouping of IDs sharing the same fate as on a
   train or plane should also be possible. .

6.  Network Mapping System (NMS) Requirements

6.1.  Mapping Responsibility

   The responsibility for the mapping may reside with the owner of the
   ID or the owner of the locator.  Both approaches exist today.

   In the DNS, authoritative servers belong to the owner of the DNS name
   space.  In case of mobility, DNS names may be mapped to IP numbers of
   foreign networks.

   In cellular communication systems, mobile phone user may roam into
   the area of another provider where its phone number is registered by
   the foreign mobile communication provider in the Visitor Location
   Register (VLR), i.e., the owner of the infrastructure takes care of
   the mapping.  In case of a phone call, an entry in the Home Location
   Register (HLR) of the mobile communication provider refers to the
   foreign mobile communication provider.  Given the fact that user stay
   most of the time within their country, roaming can be considered a
   rather rare event but that needs to be supported.

   To facilitate scalability, mapping systems may be organized
   hierarchically, e.g., in terms of ID space or locator space which may
   reflect geography.  The responsibility for the mapping may be
   assigned to an appropriated hierarchy level similarly to
   authoritative name servers in DNS.

   For example, sensors networks may be part of a private space and
   limited scope and they would only communicate within a specialized
   application interface or gateway to the internet.  In all these
   cases, it would be beneficial to have a regional allocation authority
   to manage them.







Pillay-Esnault, et al.   Expires March 18, 2017                 [Page 9]


Internet-Draft                                            September 2016


6.2.  Distribution and Redundancy

   For any mapping system to be successful, it will need to be robust,
   distributed and provide redundancy.  The mapping system design and
   architecture must avoid being single points of failure and MUST
   enforce resiliency.

6.3.  Scale and Performance

   A future mapping system will serve multiple applications requiring a
   vast number of entries.  This requires high scalability and
   performance.  Distribution, hierarchy, and aggregation may help to
   achieve these goals.  However, fast query resolution is also an
   important objective to cope with the need for low latency.
   Therefore, the resolution mechanisms must be very efficient.
   Furthermore, mobility support requires that updates can be made
   simply, fast, and as needed.  Last but not least, an ID should be
   able to be aggregated for scalability reasons, but the system should
   be flexible enough to disaggregate them if needed.

6.4.  Mapping System Security

   The secure mapping system must have the following requirements:

   1.  The components of the mapping system need to be robust against
       direct and indirect attacks.  If any component is attacked, the
       rest of the system should act with integrity and scale and only
       the information associated with the compromised component is made
       unavailable.

   2.  The addition and removal of components of the mapping system must
       be performed in a secure matter so as to not violate the
       integrity and operation of the system and service it provides.

   3.  The information returned by components of the mapping system
       needs to be authenticated as to detect spoofing from
       masqueraders.

   4.  Information registered (by publishers) to the mapping system must
       be authenticated so the registering entity or the information is
       not spoofed.

   5.  The mapping system must allow request access (for subscribers) to
       be open and public.  However, it is optional to provide
       confidentiality and authentication of the requesters and the
       information they are requesting.





Pillay-Esnault, et al.   Expires March 18, 2017                [Page 10]


Internet-Draft                                            September 2016


   6.  Any information provided by components of the mapping system must
       be cryptographically signed by the provider and verified by the
       consumer.

   7.  Message rate-limiting and other heuristics must be part of the
       foundational support of the mapping system to protect the system
       from invalid overloaded conditions.

   8.  The mapping system should support some form of provisioned
       policy.  Either internal to the system or via mechanisms for
       users of the system to describe policy rules.  Access control
       should not use traditional granular-based access lists since they
       do not scale and are hard to manage.  By the use of token- or
       key- based authentication methods as well as deploying multiple
       instances of the mapping system will allow acceptable policy
       profiles.  Machine learning techniques could automate these
       mechanisms.

6.5.  Flexibility for Next Generation Apps

   A mapping server could be a place to store metadata of interest that
   will facilitate deploying new capabilities such as context awareness
   in next generation applications and protocols.  As always there are
   tradeoffs on the type of metadata stored and its usage.  It is
   assumed that the metadata use is directly related to the use cases
   described in the document.

7.  Use Cases

7.1.  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, TCP
   (transport) connections should remain functional 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:

      - Mobility of nodes within a single provider network

      - Mobility of nodes between provider networks




Pillay-Esnault, et al.   Expires March 18, 2017                [Page 11]


Internet-Draft                                            September 2016


      - Mobility of subnet (within a provider network or between them)

7.1.1.  Mobility within a single provider network

   Figure 1 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).  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.


   +-------+
   | UE.A  |-----+
   +-------+     |
                 |
   +-------+  +-----+                                           +-----+
   | UE.B  |--|Base1|-----+                    __________    +--|Host1|
   +-------+  +-----+   __|___                /          \   |  +-----+
                       /       \   +-----+   (            )--+
                      (   RAN   )--| MGW |-- (  Internet  )
                       \_______/   +-----+   (            )--+
              +-----+      |                  \__________/   |  +-----+
              |Base2|------+                                 +--|Host2|
              +-----+                                           +-----+
                 |
   +-------+     |
   | UE.C  |-----+
   +-------+


















Pillay-Esnault, et al.   Expires March 18, 2017                [Page 12]


Internet-Draft                                            September 2016


   +-------+
   | UE.A  |-----+
   +-------+     |
                 |
   +-------+  +-----+                                           +-----+
   | UE.B  |--|Base1|-----+                    __________    +--|Host1|
   +-------+  +-----+   __|___                /          \   |  +-----+
                       /       \   +-----+   (            )--+
                      (   RAN   )--| MGW |-- (  Internet  )
                       \_______/   +-----+   (            )--+
              +-----+      |                  \__________/   |  +-----+
              |Base2|------+                                 +--|Host2|
              +-----+                                           +-----+
                 |
   +-------+     |
   | UE.C  |-----+
   +-------+


   The role of the mapping gateway is to map destination addresses on
   ingress packets into the network to deliver packets to the
   destination.  Mapping gateways maintain a list of identifiers to
   locator mappings.  Hosts on the Internet only know the identifier of
   the mobile nodes, packets sent from the Internet are routed to a
   mapping gateway that is able to map the destination to a locator 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 routed across the Internet to the provider's network
   based on the identifier address.  A mapping gateway receives the
   packet.  The destination address of a packet (identifier) is looked
   up in the mapping table.  The return result is the locator address
   for UE.A.  The MGW modifies the packet so that the destination
   address is the locator for UE.A (either by encapsulation or address
   translation).  The packet is then sent on the network and routed 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 routed to a mapping gateway.  The Mapping gateway 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



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 13]


Internet-Draft                                            September 2016


   would maintain a subset of mappings in the network that are being
   used for communications by the attached UEs to other devices in the
   network.  A protocol would be run between the base stations and
   mapping gateways to populate and invalidate entries in the cache.

   Now consider that UE.B changes locations so that it is now attached
   to Base2 (figure 2).


   +-------+
   | UE.A  |-----+
   +-------+     |
                 |
              +-----+                                           +-----+
              |Base1|----+                    __________     +--|Host1|
              +-----+  __|___               /           \    |  +-----+
       |              /       \   +-----+   (            )--+
       |             (   RAN   )--| MGW |-- (  Internet  )
       V              \_______/   +-----+   (            )--+
   +-------+  +-----+     |                  \__________/    |  +-----+
   | UE.B  |--|Base2|-----+                                  +--|Host2|
   +-------+  +-----+                                           +-----+
                 |
   +-------+     |
   | UE.C  |-----+
   +-------+


   The mapping gateways 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 routed to an
   old destination.  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.  Alternatively, a predictive
   algorithm can be used to forward packets ahead of the move.

7.1.2.  Mobility between Provider Networks

   Consider the example network topology in figure 3.  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.





Pillay-Esnault, et al.   Expires March 18, 2017                [Page 14]


Internet-Draft                                            September 2016


   +-------+
   | 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 the networks are able to share mapping information.
   Consider that UE.B moves to the other carrier network (figure 4).


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



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 15]


Internet-Draft                                            September 2016


   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 locator (mapping to
       Base_station2) and the MGW sends directly to that locator

   2.  The packet is mapped so that it is routed 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.1.3.  Mobility of a Subnet

   Figure 5 presents a topology where UE.A, UE.B, and UE.C are behind a
   subnet and the whole subnet may itself be mobile (for instance a WIFI
   network on a bus).  To treat the subnet as an aggregate the subnet is
   reflected in the identifier address.  A single mapping entry then
   could represent this 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 6).  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



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 16]


Internet-Draft                                            September 2016


   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.

7.1.4.  Transport Layer Mobility

   Identifier mobility, as described above, has the advantage that is it
   transparent to end hosts (UEs and hosts on the Internet).  The
   disadvantage is that it is not supported in all networks and sharing
   mappings between carriers may be prohibitive or a least take a long
   time to be widely deployed.  An alternative is to use a transport
   protocol that implements disassociated location, such as in QUIC and
   Transports over UDP (TOU).

   When the location is decoupled, the transport layer endpoints no
   longer consider the IP addresses in identification.  Instead a
   connection identifier is negotiated between two peers.  The
   connection identifier is unique amongst all connections to a peer, so
   when a packet is presented with a connection identifier it can be
   used to unambiguously identify the connection and the peer regardless
   of what the source address is.  Disassociated location works in
   tandem with strong encryption to prevent hijacking of connections.
   In this manner disassociated location allows mobility without losing
   connectivity.

   Multi-path TCP (MPTCP) [RFC6182] is another alternative that allows
   TCP connections to be mobile.  The downside of MPTCP is that the host




Pillay-Esnault, et al.   Expires March 18, 2017                [Page 17]


Internet-Draft                                            September 2016


   needs to have insight into the underlying network topology in order
   to create multiple paths.

7.2.  Session Continuity in Heterogeneous Multi-Access Environments

   As the Internet is experiencing a transition from the fixed host-
   server model to one which mobile platforms are the norm, a next-
   generation protocol architecture, which provides integrated and
   efficient support for advanced host and network mobility services,
   becomes a necessity.

   In terms of host mobility, the current mobile network architecture is
   unable to natively support session continuity.  Intra-network
   mobility (mobility across a single access network) and inter-network
   mobility (mobility across heterogeneous access networks) are achieved
   through the usage of mobility anchors.  These solutions generate
   problems like high latency, session disruptions (due to rerouting,
   triangular routing, unpredictable and sporadic disconnections and
   dynamic IP assignment) and lack of a common framework to inherently
   support mobility across heterogeneous access networks.  In addition
   dynamic network formation and network mobility has limited support in
   the current Internet infrastructure.

   Newer breeds of applications such as Augmented Reality, Virtual
   Reality, drone or robotic control have near real-time latency
   requirements below 10ms.  On the other hand, multimedia streaming
   services (4k, 360-degree video) have real-time latency requirements
   in the range of ~100ms.  In addition, the very low latency (<5ms)
   higher bandwidth and speed expected in the 5g networks will be
   another challenge for solutions relying on buffering for continuity.
   The solutions based on mobility anchors and rerouting buffered data
   will not work efficiently for session continuity with very low
   latency requirements.

   The principal requirements of the design of future networks for
   native support of mobility include dynamic mobility of end-hosts and
   networks across heterogeneous access networks, multi-network access
   support, late binding capability and disconnection-tolerant routing.

7.2.1.  Dynamic Mobility across Heterogeneous Access Networks

   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.



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 18]


Internet-Draft                                            September 2016


   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.

   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.

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

7.2.2.  Multi-network Access Support

   A typical mobile hand-held device can see multiple available networks
   at the same time.  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 economical" 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
   routing 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.

7.2.3.  Late Binding Capability

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



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 19]


Internet-Draft                                            September 2016


   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.

7.2.4.  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 reacts adversely to
   disconnections and has a slow re-connection and end-to-end setup
   delays, whereas unreliable protocols like UDP simply drops packets 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.

7.3.  Cross-Silo Communication

   The IoT landscape is comprised of many devices and protocols.  Often,
   protocols are chosen due to constraints in the solution - for example
   a small CPU/Memory footprint does 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.

   There is little commonality and almost no interoperability between
   IoT consumer devices and many rely on their own network
   implementation.  The use of gateways within IoT solution is common;
   areas which have several IoT solutions for different applications
   will often have more than one gateway.  The common point is usually
   at the conventional IP network CPE device.

   Whilst such an approach has allowed for rapid innovation in terms of
   IoT applications, the ability to harness the data within an entire
   domain and share it between different applications to generate
   results-based outcomes is more complex to achieve where data remains
   in silo-ed networks.

   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



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 20]


Internet-Draft                                            September 2016


   is too broad for them to be a single presentation which 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 which have been designed and optimized for the application,
   environment and devices which they target.

   Therefore, any co-joining of data must happen at a layer above the
   current network and in a way which allows for a consistent exchange
   of data.  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 the location of the
   overlay ID system.  It is expected that within a single domain, such
   an ID scheme would allow data exchange between adjacent 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).

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

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

   2.  Handling and parsing data headers is intensive work for the
       network processing elements and as such consumes power.  In some
       cases (e.g. data generated by a mobile handset as seen on the
       backhaul link between the cell-site and the aggregation point),
       there may be 9 or 10 address elements around the data.  Even if
       the data remains large compared to the address, there is still
       the need to parse and understand one-or-more of these network
       elements.  This requires compute resources which in turn requires



Pillay-Esnault, et al.   Expires March 18, 2017                [Page 21]


Internet-Draft                                            September 2016


       power.  Simplifying the overhead will result in more energy-
       efficient network solutions.

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

   4.  Likewise, applying a policy to data-traffic, for example, QoS
       characteristics, often requires that data is traced through the
       network and policies applied based on known paths.  The Per-Hop-
       Basis of DHCP provides some labeling of traffic, but it can be
       easily over-written and runs as a parallel path to the data.  An
       inherent ID as part of the end-to-end communication would allow
       intermediate systems to identify and apply policies throughout
       the lifetime.

7.5.  Ease of Provisioning

   The ease of provision become crucial as an unprecedented scale of
   disjoint IoT devices come online.  There are two main scenarios where
   ID may simplify provisioning:

   1.  1.  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. ( E.g.  Diverse entities such as Industrial
       robots or sensors having an ID may access the factory network and
       be redirected to a private network mapping system.  They may then
       authenticate and register themselves.  If the NMS has some
       metadata for configuration stored for these IDs, the entities
       could be automatically bootstrapped.  Changes of configuration
       need only be done on the NMS in the future without individually
       accessing each device.

   2.  2.  Active User driven Provisioning.  Bulk provisioning.  IoT
       devices deployed in large numbers in a given coverage area should
       be provisioned and authenticated in bulk; e.g.  Smart agriculture
       for herd inventory) Lightweight simplified device configuration.
       (e.g. health monitors, Pet tracking devices)







Pillay-Esnault, et al.   Expires March 18, 2017                [Page 22]


Internet-Draft                                            September 2016


8.  Security Considerations

   This document does not introduce any new security concerns.

9.  IANA Considerations

   This document has no actions for IANA.

10.  Contributors

   The authors would like to acknowledge the contributions of

      Rutgers University: Parishad Karimi and Shreyasee Mukherjee

      Huawei: Chencheng, Yangfei, Tingfan Tang, Mengrui and Salvatore
      Talarico

      Stewart Bryant

11.  Acknowledgments

   The authors would like to thank Renwei Li, Jeff Tansura, Lin Han and
   Kiran Makhijani and Jean-Michel Esnault who participated in numerous
   discussions.

   This document was produced using Marshall Rose's xml2rfc tool.

12.  References

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

   [RFC4984]  Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
              from the IAB Workshop on Routing and Addressing",
              RFC 4984, DOI 10.17487/RFC4984, September 2007,
              <http://www.rfc-editor.org/info/rfc4984>.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
              <http://www.rfc-editor.org/info/rfc6182>.






Pillay-Esnault, et al.   Expires March 18, 2017                [Page 23]


Internet-Draft                                            September 2016


   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <http://www.rfc-editor.org/info/rfc6740>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <http://www.rfc-editor.org/info/rfc7401>.

12.2.  Informative References

   [ILA]      Herbert, T., "Identifier-locator addressing for network
              virtualization", March 2016,
              <https://datatracker.ietf.org/doc/draft-herbert-
              nvo3-ila/>.

Authors' Addresses

   Padma Pillay-Esnault (editor)
   Huawei
   2330 Central Expressway
   Santa Clara,  CA 95050
   USA

   Email: padma@huawei.com


   Dino Farinacci
   lispers.net
   San Jose  California
   USA

   Email: farinacci@gmail.com


   Dave Meyer
   Brocade

   Email: dmm@1-4-5.net






Pillay-Esnault, et al.   Expires March 18, 2017                [Page 24]


Internet-Draft                                            September 2016


   David Lake
   Cisco Systems

   Email: dlake@cisco.com


   Tom Herbert
   Facebook

   Email: tom@herbertland.com


   Michael Menthe
   University of Tuebingen

   Email: menth@uni-tuebingen.de


   Dipenkar (Ray) Raychaudhuri
   Rutgers University

   Email: ray@winlab.rutgers.edu


   Julius Mueller
   ATT

   Email: jm169k@att.com























Pillay-Esnault, et al.   Expires March 18, 2017                [Page 25]