Network Working Group P. Kim Internet Draft KPU Intended status: Informational Expires: April 17, 2014 October 18, 2013 Name Space and System for LISP Internet Architecture draft-pskim-uribis-namesystem-lisp-00.txt Abstract This draft suggests a name space and system for the locator/ identifier split Internet architecture. The suggested name system considers a host-centric for the current stage as well as an object-centric for the next stage. Firstly, a name space for various communication objects is defined. To consider scalability and distributed architecture, the format of the name space consists of object category, local name, domain name, and parameters. Secondly, registries and servers are introduced to manage mapping between identifier and object names with one-to-many relationship. Then, name registration and resolution using these registries and servers are described. 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 April 17, 2014. Copyright Notice Copyright (c) 2012 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 Kim Expires April 17, 2014 [Page 1] Internet-Draft Name Space and System for LISP October 2013 (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 Internet-Draft An Object-Centric Name Space July 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. A Name Space for Various Communication Objects . . . . . . . 3 3. Name System for Registration and Resolution . . . . . . . . . 4 3.1. Components and Functions . . . . . . . . . . . . . . . . 4 3.2. Name Registration and Resolution . .. . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the locator/identifier split Internet architecture[LISP], the identifier plays a role of a unique identifier for communication end-point and locator plays a role of a topological and routable address in the network. Although the identifier is performing a primary role at the data plane as well as the control plane in existing architectures, its format has generally a human-unfriendly form such as self-certifying public key, self-allocating fixed-length string, etc. Thus, a human readable name space should be required for binding and resolution. The name space can be classified by "host-centric" as well as "object-centric". The host-centric name space names only host as shown in well-known Domain Name System (DNS) and AKARI [AKARI]. On the other hand, the object-centric name space can name various communication objects such as user, file, device, service, content, context as well as host, as shown in MobilityFirst[MF] and 4WARD[4WARD]. This means that communication objects would not be limited by the host. In this case, a name space should be designed with consideration of the scalability for tremendous communication objects. In addition, as the registration and resolution between identifier Kim Expires April 17, 2014 [Page 2] Internet-Draft Name Space and System for LISP October 2013 and locator has been required in [AKARI][MF][4WARD][MF][FIRMS], a name system should be also required in order to take care of the functions necessary to perform the management of mapping between name and identifier, including ensuring that names are unique, and managing the list of identifers and names. According to the name resolution method, the name system can be classified by "lookup-by-name" and "route-by-name". The lookup-by-name based approach uses an indirection system as DNS. The name system using lookup-by-name has been adopted for object-centric name space such as MobilityFirst, 4WARD as well as host-centric name space such as DNS, AKARI. The route-by-name based approach does not require an indirection system and perform the name based routing, which has been adopted for Content-Centric Network(CCN)[CCN] and Data-Oriented Network Architecture(DONA)[DONA] In this draft, an object-centric name space and a lookup-by-name based name system are suggested for the locator/identifier split Internet architecture. A name space is designed with the consideration of an object-centric name system for the next stage. That is, at the current stage, the main role of the name system is that users can perform the resolution of object names to get corresponding identifier (and vice versa) for only the connection before communication, which is similar to the lookup-by-name method used for DNS, AKARI, 4WARD, MobilityFirst. Whereas, at the next stage, the name system is required for communication as well as connection, which is similar to the route-by-name method used for CCN and DONA. Firstly, a name space for various communication objects is defined. To consider scalability and hierarchical architecture, the format of the name space consists of object category, local name, domain name, and parameters. Secondly, a name system with name registration and resolution is designed to manage mapping between identifier and object names with one-to-many relationship. In general, the name space for the networking system defines the structure of the name system and the rules for creating names. The name space is the most abstract among main functions of a name system. It is also the most fundamental part of the name system, since it actually describes how the names are created. 2. A Name Space for Various Communication Objects For a name space, various communication objects are considered such as user, file, device, service, content, and more. In addition, the name space architecture will be hierarchical for the scalability and flat for the semantic, which can be represented by mixing the network access identifier (NAI)[RFC4282] and the uniform resource identifier (URI)[RFC2396]. Ultimately, the name space can consists of object category, local name, domain name, and parameter as follows: Kim Expires April 17, 2014 [Page 3] Internet-Draft Name Space and System for LISP October 2013 ://@: - Object category : Category of objects such as user, file, device, service, content, context, etc. - Local name (Flat): Semantic name of object. - Domain name (Hierarchical) : Name of domain where the user subscribes to the communication service for objects or the object is logically associated - Parameters (Option) : Parameters can be appended according to object category Example: device://temperature@future.com:sensor:room:peter:Irvine-92614 - Objejct category : device - Local name : temperature - Domain name : future.com - Parameters : sensor, room, peter, Irvine-92614 (Naming a sensor at Peter's room with address 'Irvine-92614') content://billiejean.mp3@music.com:audio:Jackson - Objejct category : content - Local name : billiejean.mp3 - Domain name : mobile.com - Parameters : audio, Jackson (Naming an audio file of singer 'Jackson') Based on the designed name space, a name system will be designed using indirection approach. Name registries, that is, name servers should be distributed according to communication object categorization. For timely binding, a fast propagation mechanism of binding update should be required. In addition, for the resolution, a parsing mechanism for name should be also required. 3. Name System for Registration and Resolution 3.1 Components and Functions In the suggested name system, the name registration allows users to specify which identifier uses which object with object name (and vice versa). The name registration is coupled tightly with the object category used for object names. In addition to the name registration, the name resolution is also needed for user to find identifier that corresponds to object names for actual connection and communication. Actually, the name resolution is the most well-known aspect of name systems, because it is where most of the "heavy lifting" of a name system occurs[TCP/IP]. The name space is Kim Expires April 17, 2014 [Page 4] Internet-Draft Name Space and System for LISP October 2013 generally set up once, and the name registration occurs only when object names must be created or changed. On the other hand, every user of a name system instructs identifier he or she uses to perform the name resolution, hundreds or even thousands of times a day. For the name registration and resolution in the suggested name system, servers and registries are required and distributed. Basically, there are object name servers (ONSs) to manage mapping database between identifier and object names. In addition, there are a couple of registries to manage these ONSs; domain name server registry (DNSR) and object name server registry (ONSR). The DNSR stores and manages information on the binding between domain names and locators of ONSRs for corresponding domain. The OSNR stores and manages information on the binding between object categories and locators of ONSs in the same domain. The ONS stores and distributes information on the binding between identifier and object names with one-to-many relationship for corresponding object categories such as user, file, device, service, content, context, etc., of active hosts that belong to the administrative domain managed by the DNSR and ONSR. 3.2 Name Registration and Resolution The hosts register their identifiers with the ONS when they first connect to an edge network (i.e., when the user of the host subscribes to the communication service). The hosts also send identifier update requests to the ONS when they change their identifiers or other information. To register an object name, a request must be made to have the name assignment added to the ONS. That is, hosts send name registration requests to the ONS when object names corresponding to identifier, and other information must be created or changed. The ONS thus stores dynamic information on object names and identifier that change often due to the activation of different objects. That is, the identifier is dynamically mapped to different object names with one-to-many relationship. The binding information about the ONSs stored in the ONSR and the ONSRs stored in the DSNR does not change frequently because ONSs and ONSRs are generally fixed nodes that are not changing their locators. The ONSs can be organized in a distributed structure, similar to that of DNS, for storing and retrieving static mapping information. Thus, the ONS record size does not grow as fast as the number of hosts. The smaller the size of the ONS mapping table, the faster the search and retrieval process for ONS records. Consider the procedure of the suggested name system through an example that a correspondent host (CH) wants to communicate with a mobile host (MH) with the following object name: device://temperature@future:com:sensor:car:michelle:6VAD286 Kim Expires April 17, 2014 [Page 5] Internet-Draft Name Space and System for LISP October 2013 which is naming a sensor object at Michelle's car with plate number 6VAD286 and has a semantic name temperature and a domain name "future.com". First of all, it is assumed that the MH's ONS must have registered its locator in the ONSR. In addition, for the name resolution of identifier and object names to be successful, the MH must have performed the name registration of identifier and object names with one-to-many relationship through the name registration procedure in Section 3.2. Dynamic information on one-to-many relationship of identifier and object names is stored in the ONS. Then, to communicate with the MH, the CH has to perform the name resolution to get corresponding identifier. The CH can get the MH's identifier from the domain name lookup, the object category lookup, and the identifier lookup as follows. Domain Name Lookup : The CH first sends a domain name lookup query to the DNSR to get ONSR's locator using the domain name part "future.com". Then, the DNSR searches its record and finds ONSR's locator and subsequently replies to the CH. Object Category Lookup : The CH then sends an object category lookup query to the ONSR to get ONS's locator using the object category device. Then, the DNSR searches its record and finds ONS's locator and subsequently replies to the CH. Identifier Lookup : The CH then sends identifier lookup query to the ONS to get corresponding identifier for the local name "temperature" with parameters "sensor", "car", "Michelle" and "6VAD286". Then, the ONS searches its record and then finds and subsequently replies to the CH. After obtaining identifier of the MH, the CH can either directly start data communication. 4. IANA Considerations This document has no IANA actions. 5. References 5.1. Normative References [LISP] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, Locator/ ID Separation Protocol (LISP), IETF Draft : draft-farinacci-lisp-24.txt, 2013. [RFC4282] B. Aboba, M. Beadles, J. Arkko, P. Eronen, "The Network Access Identifier," RFC 4282, December 2005. [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, August 1998. Kim Expires April 17, 2014 [Page 6] Internet-Draft Name Space and System for LISP October 2013 5.2. Informative References [MF] D. Raychaudhuri, K. Nagaraja, and A. Venkataramani, "MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet," ACM SIGMOBILE Mobile Computing and Communications Review, vol. 16, no. 3, pp. 2~13, 2012. [4WARD] M. Brunner, H. Abramowicz, N. Niebert, and L. M. Correia, "4WARD: A European Perspective towards the Future Internet," IEICE Transactions on Communications, vol. E93-B, no. 3, pp. 442~445, 2013. [AKARI] V. P. Kafle and M. Inoue, "ID/Locator split-based mobility scheme for heterogeneous new generation network," Wireless Personal Communications, vol. 61, no. 4, pp. 753~764, 2013. [MOFI] S.J. Koh and H. Jung, "Mobile Oriented Future Internet (MOFI): Architectural Design and Implementations," ETRI Journal, vol. 35, no. 4, pp. 666~676, 2013. [FIRMS] M. Menth, M. Hartmann, and M. Hoing, "FIRMS: A mapping system for future Internet routing," IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1326~1331, 2010. [CCN] D. Perino and M. Varvello, "A reality check for content centric networking," in Proc. of the ACM SIGCOMM workshop on Information-centric networking (ICN), 2011, pp. 44~49. [DONA] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica, "A data-oriented (and beyond) network architecture," in Proc. of the 2007 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM), 2007, pp. 181~192. [TCP/IP] C. M. Kozierok, The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference, No Starch Press, 2005. Author's Address Pyung Soo Kim Korea Polytechnic University, 2121 Jungwang-Dong, Shiheung City, Gyeonggi-Do 429-793, KOREA Phone: +82 31 8041 0489 EMail: poongdou@gmail.com Kim Expires April 17, 2014 [Page 7]