HP OpenVMS Systems Documentation

Backtranslation soft links enable Session Control to translate a node address to the full name of a node object entry. For example, end user applications often require the node name of the source of incoming connect requests. A DECnet-Plus node can include its name in the data it sends to request a connection, but a Phase IV node provides only an address. A backtranslation soft link contains the data necessary to make the translation from an address to a DECdns node name.

Backtranslation soft links are stored in a hierarchy of directories beginning with a directory named .DNA_BackTranslation. The .DNA_BackTranslation directory contains one child directory for each IDP in the network. Each IDP directory contains one child directory for each local area defined within that IDP. Each local area directory contains one soft link for each node in that area.

Unlike DECdns, the Local namespace does not use backtranslation directories for address to node name translation. In a DECdns namespace, the decnet_register tool automatically creates the .DNA_BackTranslation directory, as well as IDP and area directories derived from all existing Phase IV addresses. In addition, the tool has an option for creating new IDP and area directories for DECnet-Plus nodes.

The following illustration shows a backtranslation soft link:

The %X symbols in the IDP, area, and node ID segments of the soft link indicate to DECdns that the numbers that follow are in hexadecimal notation. For a complete explanation of the DECnet Phase V address structure, see Section 1.3.1.

When you register a Phase IV node in a distributed namespace, decnet_register constructs a backtranslation soft link based on whatever address the user specifies in the node registration information. When you register a DECnet-Plus node, the node creates its own backtranslation soft link.

When you register a node in a local namespace using decnet_register, you can specify a Phase IV address and/or one or more towers in the local name file. Backtranslation information is maintained in the database.

5.5.3 Node Synonyms

A node synonym is a soft link that points to the full name of a node object entry. Node synonym soft links, in the form of a Phase IV-style node name, exist so that Phase IV applications that do not support the length of DECdns full names can continue to use six-character node names. A node synonym is optional; the system manager can supply it during DECnet-Plus configuration. Node synonyms are stored in a required directory called .DNA_NodeSynonym, which decnet_register creates automatically during DECnet-Plus configuration of a distributed namespace. In the Local namespace, synonym mapping is maintained by the database.

When DECnet-Plus Session Control receives a node name of six characters or fewer that does not include a leading dot or namespace nickname, it tries to look up that name in the .DNA_NodeSynonym directory in a distributed namespace. Suppose, for example, DECnet-Plus is given the node name MIS01. Session Control sends a request to DECdns to look up .DNA_NodeSynonym.MIS01. The node synonym exists and points to the full name of the node, ABC:.Geneva.Admin.MIS01. Session Control can then ask DECdns to look up the node object entry named ABC:.Geneva.Admin.MIS01 and get the address information it needs to contact the node.

Node synonyms are not for users to avoid typing the DECdns full name of a node. Local names, and a feature called the local root, offer that capability on a per-node basis. For details, see the DECnet-Plus DECdns Management guide.

5.6 How DECdns Protects Names

The decnet_register tool manage command lets you control access to clearinghouses, directories, and their contents. Access to clerks and servers is determined by operating system rights identifiers.

5.6.1 Access Rights

The DECdns access rights are read, write, delete, test, and control. Each right has a slightly different meaning, depending on the kind of name with which it is associated. In general, the meanings are as follows:

• Read access lets users view data.
• Write access lets users change data.
• Delete access lets users remove data.
• Test access lets users test whether an attribute of a name has a specific value without being able to see any values (that is, without having read access to the name). DECdns uses test access internally to test for group membership during access checking.
• Control access lets users change the access control on a name and grants other powers normally given only to an owner, such as the right to replicate a directory or relocate a clearinghouse.

You assign access in the form of an access control entry (ACE), which consists of two parts: the principal portion and the list of access rights that the principal has to the associated name in the namespace. The principal part of the ACE can be the name of an individual user, a group name, or a name with one or more wildcard characters to denote several users. For example, the following wildcard notation denotes all users on all nodes in the specified namespace:

*...

A name can have multiple ACEs associated with it. The complete set of ACEs for a particular name is called an access control set (ACS) and is an attribute of that name.

5.6.2 Access Control Groups

It is often useful to set up an access control policy when you plan your namespace, choosing a select group of users who will have control over the root of the namespace and deciding how to delegate access to other directories. Two DECdns groups are available to help you implement such an access control policy: .DNS_Admin and .DNA_Registrar.

The .DNS_Admin group is an access control group meant to contain the names of people responsible for managing the entire namespace. The DECnet configuration procedure creates this group when it creates a new namespace. If you want to use the .DNS_Admin group, you must explicitly add members and create ACEs for the directories that you want the group to control.

You can create ACEs for the .DNS_Admin group that propagate from the root directory down to all subsequent child directories and their contents. Propagating access rights allows .DNS_Admin members to monitor any changes or problems in the namespace. Consider a policy requiring that the .DNS_Admin group also be given access to all clearinghouses. A clearinghouse is named in a directory but not contained in that directory, so it does not inherit access control from a directory's ACS. See the DECnet-Plus DECdns Management guide for details on creating ACEs, managing groups, and implementing a namespacewide access control policy.

