URNBIS Working Group P. Kim Internet Draft KPU Intended status: Informational Expires: January 2013 July 3, 2012 An Object-Centric Name Space for Various Communication Objects draft-pskim-uribis-objects-names-00.txt Abstract This draft suggests a name space for identifier based Internet that has been considered to support the future Internet for mobile environment. The suggested name space considers a host-centric for the current stage as well as an object-centric for the next stage. To consider scalability and distributed architecture, the format of the name space consists of object category, local name, domain name, and parameters. 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 January 4, 2013. 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 (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 Kim Expires January 4, 2011 [Page 1] 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Normative References . . . . . . . . . . . . . . . . . . 4 4.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction Recently, several architectures of mobile-centric approach has been designed to support the mobile environment of future Internet, such as MobilityFirst[MF] in US, 4WARD[4WARD] in EU, AKARI[AKARI] in JAPAN and MOFI[MOFI] in Korea. Such architectural design works include a lot of technical issues such as locator/identifier separation, hybrid communication with locator/identifier, delay tolerant networks, storage aware routing, in-network management, strong security and privacy model, separation of control and data planes, etc. Among them, the locator/identifier separation has been considered as a key design principle. In the locator/identifier separation[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. On the other hand, the IP addressing in today's Internet overloads identifier and locator, which has introduced critical shortcomings such as routing scalability (routing table explosion) and IP address managements issues (mobility, multi-homing, IPv4/IPv6 transition). As shown in mobile-centric architectural design works [MF]-[MOFI], the identifier is performing a primary role at the data plane as well as the control plane. However, formats for these identifiers have 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, such as DNS. Moreover, the identifier is being assigned for various communication objects for sensors, contents, contexts as well as hosts. This means that communication objects in mobile-centric future Internet would not be limited by the host. So, a name space should be designed with consideration of the scalability for tremendous communication objects. Kim Expires January 4, 2011 [Page 2] Internet-Draft An Object-Centric Name Space July 2012 2. A Name Space for Various Communication Objects 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. 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)[RFC 4282] and the uniform resource identifier (URI)[RFC2396]. Ultimately, the name space can consists of object category, local name, domain name, and parameter as follows: ://@: - 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://air-conditioner@irvine.ca.us:appliance:home:irvine-92614 - Objejct category : device - Local name : air-conditioner - Domain name : irvine.ca.us - Parameters : appliance, home, irvine-92614 (naming an appliance at home with address "Irvine-92614" device://air-conditioner@irvine.ca.us:device:car:6vad286 - Objejct category : device - Local name : air-conditioner - Domain name : irvine.ca.us - Parameters : appliance, car, ac33-irvine (naming an appliance inside a car with plate number "6vad286" 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 Kim Expires January 4, 2011 [Page 3] Internet-Draft An Object-Centric Name Space July 2012 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. IANA Considerations This document has no IANA actions. 4. References 4.1. Normative References [LISP] D. Farinacci, V. Fuller, D. Meyer,D. Lewis, "Locator/ID Separation Protocol (LISP)," draft-ietf-lisp-22, (work in progress). [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. 4.2. Informative References [MF] MobilityFirst Future Internet Architecture Project, http://mobilityfirst.winlab.rutgers.edu [4WARD] 4WARD Project, http://www.sail-project.eu/ [AKARI] AKARI Project, http://akari-project.nict.go.jp/eng/index2.htm [MOFI] MOFI Project http://www.mofi.re.kr Author's Address Pyung-Soo Kim Department of Electronics Engineering, Korea Polytechnic University, 2121 Jungwang-Dong, Shiheung City, Gyeonggi-Do 429-793 KOREA Phone: +82 31 8041 0489 EMail: poongdou@gmail.com Kim Expires January 4, 2011 [Page 4]