A top-level domain for embedded devices? - Embedded.com

A top-level domain for embedded devices?

Click here for response to this article

The interest on the World Wide Web about the subject of top level domain names has led me to start thinking about the usefulness of a top level domain designation for connected embedded devices — .emb perhaps?

However, the critical assessments given to such proposals by ICANN, WW3, and other Web authorities means there must be very good reasons for granting such a status.

Beyond the original .com, .gov, .edu, .org, and .net, there are now .pw, .name, .pro, .aero, .biz, .coop, .info, .int, .mil, and .museum with several others in various stages of the approval process, including .asia, .cat, .jobs, .mail, .post, .travel, .xxx, and two competing .tel domains.

Also, a group of mobile phone and wireless converged appliance makers and vendors, led by Nokia, Microsoft, HP and Sun have proposed a new .mobi TLD for all things mobile. In addition, Saipan Datacom, acting as domain administrator and registrar for the U.S. Commonwealth of the Northern Mariana Islands, has proposed using its country code — .mp — as a mobile phone device top level domain.

The main technical argument that the .mobi activists propose in its favor is that mobile devices will ultimately be used as personal Web servers and other repositories of Internet documents, replacing traditional stationary desktops and servers.

And because they are mobile, the argument goes, the way domain name server (DNS) architecture works for domains like .com and .net is unsuitable, since it takes up to 48 hours for IP address changes to propagate on the Internet. However, mobile devices, by definition, move. So, if one is designated as a server, its IP address would be changing on a regular basis, such as when it is turned off, when it moves through a tunnel or is in some situation where connectivity is lost, requiring almost real time updates of IP addresses.

As pointed out by WWW-originator Tim Berners-Lee in a recent article, other than this the major reasons proposed by the consortium for approving the .mobi TLD are largely non-technical.

While there is a modicum of benefits to the end user, he says, virtually all benefits accrue to mobile content and service providers, mobile operators, mobile device manufacturers and vendors, and IT technology and software vendors who serve the mobile community. Nor is there anything in the technical reasons they advance to justify the TLD, he believes, that could not be achieved in some other way.

“The success of the Web stems from its universality, as do most of the architectural constraints,” he says. “The Web must operate independently of the hardware, software, or network used to access it. . . .”

I am not an expert, but I believe that a .emb TLD might be an exception to this rule, precisely because the way connected embedded microcontroller devices interact with the Web seems to me to be so fundamentally different.

For one thing, there is the relationship between the server and the device. In a sense, the server is now a client to the embedded device, which in turn is providing content to the server.

In a normal desktop/mobile transaction with a server, the assumption is made that the time frame is a one or two second human interval at the very least. And the negotiation process usually involves the client browser requesting some sort of action from the server, usually in the form of some HTML presentation.

In a connected embedded device context, the negotiation is exactly the opposite. The request can come from either the embedded device or from the server. If it is the former, the controller requests access so that it can deliver information to the server.

If the request comes from the server, it is requesting that the controller present data to it in the proper format. If the embedded developer has incorporated a minimalist servlet program on the device, information collected is organized into an HTML format for delivery to the server where it is acted upon, either at the time of the request, afterwards, or in anticipation of the request.

Even at its slowest non-real time, non-deterministic, an embedded microcontroller will still require actions from the server that are anywhere from ten to 100 times as fast as the two-to-three second response time built into most human-interaction Web activities.

But with the proliferation of RFID, ID tags will be embedded in virtually every piece of goods shipped. And wireless protocols such as Zigbee will eventually link millions of embedded controllers to the network. In such an environment, servers will also have special responsibilities not only for those specialized transactions, but as well for security, identification and status.

With IPv6, and the 340 billion billion, billion, billion unique URLs it makes available, the sheer numbers of connected and uniquely identified embedded devices presents special issues that dictate the servers responsible for them — and possibly the TLD in which they reside — have special characteristics.

For one thing, given the real time, deterministic nature of embedded controllers, the servers would have to take care to map their location as completely and as often as is possible. That implies an absolute requirement for servers with 64-bit CPUs with some special modifications to their multithreading, multitasking structure.

