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, . [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, . [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, . 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, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [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, . 12.2. Informative References [ILA] Herbert, T., "Identifier-locator addressing for network virtualization", March 2016, . 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]