< draft-irtf-icnrg-nrsarch-considerations-01.txt   draft-irtf-icnrg-nrsarch-considerations-02.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: September 12, 2019 ETRI Expires: January 9, 2020 ETRI
March 11, 2019 V. Kafle
NICT
B. Wissingh
TNO
July 08, 2019
Architectural Considerations of ICN using Name Resolution Service Architectural Considerations of ICN using Name Resolution Service
draft-irtf-icnrg-nrsarch-considerations-01 draft-irtf-icnrg-nrsarch-considerations-02
Abstract Abstract
This document discusses architectural considerations and implications This document discusses architectural considerations and implications
of Information-Centric Networking (ICN) related to the usage of the of Information-Centric Networking (ICN) related to the usage of the
Name Resolution Service (NRS). It describes how ICN architectures Name Resolution Service (NRS). It describes how ICN architectures
may change and what implications are introduced within the ICN may change and what implications are introduced within the ICN
routing system when NRS is integrated into ICN. routing system when NRS is integrated into ICN.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 39
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 4 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 5
5. ICN Architectural Considerations for NRS . . . . . . . . . . 4 5. ICN Architectural Considerations for NRS . . . . . . . . . . 5
5.1. Name resolution . . . . . . . . . . . . . . . . . . . . . 5 5.1. Name mapping records registration, resolution, and update 6
5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 5 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 7
5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 6 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. Name Space Separation . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6.2. NRS System . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. NRS Protocols and Messages . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Information-Centric Networking (ICN) is an approach to evolve the Information-Centric Networking (ICN) is an approach to evolve the
Internet infrastructure to directly access Named Data Objects (NDOs) Internet infrastructure to directly access Named Data Objects (NDOs)
by its name, i.e., the name of NDO is directly used to route the by its name, i.e., the name of NDO is directly used to route the
request to the data object. Such name based routing in ICN poses a request to the data object. Such name-based routing in ICN has
number of issues, which are not solved yet in ICN. These issues inherent challenges in supporting globally scalable routing system,
includes global scalability of routing, producer mobility, off-path producer mobility, off-path caching, etc. In order to address these
cache, etc. In order to address these issues, the Name Resolution challenges, the Name Resolution Service (NRS) has been integrated
Service (NRS) has been integrated into several ICN projects and into several ICN projects and literature
literature [Afanasyev][Zhang2][Ravindran][SAIL][MF][Bayhan]. [Afanasyev][Zhang2][Ravindran][SAIL][MF][Bayhan].
This document describes how ICN architectures may change and what This document describes how ICN architectures may change and what
implications are introduces within the ICN routing system when NRS is implications are introduces within the ICN routing system when NRS is
integrated into ICN. It also discusses ICN architectural integrated into ICN. It also discusses ICN architectural
considerations for an NRS. In other words, the scope of this considerations for an NRS. In other words, the scope of this
document includes considerations in the veiw of the ICN architecture document includes considerations in the veiw of the ICN architecture
and routing system when integrating NRS into ICN. However, it does and routing system when integrating NRS into ICN. However, it does
not include the NRS discussion, itself, which is presented in not include the NRS discussion, itself, which is presented in
[NRSrequirements]. [NRSguidelines].
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].
o Name Resolution Service (NRS): NRS in ICN is defined as the
service that provides the name resolution function for translating
an object name into some other information such as a locator and
another name that is used for forwarding the object request
[NRSguidelines].
o NRS server: The NRS is a service maintained by a distributed
mapping database system. The NRS consists of the distributed NRS
servers storing the mapping records in database. NRS servers
store and maintain the mapping records that keep the bindings of
name to other information that is used for forwarding content
request.
o NRS resolver: The client side of the NRS is called an NRS
resolver. The resolver is responsible for initiating and
sequencing the name resolution request queries that ultimately
lead to a name resolution of the data objects. NRS resolvers can
be located in the consumer (or client) nodes and ICN routers. NRS
resolver can also store the mapping records obtained through the
name for later usage.
o Name registration: In order to create the NRS, the content names
and their mapping records must be registered in NRS system by a
publisher who has at least one authoritative NRS server or by a
producer who generates named data objects. The mapping
information is the binding of a name to some information such as
another names and locators, which are used for forwarding the
content request. Thus, a publisher or producer creates an NRS
registration request and send to an NRS server. On registration,
the NRS server stores the mapping record in the database and sends
back an ACK as a response back to the producer or publisher.
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.
3. Background 3. Background
The name based routing in ICN can be helpful to address a number of The name-based routing in ICN has inherent challenges in supporting
challenges, such as global scalability of routing, producer mobility, globally scalable routing system, producer mobility, off-path
and off-path caching in ICN. In order to address these challenges, caching, etc. In order to address these challenges, an NRS has been
an NRS has been integrated into several ICN projects and literature: integrated into several ICN projects and literature as follows:
o Routing scalability : In ICN, application names identifying o Routing scalability : In ICN, application names identifying
contents are used directly for packet delivery, so ICN routers run contents are used directly for packet delivery, so ICN routers run
a name-based routing protocol to build namebased routing and a name-based routing protocol to build namebased routing and
forwarding tables. Similar to the scalability challenge of IP forwarding tables. Similar to the scalability challenge of IP
routing, if non-aggregatable name prefixes are injected to the routing, if non-aggregatable name prefixes are injected to the
Default Route Free Zone (DFZ) of ICN, they would be driving the Default Route Free Zone (DFZ) of ICN, they would be driving the
growth of the DFZ routing table size. Thus, applying an NRS can growth of the DFZ routing table size. Thus, integrating an NRS
be a feasible solution to keep the routing table size under with ICN can be a feasible solution to keep the routing table size
control, where the NRS resolves name prefixes which do not exist under control, where the NRS resolves name prefixes which do not
in the DFZ forwarding table into globally routable prefixes such exist in the DFZ forwarding table into globally routable prefixes
as one proposed in NDN [Afanasyev]. Another approach deal with such as one proposed in NDN [Afanasyev]. Another approach deal
routing scalability is the Multi-level Distributed Hash with routing scalability is the Multi-level Distributed Hash
Table (MDHT) used in NetInf [Dannewitz]. It provides name-based Table (MDHT) used in NetInf [Dannewitz]. It provides name-based
anycast routing that can support a non-hierarchical namespace can anycast routing that can support a non-hierarchical namespace can
be adopted on a global scale [Dannewitz2]. be adopted on a global scale [Dannewitz2].
o Producer mobility : In ICN, if a producer moves into a different o Producer mobility : In ICN, if a producer moves into a different
authority domain or network location, the request for a content authority domain or network location, the request for a content
produced by the moving producer with the origin name would be produced by the moving producer with the origin name would be
hardly forwarded to the moving producer's new location. hardly forwarded to the moving producer's new location.
Especially, in a hierarchical name scheme, producer mobility Especially, in a hierarchical name scheme, producer mobility
support is much harder than in a flat name scheme since the support is much harder than in a flat name scheme since the
routing tables in broader area need to be updated according to the routing tables in broader area need to be updated according to the
producer movement. Therefore, various ICN architectures such as producer movement. Therefore, various ICN architectures such as
NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to
tackle the producer's location. tackle the producer's location.
o Off-path caching : Caching in-network is considered a basic o Off-path caching : In-network caching is a feature of an ICN
architectural component of an ICN architecture and caching architecture. Caching approaches can be categorized into on-path
approaches can be categorized into off-path caching and on-path caching and off-path caching according to the location of caches
caching based on the location of caches in relation to the in relation to the forwarding path from the original server to a
forwarding path from the original server to a consumer. Off-path consumer. Off-path caching, also referred as content replication
caching, also referred as content replication or content storing, or content storing, aims at replicating content in various
aims at replicating content in various locations within a network locations within a network in order to increase availability,
in order to increase availability, where the caching locations may where the caching locations may not be lying along the content
not be lying along the content forwarding path. Thus, finding forwarding path. Thus, finding off-path cached objects is not
off-path cached objects is not trivial in name-based routing of trivial in name-based routing of ICN. In order to support off-
ICN. In order to support off-path caches, the locations of path caches, the locations of replicas are usually advertised into
replicas are usually advertised into a name-based routing system a name-based routing system or into NRS such as in [Bayhan].
or into NRS such as in [Bayhan].
This document discusses architectural considerations and implications This document discusses architectural considerations and implications
of ICN when NRS is integrated into ICN to solve such challenges due of ICN when NRS is integrated into ICN to solve such challenges due
to the name-based routing in ICN. to the name-based routing in ICN.
4. Implications of NRS in ICN 4. Implications of NRS in ICN
In general, NRS would not be mandatory in an ICN architecture if the In general, NRS would not be mandatory in an ICN architecture if the
name-based routing system can be scalable enough to timely reflect name-based routing system can be scalable enough to timely reflect
the optimal location of requested content in the routing table. the optimal location of requested content in the routing table.
However, due to the unlimited size of content namespace, it is not However, due to the unlimited size of content namespace, it is not
easy to achieve such a scalable routing system in near future. easy to achieve such a scalable routing system in near future.
Therefore, the adoption of an NRS is a design choice for making ICN Therefore, the adoption of an NRS is a design choice for making ICN
routing and forwarding scalable. Integration of NRS would change the routing and forwarding scalable. Integration of NRS would change the
ICN architecture at least with respect to procedures, latency, and ICN architecture at least with respect to procedures, latency, and
security, which are described below. security, as follows:
o Procedure : When NRS is adopted into an ICN architecture, the o Procedure : When NRS is adopted into an ICN architecture, the
procedure of the name resolution has to be integrated into ICN procedure of the name resolution has to be integrated into ICN
overall procedures. For NRS integration, there are certain things overall procedures. For NRS integration, there are certain things
that have to be decided such as where and how the name resolution that have to be decided such as where and how the name resolution
task is performed. task is performed.
o Latency : When NRS is adopted into an ICN architecture, the o Latency : When NRS is adopted into an ICN architecture, the
additional latency of the resolution obviously occurs in the additional latency of the resolution obviously occurs in the
routing and forwarding system. Although the latency of the routing and forwarding system. Although the latency of the
resolution is added, the total latency could be minimized if the resolution is added, the total latency could be minimized if the
nearest copies or off-path caches can be located by the NRS lookup nearest copies or off-path caches can be located by the NRS lookup
procedure. Additionally, there might be a trade-off between the procedure. Additionally, there might be a trade-off between the
resolution latency and inter-domain traffic reduction. resolution latency and inter-domain traffic reduction.
o Security : When NRS is adopted into an ICN architecture, security o Security : When NRS is adopted into an ICN architecture, security
treats may increase. Protection of the NRS system against attacks threats may increase. Protection of the NRS system against
such as Distributed Denial of Service (DDoS) and authentication of attacks such as Distributed Denial of Service (DDoS) and
name mapping records and related signaling messages would be authentication of name mapping records and related signaling
challenging. messages would be challenging.
5. ICN Architectural Considerations for NRS 5. ICN Architectural Considerations for NRS
This section discusses the various items that have to be considered This section discusses the various items that have to be considered
from the point of view of ICN architecture when it utilizes an NRS. from the point of view of ICN architecture when ICN utilizes an NRS.
These items are related with the name mapping records registration, These items are related with the name mapping records registration,
resolution, and update, protocols and messages, and integration with resolution, and update, protocols and messages, and integration with
the routing system. the routing system.
5.1. Name resolution 5.1. Name mapping records registration, resolution, and update
When an NRS is integrated into an ICN architecture, the followings When an NRS is integrated in an ICN architecture, the functions
related with the registration and resolution of name mapping records related with the registration, resolution and update of name mapping
have to be considered. records have to be considered. The NRS nodes maintain the name
mapping records and may exist in an overlay network over the ICN
routers, that is, they communicate to each other through ICN routers.
The NRS nodes exist in a distributed manner so that an NRS node is
always available closer to an ICN node and communication latency for
the name registration and resolution performed by the ICN node
remains very low.
o Who performs the name resolution? o Name registration: Name registration is performed by the producer
when it creates a new content and an ICN router when it stores the
content in its cache. When a producer creates a content and
assigns a name to it from the name prefix space assigned to it,
the producer performs the name registration in an NRS node. When
an ICN router caches the content in its content store, it performs
name registration with a nearby NRS node. As the content gets
cached in many ICN routers, all of them may register the same
content names in the same NRS node multiple times. In this case,
the NRS node adds the new location of the content to the name
record together with the previous locations. In this way, each of
the name records stored in the NRS node may contain multiple
locations of the content.
o How is the name resolution performed? o Name resolution: Name resolution is performed to obtain the name
record from an NRS node by sending a name resolution request
message and getting the response containing the record. Regarding
the name-based ICN routing context, the name resolution will be
mostly performed by an ICN router that does not contain the name
in its FIB table. The name resolution may also be performed by
the consumer (in case the consumer is multihomed) to make decision
to forward the content request in a better direction so that it
obtains the content from the nearest cache. If the consumer is
single homed, it may not perform the name resolution. It creates
the content request packet containing the content name and
forwards to the nearest ICN router. The ICN router checks its FIB
table to know if the content name exists. If the content name
does not exist, it performs name resolution to obtain the name
mapping record and adds to FIB table. The ICN router may also
perform name resolution even before the arrival of the content
request time to time to use the name mapping record to configure
the FIB table.
The name resolution in ICN can be performed by consumer, routers, or o Name record update: Name record update is carried out when a
both. Once it is decided where the name resolution will take place, content name mapping record changes, e.g. the content is not
it has to be considered how the name resolution will be performed. available in one or more of previous locations.
The name provided by a consumer might be always resolved to
identifiers in a differnet namespace just like a DNS lookup.
Conversely, an NRS is always needed to map names to a different
namespace.
5.2. Protocols and Semantics 5.2. Protocols and Semantics
In order to develop a NRS system within a local ICN network domain or In order to develop an NRS system within a local ICN network domain
global ICN network domain, new protocols and semantics should be or global ICN network domain, new protocols and semantics should be
designed to manage and resolve names between different name spaces. designed to manage and resolve names between different name spaces.
One way of implementing an NRS is by extending the basic ICN TLV One way of implementing an NRS is by extending the basic ICN TLV
format and semantics [CCNxMessages] [CCNxSemantics]. For instance, format and semantics [CCNxMessages] [CCNxSemantics]. For instance,
name resolution and response messages can be implemented by defining name resolution and response messages can be implemented by defining
new type fields in the Interest and Content Object messages new type fields in the Interest and Content Object messages
[CCNxNRS]. Then it allows the ICN architecture to minimize [CCNxNRS]. Then it allows the ICN architecture to minimize
implication of ICN architectural changes. But NRS system cannot implication of ICN architectural changes. But NRS system cannot
support more flexible and scalable designs cause to restrict basic support more flexible and scalable designs cause to restrict basic
ICN protocol and semantics. ICN protocol and semantics.
On the other hand, a NRS system can be implemented by using its own On the other hand, an NRS system can be implemented by using its own
protocol and semantics like existing NRS systems, such as [Hong]. protocol and semantics like existing NRS systems, such as [Hong].
For instance, the NRS protocol and messages can be implemented by For instance, the NRS protocol and messages can be implemented by
using a RESTful API. Then a NRS as application protocol can be using a RESTful API. Then an NRS as application protocol can be
operated independently from a basic ICN architecture, but an ICN operated independently from a basic ICN architecture, but an ICN
architecture cannot be assisted with the routing protocol itself architecture cannot be assisted with the routing protocol itself
effectively. effectively.
5.3. Routing System 5.3. Routing System
It has to be considered how to process the information resolved by an It has to be considered how to process the information resolved by an
NRS lookup. The results of an NRS operation can be intended to be NRS lookup. The results of an NRS operation can be intended to be
used just to construct tunnels resulting in NRS identifying tunnel used just to construct tunnels resulting in NRS identifying tunnel
endpoints. endpoints.
Another way to process the information resolved by an NRS lookup is Another way to process the information resolved by an NRS lookup is
to use it as routing hints in request messages. In this case, to use it as routing hints in request messages. In this case,
request message needs to be re-written with the resolved information request message needs to be re-written with the resolved information
including the original name that was requested by a consumer to check including the original name that was requested by a consumer to check
the data integrity. the data integrity.
6. Security Considerations 6. Security Considerations
When NRS is integrated into an ICN architecture, security threats When NRS is integrated into an ICN architecture, security threats
shall be increased in various aspects such as followings. will be increased in various aspects as follows:
6.1. Name Space Separation
In order to deploy an NRS on ICN architecture, ICN name spaces are
separated into more than two name spaces. Thus these name spaces
should be mapped and managed securely. According to the ICN research
challenge [RFC7927], new name space can also provide an integrity
verification function to authenticate its publishers. In addition to
the verification, binding two different name spaces should be
securely required.
6.2. NRS System
NRS enables deployment of new entities to build distributed and o Name Space Separation: In order to deploy an NRS on ICN
scalable NRS systems. Thus, the entities, e.g., mapping server that architecture, ICN name spaces are separated into more than two
can be a mapping database, could be a single point of failure name spaces. Thus these name spaces should be mapped and managed
receiving malicious requests from innumerable adversaries like Denial securely. According to the ICN research challenge [RFC7927], new
of Service or Distributed Denial of service attacks. Additionally, name space can also provide an integrity verification function to
in order to communicate with the entities to build a NRS system, an authenticate its publishers. In addition to the verification,
initiator should rely on other NRS entities that are designed to be binding two different name spaces should be securely required.
distributed deployed mapping servers in each network domain. Because
malicious entities should be involved in this communication to
impersonate control functions. Thus, NRS entities should trust each
other and communications with them should be protected securely.
6.3. NRS Protocols and Messages o NRS System: NRS enables deployment of new entities to build
distributed and scalable NRS systems. Thus, the entities, e.g.,
mapping server that can be a mapping database, could be a single
point of failure receiving malicious requests from innumerable
adversaries like Denial of Service or Distributed Denial of
service attacks. Additionally, in order to communicate with the
entities to build a NRS system, an initiator should rely on other
NRS entities that are designed to be distributed deployed mapping
servers in each network domain. Because malicious entities should
be involved in this communication to impersonate control
functions. Thus, NRS entities should trust each other and
communications with them should be protected securely.
Regarding NRS messages, such as lookup, update, etc., if these o NRS Protocols and Messages: Regarding NRS messages, such as
messages are transported unauthenticated, an adversary can manipulate lookup, update, etc., if these messages are transported
them and hijack the important communication to response or to store unauthenticated, an adversary can manipulate them and hijack the
fake data. Thus, the adversary can generate malicious traffic to be important communication to response or to store fake data. Thus,
redirected to victim hosts. Therefore, security requirements for NRS the adversary can generate malicious traffic to be redirected to
should be considered to protect the ICN architecture as well as the victim hosts. Therefore, security requirements for NRS should be
NRS. considered to protect the ICN architecture as well as the NRS.
7. Acknowledgements 7. Acknowledgements
[TBD] [TBD]
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 20 skipping to change at page 9, line 38
Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017. Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017.
[CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution
Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018.
[Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable
Name Resolution System for Information-Centric Name Resolution System for Information-Centric
Networking", ACM ICN , September 2015. Networking", ACM ICN , September 2015.
[NRSrequirements] [NRSguidelines]
Hong, J. et al., "Requirements for Name Resolution Service Hong, J. et al., "Design Guidelines for Name Resolution
in ICN", draft-irtf-icnrg-nrs-requirements-01 , March Service in ICN", draft-irtf-icnrg-nrs-guidelines-02 , July
2019. 2019.
[Dannewitz] [Dannewitz]
Dannewitz, C. et al., "Network of Information (NetInf)-An Dannewitz, C. et al., "Network of Information (NetInf)-An
information centric networking architecture", Computer information centric networking architecture", Computer
Communications vol. 36, no. 7, April 2013. Communications vol. 36, no. 7, April 2013.
[Dannewitz2] [Dannewitz2]
Dannewitz, C., DAmbrosio, M., and V. Vercellone, Dannewitz, C., DAmbrosio, M., and V. Vercellone,
"Hierarchical DHT-based name resolution for Information- "Hierarchical DHT-based name resolution for Information-
skipping to change at line 382 skipping to change at page 10, line 30
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
Ved Kafle
NICT
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: kafle@nict.go.jp
Bastiaan Wissingh
TNO
Email: bastiaan.wissingh@tno.nl
 End of changes. 27 change blocks. 
107 lines changed or deleted 174 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/