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]