This document describes the Iceberg Name Mapping Service, its implementation, and usage.
About the name mapping service
In Iceberg, a user could have several end-points through which she can be reached. These end-points could be devices (e.g., cell-phone, pager, etc.) or they could be communication services (e.g., Short Message Service, Instant message service, Email service, etc.). The ids associated with each of these end-points is known as the service-specific-id. For instance, a telephone number, or a pager number is a service-specific-id.
A user is also assigned a unique-id to for unique identification. The Name Mapping Service (NMS) serves the purpose of mapping a service-specific-id to the user's unique-id. Such a mapping is required since one may not always have the user's unique-id for identification. For instance, imagine a user calling another by dialing a phone-number (a service-specific-id).
The name mapping service also serves the purpose of locating the user's iPOP. Given a user's unique-id, the name mapping service can return the required location. This is similar to the DNS returning an MX record with the user's mail server.
Although the above discussion is in the context of users, any service or entity that is reachable can also have service-specific-ids and unique-ids. For instance, one may call a voice-mail service by dialing a phone number (a service-specific-id).
The name-space hierarchy
The Iceberg name mapping service has a hierarchy similar to LDAP/X.500 naming tree. Each node in the tree is a type-value pair. However, we do not use the LDAP/X.500 tree schema itself. We define our own. However, we use the same distribution and referral mechanisms as in LDAP (similar to DNS as well). In our tree, only the leaves have relevant information.
In Iceberg, there could be several name-spaces corresponding to different devices and services. For instance, phone numbers could form a hierarchy, cell-phome IMSI numbers could form one, pager numbers could form one, IP host-names, e-mail addresses, etc. To handle these multiple hierarchies, we define a top-level root-node with a "type=<typename>" identification. The hierarchy within each type could be defined independently.
There are currently three name-spaces defined: one for cell-phone numbers, one for IP host-names, and one for Iceberg unique-ids. We have chosen to represent unique-ids as email addresses of users (this email address could be a dummy one; need not be the actual email address; the syntax is what is relevant).
With the defined hierarchy for these three name-spaces, the following are examples of LDAP DN (Distinguished Names) in our tree:
Cell-Phone Numbers: cpnum=<3-digit-number>, type=gsm Example: cpnum=107, type=gsm (In our testbed, cell-phone numbers are from a flat space of 3-digit numbers) IP host names: host=<host-name>, l3=<level3-name>, l2=<level2-name>, l1=<level1-name>, type=ipaddr Example: host=jake, l3=cs, l2=berkeley, l1=edu, type=ipaddr The name starts with l1 at the topmost level and can extend to any number of levels down the hierarchy. Example: host=dummy, l2=example, l1=com, type=ipaddr Unique-Ids: uid=<user-id>, l3=<level3-name>, l2=<level2-name>, l1=<level1-name>, type=uniq Example: uid=bhaskar, l3=cs, l2=berkeley, l1=edu, type=uniq
Look at the files cpnums.demo, ipaddrs.demo, and uniqs.demo for more examples.
Since Iceberg unique-ids are equivalent to email addresses, they have two equivalent representations: email-ids and LDAP DNs. Both of these are used in different places in the code.
The server and the client
The service and client are both run as vSpace services. The service is run as part of iPOP:
java ninja2.core.vspace.vSpace ipop.cfg.demo1
The example configuration file is ipop.cfg.demo1.
The client is also run as a vSpace service:
java ninja2.core.vspace.vSpace nms-client.vspace.cfg
An example configuration file is nms-client.vspace.cfg. Make sure that the multicast address and port parameters, "stateTableName", and hashtableNode specifications match in the server and client vSpace files. The client will load the file names given the "files" parameter in the configuration file. The files are in LDIF format (LDAP DN) as explained earlier in this document.