The .DNA_Registrar group is an access control group for people who manage node object entries and node soft links. You must explicitly add members to this group as well. You might want to add the .DNS_Admin group as a member of this group, thereby automatically giving .DNS_Admin members access to whatever .DNA_Registrar members can manage.

The decnet_register tool creates the .DNA_Registrar group and grants the group full access to all directories, object entries, and soft links that the tool creates. Section 7.4 describes the access rights that the tool automatically assigns, and suggests ways to modify the default access control policy.

5.7 DECdns Management

DECdns provides two user interfaces for examining and managing the components of a namespace: a windows-based Browser utility and a DECdns Control Program, called DNS$CONTROL on OpenVMS systems and dnscp on DIGITAL UNIX and ULTRIX systems. The DECdns Control Program is an interface that accepts commands targeted for specific entities, such as clerks, clearinghouses, or directories. The browser is a tool for viewing the content and structure of a namespace. It runs on workstations with DECwindows or Motif software.

5.8 How DECnet-Plus Uses DECdts

DECnet-Plus software includes DECdts. DECdts is self-configuring, but offers a command-line management interface that allows system managers to display and update the time on any system in the network.

The DECdts application programming interface (API) allows applications (DECdns, for example) to obtain, modify, and compare timestamps. DECdts servers also accept time values from external sources through the DECdts time-provider interface; these sources can be radio receivers, data communications software, or other time services, such as NTP (Network Time Protocol). Sample time-provider programs are also supplied with the DECdts software.

DECdts consists of software components on a group of cooperating systems. In a typical DECdts implementation, a few servers supply the time to many client systems and applications through intermediaries called clerks. Clerks reside on their client systems.

Because no device can measure the exact time at a particular instant, DECdts expresses the time as an interval containing the correct time. DECdts clerks obtain time intervals from several servers, and compute the intersection where the intervals overlap. Clerks then adjust the system clocks of their client systems to the midpoint of the computed intersection. When clerks receive a time interval that does not intersect with the majority, they declare the nonintersecting value to be faulty. Clerks ignore faulty values when computing new times, thereby ensuring that defective server clocks do not affect clients.

DECdts provides many valuable services for computer networks running distributed applications. A summary of its major features and benefits follows:

• Correctness
  DECdts maximizes the probability that a client will receive the correct time. DECdts uses Coordinated Universal Time (UTC) as a base reference, and defines any time interval containing UTC as correct.
• Fault Tolerance
  DECdts reports faulty servers, and does not use their time values during clock synchronizations.
• Automatic Configuration
  DECdts entities use multicast messages to obtain the locations of servers in a LAN, and the DIGITAL Distributed Name Service (DECdns) to obtain the locations of servers in a WAN.
• Application Programming Interface
  DECdts provides an interface that allows applications to obtain, compare, and calculate UTC time values.
• Automatic Local Time Updates
  After the initial configuration of a DECnet-Plus system, DECdts sets the local system clock automatically according to the time zone rule in effect for the system.
• Local Time Translation
  When displaying time values, DECdts translates the UTC times that it uses internally into local time values.
• Quantitative Time Measurement
  DECdts uses specific measurement and manufacturer's specifications to determine the accuracy of the times reported by servers.
• NCL Management
  Through its management interface, DECdts offers Network Control Language support for controlling and monitoring the software.
• Efficiency
  Complexity is placed in the servers; network overhead is minimal.

• Monotonicity
  DECdts provides unidirectional clock adjustment to ensure that clocks do not run backwards.

DECdts offers all the features generally provided by a time service, but it also has several unique features that enhance network performance. This section describes these DECdts features.

5.9.1 Applications Support

Operating systems and distributed applications require synchronized time measurements to coordinate their processes. DECdts synchronizes the system clocks in a network with each other, and in the presence of an external time-provider, to the UTC time standard. Any distributed application that reads the system clock (the majority of applications) needs DECdts. As the number of distributed applications and systems in a network increases, DECdts becomes increasingly vital to process coordination.

For new applications, DECdts provides an application programming interface (API) that provides routines applications can use to obtain and manipulate binary timestamps. For example, routines are available to convert the OpenVMS local time format used in DECnet-Plus for OpenVMS systems to UTC. The DECdts API supports ANSI C language constructs; you can use the same calls on DECnet-Plus for OpenVMS and DECnet-Plus for DIGITAL UNIX systems.

5.9.2 Automatic Time Zone Changes

On DECnet-Plus systems, DECdts automatically sets the system time according to the time zone rule you specify during the initial configuration procedure. DECdts communicates by using UTC; it uses the time zone rules to translate from UTC to local time. In addition, the time zone rules can define seasonal time changes. For example, you can specify that when daylight saving time takes effect, the system clock should be updated automatically.

5.9.3 External Time-Provider Support

