![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Choose one ISDN number and use it to create a unique IDI value for your network. This number serves simply as a unique number that has been assigned to you.
Example:
Country code (for U.S.A.) = 1 National destination code (for New York) = 212 Subscriber number = 555-6172
Resulting IDP value = 45:12125556172
This section shows examples of how an ANSI-formatted NSAP is divided into its component fields. For all examples, except for the one that shows a Phase IV prefix, the fields have the following values:
| Field | Value |
|---|---|
| AFI | 39 |
| IDI | 840 |
| DFI | 80 |
| ORG | 01E240 |
| RES | 0000 |
| RD | 0000 |
| LocArea | 0001 |
| Node ID | 08002B143136 |
| SEL | 21 |
The example showing the Phase IV prefix uses node ID and SEL values that are Phase IV-compatible, and these fields have the following values:
| Field | Value |
|---|---|
| NodeID | AA0004000104 |
| SEL | 20 |
Figure 4-5 shows the example NSAP using DNA format.
Figure 4-5 NSAP Fields: DNA Format Examples
Figure 4-6 shows the same examples using OSI format.
Figure 4-6 NSAP Fields: OSI Format Examples
This section applies to users in the United States who have applied to ANSI for a unique network identifier in the ISO DCC format. With values assigned by ANSI, an NSAP has the following DNA format:
AFI:IDI:DFI-ORG-RES-RD-LocArea:NodeID:SEL
Table 4-2 explains the NSAP fields used in this format.
| Field | Value | Meaning |
|---|---|---|
| AFI | 39 |
ANSI provides a decimal value.
Enter as two decimal digits. |
| IDI | 840 |
ANSI provides a decimal value.
Enter as three decimal digits. |
| DFI | 128 |
ANSI provides a decimal value.
Enter as two hexadecimal digits. |
| ORG | dddddd |
ANSI provides a decimal value.
Enter as six hexadecimal digits. |
| RES | 0000 |
Value reserved by ANSI for future use.
Enter as four zeros. |
| RD | dddd | Enter as four hexadecimal digits. |
| LocArea | dddd | Enter as four hexadecimal digits. |
| Node ID | dddddddddddd | Enter as 12 hexadecimal digits. |
| SEL | dd | Enter as two hexadecimal digits. |
All values supplied by ANSI are decimal numbers. Use the AFI and IDI in
your NSAP as decimal values. However, due to the encoding rules of
binary syntax NSAPs, you must convert the DFI and ORG values to
hexadecimal. You can easily convert these two values from decimal to
hexadecimal using a calculator or using the operating system's
calculator feature.
Use the Digital UNIX bc command. For example, with an ORG value of 123456, use the following commands to convert the values:
# bc obase=16 /* Set the output radix to base 16 (hex) */ 128 /* Enter the decimal DFI value */ 80 /* Resulting hex value */ 123456 /* Enter the decimal ORG value */ 1E240 /* Resulting hex value */ <>
Use an OpenVMS symbol. For example, with an ORG value of 123456, use the following commands to convert the values:
$dfi = 128 $org=123456 $sh sym dfi DFI = 128 Hex = 00000080 Octal = 00000000200 $sh sym org ORG = 123456 Hex = 0001E240 Octal = 00000361100 $ <>
Using these values, the resulting NSAP has the following DNA NSAP format:
39:840:80-01E240-0000-RD-LocArea:NodeID:SEL
While this section discusses NSAP values from ANSI, the same information also applies to other Phase V addressing values, including the NET, Phase IV prefix, and address prefixes. In addition, this information is based on the draft ANSI standard:
"Data Communications --- Structure and Semantics of the Domain Specific Part (DSP) of the OSI Network Service Access Point (NSAP) Address"
ANSI might review and modify this standard.
The Local namespace is a discrete, nondistributed namespace that exists on an individual node and provides that node with a local database of name and addressing information. The Local namespace replaces functionality previously provided by the DECdns Local Naming Option. Depending on the number of address towers stored, the Local namespace is designed to scale to at least 100,000 nodes.
DECnet-Plus recognizes that when a node full name begins with local:, information for that node is stored in a Local namespace. The following are typical node full names properly formatted for the Local namespace: local:.xyz.abc and local:.maximum.
Unlike DECdns, the Local namespace does not employ backtranslation directories for address-to node-name translation.
The Digital Distributed Name Service (DECdns) is a networkwide service that makes it possible to use network resources without knowing their physical location. Users and applications can assign DECnet-Plus names to resources such as nodes. The creator of a name also supplies other relevant information, such as the resource's network address, for DECdns to store. Users then need to remember only the name, and DECdns acts as a lookup service, providing the rest of the data when necessary. DECnet/OSI for Digital UNIX does not contain DECdns server software.
The Digital Distributed Time Service (DECdts) is a networkwide service that synchronizes the system clocks in the network's computers. DECdts enables distributed applications to execute in the proper sequence even though they run on different systems.
All DECnet-Plus systems require a name service because the Session layer of DECnet-Plus uses it to map node names to addresses.
DECnet-Plus provides access to the node name and addressing information stored in one or more of the following name services.
While configuring DECnet-Plus, the system administrator specifies one or more of the following name services to use on the node: the Local namespace; DECdns; or Domain. Note that in this version of DECnet-Plus, even when you are using the Local namespace the DECdns clerk software is still required on each node by DECnet-Plus.
By using DECdns, you can save network resources, manage node names automatically, and scale up to thousands of nodes.
When you make the transition from DECnet Phase IV to DECnet-Plus, the nodes in your network are given DECnet-Plus full names. Along with the node names, the name service stores the address and protocol information that DECnet needs to make connections between nodes. The DECnet-Plus software includes a tool, decnet_register, to help you create and manage node information in DECdns and the Local namespace.
The major benefit of using DECdns in a distributed namespace is the ease of storing node names. With DECdns, it is not necessary to maintain a node database on every system in the network. A few DECdns servers store node names, and all other nodes in the network can depend on those servers for node-name-to-address mapping. When data associated with the node name changes, DECdns propagates the change automatically to all servers that store that node name.
Another benefit of DECnet-Plus node full names is that they can be longer and hence more descriptive than Phase IV node names. Whereas Phase IV node names are limited to six characters, any full name, including a node name, can be as long as 255 characters. See Chapter 6 for complete guidelines for all node names.
The Digital Distributed Time Service (DECdts) is another important user of DECdns in DECnet-Plus. DECdts and DECdns actually depend on each other. DECdts uses DECdns as a networkwide registry for global time servers that synchronize system clocks in the network. DECdns uses timestamps to determine the order in which changes to its data occur, and it depends on DECdts to synchronize time on DECdns servers so their timestamps are consistent. Synchronized clocks are important to any distributed application that needs to keep track of the order in which events occur across multiple systems.
DECnet-Plus constructs a name service search path file from information entered during configuration. This file determines the order in which the namespaces available on the node will be searched and, for each namespace, any defaulting rules to allow users to enter abbreviated node names.
The name service search path applies system wide and allows DECnet-Plus to search a list of name services in a predetermined order when looking up names or addressing information. The primary name service (the name service to be searched first) is listed before the secondary name services. The secondary name services are listed in the order in which they are to be searched after the primary name service.
If you choose to use a search path and configure more than one name service on your system, the ordering of the name services is very important.
The search path also contains a list of name service keywords, each followed by a naming template that specifies a "defaulting rule" so users can enter shorter node names. In each template, the user-supplied portion of the name (usually the node's terminating name or rightmost simple name) is indicated with an asterisk (*). For example, if the DECdns template is: "ABCDE:.xyz.*" and a user supplies the name foo, then the following full name: ABCDE:.xyz.foo will be looked up in namespace ABCDE in the DECdns name service.
Only one asterisk should be supplied per template. Only the first occurrence of an asterisk (*) in the template is substituted with the user-supplied name. Any additional asterisks are passed to the name service as part of the full name. When you specify a template without an asterisk, the template string is passed to the name service unchanged.
If the user-supplied name should be passed to the name service as entered by the user, the template should simply be specified as follows: "*".
Note that the system maintains two separate search paths:
During DECnet-Plus configuration, the system administrator uses net$configure.com (on OpenVMS systems) and decnetsetup (on Digital UNIX systems) to set up one or more name services on each node and set up the search path. The procedure for setting up and maintaining the search path on your node is specific to the OpenVMS and Digital UNIX systems. See your installation and configuration guide for more information.
Operation of the name service involves several major participants:
DECdns uses a client/server model: an application, such as DECnet-Plus, that depends on DECdns to store and retrieve information because it is a client of DECdns. Client applications create names for resources on behalf of their users. Through a client application, a user can supply other information for DECdns to store with a name. This information is stored in data structures called attributes. Then, when a client application user refers to the resource by its DECdns name, DECdns retrieves data from the attributes for use by the client application.
A system running DECdns server software is a DECdns server. A DECdns server stores and maintains DECdns names and handles requests to create, modify, or look up data. You designate a system as a DECdns server during configuration of the network software.
A component called the clerk is the interface between client applications and DECdns servers. A clerk must exist on every DECnet-Plus node and is created during configuration of the network software. The clerk receives a request from a client application, sends the request to a server, and returns the resulting information to the client. This process is called a lookup. The clerk is also the interface through which client applications create and modify names. One clerk can serve many client applications.
The clerk caches, or saves, the results of lookups so that it does not have to go repeatedly to a server for the same information. The cache is written to disk periodically so the information can survive a system reboot or the restart of an application. Caching improves performance and reduces network traffic.
Figure 5-1 shows a sample configuration of DECdns clerks and servers on a nine-node LAN. Every node is a clerk, and DECdns servers run on two selected nodes.
Figure 5-1 Sample DECdns LAN Configuration
Every DECdns server has a database called a clearinghouse in which it stores names and other DECdns data. The clearinghouse is where a DECdns server adds, modifies, deletes, and retrieves data on behalf of client applications. Although more than one clearinghouse can exist at a server node, Digital does not recommend it as a normal configuration.
Figure 5-2 shows the interaction between a DECdns client, clerk, server, and clearinghouse during a simple lookup. First, the clerk receives the lookup request from the client application (Step 1) and checks its cache. Not finding the name there, the clerk contacts the server on Node 2 (Step 2). The server finds the name in its clearinghouse (Steps 3 and 4) and returns the requested information over the network to the clerk (Step 5), which passes it to the client application (Step 6). The clerk also caches the information so it does not have to contact a server the next time a client requests a lookup of that same name by the same user.
Figure 5-2 Simple Lookup
The total collection of names that one or more DECdns servers know about, look up, manage, and share is called a DECdns namespace. When you create a DECdns namespace, you organize DECdns names into a hierarchical structure of directories. DECdns directories are conceptually similar to the directories that you create in your operating system's file system. They are a logical way to group names for DECdns-specific management or usage purposes.
The highest-level directory in the namespace is denoted by a dot (.) and is called the root directory. The root is created automatically when you initialize a namespace. You can then create and name other directories below the root. Any directory that has a directory beneath it is considered the parent of that directory. Any directory that has a directory above it is considered a child of the directory above it.
Figure 5-3 shows a simple hierarchy of directories. The root directory (.) is the parent of the directories named West and FarEast. The FarEast directory is a child of the root directory and the parent of the Tokyo and Osaka directories.
Figure 5-3 Example Namespace Directory Hierarchy
The complete specification of a DECdns name, going left to right from the root directory to the entry being named, is called the full name. Each element within a full name is separated by a dot and is known as a simple name. For example, the Osaka directory in the preceding figure might contain an entry for a node whose simple name is Node01. The node's full name would be .FarEast.Osaka.Node01. A full name also can include a namespace nickname, but this is not needed when only one namespace exists in a network. When you must specify a namespace, use the following format:
NamespaceNickname:.DirectoryPath.NodeObject
Each physical copy of a directory, including the original copy, is called a replica. Directory replicas are the units by which you distribute names in clearinghouses throughout the namespace. You can think of a clearinghouse as a collection of directory replicas at a particular server. After you create a directory in one clearinghouse, you can create replicas of it in other clearinghouses.
All of the replicas of a specific directory in the namespace constitute that directory's replica set. DECdns performs a periodic skulk operation to ensure that all replicas of a directory remain consistent. During a skulk operation, DECdns collects all changes that have been made to the directory since the last skulk completed and disseminates the changes to all replicas of the directory. Every replica must be available for the skulk to be considered successful. Two types of replicas can exist:
A replica's type affects the processing that can be done on it and the way DECdns updates it. The type of replica DECdns uses when it looks up or changes data is invisible to users. However, it helps to understand how the two types differ.
The master replica is the first instance of a specific directory in the namespace. After you make copies of the directory, you can designate a different replica as the master, if necessary, but only one master replica of each directory can exist at a time.
The master replica is the only directly modifiable replica of a directory. DECdns can create, change, and delete information in a master replica. Because it is modifiable, the master replica incurs more overhead than read-only replicas, which DECdns keeps up-to-date but never modifies directly. The master replica also is the place where skulks originate.
A read-only replica is a copy of a directory that is available only for looking up information. DECdns does not create, modify, or delete names in read-only replicas; it simply updates them with changes made to the master replica. Read-only replicas save resources because DECdns does not make changes directly in them, nor does it have to gather changes from them to disseminate to other replicas.
Directory replicas can contain three kinds of entries:
An object is any real-world network resource, such as a disk, application, or node, that is given a DECdns name. When an object name is created, client applications and the DECdns software supply additional data in the form of attributes to be stored with the name. The name and its attributes make up the object entry. When a client application requests information associated with the name, DECdns returns the value of the relevant attribute or attributes.
Every object has a defined class, which is stored as an attribute of the object entry. For example, a node object's class is DNA$Node. Another important class of object is the group object (class DNS$Group). Groups let you associate, or manage as a group, names that have something in common. They do this by mapping a specific name (the group name) to a set of names denoting the group members. DECdns managers can create groups that assign several users a single set of access rights to names. Two such access control groups are created automatically during configuration of the DECnet-Plus and DECdns software. See Section 5.6.2 for a description of them and recommendations on their use.
A soft link is a pointer that provides an alternate name for an object entry, directory, or other soft link in the namespace. You can restructure a namespace on a minor scale by creating soft links that point from an existing name to a new name. Soft links can be permanent, or they can expire after a period of time that you specify. If the name that a soft link points to is deleted, DECdns deletes the soft link automatically.
DECnet-Plus uses backtranslation soft links to map a node address to a node's full name when necessary. Another kind of soft link, called a node synonym, enables applications that do not support the length of a DECdns full name to continue using six-character Phase IV-style node names. Section 5.5 explains how DECnet-Plus uses backtranslation and node synonym soft links.
A child pointer connects a directory to another directory immediately beneath it in a namespace. Users and applications do not create or manage child pointers; DECdns creates a child pointer automatically when someone creates a new directory. The child pointer is created in the directory that is the parent of (one level above) the directory to which it points. DECdns uses child pointers to locate directory replicas when it is trying to find a name in the namespace. Child pointers do not require management except in rare problem-solving situations.
To summarize, a DECdns namespace consists of a complete set of names shared and managed by one or more DECdns servers. A name can designate a directory, object entry, soft link, or child pointer. The logical picture of a DECdns namespace is a hierarchical structure of directories and the names they contain. Every physical instance of a directory is called a replica. Names are physically stored in replicas, and replicas are stored in clearinghouses. Any node that contains a clearinghouse and runs DECdns server software is a server.
Figure 5-4 shows the components of a DECdns server. Every server manages at least one clearinghouse containing directory replicas. A replica can contain object entries, soft links, and child pointers. The figure shows only one replica and one of each type of entry possible in a replica. Normally, a clearinghouse contains many replicas, and a replica contains many entries.
Figure 5-4 Components of a DECdns Server Node
The decnet_register tool is available to help you create these entries in the distributed namespace. The DECnet configuration procedure starts the tool automatically after creating a new namespace. If you choose to use the Local namespace, the decnet_register tool also enables you to create entries in the Local namespace. You also can run decnet_register separately to create and manage node information in the namespace. This section introduces each type of node entry and describes how it is created and used.
In a Phase V network using DECdns, every DECnet node has a corresponding object entry in the DECdns namespace. During the DECnet configuration procedure, you must supply a DECdns full name for your node (the full name includes the complete path from the root directory to the node's simple name) if you decide to use a distributed namespace. The full name becomes the name of the node's object entry in the namespace. If you decide to use a Local namespace, you must enter local as your namespace name during the DECnet configuration procedure.
PLAN_PROFILE_006.HTML OSSG Documentation 2-DEC-1996 12:32:12.56
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.