HP OpenVMS Systems Documentation

Content starts here

Planning Guide

Previous Contents Index

Chapter 9
DECdns Namespace Design Example

International Air Freight (IAF) Corporation is a hypothetical air freight company that does business in the United States, Europe, and Japan. The company plans to expand into other countries in the near future and anticipates considerable growth in its network.

The company consists of a New York office and a Chicago office. The New York office is corporate headquarters and is also the base for IAF's sales organization. A small engineering group in New York develops and maintains software applications specific to the company's business and distribution needs. Chicago is the hub of IAF's distribution operations. Also in Chicago is a small engineering and manufacturing group. This group designs and manufactures the packaging that IAF uses to transport freight.

The IAF network currently consists of 22 DECnet nodes on a local area network (LAN) in New York and 18 DECnet nodes on a LAN in Chicago. The two LANs are connected by DEC WANrouters that are communicating by means of a High-level Data Link Control (HDLC) link. DECnet-Plus software is in use, and the hardware includes workstations, personal computers, and large VAX systems. DECdns servers are running on DECnet-Plus for ULTRIX and DECnet-Plus for OpenVMS VAX systems. Figure 9-1 is a representation of the IAF network.

Figure 9-1 The IAF Network

IAF's introduction to DECdns came when the company decided to upgrade its network to DECnet Phase V. Network administrators learned that DECnet-Plus Session Control can use DECdns to store and look up node names. They saw the ability to distribute node names, combined with the automatic updating capability of DECdns, as a time and resource saver. In the beginning, DECnet would be the primary user of DECdns and node names would be the primary entries in the namespace. The DIGITAL Distributed Time Service (DECdts), another component of DECnet-Plus, would use DECdns to store the names of global servers that synchronize system clocks in the network.

When planning for DECdns, IAF anticipated future use by applications in addition to those that would be in place immediately after the transition to DECnet-Plus. Other client applications that IAF planned to use included DIGITAL's VAX Distributed File Service (DFS), VAX Notes, and Remote System Manager (RSM), products that use Version 1 of the name service.

IAF engineers also planned to develop their own client applications specific to the company's distribution, manufacturing, and administrative needs. For instance, IAF had a real-time application that collected data on the location and flight times of air carriers and tracked the status of freight at each of the company's distribution sites. The application used a message bus for task-to-task communications and message queuing. The message bus, in turn, would be adapted to store the names and addresses of its message queues in DECdns.

IAF assembled a planning committee to plan the transition from DECnet Phase IV to DECnet-Plus and to plan the DECdns namespace. The committee decided to make a staged DECnet transition. First, they would upgrade a portion of their LAN in New York and configure two DECdns servers there. Six to eight months later, they would begin to upgrade the Chicago LAN, configuring two DECdns servers there as well. Transition of the remaining nodes in New York would be gradual, as time and resources allowed.

This chapter discusses decisions the IAF planners made in designing and configuring their namespace. It also describes some of the business changes the company went through after initially setting up its namespace, and explains the effects those changes had on the namespace. The discussion refers to other manuals or other chapters in this manual for more information on some of the activities described.

9.1 Part 1: Planning and Configuring the Namespace

The planning committee chose a namespace nickname based on the initials that stand for the company's name: IAF. For naming clearinghouses, the committee decided to identify a clearinghouse by the city where it was located and adopted the recommended convention of adding a _CH suffix to a name. They knew they would have fewer than 50 clearinghouses, so they also followed the recommendation for naming all clearinghouses in the root directory. For example, clearinghouses in New York would be called .NY1_CH and .NY2_CH.

Next, the committee decided to assess the size and contents of the IAF namespace to determine whether they needed to create a directory structure. They knew that, for DECnet-Plus, every node in the network would have three entries in the namespace: an object entry and two soft links. After considering the needs of other applications, the committee produced the following list of projected namespace contents:

  • 40 node names (for the 22 nodes in New York and 18 in Chicago)
  • 40 node synonym soft links
  • 40 node address backtranslation soft links
  • 15 VAX Notes conference names
  • 4 RSM server names and 35 client names
  • 2 DECdts server names
  • 4 DFS access point names
  • 10 message bus queue names
  • Miscellaneous names created by IAF-written applications, number to be determined

It was clear that node names and soft links would have the most significant impact on the namespace; the number of names created by other applications would be minimal. Even the impact of node names and soft links would be minimal in a network the size of IAF's. However, the company and its network were expected to grow. Therefore, the planning committee decided to prepare for future expansion by designing a directory hierarchy.

