The Community for Technology Leaders

Guest Editor's Introduction: Protocols for Extending the Net


Pages: pp. 42-44

Automatic configuration for networking follows naturally from the more traditional uses of automatic configuration in standalone computers. A good wexample of standalone use was the "autoconf" feature delivered with UC Berkeley's versions of the Unix operating system. Since then, there have been more ambitious attempts to supply so-called "plug-n-play" (or, as often, "plug-n-pray") features for commodity laptop operating systems. The problem for network computing, however, is made immeasurably more complex by the proliferating numbers of computers on the Internet and the possible interactions among them.

The need for autoconfiguration is brought about by several factors, including:

  • the proliferation of computing features and options,
  • the large number of data formats in common use, and
  • the sheer number of computers.

Even the most trivial manual configuration task can become impossible when there are hundreds or thousands of computers needing attention. Training people to perform the task themselves can frequently take longer than just manually configuring the machines.

Autoconfiguration's feasibility typically depends on one or more of the following autoconfiguration design factors:

  • information availability in a standard, or at least recognizable, format;
  • device-driver availability;
  • system extensibility, allowing new features to be added;
  • programmer understanding of user needs;
  • standard APIs and protocol availability;
  • a selection of good default values whenever possible; and
  • system support for embedded computing devices.

Design for Extensibility

The second and third factors usually require operating support. For instance, designing for extensibility is quite tricky, and involves identifying the dimensions of the problem space for which the configurable parameters tailor solutions particular to the application (and, ultimately, the person using the application). Understanding the dimensions of the problem, and then crafting an autoconfiguration facility that will create particular instances of the solution, takes a great deal of experience, study, and often just plain good luck.

Indeed, bad luck can overcome the good effects of diligent and expert design, as evidenced by the new restrictions placed on Dynamic Host Configuration Protocol (see the article, "Automated Configuration of TCP/IP with DHCP," by Ralph Droms). As you read the articles in this issue, consider how each protocol design hs been influenced by the design factors listed above.

Attaching computers to the Internet, which is currently done with DHCP, should be much easier with the deployment of IP version 6 (IPv6). In large measure, this is due to features designed into the address autoconfiguration protocols described in Thomas Narten's article "Neighbor Discovery and Stateless Autoconfiguration in IPv6." These protocols have benefited from some of the clearest thinking in autoconfiguration system design (in my opinion) by the impressive combined talents of the IPv6 engineers. And yet, even with all this talent exerted on a well-defined, narrow problem space, finer points to the protocols are still being discussed today.

Routing Protocols

Routing protocols can be considered to be autoconfiguration systems. Initially, routing was done by static routing tables, which were often distributed or updated by telephone, tape, or floppy disk. However, as the number of computers on the Internet increased, such manual configuration methods rapidly became infeasible.

With the advent of mobile computing, even the more dynamic routing protocols of the 1980s are becoming infeasible, having been based upon assumptions that are no longer true (for example, the assumption that nodes in the Internet would always be attached to the same network). Experience in the latter part of the 1980s showed that using manual configuration for routing packets to mobile computers was feasible, but only because so few mobile computers were in operation.

Automatic routing updates are more important now that there are so many mobile computers in operation. With wireless connectivity gaining importance, and with Internet availability remaining problematic in many places where computing power may be needed, it has become desirable to connect many computers by physical links that are only temporary, even without the aid of any wide-area Internet routing protocols.

Such ad hoc networks are infeasible unless enabled by new, sophisticated methods of dynamically autoconfiguring routing tables. "Internet-Based Mobile Ad Hoc Networking," by M. Scott Corson, Joseph P. Macker, and Gregory H. Cirincione, looks at these protocols. Their design is subject to the challenging problems of mobility and error-prone physical media, in addition to constraints similar to the design criteria listed earlier.

Initially, autoconfiguration systems may rely on human interaction to finalize configuration choices. As designers become more confident about the suitability of various choices, the need for human interaction will decrease until it is no longer needed. Consider, for example, a typical office setting, where people are comfortable selecting a printer from a menu of available printers discovered through an autoconfiguration program. The next logical step would be for the autoconfiguration program to make the choice, when a choice is obvious, and just make the user aware of any deviation from the usual.

As the number of network services and resources in the Internet continues to grow exponentially, browsing may become less and less desirable. Protocols such as SLP (described in the article "Service Location Protocol: Automatic Discovery of IP Network Services," by Erik Guttman), enable both browser-style, user-assisted configuration and autoconfiguration for embedded and low-level configuration requirements.

More and More Autoconfiguration

I believe that autoconfiguration systems are part of the march toward ever more capable and friendly systems. Consider how autoconfiguration may be compared with self-organizing systems. Such systems typically deal with

  • multiple functions,
  • multiple computers, with the functions placed among them according to any convenient heuristic, and
  • more autonomous operation.

Once a feature becomes amenable to automatic configuration, it is likely to be taken for granted—as just another cog in our ever grander machines. For both this reason, and for the reason of increased user convenience, automatic configuration protocols will continue to gain importance as the network becomes larger and more important to ever more people. The future of the Internet is inextricably linked with the future availability of more autoconfiguration features for using it.

The Articles


Ralph Droms

The chair of the IETF Dynamic Host Configuration (DHC) working group describes the design and operation of the widely deployed DHC Protocol. DHCP automates the configuration of network devices that use TCP/IP. Current work on the standard includes developing a version for IPv6.

Neighbor Discovery and Stateless Autoconfiguration in IPV6

Thomas Narten

The IETF's Next General Protocol (IPng) working group was originally motivated by the potential depletion of address spaces in the 20 year-old IPv4. The IPv6 standard that emerged from this group supports not only 128-bit addresses but also new functionality for plug-n-play operation.

Internet-based Mobile Ad Hoc Networking

M. Scott Corson, Joseph P. Macker, and Gregory H. Cirincione

A mobile ad hoc network (Manet) supports a mobile routing infrastructure. When multiple wireless technologies are available in a mobile network, it is desirable for routing to occur at the IP layer. Members of the IETF Manet working group review the status and future of this emerging technology.

Service Location Protocol: Automatic Discovery of IP Network Services

Erik Guttman

The chair of the IETF's SLP (srvloc) working group examines this open-standard framework for network resource discovery and automatic configuration of clients. A sidebar compares SLP with other approaches to automatic service discovery, including Sun Microsystems' Jini technology.

About the Authors

Charles E. Perkins is a senior staff engineer at Sun Microsystems, developing SLP and investigating dynamic configuration protocols for mobile networking. He holds a BA in mathematics and an MEE from Rice University, and an MA in mathematics from Columbia University. Perkins is serving as document editor for the IETF mobile-IP working group, and author or co-author of standards-track documents in other working groups such as server location, dynamic host configuration, and IPng. He is an area editor for several publications, including Mobile Communications and Computing Review, Wireless Networks, and IEEE/ACM Transactions on Networking. He is on the editorial board of IEEE Internet Computing, and a member of the IEEE, ACM, and IETF.
62 ms
(Ver 3.x)