icnrg: draft-dong-nrs-requirements-00.txt

File draft-dong-nrs-requirements-00.txt, 29.8 KB (added by borje.ohlman@…, 22 months ago)
Line 
1Internet Engineering Task Force                               Lijun Dong
2Internet Draft                                           Cedric Westphal
3Intended status: Informational                                   GQ Wang
4Expires: January 9, 2017                             Huawei Technologies
5                                                           Jianping Wang
6                                               City University Hong Kong
7
8
9
10
11              Requirements of Name Resolution Service in ICN
12                       draft-dong-NRS-requirement-00
13
14
15Abstract
16
17   This document summarizes the existing approaches for name resolution
18   in various ICN architectures, and categorizes them into two groups:
19   (1) standalone name resolution; (2) name based routing. It compares
20   the two types of approaches from the aspects of update message
21   overhead, resolution capability, node failure impact, and maintained
22   database. And hybrid approaches also exist with a subnet of routers
23   carrying out name based routing. Despite the coexistence of
24   different name resolution approaches, the Name Resolution Service
25   (NRS) is most essential service that shall be provided by the ICN
26   infrastructure. The document gives the definition of NRS in ICN and
27   proposes some requirements of NRS, i.e. resolution guarantee, delay
28   sensitivity, minimum inter-domain traffic, failure resilience,
29   accuracy, security and accessibility, scalability, and time
30   transiency, support for manifest, interoperability, resolution
31   result selection, heterogeneity, unspecified Content Name.
32
33Status of This Memo
34
35   This Internet-Draft is submitted in full conformance with the
36   provisions of BCP 78 and BCP 79.
37
38   Internet-Drafts are working documents of the Internet Engineering
39   Task Force (IETF).  Note that other groups may also distribute
40   working documents as Internet-Drafts.  The list of current Internet-
41   Drafts is at http://datatracker.ietf.org/drafts/current/.
42
43   Internet-Drafts are draft documents valid for a maximum of six
44   months and may be updated, replaced, or obsolete by other documents
45   at any time.  It is inappropriate to use Internet-Drafts as
46   reference material or to cite them other than as "work in progress."
47
48
49
50
51Dong, et al.           Expires January 9, 2017                 [Page 1]
52 
53Internet-Draft        Requirements of NRS in ICN           October 2016
54
55
56   This Internet-Draft will expire on January 9, 2017.
57
58Copyright Notice
59
60   Copyright (c) 2016 IETF Trust and the persons identified as the
61   document authors.  All rights reserved.
62
63   This document is subject to BCP 78 and the IETF Trust's Legal
64   Provisions Relating to IETF Documents
65   (http://trustee.ietf.org/license-info) in effect on the date of
66   publication of this document. Please review these documents
67   carefully, as they describe your rights and restrictions with
68   respect to this document. Code Components extracted from this
69   document must include Simplified BSD License text as described in
70   Section 4.e of the Trust Legal Provisions and are provided without
71   warranty as described in the Simplified BSD License.
72
73Table of Contents
74
75
76   1. Introduction...................................................2
77      1.1. Comparisons of Standalone Name Resolution and Name based
78      Routing Approaches.............................................4
79   2. Definition of Name Resolution Service in ICN...................5
80   3. Requirements of Name Resolution Service in ICN.................6
81      3.1. Resolution Guarantee......................................6
82      3.2. Delay Sensitivity.........................................6
83      3.3. Minimum Inter-Domain Traffic..............................6
84      3.4. Failure Resilience........................................6
85      3.5. Accuracy..................................................7
86      3.6. Security and accessibility................................7
87      3.7. Scalability...............................................7
88      3.8. Time Transiency...........................................8
89      3.9. Support for manifest......................................8
90      3.10. Interoperability.........................................8
91      3.11. Resolution Result Selection..............................9
92      3.12. Heterogeneity............................................9
93      3.13. Unspecified Content Name................................10
94   4. IANA Considerations...........................................10
95   5. Conclusions...................................................10
96   6. Informative References........................................10
97
981. Introduction
99
100   Information Centric Networking (ICN)[1] has been identified and
101   acknowledged as the most promising architecture for the future
102   Internet as well as the future Internet of Things(IoT)[2][3]. There
103
104
105Dong, et al.           Expires January 9, 2017                 [Page 2]
106 
107Internet-Draft        Requirements of NRS in ICN           October 2016
108
109
110   are existing efforts in designing the ICN architecture, such as
111   DONA[4], PURSUIT[5], NDN[7][10], CCN[8], SAIL[6], MobilityFirst[9].
112   Most ICN architectures are centered around routing for content
113   retrieval.
114
115   ICN routing generally involves three steps:
116
117  - Name resolution[11][12][14][15][17][18]: matches/translates a
118     content name to locators of providers/sources that can provide the
119     content.
120
121  - Content request routing: routes the content request towards the
122     producer either based on the name or the locator. The process of
123     name resolution and content request routing can be integrated. If
124     integrated, the content request is routed by name, such as in
125     NDN/CCN. If not integrated, the content request is routed by the
126     locator obtained from the previous name resolution step, such as
127     in DONA, PURSUIT, SAIL, MobilityFirst.
128
129  - Content delivery: Constructs a path for transferring the content
130     from the provider to the requester.  In the integrated approach,
131     content can be routed using breadcrumbs left by the request to
132     define a reverse path, or by some other mechanism, such as
133     including a locator for the requester in the content request. In
134     the uncombined approach, the content can be routed from the
135     provider back to the request through an independent path.
136
137   Thus the name resolution process in ICN architectures either can be
138   separated from the message routing (e.g. routing of content request
139   message) as a standalone process or can be integrated with the
140   message routing as one combined process. The former is referred as
141   standalone name resolution approach, the latter is referred as name
142   based routing approach in this document.
143
144   In the case that the content request also specifies the reverse
145   path, as in NDN/CCN, the name resolution mechanism also determines
146   the routing path for the data. This adds a requirement on the name
147   resolution service to propagate interest in a way that is consistent
148   with the subsequent data forwarding. Namely, the interest must
149   select a path for the data based upon the finding the copy of the
150   content, but also properly delivering the data.
151
152   A hybrid approach would combine name resolution as a subset of
153   routers on the path with some tunneling in between (say, across an
154   administrative domain) so that only a few of the nodes in the
155   architecture perform name resolution in the name-based approach.
156
157
158
159Dong, et al.           Expires January 9, 2017                 [Page 3]
160 
161Internet-Draft        Requirements of NRS in ICN           October 2016
162
163
164   Additionally, some other intermediary step may be included in the
165   name resolution, namely the mapping of one name to other names, in
166   order to facilitate the retrieval of named content, by way of a
167   manifest[24][25]. The manifest is resolved using one of the two
168   above approaches, and it may include further mapping of names to
169   content and location. The steps for name resolution then become:
170   first translate the manifest name into a location of a copy of the
171   manifest; the manifest includes further names of the content
172   components, and potentially locations for the content. The content
173   is then retrieved by using these names and/or location, potentially
174   resulting in additional name resolutions.
175
1761.1. Comparison of Standalone Name Resolution and Name based Routing
177   Approaches
178
179   The following compares the standalone name resolution and name based
180   routing approaches from different aspects:
181
182  - Update message overhead: The update message overhead is due to the
183     change of content reachability, which may include content caching
184     or expiration, content producer mobility etc. The name based
185     routing approach may require to flood part of the network for
186     update propagation. In the worst case, the name based routing
187     approach may flood the whole network (but mitigating techniques
188     may be used to scope the flooding). The standalone name resolution
189     approach only requires to update propagation in part of the name
190     resolution overlay.
191
192  - Resolution capability:  The standalone name resolution approach
193     can guarantee the resolution of any content in the network if it
194     is registered to the name resolution overlay (assuming the content
195     is being broadcast in the overlay after it is registered). On the
196     other hand, the name based routing approach can only promise a
197     high probability of content resolution, depending on the flooding
198     scope of the content availability information (i.e. content
199     publishing message and name based routing table).
200
201  - Node failure impact: Nodes involved in the standalone name
202     resolution approach are the name resolution overlay servers (e.g.
203     Resolution Handlers in DONA), while the nodes involved in the name
204     based routing approach are routers which route messages based on
205     locally maintained name based routing tables (e.g. NDN routers).
206     Node failures in the standalone name resolution approach may cause
207     some content resolution to fail even though the content is
208     available. This problem does not exist in the name based routing
209     approach because other alternative paths can be discovered to
210
211
212
213Dong, et al.           Expires January 9, 2017                 [Page 4]
214 
215Internet-Draft        Requirements of NRS in ICN           October 2016
216
217
218     bypass the failed ICN routers, given the assumption that the
219     network is still connected.
220
221  - Maintained databases: The storage usage for the standalone name
222     resolution approach is different from that of the name based
223     routing approach. The standalone name resolution approach
224     typically needs to maintain two databases: name to locator mapping
225     in the name resolution overlay and routing tables in the routers
226     on the data forwarding plane. The name based routing approach
227     needs to maintain different databases: name routing table and
228     optionally breadcrumbs for reverse routing of content back to the
229     requester.
230
2312. Definition of Name Resolution Service in ICN
232
233   In ICN design, a name is used to identify an entity, such as named
234   data content, a device, an application, a service. ICN requires
235   uniqueness and persistency of the name of any entity to ensure the
236   reachability of the entity within certain scope and with proper
237   authentication and trust guarantees. The name does not change with
238   the mobility and multi-home of the corresponding entity. A client
239   can always use this name to retrieve the content from network and
240   verify the binding of the content and the name. Ideally, a name can
241   include any form of identifier, which can be flat, hierarchical, and
242   human readable or non-readable.
243
244   The Name Resolution Service (NRS) is defined as the service that is
245   provided by ICN infrastructure to help a client to reach a specific
246   piece of content, service, or host using a persistent name. The NRS
247   could take the standalone name resolution approach to return the
248   client with the locators of the content, which will be used by the
249   underlying network as the identifier to route the client's request
250   to one of the producers. The examples are iDNS [18], Global Name
251   Resolution Service (GNRS)[9], and Locator/ID Separation Protocol
252   (LISP)[26][27]based approach. The NRS could take the name based
253   routing approach, which integrates the name resolution with the
254   content request message routing. No matter which approach is taken
255   by the NRS in ICN, it is the most essential component or service of
256   the ICN infrastructure. The NRS could also take hybrid approach
257   which can perform name based routing approach from the beginning,
258   when it fails at certain router, the router can go back to the
259   standalone name resolution approach. The alternative hybrid NRS
260   approach also works, which can perform standalone name resolution
261   approach to find locators of routers which can carry out the name
262   based routing of the client's request.
263
264
265
266
267Dong, et al.           Expires January 9, 2017                 [Page 5]
268 
269Internet-Draft        Requirements of NRS in ICN           October 2016
270
271
2723. Requirements of Name Resolution Service in ICN
273
2743.1. Resolution Guarantee
275
276   The NRS must ensure the name resolution success if the matching
277   content exists in the network, regardless of its popularity, number
278   of cached copies.
279
2803.2. Delay Sensitivity
281
282   The name resolution process provided by the NRS must not introduce
283   significant latencies. With more number of name record replications,
284   the number of nodes involved in the name resolution may be reduced.
285   For example, in the standalone name resolution approach, with the
286   name record being replicated to higher hierarchy or the peer NRS
287   server in the overlay, the name resolution can be responded more
288   promptly. In the content based routing approach, with the content
289   based routing table being broadcast within the larger scope in the
290   network, the name resolution and request routing can have higher
291   probability to successfully reach the nearer copy of the requested
292   content.
293
294   The NRS deployment should balance the number of nodes involved in
295   the name resolution and the overhead/cost for the name record
296   replication. To ensure the low latency, the NRS should be able to
297   route a content request to the closest copy. Message forwarding and
298   processing should be efficient and computation complexity should be
299   reasonable low and affordable by the current processor technologies.
300
3013.3. Minimum Inter-Domain Traffic
302
303   The NRS must attempt to minimize total traffic, and inter-domain
304   traffic in particular. In order to achieve that, message propagation
305   for name resolution and retrieval should retain the locality and
306   should be kept in the network domain if that domain contains both
307   the client and the content copy.
308
309   For example, a client is requesting the temperature data of the
310   building that he/she is residing in, the NRS should be able to
311   return or route to the nearest gateway in the building that stores
312   such data instead of a remote server in the cloud.
313
3143.4. Failure Resilience
315
316   The NRS must ensure resilience to node failures. After a NRS node
317   fails, the NRS system must be able to restore the name records
318
319
320
321Dong, et al.           Expires January 9, 2017                 [Page 6]
322 
323Internet-Draft        Requirements of NRS in ICN           October 2016
324
325
326   stored in the NRS node. The NRS must also ensure resolution failure
327   at one NRS node would be resolved and corrected by other NRS nodes.
328
329   For example, in the standalone name resolution approach, when a NRS
330   overlay server fails, the name records should be able to transferred
331   and recovered in its peer server or its replacement. In the content
332   based approach, the failure of one ICN router does not cause much
333   trouble in the name resolution, because the other alternative paths
334   can be established that bypass the failed ICN router. However, it
335   requires that the ICN router has propagated its content based
336   routing information in the network.
337
3383.5. Accuracy
339
340   The NRS must provide accurate and up-to-date information on how to
341   reach the producer(s) of requested content with minimum overhead in
342   propagation the update information. Content mobility and expiration
343   must be reflected in the corresponding records in the NRS system
344   with minimum delay to guarantee the accurate resolution.
345
346   For example, a content can be moved from one domain to another
347   domain due to the mobility of the producer, then the old name record
348   should be deleted from the NRS system and a new name record should
349   be added and updated with minimum delay.
350
3513.6. Security and accessibility
352
353   The NRS system must be prevented from the malicious users attempting
354   to hijack or corrupt name records.
355
356   The name records must have proper access rights such that the
357   information contained in the name record would not be revealed to
358   unauthorized users.
359
360   The name records may be associated within certain domain, and cannot
361   be propagated outside the domain. For example, for content that is
362   only shared within the community should be restricted within the
363   community network, outside of which the content does not exist.
364
3653.7. Scalability
366
367   The NRS system must to be extremely scalable to support a large
368   number of content objects as well as billions of users, who may
369   access the system through various connection methods and devices.
370   Specially in IoT applications, the data size is small but frequently
371   generated by sensors.
372
373
374
375Dong, et al.           Expires January 9, 2017                 [Page 7]
376 
377Internet-Draft        Requirements of NRS in ICN           October 2016
378
379
380   Message forwarding and processing, routing table building-up and
381   name records propagation must be efficient and scalable. The memory
382   requirement for NRS nodes should be achievable by the current memory
383   technologies.
384
3853.8. Time Transiency
386
387   The NRS should support time-transient content, which is frequently
388   created in and disappearing from the network. This kind of content
389   only stays in the network for a short time, which requires the NRS
390   be able to promptly reflects the records of them in the system. For
391   example, some video clip only exists in the network for a very short
392   time, which requires the NRS to promptly update their name records.
393
3943.9. Support for manifest
395
396   The NRS should support resolution using manifests. Namely, if a
397   content object is described by a manifest, the NRS should support
398   efficient recursive resolution of the names included in the
399   manifest. Alternatively, if the manifest contains mapping of content
400   names to location (for instance, DASH manifest contain additional
401   Base URL for a specific content stream), then this should be
402   consistent with the mapping obtained from the NRS.
403
4043.10. Interoperability
405
406   Considering the emergence of IoT applications, many standard bodies
407   for IoT have settled their ways for resource/data management. For
408   example:
409
410  - oneM2M[19] uses tree structure to store resources. Each resource
411     is addressable by its URI. oneM2M resources are linked together by
412     parent-child relationship or link relationship with pointers.
413     Resource resolution is indicated in the hierarchical name of the
414     resources. With one entrance, a client can go anywhere within the
415     tree structure. As an example, a content is stored under the
416     container with URI prefix of /CSEBase-ID/AE-ID/container-
417     ID/contentInstance-ID. From the URI of the content, a client would
418     be able to easily do the name resolution and go to the oneM2M
419     server identified by CSEBase-ID.
420
421  - IETF CoRE[21] specifies the Resource Directory (RD) [23] for
422     resource registration and resolution. A RD is a database that
423     stores links about resources hosted by endpoints (EP), which are
424     called RD entries. An EP is a server that is associated with a
425     scheme (e.g. CoAP[22] by default, or HTTP), IP address and port.
426     It is likely that a physical IoT node may host one or more EPs.
427
428
429Dong, et al.           Expires January 9, 2017                 [Page 8]
430 
431Internet-Draft        Requirements of NRS in ICN           October 2016
432
433
434     The RD provides a set of RESTful interface for EPs to register and
435     maintain sets of RD entries, and for clients to look up resources.
436
437   In order for the ICN infrastructure to support IoT applications, the
438   NRS should provide the interoperability between those existing
439   resource registries as well as integration of them into the ICN
440   infrastructure. The NRS should allow different providers to coexist
441   and for requesters to choose one or more preferred providers on
442   their own.
443
4443.11. Resolution Result Selection
445
446   The NRS may be able to return some of the active producers or all of
447   them for the client's selection or select the best producer based on
448   the client's criteria and context information, e.g. producer with
449   least load, with least response time, etc.
450
4513.12. Heterogeneity
452
453   There are heterogeneous content naming schemes[16][19] and name
454   resolution approaches from different ICN architectures. For example:
455
456  - Names in DONA[1] consist of the cryptographic hash of the
457     principal's public key P and a label L uniquely identifying the
458     information with respect to the principal. Name resolution in DONA
459     is provided by specialized servers called Resolution Handlers
460     (RHs).
461
462  - Content in PURSUIT[5] is identified by a combination of a scope ID
463     and a rendezvous ID. The scope ID represents the boundaries of a
464     defined dissemination strategy for the content it contain. The
465     rendezvous ID is the actual identity for a particular content.
466     Name resolution in PURSUIT is handled by a collection of
467     Rendezvous Nodes (RNs), which are implemented as a hierarchical
468     Dynamic Hash Table (DHT)[13][14].
469
470  - Names in NDN/CCN[8][10] are hierarchical and may be similar to
471     URLs. Each name component can be anything, including a dotted
472     human-readable string or a hash value. NDN/CCN adopts the name
473     based routing. The NDN router forwards the interest by doing the
474     longest-match lookup in the Forwarding Information Base (FIB)
475     based on the content name and the interest is stored in the
476     Pending Interest Table (PIT).
477
478  - In MobilityFirst[9], every network entity, content has a Global
479     Unique Identifier (GUID). GUIDs are flat 160-bit strings with no
480
481
482
483Dong, et al.           Expires January 9, 2017                 [Page 9]
484 
485Internet-Draft        Requirements of NRS in ICN           October 2016
486
487
488     semantic structure. Name Resolution in MobilityFirst all is
489     carried out via a Global Name Resolution Service (GNRS).
490
491   Although the existing naming schemes are different, they all need to
492   provide basic functions for identifying a content, supporting trust
493   provenance, content lookup and routing. The NRS may combine the
494   advantages of different mechanisms. The NRS may be able to provide a
495   generic naming schema to resolve any type of content name, either it
496   is flat or hierarchical.
497
4983.13. Unspecified Content Name
499
500   Currently, both the standalone name resolution and name based
501   routing approaches assume that the content name is known and
502   specified by the client, which is sometimes not the case. A client
503   may not know the exact name of the data that he/she is requesting,
504   for example, a client wants to retrieve the temperature data on
505   07/21/2015 in San Diego. In this case, the client is only able to
506   specify some semantics and contextual information of the data that
507   he/she is looking for.
508
509   The NRS may be able to resolve those requests by having a northbound
510   interface to the other services, which can return the content
511   name(s) matching the client's request.
512
5134. IANA Considerations
514
515   This document makes no specific request of IANA.
516
5175. Conclusions
518
519   In this draft, we broaden the definition of NRS in the ICN
520   infrastructure as the service which can help a client to reach a
521   producer of the requested content. Thus the NRS could take the
522   approaches of standalone name resolution, name based routing or
523   hybrid of the two. With the essence of NRS, it is urgent to identify
524   the requirements for the NRS design in ICN. In the draft, we propose
525   the NRS requirements from the different aspects and elaborate each
526   of them with examples for verification of its importance.
527
5286. Informative References
529
530   [1]   G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, C.
531         Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C. Polyzos,
532         A Survey of Information-Centric Networking Research,
533         Communications Surveys and Tutorials, Vol. 16, No. 2, 2014, P.
534         1024-1049.
535
536
537Dong, et al.           Expires January 9, 2017                [Page 10]
538 
539Internet-Draft        Requirements of NRS in ICN           October 2016
540
541
542   [2]   E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Wahlisch,
543         Information Centric Networking in the IoT: Experiments with
544         NDN in the Wild, in ACM ICN, 2014.
545
546   [3]   Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, Named data
547         networking for IoT: An architectural perspective, in European
548         Conference on Networks and Communications (EuCNC), 2014.
549
550   [4]   T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim,S.
551         Shenker, and I. Stoica, "A Data-Oriented (and Beyond) Network
552         Architecture." in ACM SIGCOMM, 2007, pp. 181-192.
553
554   [5]   FP7 PURSUIT project. http://www.fp7-pursuit.eu/PursuitWeb/.
555
556   [6]   FP7 SAIL project. http://www.sail-project.eu/.
557
558   [7]   NSF Named Data Networking project. http://www.named-data.net/.
559
560   [8]   Content Centric Networking project. http://www.ccnx.org/.
561
562   [9]   NSF Mobility First project.
563         http://mobilityfirst.winlab.rutgers.edu/.
564
565   [10]  V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N.
566         H. Briggs, and R. L. Braynard, "Networking Named Content." in
567         ACM CoNEXT, 2009.
568
569   [11]  A. Baid, T.Vu, and D. Raychaudhuri, "Comparing Alternative
570         Approaches for Networking of Named Objects in the Future
571         Internet." in IEEE Workshop on Emerging Design Choices in
572         Name-Oriented Networking (NOMEN), 2012.
573
574   [12]  M. F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba and B.
575         Mathieuy, "A Survey of Naming and Routing in Information-
576         Centric Networks.", IEEE Communications Magazine, Vol. 50, No.
577         12, P. 44-53.
578
579   [13]  J. Rajahalme, M. Sarela, K. Visala, and J. Riihijarvi, "On
580         Name-based Inter-domain Routing," Computer Networks, vol. 55,
581         no. 4, pp. 975-986,March 2011.
582
583   [14]  K. V. Katsaros, N. Fotiou, X. Vasilakos, C. N. Ververidis, C.
584         Tsilopoulos, G. Xylomenos, and G. C. Polyzos, "On Inter-Domain
585         Name Resolution for Information-Centric Networks," in Proc.
586         IFIP-TC6 Networking Conference,2012.
587
588
589
590
591Dong, et al.           Expires January 9, 2017                [Page 11]
592 
593Internet-Draft        Requirements of NRS in ICN           October 2016
594
595
596   [15]  Namespace Resolution in Future Internet Architectures,draft-
597         wang-fia-namespace-01.
598
599   [16]  PID: A Generic Naming Schema for Information-centric Network,
600         draft-zhang-icnrg-pid-naming-scheme-03.
601
602   [17]  D. Zhang, H. Liu, Routing and Name Resolution in Information-
603         Centric Networks, 22nd International Conference on Computer
604         Communications and Networks (ICCCN), 2013.
605
606   [18]  S. Sevilla, P. Mahadevan, J. Garcia-Luna-Aceves, "iDNS:
607         Enabling Information Centric Networking Through The DNS." Name
608         Oriented Mobility (workshop co-located with Infocom 2014).
609
610   [19]  On the Naming and Binding of Network Destinations,
611         https://tools.ietf.org/html/rfc1498.
612
613   [20]  oneM2M Functional Architecture TS 0001,
614         http://www.onem2m.org/technical/published-documents.
615
616   [21]  Constrained RESTful Environments, CoRE,
617         https://datatracker.ietf.org/wg/core/charter/, 2013.
618
619   [22]  RFC 7252, The Constrained Application Protocol (CoAP).
620
621   [23]  CoRE Resource Directory,
622         https://datatracker.ietf.org/doc/draft-ietf-core-resource-
623         directory/.
624
625   [24]  C. Westphal, E. Demirors, An IP-based Manifest Architecture
626         for ICN, 2nd ACM Conference on Information-Centric Networking
627         (ICN 2015).
628
629   [25]  M. Mosko , G. Scott , I. Solis , C. Wood CCNx Manifest
630         Specification, http://www.ccnx.org/pubs/draft-wood-icnrg-
631         ccnxmanifests-00.html.
632
633   [26]  The Locator/ID Separation Protocol (LISP),
634         https://datatracker.ietf.org/doc/rfc6830/.
635
636   [27]  Locator/ID Separation Protocol (LISP) Map-Server Interface,
637         https://datatracker.ietf.org/doc/rfc6833/.
638
639
640
641
642
643
644
645Dong, et al.           Expires January 9, 2017                [Page 12]
646 
647Internet-Draft        Requirements of NRS in ICN           October 2016
648
649
650Authors' Addresses
651
652   Lijun Dong
653   Huawei Technologies
654   10180 Telesis Court
655   Suite 220
656   San Diego, CA, 92121
657
658   Phone:
659   Email: lijun.dong@huawei.com
660
661   Cedric Westphal, GQ Wang
662   Huawei Technologies
663   2330 Central Expressway
664   Santa Clara, CA 95050
665
666   Phone:
667   Email: {cedric.westphal,gq.wang}@huawei.com
668
669   Jianping Wang
670   City University Hong Kong
671
672   Email: jianwang@cityu.edu.hk
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699Dong, et al.           Expires January 9, 2017                [Page 13]
700 
701