Internet DRAFT - draft-pskim-uribis-objects-names
draft-pskim-uribis-objects-names
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>://<local name>@<domain name>:<parameters>
- 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]