9.1.1 Designing the Directory Structure

The committee decided that creating several directories, all one level below the root, would be more than sufficient to handle the size of the IAF namespace. They wanted to avoid the longer names and the additional management tasks associated with multiple directory levels. They also felt confident that it would be a long time before any one directory contained more than 5000 names: a number that they considered a practical directory size limit.

The planners decided on a functional directory naming scheme. The decision was easy, because IAF is a functionally oriented organization. Resources, including nodes, are allocated and managed on a departmental basis, regardless of geographic location. For that reason, the company's organization chart could serve as a template both for the directory structure and for designing an access control policy.

Using the organization chart, the committee planned functional directories for administration, engineering, distribution, and sales, resulting in the hierarchy shown in Figure 9-2.

Figure 9-2 IAF Namespace Hierarchy

9.1.2 Planning Access Control

The namespace access control policy would be closely tied to the directory structure. The committee decided to implement a policy of world read and test access on the entire namespace, but to limit other access rights for each functional directory to the main users and managers of the names in those directories. They would use DECdns access control groups to implement this policy.

The .DNS_Admin group, a namespacewide administrative group, would consist of the network manager, who was the designated namespace administrator, and other staff members from IAF's Network Control Center. The members of the .DNS_Admin group would be the only people with full access to the root directory. The planners also decided to give the group access that propagates down to all subsequent directories and their contents. The propagating access would allow the .DNS_Admin group members to monitor any changes or problems in the namespace.

The .DNA_Registrar group is an access control group created during configuration of the first DECnet-Plus node in the namespace. Its purpose is to contain the names of people responsible for managing node object entries and soft links. The planners had read the DECnet transition documentation and decided to use this group as well. They decided to make the .DNS_Admin group a member of the .DNA_Registrar group, automatically granting the namespacewide administrators access to all node-related entries in the namespace. Additionally, the .DNA_Registrar group would contain the names of people at each site who were traditionally responsible for assigning and monitoring node names.

In addition to the .DNS_Admin and .DNA_Registrar groups, the planners decided to create separate access control groups to manage each functional directory. The directory management groups would be named .Admin.Dir_Admin, .Sales.Dir_Admin, .Eng.Dir_Admin, and .Mfg.Dir_Admin. Each group would have full access to the contents of the directory it was associated with, and would contain the names of the current managers of that directory. With groups as the main method of granting access control, the namespacewide administrative group could simply add and remove members of a group instead of creating and deleting individual ACEs whenever management responsibility for a directory changed.

9.1.3 Assessing Directory Contents

Based on their decisions, the planners outlined the contents of each directory as follows:

  • Root directory (.)
    • Clearinghouse names (object entries).
    • The .DNS_Admin namespace administrator group.
    • The .DNA_Registrar node entry administrator group.
  • .Admin directory
    • Names of DECnet-Plus nodes used by administrative groups, including the executive office, personnel, finance, accounting, payroll, and management information systems.
    • Names of RSM client and server systems.
    • The .Admin.Dir_Admin group.
  • .Sales directory
    • Names of DECnet-Plus nodes used by the sales groups.
    • Names of RSM client and server systems.
    • Names of sales-related Notes conferences.
    • Names translating to file specifications of price databases, to be created and used by an IAF-developed application.
    • The .Sales.Dir_Admin group.
  • .Eng directory
    • Names of DECnet-Plus nodes used by the New York engineering group. Names of nodes from the Chicago engineering and manufacturing groups would also be stored in this directory, but not until 8 months to a year after the New York LAN began the transition to DECnet-Plus.
    • DFS access point names.
    • Names of RSM client and server systems.
    • Names of code libraries to be created and used by an IAF-developed application.
    • Names of development Notes conferences.
    • Names of industrial processes used in a distributed manufacturing work flow controller, to be designed by an IAF engineer.
    • The .Eng.Dir_Admin group.
  • .Dist directory
    • Names of DECnet-Plus nodes used by the distribution organization.
    • Names of RSM client and server systems.
    • Message bus queue names.
    • The .Dist.Dir_Admin group.

