< draft-irtf-icnrg-nrs-requirements-00.txt   draft-irtf-icnrg-nrs-requirements-01.txt >
ICN Research Group J. Hong ICN Research Group J. Hong
Internet-Draft T. You Internet-Draft T. You
Intended status: Informational Y-G. Hong Intended status: Informational Y-G. Hong
Expires: April 20, 2019 ETRI Expires: September 12, 2019 ETRI
L. Dong
C. Westphal C. Westphal
Huawei Huawei
V. Kafle V. Kafle
NICT NICT
October 17, 2018 B. Ohlman
Ericsson
March 11, 2019
Requirements for Name Resolution Service in ICN Requirements for Name Resolution Service in ICN
draft-irtf-icnrg-nrs-requirements-00 draft-irtf-icnrg-nrs-requirements-01
Abstract Abstract
This document discusses the motivation and requirements for Name This document discusses the motivation and requirements for Name
Resolution Service (NRS) in ICN. The NRS in ICN is to translate an Resolution Service (NRS) in ICN. The NRS in ICN is to translate an
object name into some other information such as locator and another object name into some other information such as a locator and another
name which is used for forwarding the object request. name which is used for forwarding the object request towards the
object location.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4 3. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4
3.1. Standalone name resolution approach . . . . . . . . . . . 4 4. Objectives of NRS in ICN . . . . . . . . . . . . . . . . . . 5
3.2. Name based routing approach . . . . . . . . . . . . . . . 4 4.1. To support heterogeneous types of names . . . . . . . . . 5
3.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . 4 4.2. To support dynamic features . . . . . . . . . . . . . . . 5
3.4. Comparisons of name resolution approaches . . . . . . . . 5 4.3. To support efficient routing . . . . . . . . . . . . . . 6
4. Motivation of NRS in ICN . . . . . . . . . . . . . . . . . . 6 4.4. Use cases of NRS . . . . . . . . . . . . . . . . . . . . 6
4.1. Heterogeneous names in ICN . . . . . . . . . . . . . . . 6 4.4.1. To support flat name based routing . . . . . . . . . 6
4.2. Dynamism in ICN . . . . . . . . . . . . . . . . . . . . . 7 4.4.2. To support producer mobility . . . . . . . . . . . . 7
4.3. Routing system in ICN . . . . . . . . . . . . . . . . . . 7 4.4.3. To support scalable routing system . . . . . . . . . 7
4.4. Use cases of NRS . . . . . . . . . . . . . . . . . . . . 8 4.4.4. To support off-path caching . . . . . . . . . . . . . 8
4.4.1. Flat name based routing support . . . . . . . . . . . 8 4.4.5. To support nameless object . . . . . . . . . . . . . 8
4.4.2. Producer mobility support . . . . . . . . . . . . . . 8 4.4.6. To support manifest . . . . . . . . . . . . . . . . . 9
4.4.3. Scalable routing support . . . . . . . . . . . . . . 9 5. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 9
4.4.4. Off-Path cache support . . . . . . . . . . . . . . . 9 5.1. Requirements as a service . . . . . . . . . . . . . . . . 9
4.4.5. Nameless object support . . . . . . . . . . . . . . . 10 5.1.1. Resolution response time . . . . . . . . . . . . . . 9
4.4.6. Menifest support . . . . . . . . . . . . . . . . . . 10 5.1.2. Response accuracy . . . . . . . . . . . . . . . . . . 10
5. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 11 5.1.3. Resolution guarantee . . . . . . . . . . . . . . . . 10
5.1. Requirements as a service . . . . . . . . . . . . . . . . 11 5.1.4. Resolution fairness . . . . . . . . . . . . . . . . . 10
5.1.1. Delay sensitivity . . . . . . . . . . . . . . . . . . 11 5.2. Requirements as a system . . . . . . . . . . . . . . . . 10
5.1.2. Accuracy . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Resolution guarantee . . . . . . . . . . . . . . . . 11
5.2. Requirements as a system . . . . . . . . . . . . . . . . 11
5.2.1. Scalability . . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Scalability . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Manageability . . . . . . . . . . . . . . . . . . . . 12 5.2.2. Manageability . . . . . . . . . . . . . . . . . . . . 11
5.2.3. Deployability . . . . . . . . . . . . . . . . . . . . 12 5.2.3. Deployed system . . . . . . . . . . . . . . . . . . . 11
5.2.4. Fault tolerance . . . . . . . . . . . . . . . . . . . 12 5.2.4. Fault tolerance . . . . . . . . . . . . . . . . . . . 12
5.3. Requirements on Security aspect . . . . . . . . . . . . . 12 5.3. Requirements on Security aspect . . . . . . . . . . . . . 12
5.3.1. Accessibility . . . . . . . . . . . . . . . . . . . . 12 5.3.1. Accessibility . . . . . . . . . . . . . . . . . . . . 12
5.3.2. Authentication . . . . . . . . . . . . . . . . . . . 12 5.3.2. Authentication . . . . . . . . . . . . . . . . . . . 12
5.3.3. Data confidentiality . . . . . . . . . . . . . . . . 12 5.3.3. Data confidentiality . . . . . . . . . . . . . . . . 13
5.3.4. Data privacy . . . . . . . . . . . . . . . . . . . . 13 5.3.4. Privacy protection . . . . . . . . . . . . . . . . . 13
5.3.5. Robustness/resiliency . . . . . . . . . . . . . . . . 13
5.3.6. Network privacy . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The current Internet is a host-centric networking, where hosts are The current Internet is a host-centric networking, where hosts are
uniquely identified with IP addresses and communication is possible uniquely identified with IP addresses and communication is possible
between any pair of hosts. Thus, information in the current Internet between any pair of hosts. Thus, information in the current Internet
is identified by the name of host where the information is stored. is identified by the name of host where the information is stored.
In contrast to the host-centric networking, the primary communication In contrast to the host-centric networking, the primary communication
objects in Information-centric networking (ICN) are the named data objects in Information-centric networking (ICN) are the named data
objects (NDOs) and they are uniquely identified by the location- objects (NDOs) and they are uniquely identified by the location-
independent names. Thus, ICN aiming to the efficient dissemination independent names. Thus, ICN aiming to the efficient dissemination
and retrieval of the NDOs in a global scale has been identified and and retrieval of the NDOs in a global scale has been identified and
acknowledged as a promising technology for the future Internet acknowledged as a promising technology for the future Internet
architecture to overcome the limitations of the current Internet such architecture to overcome the limitations of the current Internet such
as scalability, mobility, etc.[Ahlgren] [Xylomenos]. ICN also has as scalability and mobility.[Ahlgren] [Xylomenos]. ICN also has been
been emerged as a candidate architecture for IoT environment since emerged as a candidate architecture for IoT environment since IoT
IoT focuses on data and information rather than end-to-end focuses on data and information rather than end-to-end communications
communications [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].
Since naming data independently from the current location where it is Since naming data independently from the current location where it is
stored is a primary concept of ICN, how to find the NDO using the stored is a primary concept of ICN, how to find the NDO using the
location-independent name is one of the most important design location-independent name is one of the most important design
challenges in ICN. Such ICN routing may comprise three steps challenges in ICN. Such ICN routing may comprise three steps
[RFC7927] : [RFC7927] :
o Name resolution : matches/translates a content name to locators of o Name resolution : matches/translates a content name to locators of
providers/sources that can provide the content. content producers or sources that can provide the content.
o Content discovery : routes the content request towards the content o Content discovery : routes the content request towards the
either based on its name or locator. content's location either based on its name or locator.
o Content delivery : transfers the content to the requester. o Content delivery : transfers the content to the requester.
In three steps of ICN routing, this document focuses only the name Among these three steps of ICN routing, this document focuses only on
resolution step which translates a content name to its locators. In the name resolution step which translates a content name to the
addition, this document considers all other types of name resolution content locators. In addition, this document covers various possible
in ICN such as name to name, name to manifest. types of name resolution in ICN such as one name to another name,
name to manifest, and name to locator.
Thus, this document presents the definition of the Name Resolution This document first presents the components of the Name Resolution
Service (NRS) in ICN and discusses the motivation and the Service (NRS) in ICN and then discusses the objectives of NRS and the
requirements in designing the NRS for ICN. requirements in designing the NRS for ICN.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Name Resolution Service in ICN 3. Name Resolution Service in ICN
The Name Resolution Service (NRS) in ICN is defined as the service The Name Resolution Service (NRS) in ICN is defined as the service
that provides the name resolution function translating an object name that provides the name resolution function for translating an object
into some other information such as locator and another name that is name into some other information such as a locator and another name
used for forwarding the object request. In other words, the NRS is that is used for forwarding the object request. In other words, the
the service that shall be provided by ICN infrastructure to help a NRS is the service that shall be provided by ICN infrastructure to
consumer to reach a specific piece of content, service, or host using help a consumer to reach a specific piece of content, service, or
a persistent name when the name resolution is needed. host using a persistent name when the name resolution is needed.
The name resolution is a necessary process in ICN routing although
the name resolution either can be separated from the content
discovery as a standalone process or can be integrated with the
content discovery as one combined process. The former is referred as
standalone name resolution approach, the latter is referred as name
based routing approach in this document.
3.1. Standalone name resolution approach
The NRS could take the standalone name resolution approach to return
the client with the locators of the content, which will be used by
the underlying network as the identifier to route the client's
request to one of the producers. There are several ICN projects that
use the standalone name resolution approach such as DONA[Koponen],
PURSUIT [PURSUIT], SAIL [SAIL], MobilityFirst [MF], IDNet [Jung],
etc.
3.2. Name based routing approach
The NRS could take the name based routing approach, which integrates
the name resolution with the content request message routing as in
NDN [NDN]/CCN [CCN].
In the case that the content request also specifies the reverse path,
as in NDN/CCN, the name resolution mechanism also determines the
routing path for the data. This adds a requirement on the name
resolution service to propagate request in a way that is consistent
with the subsequent data forwarding. Namely, the request must select
a path for the data based upon the finding the copy of the content,
but also properly delivering the data.
3.3. Hybrid approach
The NRS could also take hybrid approach which can perform name based
routing approach from the beginning, when it fails at certain router,
the router can go back to the standalone name resolution approach.
The alternative hybrid NRS approach also works, which can perform
standalone name resolution approach to find locators of routers which
can carry out the name based routing of the client's request.
A hybrid approach would combine name resolution as a subset of
routers on the path with some tunneling in between (say, across an
administrative domain) so that only a few of the nodes in the
architecture perform name resolution in the name-based routing
approach.
3.4. Comparisons of name resolution approaches
The following compares the standalone name resolution and name based There are two main NRS components:
routing approaches from different aspects:
o Update message overhead : The update message overhead is due to o NRS server: The NRS is a service maintained by a distributed
the change of content reachability, which may include content mapping database system. The NRS consists of the distributed NRS
caching or expiration, content producer mobility etc. The name servers storing the mapping records in database. NRS servers
based routing approach may require to flood part of the network store and maintain the mapping records that keep the bindings of
for update propagation. In the worst case, the name based routing name to other information that is used for forwarding content
approach may flood the whole network (but mitigating techniques request.
may be used to scope the flooding). The standalone name
resolution approach only requires to update propagation in part of
the name resolution overlay.
o Resolution capability : The standalone name resolution approach o NRS resolver: The client side of the NRS is called an NRS
can guarantee the resolution of any content in the network if it resolver. The resolver is responsible for initiating and
is registered to the name resolution overlay (assuming the sequencing the name resolution request queries that ultimately
information of content is being broadcast in the overlay after it lead to a name resolution of the data objects. NRS resolvers can
is registered). On the other hand, the name based routing be located in the consumer (or client) nodes and ICN routers. NRS
approach can only promise a high probability of content resolver can also store the mapping records obtained through the
resolution, depending on the flooding scope of the content name for later usage.
availability information (i.e. content publishing message and name
based routing table).
o Node failure impact : Nodes involved in the standalone name There are two main NRS processes:
resolution approach are the name resolution overlay servers (e.g.
Resolution Handlers in DONA), while the nodes involved in the name
based routing approach are routers which route messages based on
locally maintained name based routing tables (e.g. NDN routers).
Node failures in the standalone name resolution approach may cause
some content discovery to fail even though the content is
available. This problem does not exist in the name based routing
approach because other alternative paths can be discovered to
bypass the failed ICN routers, given the assumption that the
network is still connected.
o Maintained databases : The storage usage for the standalone name o Name registration: In order to create the NRS, the content names
resolution approach is different from that of the name based and their mapping records must be registered in NRS system by a
routing approach. The standalone name resolution approach publisher who has at least one authoritative NRS server or by a
typically needs to maintain two databases: name to locator mapping producer who generates named data objects. The mapping
in the name resolution overlay and routing tables in the routers information is the binding of a name to some information such as
on the data forwarding plane. The name based routing approach another names and locators, which are used for forwarding the
needs to maintain different databases: name routing table and content request. Thus, a publisher or producer creates an NRS
optionally breadcrumbs for reverse routing of content back to the registration request and send to an NRS server. On registration,
requester. the NRS server stores the mapping record in the database and sends
back an ACK as a response back to the producer or publisher.
4. Motivation of NRS in ICN o Name resolution: Name resolution is the main process of the NRS.
It is performed by an NRS resolver which can be deployed on a
consumer node or an ICN router. When the required name mapping
record has not been stored in the cache of a NRS resolver, it
sends a name resolution request toward the NRS server. The NRS
server searches the content name in its mapping record database,
retrieves and sends the mapping record in the name resolution
response message to the NRS resolver.
This section presents the motivation and use cases of NRS in ICN. 4. Objectives of NRS in ICN
4.1. Heterogeneous names in ICN This section presents the objectives and use cases of NRS in ICN.
In ICN design, a name is used to identify an entity, such as named 4.1. To support heterogeneous types of names
data content, a device, an application, a service. ICN requires
uniqueness and persistency of the name of any entity to ensure the
reachability of the entity within certain scope and with proper
authentication and trust guarantees. The name does not change with
the mobility and multi-home of the corresponding entity. A client
can always use this name to retrieve the content from network and
verify the binding of the content and the name.
In ICN, a name is used to identify data object and is bound to it
[RFC7927]. ICN requires uniqueness and persistency of the name of
data object to ensure the reachability of the object within a certain
scope and with proper authentication and trust management. There are
heterogeneous approaches to designing ICN naming schemes [Bari].
Ideally, a name can include any form of identifier, which can be Ideally, a name can include any form of identifier, which can be
flat, hierarchical, and human readable or non-readable. flat, hierarchical, and human readable or non-readable.
There are heterogeneous content naming schemes [ID.Zhang] [RFC1498] Although there are diverse types of naming schemes proposed in
and name resolution approaches from different ICN architectures. For literature, they all need to provide basic functions for identifying
example: data object, supporting trust provenance, named data lookup and
routing. The NRS may combine the good aspects of different schemes.
o Names in DONA [Koponen] consist of the cryptographic hash of the Basically, the NRS should be able to support a generic naming schema
principal's public key P and a label L uniquely identifying the so that it can resolve any type of content name, irrespective of
information with respect to the principal. Name resolution in whether it is flat or hierarchical.
DONA is provided by specialized servers called Resolution Handlers
(RHs).
o Content in PURSUIT [PURSUIT] is identified by a combination of a
scope ID and a rendezvous ID. The scope ID represents the
boundaries of a defined dissemination strategy for the content it
contain. The rendezvous ID is the actual identity for a
particular content. Name resolution in PURSUIT is handled by a
collection of Rendezvous Nodes (RNs), which are implemented as a
hierarchical Dynamic Hash Table (DHT)[Rajahalme] [Katsaros].
o Names in NDN [NDN] and CCN [CCN] are hierarchical and may be
similar to URLs. Each name component can be anything, including a
dotted human-readable string or a hash value. NDN/CCN adopts the
name based routing. The NDN router forwards the request by doing
the longest-match lookup in the Forwarding Information Base (FIB)
based on the content name and the request is stored in the Pending
Interest Table (PIT).
o In MobilityFirst [MF], every network entity, content has a Global
Unique Identifier (GUID). GUIDs are flat 160-bit strings with no
semantic structure. Name Resolution in MobilityFirst is carried
out via a Global Name Resolution Service (GNRS).
Although the existing naming schemes are different, they all need to
provide basic functions for identifying a content, supporting trust
provenance, content lookup and routing. The NRS may combine the
advantages of different mechanisms. The NRS should be able to
support a generic naming schema to resolve any type of content name,
either it is flat or hierarchical.
4.2. Dynamism in ICN 4.2. To support dynamic features
In ICN literature, it is said that mobility can be achieved in ICN natively supports mobility management. Especially, consumer or
fundamental feature of ICN. Especially, consumer or client mobility client mobility is handled by requesting the content again in case
can be achieved by requesting information again according to the the mobility or handover occurred before receiving the corresponding
basic procedure from different interfaces or through attachment point content from the network. Since ICN can ensure that content
of the new network. Moreover, seamless mobility service in ICN reception continues without any disruption in ICN application,
ensures that content reception continues without any disruption in seamless mobility in consumer point of view can be easily supported.
ICN application, so in consumer point of view, seamless mobility can
be easily supported.
However, producer or publisher mobility in ICN is more complicated to However, producer or publisher mobility in ICN is complicated to
be supported. If a producer moves into different authority domain or support. If a producer moves into a different authority domain or
network location, then the request for a content published by the network location, it would be difficult for the mobility management
moving puroducer with origin name would be hardly forwarded to the update RIB and FIB entries in ICN routers with the new forwarding
moving producer since the routing tables related in broad area should path in a very short time. Therefore, various ICN architectures in
be updated according to the producer movement. Therefore, various literatures have proposed to adopt NRS to achieve the producer or
ICN literatures would adopt NRS to achieve the producer or publisher publisher mobility, where NRS can be implemented in different ways
mobility, where NRS can be implemented in different ways such as such as at rendezvous points and overlay mapping systems.
rendezvous mechanism, mapping, etc.
Besides mobility, ICN has challenge to support the dynamism features Besides the consumer and producer mobility, ICN also has to face
like multi-homing, migration, and replication of named resources such challenges to support the other dynamic features such as multi-
as content, devices, services, etc. and NRS may help to support the homing, migration, and replication of named resources such as
dynamism features. content, devices, and services. Therefore, NRS can help to support
these dynamic features.
4.3. Routing system in ICN 4.3. To support efficient routing
In ICN, data objects must be identified by names regardless their In ICN, name of data objects is used for routing by either name
location or container [RFC7927] and the names are divided into two resolution step or routing table lookup. Thus, routing information
types of schemes: hierarchical and flat namespaces. A hierarchical for each data object should be maintained in routing base, such as
scheme used in CCN and NDN architectures has a structure similar to Routing Information Base (RIB) and Forwarding Information Base (FIB).
current URIs, where the hierarchy improves scalability of routing Since the number of data objects would be very large, the size of
system. It is because the hierarchy enables aggregation of the name information bases would be significantly large as well [RFC7927].
resulting in reducing the size of RIB or FIB as similar to IP routing
system. In a flat scheme, on the other hand, name routing is not
easy since names in a flat namespace cannot be aggregated anymore,
which would cause more the scalability problem in routing system. In
order to address such problem, a flat name can be resolved to some
information which is routable through NRS.
In ICN, application names identifying contents are used directly for The hierarchical namespace used in CCN [CCN] and NDN [NDN]
packet delivery, so ICN routers run a name-based routing protocol to architectures reduces the size of these tables through name
build name-based routing and forwarding tables. Regardless of name aggregation and improves scalability of routing system. In a flat
scheme, if non-aggregated name prefixes are injected to the Default naming scheme, on the other hand, it would aggravate the scalability
Route Free Zone (DFZ) of ICN, then they would be driving the growth problem in routing system. The non-aggregated name prefixes injected
of the DFZ routing table size, which is the same as the scalability to the Default Route Free Zone (DFZ) of ICN would create more serious
issue of IP routing. Thus a solution to keep the routing table size scalability problem similar to the scalability issue of IP routing
under control is needed, which can be done by defining indirection system. Thus, NRS may play an important role in the reduction of the
layer. routing scalability problem regardless of the types of namespaces.
4.4. Use cases of NRS 4.4. Use cases of NRS
This subsection describes NRS used in many other ways in ICN This subsection describes more specific use cases of NRS reported in
literature. ICN literature.
4.4.1. Flat name based routing support 4.4.1. To support flat name based routing
In PURSUIT [PURSUIT], names are flat and the rendezvous functions are In PURSUIT [PURSUIT], names are flat and the rendezvous functions are
defined for NRS, which is implemented by a set of Rendezvous Nodes defined for NRS, which is implemented by a set of Rendezvous Nodes
(RNs), the Rendezvous Network (RENE). Thus a name consisted of a (RNs), the Rendezvous Network (RENE). Thus a name consisted of a
sequence of scope IDs and a single rendezvous ID is routed by RNs in sequence of scope IDs and a single rendezvous ID is routed by RNs in
RENE. Thus, PURSUIT decouples name resolution and data routing, RENE. Thus, PURSUIT decouples name resolution and data routing,
where NRS is performed by the RENE. where NRS is performed by the RENE.
In MobilityFirst [MF], a name called a global unique Identifier In MobilityFirst [MF], a name called a global unique Identifier
(GUID) derived from a human-readable name via a global naming service (GUID) derived from a human-readable name via a global naming service
is flat typed 160-bits strings with self-certifying function. Thus, is flat typed 160-bits strings with self-certifying function. Thus,
MobilityFirst defines a global name resolution service (GNRS) which MobilityFirst defines a global name resolution service (GNRS) which
resolves GUIDs to network addresses and decouples name resolution and resolves GUIDs to network addresses and decouples name resolution and
data routing as similar to PURSUIT. data routing as similar to PURSUIT.
4.4.2. Producer mobility support In NetInf [Dannewitz], named information (ni) naming consist of an
authority part and digest part (content hash). The ni names can be
flat as the authority part is optional. Thus, the architecture also
includes a Name Resolution System (NRS) which can be used to resolve
ni names to addresses in an underlying routable network layer.
4.4.2. To support producer mobility
In NDN [Zhang2], for producer mobility support, rendezvous mechanisms In NDN [Zhang2], for producer mobility support, rendezvous mechanisms
have been proposed to build interests rendezvous (RV) with data have been proposed to build interests rendezvous (RV) with data
generated by a mobile producer (MP). There can be classified two generated by a mobile producer (MP). There can be classified two
approaches such as chase mobile producer and rendezvous data. approaches such as chase mobile producer and rendezvous data.
Regarding MP chasing, rendezvous acts as a mapping service that Regarding MP chasing, rendezvous acts as a mapping service that
provides the mapping from the name of the data produced by the MP to provides the mapping from the name of the data produced by the MP to
the MP's current point of attachment (PoA) name. Alternatively, the the MP's current point of attachment (PoA) name. Alternatively, the
RV serves as a home agent like as IP mobility support, so the RV RV serves as a home agent like as IP mobility support, so the RV
enables consumer's interest message to tunnel towards the MP at the enables consumer's interest message to tunnel towards the MP at the
skipping to change at page 9, line 31 skipping to change at page 7, line 43
messages through mapping service between IDs and LIDs. Therefore, messages through mapping service between IDs and LIDs. Therefore,
the mapping service in control plane infrastructure can be considered the mapping service in control plane infrastructure can be considered
as NRS in this draft. as NRS in this draft.
In MobilityFirst [MF], both consumer and publisher mobility can be In MobilityFirst [MF], both consumer and publisher mobility can be
primarily handled by the global name resolution service (GNRS) which primarily handled by the global name resolution service (GNRS) which
resolves GUIDs to network addresses. Thus, the GNRS must be updated resolves GUIDs to network addresses. Thus, the GNRS must be updated
for mobility support when a network attached object changes its point for mobility support when a network attached object changes its point
of attachment, which differs from NDN/CCN. of attachment, which differs from NDN/CCN.
4.4.3. Scalable routing support 4.4.3. To support scalable routing system
In [Afanasyev], in order to address the routing scalability problem In [Afanasyev], in order to address the routing scalability problem
in NDN's DFZ, a well-known concept of Map-and-Encap is applied to in NDN's DFZ, a well-known concept of Map-and-Encap is applied to
provide a simple and secure namespace mapping solution. In the provide a simple and secure namespace mapping solution. In the
proposed map-and-encap design, data whose name prefixes do not exist proposed map-and-encap design, data whose name prefixes do not exist
in the DFZ forwarding table can be retrieved by a distributed mapping in the DFZ forwarding table can be retrieved by a distributed mapping
system called NDNS, which maintains and lookups the mapping system called NDNS, which maintains and lookups the mapping
information from a name to its globally routed prefixes, where NDNS information from a name to its globally routed prefixes, where NDNS
is a kind of NRS. is a kind of NRS.
4.4.4. Off-Path cache support 4.4.4. To support off-path caching
Caching in-network is considered to be a basic architectural Caching in-network is considered to be a basic architectural
component of an ICN architecture. It may be used to provide a component of an ICN architecture. It may be used to provide a
Quality-of-Service (QoS) experience to users, reduce the overall Quality-of-Service (QoS) experience to users, reduce the overall
network traffic, prevent network congestion and Denial-of-Service network traffic, prevent network congestion and Denial-of-Service
(DoS) attacks and increase availability. Caching approaches can be (DoS) attacks and increase availability. Caching approaches can be
categorized into off-path caching and on-path caching based on the categorized into off-path caching and on-path caching based on the
location of caches in relation to the forwarding path from a original location of caches in relation to the forwarding path from a original
server to a consumer. Off-path caching, also referred as content server to a consumer. Off-path caching, also referred as content
replication or content storing, aims to replicate content within a replication or content storing, aims to replicate content within a
skipping to change at page 10, line 18 skipping to change at page 8, line 31
In order to support off-path caches, replicas are usually advertised In order to support off-path caches, replicas are usually advertised
into a name- based routing system or into NRS. into a name- based routing system or into NRS.
In [Bayhan], a NRS used to find off-path copies in the network, which In [Bayhan], a NRS used to find off-path copies in the network, which
may not be accessible via content discovery mechanisms. Such may not be accessible via content discovery mechanisms. Such
capability is essential for an Autonomous System (AS) to avoid the capability is essential for an Autonomous System (AS) to avoid the
costly inter-AS traffic for external content, to yield higher costly inter-AS traffic for external content, to yield higher
bandwidth efficiency for intra-AS traffic, and to decrease the data bandwidth efficiency for intra-AS traffic, and to decrease the data
access latency for a pleasant user experience. access latency for a pleasant user experience.
4.4.5. Nameless object support 4.4.5. To support nameless object
In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a
Content Object without a Name is introduced to provide a means to Content Object without a Name is introduced to provide a means to
move Content between storage replicas without having to rename or re- move Content between storage replicas without having to rename or re-
sign the content objects for the new name. Nameless Objects can be sign the content objects for the new name. Nameless Objects can be
addressed by the ContentObjectHash that is to restrict Content Object addressed by the ContentObjectHash that is to restrict Content Object
matching by using SHA-256 hash. matching by using SHA-256 hash.
An Interest message would still carry a Name and a ContentObjectHash, An Interest message would still carry a Name and a ContentObjectHash,
where a Name is used for routing, while a ContentObjectHash is used where a Name is used for routing, while a ContentObjectHash is used
for matching. However, on the reverse path, if the Content Object's for matching. However, on the reverse path, if the Content Object's
name is missing, it is a "Nameless Object" and only matches against name is missing, it is a "Nameless Object" and only matches against
the ContentObjectHash. Therefore, a consumer needs to resolve proper the ContentObjectHash. Therefore, a consumer needs to resolve proper
name and hashes through an outside system, which can be considered as name and hashes through an outside system, which can be considered as
NRS. NRS.
4.4.6. Menifest support 4.4.6. To support manifest
In collection of data objects which were organized as large and file In collection of data objects which were organized as large and file
like contents [FLIC], the manifests are used as data structures to like contents [FLIC], the manifests are used as data structures to
transport this information. Thus, the manifests may contain hash transport this information. Thus, the manifests may contain hash
digests of signed content objects or other manifests, so that large digests of signed content objects or other manifests, so that large
content objects which represent large piece of application data can content objects which represent large piece of application data can
be collected by using the manifest. be collected by using the manifest.
In order to request content objects, a consumer needs to know a In order to request content objects, a consumer needs to know a
manifest root name to acquire the manifest. In case of FLIC, a manifest root name to acquire the manifest. In case of FLIC, a
manifest name can be represented by a nameless root manifest, so that manifest name can be represented by a nameless root manifest, so that
outside system may be involved to give this information to the outside system may be involved to give this information to the
consumer. Therefore, NRS can be considered as a kind of mapping consumer. Therefore, NRS can be considered as a kind of mapping
database system. database system.
5. Requirements for NRS in ICN 5. Requirements for NRS in ICN
This section presents the requirements for designing NRS in ICN in This section presents the requirements for designing NRS in ICN in
terms of service, system and security aspects, respectively. terms of service, system and security aspects.
5.1. Requirements as a service 5.1. Requirements as a service
This subsection presents the requirements for NRS as a service. Resolution response time, resolution accuracy, resolution guarantee,
and resolution fairness are the requirements for NRS as a service,
which are described below.
5.1.1. Delay sensitivity 5.1.1. Resolution response time
The name resolution process provided by the NRS must be completed The name resolution process should provide a response within a
within a minimum delay. If the name resolution takes too long, then reasonable amount of time. The response should be either a proper
the content request packet may get dropped or it will yield the high mapping of the name to a copy of the content, or an error message
content retrieval time for content requestor. Thus, the content stating that no such file exists. If the name resolution does not
retrieval time has to be content requestor-tolerant. map to a location, the system may not issue any response, and the
client should set a timer when sending a request, so as to consider
the resolution incomplete when the timer expires.
5.1.2. Accuracy The acceptable response delay should be of the order of a round trip
time between the client issuing the request and the NRS servers that
provides the response. While this RTT may be very greatly depending
on the proximity between the two end points, some upper bound should
be used.
The NRS must provide accurate and up-to-date information on how to The response time should be within the same order of magnitude for
discover the requested content with minimum overhead in propagating most pairs of a client issuing a request, and the NRS server
the update information. For example, a content can be moved from one responding to this request.
domain to another domain due to the mobility of the producer, then
the old name record should be deleted from the NRS system and a new The response time should include all the steps of the resolution,
name record should be added and updated with minimum delay. including potentially a hop-by-hop resolution or a hierarchical
forwarding of the resolution request.
5.1.2. Response accuracy
The NRS must provide an accurate response, namely a proper binding of
the requested name (or prefix) with a location. The response can be
either a (prefix, location) pair, or the actual forwarding of a
request to a node holding the content, which is then transmitted in
return.
The NRS must provide an up-to-date response, namely the NRS should be
updated within a reasonable time when new copies of the content are
being stored in the network. While every transient cache addition/
eviction should not trigger an NRS update, some origin servers may
move and require the NRS to be updated.
The NRS must provide mechanisms to update the mapping of the content
with its location. Namely, the NRS must provide a mechanism for a
content owner to add new content, revoke old/dated/obsolete content,
and modify existing content. Any content update should then be
propagated through the NRS system within reasonable delay.
Content that is highly mobile may require to specify some type of
anchor that is kept at the NRS, instead of the content location.
5.1.3. Resolution guarantee 5.1.3. Resolution guarantee
The NRS must ensure the name resolution success if the matching The NRS must ensure that the name resolution would be successful if
content exists in the network, regardless of its popularity, number the name matching content exists in the network, regardless of its
of cached copies. popularity and number of cached copies existing in the network.
5.1.4. Resolution fairness
The NRS should provide this service for all content in a fair manner,
independently of the specific content properties (content producer,
content popularity, availability of copies, content format, etc.)
5.2. Requirements as a system 5.2. Requirements as a system
This subsection presents the requirements for NRS as a system. Scalability, manageability, deployability, and fault tolerant are the
requirements for NRS as a system, which are described below.
5.2.1. Scalability 5.2.1. Scalability
The NRS system must be extremely scalable to support a large number The NRS system must scale up to support a very large user population
of content objects as well as billions of users, who may access the (including human users as well as machine-to-machine communications).
system through various connection methods and devices. Especially in The system must be able to respond to a very large number of requests
IoT applications, the data size is small but frequently generated by per unit of time. Message forwarding and processing, routing table
sensors. Message forwarding and processing, routing table building- building-up and name records propagation must be efficient and
up and name records propagation must be efficient and scalable. scalable.
The NRS system must scale up with the number of pieces of content
(content names) and should be able to support a content catalog that
is extremely large.
The NRS system must be able to scale up, namely to add NRS servers to
the NRS system, in a way that is transparent to the users. Addition
of a new server should have limited impact on the other NRS servers
(or should have impact on only a small subset of the NRS servers).
The NRS system should support access from a heterogeneity of
connection methods and devices. In particular, the NRS system should
support access from constrained devices and interactions with the NRS
system should not be too costly. An IoT node for instance should be
able to access the NRS system as well as a more powerful node.
The NRS system should scale up in its responsiveness to the increased
request rate that is expected from applications such as IoT or M2M,
where data is being frequently generated and/or frequently requested.
5.2.2. Manageability 5.2.2. Manageability
The NRS system must be manageable since some parts of the system may The NRS system must be manageable since some parts of the system may
grow or shrink dynamically and a NRS system node may be added or grow or shrink dynamically and an NRS system node may be added or
deleted. deleted frequently.
5.2.3. Deployability The NRS may support an NRS management layer that allows for adding or
subtracting NRS nodes. The management layer should be able to infer
if the use of the NRS in some parts of the network is growing (or
shrinking).
5.2.3. Deployed system
The NRS system must be deployable since deployability is important The NRS system must be deployable since deployability is important
for a real world system. If the NRS system can be deployed from the for a real world system. The NRS system must be deployable in
edges, then the deployment can be simplified. network edges and cores so that the consumers as well as ICN routers
can perform name resolution in a very low latency.
5.2.4. Fault tolerance 5.2.4. Fault tolerance
The NRS system must ensure resilience to node failures. After a NRS The NRS system must ensure resiliency in the event of NRS server
node fails, the NRS system must be able to restore the name records failures. The failure of a small subset of nodes should not impact
stored in the NRS node. the NRS performance significantly.
After a NRS server fails, the NRS system must be able to recover and/
or restore the name records stored in the NRS server.
5.3. Requirements on Security aspect 5.3. Requirements on Security aspect
This subsection presents the requirements for NRS on security aspect Accessibility, authentication, confidentiality and privacy protection
for both node and data in the NRS system. are the requirements on security aspect of both the NRS server nodes
and mapping records stored in the NRS system. These requirements are
described below.
5.3.1. Accessibility 5.3.1. Accessibility
The name records must have proper access rights such that the The name records must have assigned with proper access rights such
information contained in the name record would not be revealed to that the information contained in the name mapping record would not
unauthorized users. In other words, The NRS system must be prevented be revealed to unauthorized users. In other words, the NRS system
from the malicious users attempting to hijack or corrupt name must be prevented from malicious users attempting to hijack or
corrupt the name mapping records.
The NRS may support access control for certain name records, so that
only users with the proper credential can access these record, and
these records would not be shared to unauthorized users.
The NRS may support authentication of the content producers to
determine that any location update/addition/removal that a content
producer is requesting is indeed valid and that the content producer
is authorized to modify this record.
The NRS should verify new mapping location that are being registered
so that it cannot be polluted with falsified information or invalid
records. records.
5.3.2. Authentication 5.3.2. Authentication
Users/nodes that register themselves in the NRS system must require The NRS must require authentication of new NRS nodes that register
the authentication to ensure who claims to be. For example, the themselves in the NRS system to ensure they are who they claim to be.
attacker can act as a fake NRS server which causes disruption or For example, it should detect an attacker attempting to act as a fake
intercepts the data. NRS server to disrupt the NRS service, or to intercept some users'
data.
5.3.3. Data confidentiality 5.3.3. Data confidentiality
NRS must keep the data confidentiality to prevent a lot of sensitive NRS must keep the data confidentiality to prevent a lot of sensitive
data from reaching unauthorized data requestor such as in IoT data from reaching unauthorized data requestor such as in IoT
environment. environment.
5.3.4. Data privacy NRS must keep meta-data confidential as well as usage to protect the
privacy of the users. For instance, a specific user's NRS requests
should not be shared outside the NRS system (with the exception of
legal intercept).
When a private data is registered in the system, the NRS system must 5.3.4. Privacy protection
support the privacy to avoid the information leaking. Otherwise,
unauthorized entity may disclose the privacy. When a private name mapping record is registered in the system, the
NRS system must support the privacy to avoid the information leaking.
Otherwise, unauthorized entity may disclose the privacy.
5.3.5. Robustness/resiliency
The NRS system should be resilient to denial of service attacks and/
or other common attacks on the integrity of its system. The NRS
system should be resilient if a few attacked nodes are unable to
participate in the system.
5.3.6. Network privacy
The NRS node in a given subdomain should not leak information about
this domain (say, topology, number of nodes, number of clients,
number of requests) to nodes outside of this domain, except for
sharing the content that it is allowed to advertise, or for the
management protocols that it is supporting.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
7. Security Considerations 7. Security Considerations
[TBD] [TBD]
8. Acknowledgements 8. Acknowledgements
skipping to change at page 18, line 19 skipping to change at page 19, line 4
Email: twyou@etri.re.kr Email: twyou@etri.re.kr
Yong-Geun Hong Yong-Geun Hong
ETRI ETRI
218 Gajeong-ro, Yuseung-Gu 218 Gajeong-ro, Yuseung-Gu
Daejeon 34129 Daejeon 34129
Korea Korea
Email: yghong@etri.re.kr Email: yghong@etri.re.kr
Lijun Dong
Huawei
10180 Telesis Court
San Diego, CA 92121
USA
Email: lijun.dong@huawei.com
Cedric Westphal Cedric Westphal
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: cedric.westphal@huawei.com Email: cedric.westphal@huawei.com
Ved Kafle Ved Kafle
NICT NICT
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
Email: kafle@nict.go.jp Email: kafle@nict.go.jp
Borje Ohlman
Ericsson Research
S-16480 Stockholm
Sweden
Email: Borje.Ohlman@ericsson.com
 End of changes. 62 change blocks. 
291 lines changed or deleted 315 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/