In the present IPv4 environment, the latency time for a server that must map much of the URL universe in DRAM as possible is limited because 32-bit servers have a theoretical limit of 232 bits of directly accessible DRAM. Therefore, they must use disk based virtual memory and suffer — or work around — the latencies that involves. The 264 bits of directly addressable memory of 64-bit servers would do much to eliminate such latencies.

Another factor that might dictate a shift to a special .emb TLD is the nature of the server to server negotiations that must support any device/server transaction. Let's be conservatively realistic and assume there is a company which has deployed one million refrigerators with microcontrollers that have Internet access. Suppose that 1 percent of them, or 100,000, reported a problem and each expects a response within a tenth of a second. That's 100 to 1,000 times slower than a microcontroller's normal response time. It seems to me that the dynamics of such an environment are vastly different that the normal client/server transaction.

Even more so in a Web services environment where the server will have to maintain specialized business to business linkages with other servers, calling for services in a time frame that is short enough to either download a new fix, or direct that an automated call be sent to the home telling the owner that the refrigerator is not working, that it is being fixed, or when it will be fixed.

Perhaps some of the alternatives proposed by Berners-Lee might solve the problems of client-side server/server-side client interactions that seem to me to be so unique.

For example, there are the CC/PP specifications which provide a framework for a client device to describe its capabilities in great detail to a server. Another alternative that could be adapted might be the UAPROF (User Agent Profile) specifications developed by the mobile phone industry. The HTTP specification also has a content negotiation mechanism that allows a device to give a simple profile of its capabilities whenever it asks for some information.

But it seems to me that there is more than enough about this new kind of device/server interaction to warrant some further investigation.

I understand the need to focus on maintaining the universality of the Web and Internet by making them as hardware- and software-independent as possible. And that sort of discipline should always be uppermost in any decisions related to modifying the Internet and Web standards.

But given the sheer size of the coming IPv6 Web/Internet, that should only be a goal to work for, not an absolute. After all, the Internet began as an “inter-network” — a grid of cooperating proprietary networks for which the common set of protocols was developed to allow dissimilar networks and systems to talk to each other when necessary.

By and large most of the devices and systems on the Internet and Web now speak the same “language.” But not all. And in an IPv6 future with 340 X 1036 unique URLs, not all will. There will always be special cases, and accommodations will have to be made.

What do you think? I'd like to get your feedback.

Bernard Cole is site leader and contributing editor of iApplianceweb and an independent editorial services consultant working with high technology companies. He welcomes your feedback. Call him at 602-288-7257 or send an email to .

Reader Response

This proposal isn't really practical. Other than the mobile devices, most IP-aware embedded devices will belong to someone's existing network. The natural hierarchy of DNS is structured around the organization having a domain name and controlling the IP address of devices within it. Why would someone want a distinct domain name that they had to manage separately for the embedded devices at their company?

Let's say my refrigerator (to use your example) connects to my in-home wireless network. Why would my ISP (say that's Earthlink) want to assign its address to a domain other than earthlink.com?

In another vein, since you mention IPv6 — this may eliminate the issue you have raised with IP addresses changing from place to place, since one legal IPv6 address for the device is derived from its MAC address. As long as the routers of the world can be trained to keep up with this address as it moves, this could be assigned a stable host name that could be looked up through the normal DNS process. So your www.bernard-cole.org web server running from your cell phone could always resolve to the same IPv6 address, and it would simply be the responsibility of the routers to get the data to you.

Greg Nelson

I agree with Greg Nelson's comment that most embedded devices would naturally be part of an existing domain, or more likely part of a private network.

Beyond that, there is no need for an embedded device to have the convenience of a TLD. TLDs make typing easier, embedded devices do not get sore fingers from typing long URLs.

If you really needed to have a DNS resolvable name for every RFID device, then the RFID consortium could just add all of those entries to some sub-domain off of their main domain. Embedded devices and their drivers will not mind asking for xxxxxxxxx.dir.rfid.org, or whatever it is. You could even map “rfid:xxxxxxx” to the above automatically, so it wouldn't take up a lot of constant space in the ROM.

The ultimate justification for any new TLD will never be technical, because it has to do with how many TLDs make sense to users. Any TLD that makes sense to the typical user makes domain names more friendly. As soon as it gets confusing, you've added too many.

Caitlin Bestler
Director Software Architecture
Siliquent Technologies

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.