In addition, the following directories would be created during or soon after configuration of the first DECnet-Plus node:

  • .DNA_Node directory, a directory to contain node object entries for systems still running DECnet Phase IV.
  • .DNA_NodeSynonym directory, to contain soft links pointing from a Phase IV-style version of a node name to the node object entry.
  • .DNA_BackTranslation directories, to contain soft links pointing from the address of a node to its node object entry. The top-level .DNA_BackTranslation directory would have a child directory for each initial domain part (IDP) in the network, and the IDP directory would have a child for each area in the network. IAF planned to use only one IDP (the default IDP of 49) because the IAF network is private and the company is not interested in communicating with other OSI networks. Two area child directories would be created, for the New York LAN (Area 1) and the Chicago LAN (Area 2). The area directories would contain the node address-to-name soft links.
  • .DTSS_GlobalTimeServers, a default directory that DECdts uses for storing information about global time synchronization servers. Based on the recommendation in Chapter 10 for one global server on each LAN, the planners anticipated this directory would contain two entries.

With these additional directories added into the hierarchy, the complete picture of the namespace would look like the one in Figure 9-3. The shaded areas separated by white lines indicate levels of the hierarchy.

Figure 9-3 Complete IAF Namespace Hierarchy

The committee could see that, at least in the initial stages of DECdns usage, the sales and engineering directories and the node soft link directories would be the most heavily populated. However, the planners were not concerned that some directories would be larger than others. They knew that load balancing is determined not by directory size but by the number of servers in the namespace and how directories are replicated on those servers. Additionally, in such a small namespace, none of the directories would contain enough entries to have significant impact relative to any other directory.

9.1.4 Choosing Servers and Planning Replication

The next step for the committee was to plan how they were going to replicate directories and how many DECdns servers they would need.

After considering the guidelines in Chapter 8, the planners decided to configure two servers on the New York LAN and two servers on the Chicago LAN. The clearinghouses at the two New York servers would both contain an identical set of directory replicas. The planners felt this replication scheme would help to reduce confusion during the initial configuration of DECdns in the network. They also knew it would help to balance the work load between the two servers, increase the likelihood of finding a name without going off the LAN, and provide automatic, real-time backup of data in case a clearinghouse or replica became corrupted or temporarily unavailable.

The committee selected systems based on estimates of 1 MIPS of CPU power, 3,000 disk blocks, and 1 megabyte (2,000 pages) of memory required to run DECdns in the IAF network. In choosing the first server to be configured in New York, the committee also considered additional requirements, because that system would be the first system in the network to make the transition to DECnet-Plus. Table 9-1 indicates the systems selected to be DECdns servers.

Table 9-1 IAF Corporation DECdns Server Plan
Clearinghouse Name Server Hardware
.NY1_CH VAX 6310
.NY2_CH VAXstation 3500
.Chicago1_CH DECsystem 5400
.Chicago2_CH DECstation 3100

Figure 9-4 shows the plan for the first two servers in the namespace and the directory replicas their clearinghouses would contain.

Figure 9-4 Replication Plan for New York Servers

Because the .Dist directory would not be used until the Chicago LAN began the transition to DECnet-Plus, the committee decided not to create the directory until that time.

IAF was ready to configure its namespace. The planning committee had established a general naming policy, planned their directory structure and decided on an access control policy, and planned to replicate the same set of directories at each of the first two servers in the namespace. The committee had chosen the first node to migrate to DECnet-Plus and had selected three additional systems to be DECdns servers. More decisions could come later, as the Chicago LAN began the transition and the namespace grew. IAF was ready to begin building its namespace.

9.2 Part 2: The Namespace Grows

Eight months after IAF completed the first phase of its transition to DECnet-Plus, it was ready to migrate the nodes on the Chicago LAN. In the meantime, some major changes occurred within the company as well. As part of its plan to expand its international operations, IAF bought a similar company in Paris, France, called AeroFrance. The AeroFrance network was a LAN consisting of 100 DECnet nodes running Phase IV software. It connected to New York headquarters through an X.25 link.

The AeroFrance company had a very strong sales and distribution organization, whose headquarters remained in France. It had a small engineering group that also remained in France. Some administrative functions stayed at the Paris site, which became IAF's European headquarters. Other functions moved to corporate headquarters in New York, increasing the number of nodes there to 70 and reducing the number of nodes in Paris to 50.

When IAF acquired AeroFrance, IAF consolidated its U.S. engineering operations. IAF thought that the New York engineering group should be physically closer to the distribution organization that it served. Also, both the New York and Chicago engineering groups were too small to be under separate administrators. Therefore, the two groups were combined in Chicago, increasing the number of nodes there to 40. Figure 9-5 shows the new network topology after the acquisition of AeroFrance and the combination of the domestic engineering groups in Chicago.

Figure 9-5 Expanded IAF Network