For most networks, it is desirable to synchronize the system clocks with the UTC time standard. Many commercial devices are available for obtaining the UTC time provided by standards organizations; these devices receive signals by short-wave radio, satellite, and telephone. If your network is larger than a single LAN, DIGITAL recommends that you use at least one external time-provider in combination with the DECdts software. Sample time-provider programs for use with various time-providers are supplied with the DECdts kit and are available on line. The DECdts kit also contains a time-provider interface that describes the interprocess communications between a DECdts server and a time-provider.

5.9.4 Quantitative Inaccuracy Measurement

Unlike other network time services, DECdts uses manufacturer's specifications and direct observation to determine the inaccuracy of system clocks relative to UTC. DECdts appends an inaccuracy measurement to each time value that it uses internally; this measurement takes into account cumulative clock error, communications delays, and processing delays. DECdts uses combined time and inaccuracy measurements from one or several sources to calculate the most accurate new clock settings for client systems.

5.10 How DECdts Works

DECdts has two major software components:

• Clerks
• Servers

The following sections describe each of these components and tell how they interact to provide time to client applications and to synchronize system clocks.

5.10.1 Clerks

Any system that is not a DECdts server is a DECdts clerk; most network systems run clerk software. Clerks are the intermediaries between clients and servers. Clerks also maintain server lists and perform the synchronization functions for DECdts client systems. Clerks send multicast queries to all servers and build server lists from the servers that respond. Clerks contact known servers for new server lists periodically, or whenever the number of servers on their lists falls below the minimum specified by the servers required attribute. (This attribute is one of several settable DECdts characteristics available through the management interface.)

After building a server list, a clerk can directly request time values from the number of servers determined by the servers required management parameter. The clerk then receives these time values and uses them to compute a new system time for its client system.

5.10.2 Servers

Servers provide many of the communications functions for DECdts. They provide time intervals to clerks and other servers, and advertise their presence on the LANs of which they are members.

External time providers can be connected to servers, which then propagate the precise time intervals they obtain from the time-provider throughout the network. The rest of this section describes the three types of DECdts servers.

5.10.2.1 Local Servers

A set of local servers reside on the same LAN and maintain their clocks by synchronizing with each other. Local servers use the IEEE 802.2 (CSMA-CD) protocol to communicate; due to the high throughput on this type of network, the skews between the local servers on the LAN are normally maintained at under 200 milliseconds. If at least one of the servers in the local set synchronizes with an accurate external time-provider, inaccuracies at each server may be even less.

Each local server advertises itself on the LAN by sending multicast messages containing its address. Each server builds lists of the other servers in the LAN by listening to the multicast messages. When a server synchronizes, it queries all the other servers on its server list for time values. Servers that do not respond are deleted from the list of servers. Local servers perform time-interval computations, adjust their clocks, and provide time values to each other for synchronization purposes. Each server must synchronize with every other server in the local set at periodic intervals.

5.10.2.2 Global Servers

WANs and many extended LANs require global servers. Local servers are available only to the servers and clerks in a single LAN, but global servers are available across an extended LAN or WAN. Any server can be configured as both a local and a global server. The number of global servers is usually small, but global servers have several important functions that enable DECdts to synchronize every node in the network. Global servers are necessary in the following situations:

• When a network has multiple LANs or an extended LAN with bridges that block multicast messages.
• When systems that are not on LANs have access to LANs through point-to-point links.
• When clerks or local servers cannot access the required number of local servers determined by the servers required management parameter.

A list of DECdts global servers is always available to network systems through DECdns, which maintains a list of the DECdts global servers. All DECdts clerk and server systems are also DECdns clients. DECdts servers and clerks also maintain their own lists of global servers, which are periodically refreshed from the directories maintained by DECdns.

Local servers and clerks request time values from global servers when they cannot obtain the number of local server responses mandated by the servers required attribute. Certain local servers also regularly request the time from global servers; see the following section.

5.10.2.3 Couriers

Designated local servers called couriers regularly communicate with global servers. Couriers are local servers that request time values from one global server at every synchronization. To ensure that all parts of the network contribute their time values to the LAN, couriers randomly select a global server from the DECdns namespace before each synchronization. Couriers use the responses of both local and global servers when synchronizing their own clocks.

For a network containing multiple LANs or point-to-point links, configure one server on each LAN or segment as a courier; this configuration ensures that various portions of the network remain synchronized and are not isolated from each other.

Using the management interface, you can also designate one or more servers to be backup couriers. These local servers temporarily assume courier functions in the event that no courier servers are available on the LAN. In such a case, the backup courier with the lowest numbered Ethernet address regularly synchronizes with global servers until a courier is again available.

5.11 DECdts Management

DECdts is managed with NCL. System managers can adjust system clocks, change the values of the DECdts management parameters, and add or subtract servers from the network. To aid in solving problems with system clocks, DECdts also provides event reporting that notifies system operators and managers in the rare event that a system clock is inaccurate or fails to synchronize.