ETSI GR NGP 004 V1.1.1 (2018-01)

Next Generation Protocol (NGP); Evolved Architecture for mobility using Identity Oriented Networks

DGR/NGP-004

General Information

• Status: Published
• Publication Date: 18-Jan-2018
• Technical Committee: NGP - Next Generation Protocols
• Current Stage: 12 - Completion
• Due Date: 06-Feb-2018
• Completion Date: 19-Jan-2018

Standards Content (Sample)

GROUP REPORT
Next Generation Protocol (NGP);
Evolved Architecture for mobility using
Identity Oriented Networks
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR NGP 004 V1.1.1 (2018-01)

Reference
DGR/NGP-004
Keywords
GRIDS, identity, ION, IoT, mapping system,
mobility
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR NGP 004 V1.1.1 (2018-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Identity Oriented Networks (IONs): Architecture Overview . 9
4.1 Introduction . 9
4.2 Key Aspects of the Architecture . 10
4.2.1 Identifier and Location Decoupling . 10
4.2.2 Identifier Allocation . 12
4.2.3 Identifier Groups, Range and Scope . 13
4.2.4 Identifier Structure and Life Span . 13
4.3 Mapping and Generic Identity Services Infrastructure (GRIDS) . 13
4.4 Mapping Service Responsibility . 15
4.5 Mapping System design principles . 16
4.5.1 Distribution and Redundancy . 16
4.5.2 Scale and Performance . 16
4.5.3 Performance Optimization . 16
4.5.4 Flexible, Open and Efficient Mapping System Interfaces . 16
4.6 Forwarding Infrastructure . 16
5 Next Generation ION Network Architecture . 17
5.1 ION Network Architecture . 17
5.2 Future Control Plane . 19
5.3 Future User Plane . 20
5.4 Data Plane Agnostic Solution . 20
6 Functionalities Supported . 21
6.1 Registration and reachability management . 21
6.1.1 Registration management . 21
6.1.2 Reachability management . 21
6.2 Mobility management . 22
6.2.1 Mobility changes . 22
6.2.2 Mobility without UPF change . 22
6.2.3 Mobility with UPF change . 23
6.2.4 Mobility with Predictive movement . 24
6.3 Confidentiality and Security . 24
6.3.1 Privacy . 24
6.3.2 Verification . 24
6.3.3 Security . 25
6.3.4 Mapping and Services System Security . 25
6.4 Heterogeneous Multi-Access Support . 25
6.5 Edge computing . 26
6.6 IoT Support . 27
6.7 Automatic Bootstrapping . 28
7 Summary . 28
ETSI
4 ETSI GR NGP 004 V1.1.1 (2018-01)
Annex A: Authors & contributors . 29
History . 30

ETSI
5 ETSI GR NGP 004 V1.1.1 (2018-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Next Generation Protocols
(NGP).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
This work item focuses on using Identity Oriented Networks (ION) for next generation architectures toward 5G and
beyond. The basic concept and goal behind ION is to dissociate the identifier and temporal location information for an
entity. Ideally, this goal should endeavour for deployment to support current architectures while also enabling more
optimal future architectures. The work aims to examine and propose recommendations to improve and simplify the
network infrastructure to support mobility natively by adopting ION. In addition, the work item may require the
development of new protocols and/or modification of existing protocols.
ETSI
6 ETSI GR NGP 004 V1.1.1 (2018-01)
Introduction
The Internet is seminal for communication technologies and is a powerful enabler for modern applications with
connectivity needs. However, when the Internet was designed the requirements were wildly different from the
applications to be enabled by 5G infrastructure. Forty years ago, no one expected the user behaviour to evolve from text
based fixed Internet access to streaming 4K quality media over a mobile device with session continuity. Mobility
support is today the norm and new solutions should be examined for the network to support these new capabilities. As
the Internet is pervasive and therefore these solutions should still interoperate with the current architecture.
Today the user's expectation and experience is at the forefront driving the requirements of applications such as session
continuity, augmented reality, virtual reality or high definition video. Most importantly perhaps, the future deployment
of 5G gives a unique opportunity to examine how core technologies may be modified, enhanced or replaced for a more
secure, robust and optimized architecture for the future mobile networks.
With this in focus, the present document reviews the current state-of-art of Identity-oriented solutions (ION), and
provides recommendations toward new protocols and/or modification of existing ones in the context of ION.

ETSI
7 ETSI GR NGP 004 V1.1.1 (2018-01)
1 Scope
The present document provides an overview of existing identity oriented protocols, mapping systems and proposes next
generation mobility with a generic and resilient identity services infrastructure.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] Number of Mobile-Only Internet Users Now Exceeds Desktop-Only in the U.S.
NOTE: Available at https://www.comscore.com/Insights/Blog/Number-of-Mobile-Only-Internet-Users-Now-
Exceeds-Desktop-Only-in-the-U.S.
[i.2] Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2016-2021 White
Paper.
NOTE: Available at http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-
vni/mobile-white-paper-c11-520862.html.
[i.3] M. Hoefling, M. Menth, and M. Hartmann: "A Survey of Mapping Systems for Locator/Identifier
Split Internet Routing", IEEE Communications Surveys & Tutorials, vol. 15, n. 4, Fourth Quarter
2013.
[i.4] International roaming explained.
NOTE: Available at http://www.gsma.com/publicpolicy/wp-content/uploads/2012/09/Africa-International-
roaming-explained-English.pdf.
[i.5] IETF draft-herbert-nvo3-ila: "Identifier-locator addressing for network virtualization", T. Herbert.
NOTE: Available at https://tools.ietf.org/html/draft-herbert-nvo3-ila-00.
[i.6] IETF draft-padma-ideas-problem-statement: "Problem Statement for Identity Enabled Networks",
P. Pillay-Esnault, M. Boucadair, C. Jacquenet, G. Fioccola, A. Nennker.
NOTE: Available at https://datatracker.ietf.org/doc/draft-padma-ideas-problem-statement-01.
[i.7] ETSI GS NGP 001: "Next Generation Protocol (NGP); Scenario Definitions".
[i.8] IETF RFC 6301 (July 2011): "A Survey of Mobility Support in the Internet", Z. Zhu,
R. Wakikawa, and L. Zhang.
[i.9] IETF RFC 3753 (June 2004): "Mobility Related Terminology", J. Manner, and M. Kojo.
ETSI
8 ETSI GR NGP 004 V1.1.1 (2018-01)
[i.10] ETSI TS 124 301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) (3GPP
TS 24.301)".
[i.11] ETSI TS 136 300: "Access Network (E-UTRAN); Overall description; Stage 2 (3GPP
TS 36.300)".
[i.12] ETSI TS 123 060: "Access General Packet Radio Service (GPRS); Service description (3GPP
TS 23.060)".
[i.13] ETSI TS 129 060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp Interface (3GPP TS 29.060)".
[i.14] IETF RFC 6275 (July 2011): "Mobility Support in IPv6", C. Perkins, D. Johnson, and J. Arkko.
[i.15] IETF RFC 5213 (August 2008): "Proxy Mobile IPv6", S. Gundavelli, K. Leung, V. Devarapalli,
K. Chowdhury and B. Patil.
[i.16] IETF RFC 5949 (September 2010): "Fast Handovers for Proxy Mobile IPv6", H. Yokota,
K Chowdhury, R. Koodli, B. Patil, and F. Xia.
[i.17] IETF RFC 6740 (November 2012): "Identifier-Locator Network Protocol (ILNP) Architectural
Description", Atkinson, RJ. and SN. Bhatti.
[i.18] IETF RFC 6830 (January 2013): "The Locator/ID Separation Protocol (LISP)", D. Farinacci,
V. Fuller, D. Meyer and D. Lewis.
[i.19] IETF RFC 7401 (April 2015): "Host Identity Protocol Version 2 (HIPv2)", R. Moskowitz, T. Heer,
P. Jokela and T. Henderson.
[i.20] 3GPP TS 22.261: "Service requirements for next generation new services and markets".
[i.21] IETF draft-ietf-lisp-predictive-RLOCs: "LISP Predictive RLOCs", D. Farinacci, P. Pillay-Esnault.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
binding: process of binding an identifier to its associated LOC(s), based on a lookup/query of the NMS
entity: device or node or a process, which needs to be identified in a network
Identifier (IDf): name that can be used to identify an entity unambiguously within a scope
Identity(IDy): identity of an entity used to securely access the mapping system and to enhance anonymity and privacy
locator: routable address in a network
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
5G Fifth Generation Mobile Networks
BGP Border Gateway Protocol
DHT Distributed Hash Table
DNS Domain Name System
DNSSEC Domain Name System Security Extensions
EMM EPC Mobility Management
EPC Evolved Packet Core
ETSI
9 ETSI GR NGP 004 V1.1.1 (2018-01)
GMM GPRS Mobility Management
GPRS General Packet Radio Service
GRIDS Generic Resilient Identity Services
HLR Home Location Register
IDf Identifier
IDMS Integrated Database Management System
IDy device identity
ION Identity Oriented Network
IoT Internet of Things
IP Internet Protocol
ISP Internet Service Provider
LTE Long Term Evolution
MIP Mobile IP
NMS Network Mapping System
NMSFK Network Mapping System with Full Knowledge
NMSPK-LL Network Mapping System with Partial Knowledge using Local Lookup
NMSPK-SRL Network Mapping System with Partial Knowledge using Single Remote Lookup
NMSPK-IRL Network Mapping System with Partial Knowledge using Iterative Remote Lookup
NMSPK-HSO Network Mapping System with Partial Knowledge with Hierarchically Structured Overlay
NMSPK-DHT Network Mapping System with Partial Knowledge with Distributed Hash Table
NMSPK-MCO Network Mapping System with Partial Knowledge with Multicast Overlay
PKI Public Key Infrastructure
UE User Equipment
VLR Visitor Location Register
VPN Virtual Private Network
4 Identity Oriented Networks (IONs): Architecture
Overview
4.1 Introduction
The current Internet architecture, which has been built with and on top of the Internet Protocol (IP), was designed for a
very different environment from modern networks. Early versions of the Internet Protocol were designed in the 1970's.
The Internet protocol architecture has evolved over time since then, largely as a result of the Internet Engineering Task
Force (IETF) organization. However, the landscape of networks has changed dramatically and many of the initial
Internet architecture tenets have changed too.
As an example of one of these dramatic Internet architectural changes, today many Internet references cite that 70 % of
the access sessions setup towards it are originated on a mobile device. However, at the start of the Internet design, the
notion of mobility was not even considered.
Today, mobility is a major Internet requirement, and the number of users operating mobile devices has exploded,
overtaking the number of fixed PC connections in 2014 [i.1]. According to reference [i.2], the projected growth of
mobile devices is 1,5 per person, reaching a staggering total number of 11,6 billion connections by 2020. To cement a
more near-term understanding of this trend, that global mobile data traffic has increased by 74 % in 2015 (according to
reference [i.2]). Indeed, ubiquitous mobility is the norm and here to stay.
It is also very important to highlight that both the definition of mobility and its correlated requirements in the networks
have drastically changed over time. For instance, in order to transit from LTE to 5G, the network requirements have
become more stringent with respect to KPIs for latency, reliability, throughput, etc. [i.20]. This increase, in conjunction
with evolving user behaviour, presents many technical challenges in the current Internet architecture in order to meet
the requirements of future networks. Furthermore, due to the huge success of the Internet, there are many other non-
technical issues that impact the Internet architecture: for instance those related to economical, or user behaviour. All of
these technical and non-technical aspects need to be taken into account in the future solutions for any Internet
architecture and protocol evolution (as detailed in ETSI GS NGP 001 [i.7]). In order to meet the aforementioned
challenges of the current architecture based on IP, the present document introduces Identity Oriented Networks (IONs)
as a candidate solution and provides a novel framework for next generation networks using a holistic approach.
Furthermore, the present document extends some of the recommendations provided in ETSI GS NGP 001 [i.7] with
respect to IONs.
ETSI
10 ETSI GR NGP 004 V1.1.1 (2018-01)
4.2 Key Aspects of the Architecture
4.2.1 Identifier and Location Decoupling
This clause, introduces the key aspects of the ION architecture focusing on the fundamental importance of separating:
i) identifier; and
ii) location for each Entity within the network.
Furthermore, it provides an overview of the possible Entity identifier binding approaches and listing the pro and cons
for each solution.
A mobile entity that intends to operate mobility needs three basic components (see references [i.7] to [i.11]):
a) An identifier, which univocally identifies an entity in the network. This is a static mobile entity identifier, in
the context of the mobility system it wants to use.
b) A locator, which provides information regarding the current location of an entity. This is typically the static
address of the Access Point that the mobile entity wants to connect to or be reachable from.
c) A network mapping system that creates a temporal binding of the identifier and the locator.
Additionally, new optional services can be possible with an Identity (IDy) (see reference [i.6]) for identifiers associated
with it. These services namely access control, authorization of who can resolve location of an identifier use policy and
metadata tied to Identity.
In a fixed network, an IP address has an overloaded semantic and it represents both the identifier and location of an
entity. In the Internet Protocols, these two components were effectively bound, co-located, and somewhat immutable.
As the network evolved, new breeds of devices have been introduced, which are increasingly highly mobile, and there
has been an increased need to individually distinguish a multitude of applications that run on a device. However, the
traditional methodologies, which use well-known ports and data forwarding, such as in mobile IP (MIP), [i.8] and [i.14]
to [i.16] or 3GPP EPC mobility management (EMM) and GPRS mobility management (GMM) [i.12], solve the
problem inefficiently. MIP binds a temporary IP address to a static IP address while in 3GPP (EMM and GMM) a
temporary IP address to 3GPP Base Station IP address and Mobile Identifier. In 3GPP, the mobility structured
Hierarchy of Identifiers is as follows:
1) Cells;
2) Tracking Areas;
3) Networks; and
4) Countries.
In order to maintain session continuity, the mobile device needs to retain some identifier that allows the communication
to be seamless. In fact, when a device moves, the only component that changes is its location or its access point and not
its identifier, however, today's overloaded semantic of an IP address for identifier and locator make them
indistinguishable, therefore the only solution is to retain the IP address. However, holding on to an IP address during
mobility requires solutions such as anchoring or reforwarding that introduce delays.
In order to overcome these issues, the ION architecture proposes to separate the identifier and location components. In
ION the following components are present:
1) Entity identifier - identifies unambiguously entities within a scope.
2) Locator address -provides a location that is decoupled from the entity identifier.
ETSI
11 ETSI GR NGP 004 V1.1.1 (2018-01)
This proposal does not intend to change the IP infrastructure, and proposes to work in a backward compatible manner
with the current Internet, since the concept behind ION is applicable to any underlying network infrastructure. The basic
idea beyond our proposal is to insert a naming/identifier sub-layer in the protocol stack, generally as an over-layer of IP
stack as shown in figure 1. The Identity oriented architecture relies on defining the identifier of the entity and a mapping
or binding to the location of the entity in order to forward traffic. The identifier namespace comprises the whole IPv4
and IPv6 address space to enable it to interoperate with traditional applications, while newer applications can use the
newly defined identifier, which may not be necessarily IP address namespace. In alternative, the Identity oriented
:
architecture may also reside directly on the L2 level in this case the mapping is between the identifier and the L2 layer.
The evolved architecture using Identity oriented networks aims at using the IP addressing, but inserting an Identifier
layer and gives new possibilities to change the upper layer by having identifier aware applications above the identifier
layer.
Application
Layer 4
NGP
Layer 3.5
Identifier
Layer 3
NGP ANY
Layer 2
Access Technology
NOTE: In reality the Identifier layer can be mapped to any layer used for forwarding or route locators.

