Internet DRAFT - draft-pskim-uribis-namesystem-lisp
draft-pskim-uribis-namesystem-lisp
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>://<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://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]