IAF decided to start migrating the AeroFrance nodes to DECnet-Plus on a parallel transition schedule with the Chicago LAN, so that the Paris LAN could also take advantage of DECdns and other features of DECnet-Plus. The acquisition, the engineering reorganization, and the DECnet-Plus transition caused several changes to the namespace over the next year.

One major change was the addition of DECdns servers. Because the newly acquired French company was a single LAN, IAF took the same approach it had planned for New York and Chicago and configured two servers in Paris. The new network, combined with transition of the Chicago site, resulted in four additional servers, with clearinghouses named .Chicago1_CH, .Chicago2_CH, .Paris1_CH, and .Paris2_CH.

Figure 9-6 shows the four new DECdns servers --- two in Chicago and two in Paris --- and their contents at the end of the year.

Figure 9-6 New Servers and Their Contents

The figure reflects the following changes:

  • Creation and replication of the distribution directory (.Dist).
  • Replication of other directories that were created at New York servers.

Figure 9-7 shows the status of the two New York clearinghouses at the end of the year.

Figure 9-7 New York Server Contents a Year Later

The figure reflects these changes:

  • Creation of a new backtranslation area directory at Server 1 to accommodate soft links for the Paris nodes in Area 3.
  • Transfer of the .NY1_CH clearinghouse to a VAXstation 3100 system.
  • Removal of the .Eng replicas from both New York clearinghouses.

The remainder of this chapter explains in detail each of the changes that occurred and refers to other documentation for details on the activities described.

  • After nearly a year of using DECdns, the namespace administrator decided that it would be better to move at least one of the servers in New York off of a timesharing system. The Network Control Center wanted a central node from which they could manage the network and possibly add some new routing capabilities. So IAF purchased a VAXstation 3100 and moved .NY1_CH from the VAX 6310 to the new machine.
    See the DECnet-Plus DECdns Management guide for more on moving a clearinghouse.
  • The newly acquired AeroFrance LAN was in a new DECnet Phase V area, number 3. Therefore, a new backtranslation directory was necessary for the addresses of nodes in Area 3. At the DECdns server in New York, the namespace administrator ran the DECnet node registration tool to create the new area directory and fill it with Area 3 addresses. The tool was also used to
    • Populate the .DNA_Node directory with AeroFrance nodes still running Phase IV.
    • Populate the .Sales, .Dist, and .Admin directories with AeroFrance nodes as they upgraded to DECnet-Plus.
    • Fill the .DNA_NodeSynonym directory with node synonym soft links for the AeroFrance nodes.

    See the DECnet-Plus for OpenVMS Network Management manual for more on registering node names and soft links.
  • Once DECdns servers were configured in Area 2 (Chicago) and Area 3 (Paris), the namespace administrator replicated the Area 2 backtranslation directory at a server in Chicago and the Area 3 backtranslation directory at a server in Paris. This was in accordance with the recommendation that the master of the replica of a backtranslation area directory should reside in the area it describes.
    See Section 8.2.1 for detailed replication guidelines for the node name and soft link directories. See the DECnet-Plus DECdns Management guide for more on replicating a directory.
  • The .DTSS_GlobalTimeServers, .DNA_NodeSynonym, and .DNA_Node directories were replicated at one server in Chicago and one server in Paris for availability on those LANs.
    See the DECnet-Plus DECdns Management guide for more on replicating a directory.
  • Because many administrative functions and resources stayed in Paris after IAF bought AeroFrance, the namespace administrators decided it would be efficient to replicate the .Admin directory in Paris.
    See the DECnet-Plus DECdns Management guide for more on replicating a directory.
  • The namespace administrator created the .Dist directory in .Chicago1_CH and populated it with names of distribution nodes as they migrated to DECnet-Plus, names of message bus queues, and RSM client and server names. The .Dist directory was replicated at the second DECdns server in Chicago.
    See the DECnet-Plus DECdns Management guide for more on creating a directory.
  • As a result of the New York engineering group's move to Chicago, the namespace administrators replicated the engineering directory at the two Chicago DECdns servers. They also realized that it was no longer necessary to have two replicas of the engineering directory in New York, and decided to delete them from the New York servers. However, one of the replicas in New York was the master replica, since the directory had been created there. So they declared a new epoch for the directory, redesignating the master replica in Chicago. Then they were able to delete the two replicas from the New York clearinghouses.
    See the DECnet-Plus DECdns Management guide for more on setting a new epoch for a directory.

Previous Next Contents Index