Figure 1: Proposed stack
It is possible to have multiple locations for an identifier in case an entity is multi-homed. This case brings lot of
complexity in today's IP networks because of the already overloaded semantics of identifier and location with IP.
However the decoupling will give greater flexibility for multi homing cases.
An important characteristic of the identifier format is that it needs to satisfy or facilitate several requirements, which are
both technical and non-technical. One approach is to have a "dumb" identifier, which only serves the purpose of
identifying an entity, and nothing more. Another alternative is format the identifier by conferring to it some properties
inherently. Table 1 captures the main pros and cons of some of the characteristics the format could have. While table 1
is not exhaustive, it provides an idea of the number of parameters, which are potentially connected to the identifier
infrastructure.
ETSI
12 ETSI GR NGP 004 V1.1.1 (2018-01)
Table 1: Characteristics of an identifier format: Pros and Cons
Identifier format Pros Cons
characteristics
Large name space Need to account for billions of devices, Very large space - Might become hard to
scalable manage in the long run, and likely to reduce
performance
Unique Global Identifier It facilitates the creation of a unique mapping It leads to possible lack of privacy, and
service. Requires access to a mapping security risks. Robo Calls once your phone
service, an entity can be easily identified number is known, One mitigation is the use
through its identifier. Efficiency depends on of ephemeral identifier and change it often
latency of mapping in hardware or forwarding
path
Multiple Identifiers It allows multiple identifiers, which may have Complexity
multiple classes of services. Preserve privacy
by allowing some identities to be ephemeral
Easily mapped It provides backward compatibility with Mappings need to be fast. In mobile
/Translatable to IP existing apps. It is cost effective, since no technology this is done in the firmware for
changes are required for the base RAN and SW in for core but it is expensive
infrastructure
Variable Length It provides backward compatibility with It leads to high implementation costs
existing apps It is cost effective. It also can
work with both IPv4 and ipv6 as well as
non-IP solutions
Non-Encrypted Ease of use and troubleshooting Security Risk
Encrypted It increases the level of security It is not human readable. It is hard to use,
and troubleshoot
Human Readable Human Manageable. Ease to use Security Risk
Hierarchical Easy to look up. Easy assignment Need Identifier with structure. Lack of
privacy and security risks as the root has
access to all
Non-Structured Need to ensure no collision. Can use Might be harder to manage look-up scale
crypto-keys. Complete freedom
Range or scope Easier to have hierarchy in mapping systems. Confidentiality
Administrative Domain control easier. Lawful
interception
Geographical awareness Easier for incremental deployment Privacy, confidentiality, tracking
Administrative control per AS or ISP. Policy
possible per administrative domain
Provider Dependency Locked in, Migration
Structured Under this solution, it is easier to have Masquerading, Misconfiguration, Maliciously
orthogonal distributed systems, where each Misrepresenting
of them identifies a different type of devices
(i.e. mobiles, IoT ephemeral, etc.),
apps/processes, and slices. It is possible to
classify the entities and customize
behaviours, services and apps. The name
identifies type of objects (e.g. a fridge is not
mobile, and will not belong to smart home)
Context-aware It allows to perform instantiation. It allows Privacy, Net Neutrality
customize behaviours, services and
applications based on Identifier awareness
billing
4.2.2 Identifier Allocation
Ideally, identifiers should be unique and have an easy allocation scheme with minimal overhead for the administrators.
It would be desirable to support public and private identifiers for various use case requirements. Public identifiers may
be visible to the external world or not. Private identifiers should still be unique in order to avoid issues during merges.
The method of allocation of identifiers may be automatically or administratively by configuration. It is also possible for
an entity to select its identifiers and register with provider. However the user selected identifiers should be checked for
uniqueness at the provider or in the mapping infrastructure storing the identifiers-location pairs.
ETSI
13 ETSI GR NGP 004 V1.1.1 (2018-01)
4.2.3 Identifier Groups, Range and Scope
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 "identifier block" to enable aggregation. Grouping of identifiers sharing the same context,
such as on a train or plane should also be possible. These identifier groups may also be used for policy controls
eventually or the controls could also be delegated at the time of mapping binding and requests.
4.2.4 Identifier Structure and Life Span
The identifier should be unique in order to facilitate interoperability and simplify the implementation of some use cases.
More precisely, the format may be different as long as there sufficient information for the encapsulation decode. A
collision detection mechanism such as already in place in several solutions should be put in place in case of automatic
allocation.
Finally, it is possible to have ranges for automatic allocation and for manual allocation or it should be possible to at
least have private or public instances.
4.3 Mapping and Generic Identity Services Infrastructure
(GRIDS)
This clause provides an overview of mapping infrastructures, which is one of the central services of a GeneRic Identity
Service (GRIDS) used for mobility, and the current available solutions.
The main functionality of a mapping service provided by GRIDS is to map or bind the identifier associated to an entity
within a network with its physical location. An overview of several mapping options for Identity oriented networks is
given in [i.3], and the classification and table is expanded and provided here for reference. The network mapping
systems are classified into seven groups:
a) Network mapping system with full knowledge (NMSFK)- it is composed by a centralized network mapping
system, composed by a single mapping server that contains full knowledge on how to map identifiers to LOCs.
b) Network mapping system with partial knowledge using local lookup (NMSPK-LL) - it is composed by a
distributed network mapping system, composed by a plurality of mapping servers. The information related to
which mapping server needs to be accessed in order to retrieve mapping for a specific identifier is contained
into local lookup tables.
c) Network mapping system with partial knowledge using single remote lookup (NMSPK-SRL) - it is composed
by a distributed network mapping system, composed by a plurality of mapping servers. In this case the lookup
table that contains information related to which mapping server needs to be accessed in order to retrieve
mapping for a specific identifier is contained into a global lookup table.
d) Network mapping system with partial knowledge using iterative remote lookup (NMSPK-IRL) - it is
composed by a distributed network mapping system, composed by a plurality of mapping servers. In this case
in order to find the network mapping server that contains the information queried, an iterative process is
established: the request is directed initially to the highest authoritative server, which if not in possess of the
requested information, provides feedback referral to a lower level authoritative server. If this new server does
not have the requested mapping information, it refers to a lower authoritative server. This process continues
until mapping server with the wanted mapping information is discovered.
e) Network mapping system with partial knowledge with hierarchically structured overlay (NMSPK-HSO) - it is
composed by a distributed network mapping system, composed by a plurality of mapping servers. In this case
the mapping servers are ordered in a hierarchical manner and the mapping information are retrieved following
this overlay structure.
f) Network mapping system with partial knowledge with distributed hash table (NMSPK-DHT) - it is composed
by a distributed network mapping system, composed by a plurality of mapping servers. In this case the
mapping servers are clustered in distributed hash tables (DHTs), and the mapping information are retrieved
through referrals among DHTs.
ETSI
14 ETSI GR NGP 004 V1.1.1 (2018-01)
g) Network mapping system with partial knowledge with multicast overlay (NMSPK-MCO) - it is composed by a
distributed network mapping system, composed by a plurality of mapping servers. In this case the mapping
servers are grouped in multicast groups, and the query is sent in multicast.
Table 2 provides a thorough summary of the currently available network mapping systems for ION solutions.
Table 2: Summary of available or already proposed network mapping systems for ION
Name Structure Scalability Resilience Security Relaying
LISP-NERD Hierarchical MSs store partition of mappings and Replication of X.509 Yes
(NMSFK) ingress tunnel routers (ITRs) MSs certificates
assemble complete mapping table.
APT (NMSFK) Hierarchical Default mappers (DMs) know all Replication of Digital Yes
mapping information. DMs signatures
FIRMS (NMBPK- Flat and ITRs/MSs know global table. Replication all X.509, PKI Yes
LL) hierarchical components
"HiiMap"(NMSPK- Flat and One regional prefix per EID, large Replication, PKI No
SRL) hierarchical storage requirements. DHTs
ILA (NMSPK-SRL) Flat Relies on DNS DNSSEC No
One-Phase Lookup Flat Uses DNS infrastructure. Relies on DNS DNSSEC No
Using Reverse
DNS/
DNSMAP(NMSPK-
IRL)
Two-Phase Lookup Flat Uses DNS infrastructure. Relies on DNS DNSSEC No
Using Reverse
DNS (NMBPK-IRL)
ILNP-DNS Flat Uses DNS infrastructure. Relies on DNS DNSSEC No
(NMSPK-IRL)
Use of DNS for Flat Uses DNS infrastructure. Relies on DNS DNSSEC No
HIT-to-IP Lookup in
HIP
(NMBPK-IRL)
LISP-TREE Flat and Uses DNS infrastructure, optionally Relies on DNS DNSSEC No
(NMSPK-IRL) hierarchical own physical infrastructure based
on DNS software.
LISP-DDT Flat and Based on DNS software. Similar to DNS Similar to No
(NMSPK-IRL) hierarchical DNSSEC
IVIP DRTM Hierarchical Aggregation of mapping Replication of None No
(NMSPK-IRL) information, load balancing between all components
components.
IDMS (NMSPK- Flat and Uses DNS infrastructure, IDMS DNS, replication PKI, digital No
IRL) hierarchical implementation. of MS. signatures
"MobilityFirst" Flat GUID's mapping with late binding. Replication of None No
(NMSPK-IRL) MSs
LISP+ALT Hierarchical BGP aggregation and limitations, Replication of BGP security Optionally
(NMSPK-HSO) complex configuration. all components
LISP-CONS Hierarchical Strict aggregation hierarchy. Replication of Similar to Yes
(NMSPK-HSO) all components, BGP and
redundant DNSSEC
topology
LISP-HMS Hierarchical Strong aggregation of mapping Replication of BGP security No
(NMSPK-HSO) information, DHT. all components
ID/Locator Hierarchical BGP and DHT, aggregation. DHTs None No
Distributed
Mapping Server
(NMSPK-HSO)
IRON (NMSPK- Hierarchical Aggregation. Replication of Mutual Yes
HSO) all components authentication
between
components
RZBS (NMSPK- Hierarchical Similar to DNS. Replication of Trust No
HSO) all components relationships
between sub
realms
LISP-DHT Hierarchical DHT. Replication of X.509 No
(NMSPK-DHT) all components certificates
ETSI
15 ETSI GR NGP 004 V1.1.1 (2018-01)
Name Structure Scalability Resilience Security Relaying
ER+MO (NMSPK- Hierarchical BGP and DHT, aggregation. Replication of BGP security, Yes
DHT) all components Kademlia
security
DHT-MAP Flat DHT. Replication of Digital No
(NMSPK-DHT) all components signatures
HIP-DHT (NMSPK-Flat DHT. DHTs None No
DHT)
RANGI (NMSPK- Hierarchical DHT. DHTs Digital No
DHT) signatures
CoDoNS (NMSPK-Flat DHT. Replication of None No
DHT) all components
MDHT (NMSPK- Flat Multilevel DHT. Replication of None Yes
DHT) all components
LISP-SHDHT Flat and DHT. Replication of None No
(NMSPK-DHT) hierarchical all components
EMACS-LISP Hierarchical Number of multicast groups, Replication of None No
(NMBPK-MCO) unnecessary multicast traffic. MSs
GTP/ EMM Hierarchical Difficult to scale and costly to Provides full Control is Yes
(2 level) support Tunnel Mappings providing cellular support built into
IoN like capability. from mobility Cellular GTP
Proven to scales within network to over IP network
400Million simultaneously Supports 'Flex' signalling: AS
connected subscribers. capability - security and
Scalability between countries is not good R&A NAS security
ideal often involving "tromboning"
back to home network as cheaper
and less complex to do this,
although there is a capability to do
path re-direction when roaming in
3GPP.
M2CNP Flat and
hierarchical
While it is desirable to have different forwarding mechanisms as described in the next clause, there is a case for a
common control plane across all Identifier-aware protocols. While many identifier-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.
4.4 Mapping Service Responsibility
The responsibility for the mapping may reside with the owner of the identifier or the owner of the locator. Both
approaches exist today.
In the DNS, authoritative servers belong to the owner of the DNS namespace. 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.
Today, ISPs, mobile, wireless and fixed networks and VPNs operate geographical boundaries [i.4] or areas of
administration for physical and logical networks and these administrative areas form natural boundaries for some of the
mapping server capabilities required to operate network addressing and mobility. If the majority of things in one of
these areas of administration communicate with each other in a geographical zone then it makes sense to keep the
mapping server as close (in terms of physical proximity) as is possible.
There are not many options to effect binding and few of the above schemes take advantage of geographical location
implications (GTP and M2CNP do).
ETSI
16 ETSI GR NGP 004 V1.1.1 (2018-01)
To facilitate scalability, mapping systems may be organized hierarchically, e.g. in terms of identifier space or locator
space that may reflect AS boundaries. The responsibility for
...