Requirements for Name Resolution Service in ICN
draft-jhong-icnrg-nrs-requirements-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jungha Hong , Lijun Dong , Taewan You , Cedric Westphal , Yong-Geun Hong , Guoqiang Wang , Jianping Wang | ||
| Last updated | 2017-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jhong-icnrg-nrs-requirements-00
ICNRG J. Hong
Internet-Draft ETRI
Intended status: Informational Lijun Dong
Expires: September 14, 2017 Huawei
T. You
ETRI
Cedric Westphal
Huawei
Y-G. Hong
ETRI
GQ Wang
Huawei
Jianping Wang
City University Hong Kong
March 13, 2017
Requirements for Name Resolution Service in ICN
draft-jhong-icnrg-nrs-requirements-00.txt
Abstract
This document discusses the motivation and requirements for Name
Resolution Service (NRS) in ICN. The NRS in ICN is to translate
object names into routing hints such as locators, where names are
location-independent and locators are network addresses.
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 September 14, 2017.
Hong, et al. Expires September 14, 2017 [Page 1]
Internet-Draft NRS Requirements March 2017
Copyright Notice
Copyright (c) 2017 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.
Hong, et al. Expires September 14, 2017 [Page 2]
Internet-Draft NRS Requirements March 2017
Table of Contents
1. Introduction ................................................ 4
2. Conventions and Terminology .................................. 6
3. Motivation .................................................. 7
3.1. Name Resolution Service in ICN .......................... 7
3.2. Handling Heterogeneous Names in ICN ..................... 8
3.3. Handling Dynamism in ICN ................................ 8
4. Requirements for NRS in ICN .................................. 9
4.1. Requirements on Operability ............................. 9
4.1.1. Scalability ........................................ 9
4.1.2. Delay sensitivity .................................. 9
4.1.3. Time transiency ................................... 10
4.1.4. Minimum inter-domain traffic ...................... 10
4.1.5. Fault tolerance ................................... 10
4.1.6. Resolution guarantee .............................. 10
4.1.7. Accuracy ......................................... 11
4.1.8. Heterogeneity ..................................... 11
4.1.9. Unspecified content name .......................... 12
4.2. Requirements on Manageability .......................... 12
4.2.1. Manageability ..................................... 12
4.2.2. Deployability ..................................... 12
4.2.3. Interoperability .................................. 12
4.2.4. Support for manifest .............................. 13
4.2.5. Resolution result selection ....................... 13
4.3. Requirements on Security ............................... 14
4.3.1. Accessibility ..................................... 14
4.3.2. Authentication .................................... 14
4.3.3. Data confidentiality .............................. 14
4.3.4. Privacy .......................................... 14
5. Use cases of NRS ........................................... 15
5.1. Flat Name routing support .............................. 15
5.2. Publisher Mobility support ............................. 15
5.3. Scalable Routing support ............................... 17
5.4. Nameless object support ................................ 17
6. Security Considerations ..................................... 17
7. IANA Considerations ........................................ 18
8. Conclusions ................................................ 18
9. References ................................................. 18
9.1. Normative References ................................... 18
9.2. Informative References ................................. 18
Hong, et al. Expires September 14, 2017 [Page 3]
Internet-Draft NRS Requirements March 2017
1. Introduction
The current Internet is a host-centric networking, where hosts are
uniquely identified with IP addresses and communication is possible
between any pair of hosts. Thus, information in the current Internet
is identified by the name of host where the information is stored.
In contrast to the host-centric networking, the primary
communication objects in Information-centric networking (ICN) are
the named data objects (NDOs) and they are uniquely identified by
the location-independent names. Thus, ICN aiming to the efficient
dissemination and retrieval of the NDOs in a global scale has been
identified and acknowledged as the most promising technology for the
future Internet architecture to overcome the limitations of the
current Internet such as scalability, mobility, etc.[28][29]
ICN also has been emerged as a candidate architecture for IoT
environment since IoT focuses on data and information rather than
end-to-end communications [30][31][32]. In addition, the following
ICN features are fulfilling well the architectural requirements of
IoT such as naming, name resolution, scalability, resource
constraints, mobility, caching, security, privacy, etc.[33][34]:
- Naming of data, devices, and services independently from their
locations
- Distributed caching and processing
- Decoupling between sender and receiver
- Mobility support
- Authentication and verification of content
Since naming data independently from the current location where it
is stored is a primary concept of ICN, how to discover the NDO using
the location-independent name is one of the most important design
challenges in ICN. Thus, most ICN architectures, such as DONA[4],
PURSUIT[5], NDN[7][10], CCN[8], SAIL[6], MobilityFirst[9] are
centered around routing for content retrieval.
ICN routing generally involves three steps:
- Name resolution[11][12][14][15][17][18]: matches/translates a
content name to locators of providers/sources that can provide the
content.
Hong, et al. Expires September 14, 2017 [Page 4]
Internet-Draft NRS Requirements March 2017
- Content request routing: routes the content request towards the
producer either based on the name or the locator. The process of
name resolution and content request routing can be integrated. If
integrated, the content request is routed by name, such as in
NDN/CCN. If not integrated, the content request is routed by the
locator obtained from the previous name resolution step, such as
in DONA, PURSUIT, SAIL, MobilityFirst.
- Content delivery: Constructs a path for transferring the content
from the provider to the requester. In the integrated approach,
content can be routed using breadcrumbs left by the request to
define a reverse path, or by some other mechanism, such as
including a locator for the requester in the content request. In
the uncombined approach, the content can be routed from the
provider back to the request through an independent path.
Thus the name resolution process in ICN architectures either can be
separated from the message routing (e.g. routing of content request
message) as a standalone process or can be integrated with the
message routing 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.
The following compares the standalone name resolution and name based
routing approaches from different aspects:
- Update message overhead: The update message overhead is due to the
change of content reachability, which may include content caching
or expiration, content producer mobility etc. The name based
routing approach may require to flood part of the network for
update propagation. In the worst case, the name based routing
approach may flood the whole network (but mitigating techniques
may be used to scope the flooding). The standalone name resolution
approach only requires to update propagation in part of the name
resolution overlay.
- Resolution capability: The standalone name resolution approach can
guarantee the resolution of any content in the network if it is
registered to the name resolution overlay (assuming the content is
being broadcast in the overlay after it is registered). On the
other hand, the name based routing approach can only promise a
high probability of content resolution, depending on the flooding
scope of the content availability information (i.e. content
publishing message and name based routing table).
- Node failure impact: Nodes involved in the standalone name
resolution approach are the name resolution overlay servers (e.g.
Hong, et al. Expires September 14, 2017 [Page 5]
Internet-Draft NRS Requirements March 2017
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 resolution 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.
- Maintained databases: The storage usage for the standalone name
resolution approach is different from that of the name based
routing approach. The standalone name resolution approach
typically needs to maintain two databases: name to locator mapping
in the name resolution overlay and routing tables in the routers
on the data forwarding plane. The name based routing approach
needs to maintain different databases: name routing table and
optionally breadcrumbs for reverse routing of content back to the
requester.
Despite the coexistence of different name resolution approaches, the
Name Resolution Service (NRS) is most essential service that shall
be provided by the ICN infrastructure. Thus, in this document, we
give the definition of NRS in ICN and discuss the motivation and the
requirements in designing the NRS for ICN.
2. Conventions and Terminology
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].
Hong, et al. Expires September 14, 2017 [Page 6]
Internet-Draft NRS Requirements March 2017
3. Motivation
In this section, we give the definition of NRS in ICN and discuss
the motivation why NRS is needed in ICN.
3.1. Name Resolution Service in ICN
The Name Resolution Service (NRS) is defined as the service that is
provided by ICN infrastructure to help a client to reach a specific
piece of content, service, or host using a persistent name.
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[4],
PURSUIT[5], SAIL[6], MobilityFirst[9], IDNet[35], etc.
The NRS could take the name based routing approach, which integrates
the name resolution with the content request message routing as in
NDN[7]/CCN[8].
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 interest in a way that is consistent
with the subsequent data forwarding. Namely, the interest must
select a path for the data based upon the finding the copy of the
content, but also properly delivering the data.
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.
Hong, et al. Expires September 14, 2017 [Page 7]
Internet-Draft NRS Requirements March 2017
Additionally, some other intermediary step may be included in the
name resolution, namely the mapping of one name to other names, in
order to facilitate the retrieval of named content, by way of a
manifest[24][25]. The manifest is resolved using one of the two
above approaches, and it may include further mapping of names to
content and location. The steps for name resolution then become:
first translate the manifest name into a location of a copy of the
manifest; the manifest includes further names of the content
components, and potentially locations for the content. The content
is then retrieved by using these names and/or location, potentially
resulting in additional name resolutions.
No matter which approach is taken by the NRS in ICN, it is the most
essential component or service of the ICN infrastructure.
3.2. Handling Heterogeneous Names in ICN
In ICN design, a name is used to identify an entity, such as named
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.
Ideally, a name can include any form of identifier, which can be
flat, hierarchical, and human readable or non-readable.
3.3. Handling Dynamism in ICN
I
ICN has the dynamic features like mobility, multi-homing, migration,
and replication of named resources such as content, devices,
services, etc. The dynamism of the names resources will be more in
future networking contexts such as 5G or when services are
virtualized over wider geography due to the namespace expansion into
the routing/forwarding.
Hong, et al. Expires September 14, 2017 [Page 8]
Internet-Draft NRS Requirements March 2017
4. Requirements for NRS in ICN
In this section, we provide the requirements for designing NRS in
ICN in terms of operability, security and manageability,
respectively.
4.1. Requirements on Operability
The requirements on operability aspect are things that should be
considered when the key operations of NRS are designed.
4.1.1. Scalability
The NRS system must to be extremely scalable to support a large
number of content objects as well as billions of users, who may
access the system through various connection methods and devices.
Especially in IoT applications, the data size is small but
frequently generated by sensors. Message forwarding and processing,
routing table building-up and name records propagation must be
efficient and scalable. The memory requirement for NRS nodes should
be achievable by the current memory technologies.
4.1.2. Delay sensitivity
The name resolution process provided by the NRS must not introduce
significant latencies. With more number of name record replications,
the number of nodes involved in the name resolution may be reduced.
For example, in the standalone name resolution approach, with the
name record being replicated to higher hierarchy or the peer NRS
server in the overlay, the name resolution can be responded more
promptly. In the name based routing approach, with the content based
routing table being broadcast within the larger scope in the
network, the name resolution and request routing can have higher
probability to successfully reach the nearer copy of the requested
content.
The NRS deployment should balance the number of nodes involved in
the name resolution and the overhead/cost for the name record
replication. To ensure the low latency, the NRS should be able to
route a content request to the closest copy. Message forwarding and
processing should be efficient and computation complexity should be
reasonable low and affordable by the current processor technologies.
Hong, et al. Expires September 14, 2017 [Page 9]
Internet-Draft NRS Requirements March 2017
4.1.3. Time transiency
The NRS should support time-transient content, which is frequently
created in and disappearing from the network. This kind of content
only stays in the network for a short time, which requires the NRS
to be able to promptly reflect the records of them in the system.
For example, some video clip only exists in the network for a very
short time, which requires the NRS to promptly update their name
records.
4.1.4. Minimum inter-domain traffic
The NRS must attempt to minimize total traffic, and inter-domain
traffic in particular. In order to achieve that, message propagation
for name resolution and retrieval should retain the locality and
should be kept in the network domain if that domain contains both
the client and the content copy.
For example, a client is requesting the temperature data of the
building that he/she is residing in, the NRS should be able to
return or route to the nearest gateway in the building that stores
such data instead of a remote server in the cloud.
4.1.5. Fault tolerance
The NRS must ensure resilience to node failures. After a NRS node
fails, the NRS system must be able to restore the name records
stored in the NRS node. The NRS must also ensure resolution failure
at one NRS node would be resolved and corrected by other NRS nodes.
For example, in the standalone name resolution approach, when a NRS
overlay server fails, the name records should be able to transferred
and recovered in its peer server or its replacement. In the name
based approach, the failure of one ICN router does not cause much
trouble in the name resolution, because the other alternative paths
can be established that bypass the failed ICN router. However, it
requires that the ICN router has propagated its name based routing
information in the network.
4.1.6. Resolution guarantee
The NRS must ensure the name resolution success if the matching
content exists in the network, regardless of its popularity, number
of cached copies.
Hong, et al. Expires September 14, 2017 [Page 10]
Internet-Draft NRS Requirements March 2017
4.1.7. Accuracy
The NRS must provide accurate and up-to-date information on how to
reach the producer(s) of requested content with minimum overhead in
propagating the update information. Content mobility and expiration
must be reflected in the corresponding records in the NRS system
with minimum delay to guarantee the accurate resolution.
For example, a content can be moved from one 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 name record should
be added and updated with minimum delay.
4.1.8. Heterogeneity
There are heterogeneous content naming schemes[16][19] and name
resolution approaches from different ICN architectures. For example:
- Names in DONA[1] consist of the cryptographic hash of the
principal's public key P and a label L uniquely identifying the
information with respect to the principal. Name resolution in DONA
is provided by specialized servers called Resolution Handlers (RHs).
- Content in PURSUIT[5] 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)[13][14].
- Names in NDN/CCN[8][10] 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 interest by doing the longest-
match lookup in the Forwarding Information Base (FIB) based on the
content name and the interest is stored in the Pending Interest
Table (PIT).
- In MobilityFirst[9], every network entity, content has a Global
Unique Identifier (GUID). GUIDs are flat 160-bit strings with no
semantic structure. Name Resolution in MobilityFirst all 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
Hong, et al. Expires September 14, 2017 [Page 11]
Internet-Draft NRS Requirements March 2017
advantages of different mechanisms. The NRS may be able to provide a
generic naming schema to resolve any type of content name, either it
is flat or hierarchical.
4.1.9. Unspecified content name
Currently, both the standalone name resolution and name based
routing approaches assume that the content name is known (or
potentially retrieved from some other service) and specified to the
network by the client, which is sometimes not the case. A client may
not know the exact name of the data that he/she is requesting. For
example, a client wants to retrieve the temperature data on
07/21/2015 in San Diego. In this case, the client is only able to
specify some semantics and contextual information of the data that
he/she is looking for.
The NRS may be able to resolve those requests by having a northbound
interface to the other services, which can return the content
name(s) matching the client's request.
4.2. Requirements on Manageability
Requirements on manageability are things that should be considered
in terms of the system management aspect.
4.2.1. Manageability
NRS has to be manageable since some parts of the system may grow or
shrink dynamically and a name resolution server may be added or
deleted.
4.2.2. Deployability
Deployability is important for a real world system. If the NRS can
be deployed from the edges, then the deployment can be simplified.
4.2.3. Interoperability
Considering the emergence of IoT applications, many standard bodies
for IoT have settled their ways for resource/data management. For
example:
- oneM2M[19] uses tree structure to store resources. Each resource
is addressable by its URI. oneM2M resources are linked together by
parent-child relationship or link relationship with pointers.
Hong, et al. Expires September 14, 2017 [Page 12]
Internet-Draft NRS Requirements March 2017
Resource resolution is indicated in the hierarchical name of the
resources. With one entrance, a client can go anywhere within the
tree structure. As an example, a content is stored under the
container with URI prefix of /CSEBase-ID/AE-ID/container
ID/contentInstance-ID. From the URI of the content, a client would
be able to easily do the name resolution and go to the oneM2M server
identified by CSEBase-ID.
- IETF CoRE[21] specifies the Resource Directory (RD) [23] for
resource registration and resolution. A RD is a database that stores
links about resources hosted by endpoints (EP), which are called RD
entries. An EP is a server that is associated with a scheme (e.g.
CoAP[22] by default, or HTTP), IP address and port.
It is likely that a physical IoT node may host one or more Eps. The
RD provides a set of RESTful interface for EPs to register and
maintain sets of RD entries, and for clients to look up resources.
In order for the ICN infrastructure to support IoT applications, the
NRS should provide the interoperability between those existing
resource registries as well as integration of them into the ICN
infrastructure. The NRS should allow different providers to coexist
and for requesters to choose one or more preferred providers on
their own.
4.2.4. Support for manifest
The NRS should support resolution using manifests. Namely, if a
content object is described by a manifest, the NRS should support
efficient recursive resolution of the names included in the
manifest. Alternatively, if the manifest contains mapping of content
names to location (for instance, DASH manifest may contain
additional Base URL for a specific content stream), then this should
be consistent with the mapping obtained from the NRS.
4.2.5. Resolution result selection
The NRS may be able to return some of the active producers or all of
them for the client's selection or select the best producer based on
the client's criteria and context information, e.g. producer with
least load, with least response time, etc.
Hong, et al. Expires September 14, 2017 [Page 13]
Internet-Draft NRS Requirements March 2017
4.3. Requirements on Security
Requirements on security are things that should be considered in
terms of the security aspect for both the node and data.
4.3.1. Accessibility
The NRS system must be prevented from the malicious users attempting
to hijack or corrupt name records.
The name records must have proper access rights such that the
information contained in the name record would not be revealed to
unauthorized users.
The name records may be associated within certain domain, and cannot
be propagated outside the domain. For example, for content that is
only shared within the community should be restricted within the
community network, outside of which the content may not exist.
4.3.2. Authentication
Users/nodes that register themselves with NRS server require the
authentication to ensure who claims to be. For example, the attacker
can act as a fake NRS server which causes disruption or intercepts
the data.
4.3.3. Data confidentiality
NRS has to keep the data confidentiality to prevent a lot of
sensitive data from reaching unauthorized data requestor in IoT
environment.
4.3.4. Privacy
When a private data is registered in the system, NRS has to support
the privacy to avoid the information leaking. Otherwise,
unauthorized entity may disclose the privacy.
Hong, et al. Expires September 14, 2017 [Page 14]
Internet-Draft NRS Requirements March 2017
5. Use cases of NRS
In this section, we describe usages of NRS in the ICN literature.
5.1. Flat Name routing support
In ICN, data objects must be identified by names regardless their
location or container [RFC 7927] and the names are divided into two
types of schemes: hierarchical and flat namespaces. A hierarchical
scheme used in CCN and NDN architectures has a structure similar to
current URIs, where the hierarchy improves scalability of routing
system. It is because the hierarchy enables aggregation of the name
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 is resolved to some information
which is routable through NRS or a sort of NRS in various ICN
literatures.
In PURSUIT [5], names are flat and the rendezvous functions are
defined for NRS, which is implemented by a set of Rendezvous Nodes
(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
RENE. Thus, PURSUIT decouples name resolution and data routing,
where NRS is performed by the RENE.
In MobilityFirst [9], a name called a global unique Identifier
(GUID) derived from a human-readable name via a global naming
service is flat typed 160-bits strings with self-certifying
function. Thus, MobilityFirst defines a global name resolution
service (GNRS) which resolves GUIDs to network addresses and
decouples name resolution and data routing as similar to PURSUIT.
5.2. Publisher Mobility support
In ICN literature, it is said that mobility can be achieved in
fundamental feature of ICN. Especially, consumer or client mobility
can be achieved by allowing information requests to basic procedure
from different interfaces or through attachment point of the new
network. Moreover, seamless mobility service in ICN ensures that
content reception continues without any disruption in ICN
application, so in consumer point of view, seamless mobility can be
easily supported.
Hong, et al. Expires September 14, 2017 [Page 15]
Internet-Draft NRS Requirements March 2017
However, producer or publisher mobility in ICN is more complicated
to be supported. If a publisher moves into different authority
domain or network location, then the request for a content published
by the moving publisher with origin name would be hardly forwarded
to the moving publisher. Especially in a hierarchical name scheme,
publisher mobility support is much harder than in a flat name scheme
since the routing tables related in broad area should be updated
according to the publisher movement. Therefore, various ICN
literatures would adopt NRS to achieve the publisher mobility, where
NRS can be implemented in different ways such as rendezvous
mechanism, mapping, etc.
In NDN, for publisher mobility support, rendezvous mechanisms have
been proposed to build interests rendezvous (RV) with data generated
by a mobile producer (MP) [36]. There can be classified two
approaches such as chase mobile producer and rendezvous data.
Regarding MP chasing, rendezvous acts as a mapping service that
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
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
PoA. Regarding rendezvous data, moving the data produced by the MP
have been hosting at data depot instead of forwarding interest
messages. Thus a consumer's interest message can be forwarded to
stationary place as called data rendezvous, so it would either
return the data or fetch it using another mapping solution.
Therefore, RV or other mapping functions are in the role of NRS in
NDN.
In [37], forwarding-label (FL) object is referred to enable
identifier (ID) and locator (LID) namespaces to be split in ICN.
Generally, IDs are managed by applications, while locators are
managed by a network administrator, so that IDs are mapping to
heterogeneous name schemes and LIDs are mapping to network domains
or specific network elements. Thus the proposed FL object acts as a
locator (LID) and provides the flexibility to forward Interest
messages through mapping service between IDs and LIDs. Therefore,
the mapping service in control plane infrastructure can be
considered as NRS in this draft.
In MobilityFirst [9], both consumer and publisher mobility can be
primarily handled by the global name resolution service (GNRS) which
resolves GUIDs to network addresses. Thus, the GNRS must be updated
for mobility support when a network attached object changes its
point of attachment, which differs from NDN/CCN.
Hong, et al. Expires September 14, 2017 [Page 16]
Internet-Draft NRS Requirements March 2017
5.3. Scalable Routing support
In ICN, application names identifying contents are used directly for
packet delivery, so ICN routers run a name-based routing protocol to
build name-based routing and forwarding tables. As same as
scalability of IP routing, if non-aggregated name prefixes are
injected to the Default Route Free Zone (DFZ) of ICN, then they
would be driving the growth of the DFZ routing table size. Thus a
solution to keep the routing table size under control is needed,
which can be done by defining indirection layer.
In [38], a well-known concept of Map-and-Encap is applied to provide
a simple and secure namespace mapping solution to address the
routing scalability problem in NDN's DFZ. In the proposed map-and-
encap design, data whose name prefixes do not exist in the DFZ
forwarding table can be retrieved by a distributed mapping system
called NDNS, which maintains and lookups the mapping information
from a name to its globally routed prefixes. Therefore, NDNS is a
kind of NRS.
5.4. Nameless object support
In CCNx 1.0, the concept of "Nameless Objects" that are a Content
Object without a Name is introduced to provide a means to move
Content between storage replicas without having to rename or re-sign
the content objects for the new name. Nameless Objects can be
addressed by the ContentObjectHash that is to restrict Content
Object matching by using SHA-256 hash [39].
An Interest message would still carry a Name and a
ContentObjectHash, where a Name is used for routing, while a
ContentObjectHash is used for matching. However, on the reverse
path, if the Content Object's name is missing, it is a "Nameless
Object" and only matches against the ContentObjectHash. Therefore, a
consumer needs to resolve proper name and hashes through an outside
system, which can be considered as NRS.
6. Security Considerations
[TBD]
Hong, et al. Expires September 14, 2017 [Page 17]
Internet-Draft NRS Requirements March 2017
7. IANA Considerations
This document makes no specific request of IANA.
8. Conclusions
In this draft, we broaden the definition of NRS in the ICN
infrastructure as the service which can help a client to reach a
producer of the requested content. Thus the NRS could take the
approaches of standalone name resolution, name based routing or
hybrid of the two. With the essence of NRS, it is urgent to identify
the requirements for the NRS design in ICN. In the draft, we propose
the NRS requirements from the different aspects and elaborate each
of them with examples for verification of its importance. We also
discuss the use cases of NRS in the ICN literature.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<http://www.rfc-editor.org/info/rfc7927>.
9.2. Informative References
[1] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou,
C.Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C.
Polyzos, A Survey of Information-Centric Networking Research,
Communications Surveys and Tutorials, Vol. 16, No. 2, 2014,
pp. 1024-1049.
[2] E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch,
Information Centric Networking in the IoT: Experiments with
NDN in the Wild, in ACM ICN, 2014.
Hong, et al. Expires September 14, 2017 [Page 18]
Internet-Draft NRS Requirements March 2017
[3] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data
networking for IoT: An architectural perspective, in European
Conference on Networks and Communications (EuCNC), 2014.
[4] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim,
S.Shenker, and I. Stoica, "A Data-Oriented (and Beyond)
Network Architecture." in ACM SIGCOMM, 2007, pp. 181-192.
[5] FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/.
[6] FP7 SAIL project. http://www.sail-project.eu/.
[7] NSF Named Data Networking project. http://www.named-data.net/.
[8] Content Centric Networking project. http://www.ccnx.org/.
[9] NSF Mobility First project.
http://mobilityfirst.winlab.rutgers.edu/.
[10] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N.H.
Briggs, and R. L. Braynard, "Networking Named Content." in ACM
CoNEXT, 2009.
[11] A. Baid, T.Vu, and D. Raychaudhuri, "Comparing Alternative
Approaches for Networking of Named Objects in the Future
Internet." in IEEE Workshop on Emerging Design Choices in
Name-Oriented Networking (NOMEN), 2012.
[12] M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba and B.
Mathieu, "A Survey of Naming and Routing in Information-
Centric Networks.", IEEE Communications Magazine, Vol. 50,
No.12, P. 44-53.
[13] J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On
Name-based Inter-domain Routing," Computer Networks, vol. 55,
no. 4, pp. 975-986, March 2011.
[14] K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis,
C.Tsilopoulos, G. Xylomenos, and G. C. Polyzos, "On Inter-
Domain Name Resolution for Information-Centric Networks," in
Proc.IFIP-TC6 Networking Conference,2012.
[15] Namespace Resolution in Future Internet Architectures, draft-
wang-fia-namespace-01.
[16] PID: A Generic Naming Schema for Information-centric Network,
draft-zhang-icnrg-pid-naming-scheme-03.
Hong, et al. Expires September 14, 2017 [Page 19]
Internet-Draft NRS Requirements March 2017
[17] D. Zhang, H. Liu, Routing and Name Resolution in Information-
Centric Networks, 22nd International Conference on Computer
Communications and Networks (ICCCN), 2013.
[18] S. Sevilla, P. Mahadevan, J. Garcia-Luna-Aceves, "iDNS:
Enabling Information Centric Networking Through The DNS." Name
Oriented Mobility (workshop co-located with Infocom 2014).
[19] On the Naming and Binding of Network Destinations,
https://tools.ietf.org/html/rfc1498.
[20] oneM2M Functional Architecture TS 0001,
http://www.onem2m.org/technical/published-documents.
[21] Constrained RESTful Environments, CoRE,
https://datatracker.ietf.org/wg/core/charter/, 2013.
[22] RFC 7252, The Constrained Application Protocol (CoAP).
[23] CoRE Resource Directory,
https://datatracker.ietf.org/doc/draft-ietf-core-resource-
directory/.
[24] C. Westphal, E. Demirors, An IP-based Manifest Architecture
for ICN, 2nd ACM Conference on Information-Centric Networking
(ICN 2015).
[25] M. Mosko, G. Scott , I. Solis , C. Wood, CCNx Manifest
Specification, http://www.ccnx.org/pubs/draft-wood-icnrg-
ccnxmanifests-00.html.
[26] The Locator/ID Separation Protocol (LISP),
https://datatracker.ietf.org/doc/rfc6830/.
[27] Locator/ID Separation Protocol (LISP) Map-Server Interface,
https://datatracker.ietf.org/doc/rfc6833/.
[28] Ahlgren, B. et al., "A Survey of Information-Centric
Networking", IEEE Communications Magazine vol. 50, no. 7, July
2012.
[29] Xylomenos, G. et al., "A Survey of Information-Centric
Networking Research", IEEE Communications Surveys and
Tutorials vol. 16, no. 2, 2014.
Hong, et al. Expires September 14, 2017 [Page 20]
Internet-Draft NRS Requirements March 2017
[30] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
Wahlisch, "Information Centric Networking in the IoT:
Experiments with NDN in the Wild", ACM ICN, September 2014.
[31] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named
data networking for IoT: An architectural perspective",
European Conference on Networks and Communications, July 2014.
[32] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN usage
in IoT environments", IEEE GLOBECOM, 2014.
[33] Amadeo, M. et al., "Information-centric networking for the
internet of things: challenges and opportunities", IEEE
Network vol. 30, no. 2, July 2016.
[34] Zhang, Y. et al., "Requirements and Challenges for IoT over
ICN", Internet Draft, draft-zhang-icnrg-icniotrequirements-01,
April 2016.
[35] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI Jouranl
vol. 37, no. 5, October 2015.
[36] Yu Zhang et al., "A Survey of Mobility Support in Named Data
Networking," NOM 2016.
[37] R. Ravindran et al., "Forwarding-Label support in CCN
Protocol," IETF draft, March 2016.
[38] Alexander Afanasyev et al., "SNAMP: Secure Namespace Mapping
to Scale NDN Forwarding," IEEE Global Internet Symposium,
April 2015.
[39] Marc Mosko, "Nameless Objects," July 2015.
Hong, et al. Expires September 14, 2017 [Page 21]
Internet-Draft NRS Requirements March 2017
Authors' Addresses
Jungha Hong
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon 34129
Korea
Phone: +82-42-860-0926
Email: jhong@etri.re.kr
Lijun Dong
Huawei Technologies
10180 Telesis Court
Suite 220
San Diego, CA, 92121
Phone:
Email: lijun.dong@huawei.com
Tae-Wan You
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon 34129
Korea
Phone: +82-42-860-0642
Email: twyou@etri.re.kr
Cedric Westphal
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
Phone:
Email: cedric.westphal@huawei.com
Yong-Geun Hong
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon 34129
Korea
Phone: +82-42-860-6557
Email: yghong@etri.re.kr
Hong, et al. Expires September 14, 2017 [Page 22]
Internet-Draft NRS Requirements March 2017
GQ Wang
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
Phone:
Email: gq.wang@huawei.com
Jianping Wang
City University Hong Kong
Phone:
Email: jianwang@cityu.edu.hk
Hong, et al. Expires September 14, 2017 [Page 23]