HP OpenVMS Systems Documentation

The DECnet-Plus software supports a new address format, the OSI addressing format. OSI addresses (NSAPs) can be bigger and longer than Phase IV addresses, or they can fall within the limits of Phase IV addressing. OSI addresses that falls within the limits of Phase IV addressing are referred to as Phase IV-compatible addresses. DECnet Phase V addresses that fall outside Phase IV address space are referred to as extended addresses. Refer to Section 4.5 for more information.

Making communication possible between a Phase IV node and a DECnet-Plus system depends on the address of the DECnet-Plus system and on your routing configurations. You have the following options for assigning addresses to DECnet-Plus systems:

• You can assign OSI addresses that are also Phase IV-compatible to all DECnet-Plus systems.
• You can use OSI addresses that are not Phase IV-compatible on all DECnet-Plus systems, if you meet the requirements listed in Section 2.3.4.
• You can have a mixture of Phase IV-compatible and extended addresses:
  • By having Phase IV areas and DECnet Phase V areas.
  • Within a single area, if the area has multiple area addresses, one of which is a Phase IV-compatible address and another which is an extended address.
    You can have an area with DECnet Phase V routers running link state in which some nodes have Phase IV addresses and some have OSI addresses that are beyond Phase IV limitations. As long as the routers all have Phase IV addresses, the nodes with Phase IV addresses can communicate with other Phase IV nodes outside the area. Nodes with extended OSI addresses cannot communicate with Phase IV nodes in other areas.
• You can multihome each system, giving it from one to three different addresses (see Section 1.3.4).

The DECnet Phase IV network-address format consists of 16 bits (2 bytes) of information:

• 6 bits for the area address
• 10 bits for the node identifier

This format limits the network to 63 areas and a maximum of 1023 nodes per area. In contrast, the OSI address format can be up to 20 bytes long, thus extending network addresses beyond Phase IV limits.

Table 1-1 lists the differences between Phase IV and OSI addresses. Figure 1-1 shows the address parts listed in Table 1-1. For a complete description of OSI addresses and their individual parts, see Chapter 4.

Figure 1-1 Examples of Phase IV and DECnet Phase V Addresses

Phase IV nodes can communicate with DECnet-Plus systems only if the DECnet-Plus systems have Phase IV-compatible addresses. A Phase IV-compatible address is an OSI address that has a Phase IV address encoded within it.

You can use link state routing with Phase IV-compatible addressing.

Phase IV-compatible addresses continue to be suitable for many DECnet Phase V networks; using them can ease migration to link state routing. You can choose to use Phase IV-compatible addressing until all, or most, network servers and services are running DECnet-Plus.

1.3.2 Advantages of Using OSI Addresses That Are Also Phase IV Compatible

Use Phase IV-compatible addresses for DECnet-Plus systems that:

• Need to communicate with Phase IV nodes, either for the short term (until the Phase IV nodes migrate to DECnet-Plus), or for the long term (because those nodes cannot migrate).
• Exist in the same area as Phase IV routers.

Use Phase V addresses that are larger than Phase IV limitations if one or more of the following apply to your network:

• The network size requires more than 63 areas per network and/or 1023 nodes per area.
• You plan to connect your network to other OSI networks.
  Phase V addresses include an initial domain part (IDP), a unique identifier for a network that permits connection to other networks.
• The Phase V systems do not need to communicate with Phase IV nodes.
• You want to allow end systems to autoconfigure their network addresses during the installation/configuration process.

You can assign more than one address to a system. This practice is called multihoming. For example, you can give any DECnet-Plus system both a Phase IV-compatible OSI address and an extended address. The benefit is that you can communicate with Phase IV, Phase V, and other OSI systems.

DECnet-Plus allows you to assign to a node as many as three addresses.

Multihoming also makes it easy for you to belong to more than one OSI network. This feature is particularly useful when you want to combine networks. Rather than have all the systems in both networks get new addresses that reflect the new combined network, the systems that need to participate in both networks can have an address in each one.

1.3.5 Autoconfiguration of Addresses

Two ways exist to configure network addresses: autoconfiguring them or manually configuring them. Autoconfiguration means that the adjacent router configures an end node's network address. This is the easier way to configure NETs. If you have a DECnet Phase V router adjacent to your system (on the same LAN or connected to your system by a point-to-point link), you can let the router configure your network addresses for you.

DECnet-Plus end systems can communicate with both DECnet Phase V routers and Phase IV routers. For Phase-IV compatibility, DECnet Phase V routers can communicate in Phase IV routing packet format. While running the Phase IV algorithm, DECnet Phase V routers provide full routing capability for:

• Phase IV nodes
• DECnet-Plus systems with Phase IV-compatible addresses
• Multivendor systems that conform to OSI-packet and OSI-addressing standards, and that have addresses within Phase IV limits.

Like all DECnet-Plus systems, DECnet Phase V routers support OSI addressing. You can set these systems to use either DECnet Phase V link state or Phase IV routing vector for routing on either level 1 or level 2, depending on your network's needs. Note that you can also choose between using a dedicated router in your network to perform routing or to configure your system as a host-based router.

You can configure end systems with DECnet Phase V addresses beyond the limits of Phase IV addressing if your routing infrastructure supports it. For complete information about routing topology choices, see the documentation set of your routing product.

1.4.1 Interdomain Routing

DECnet-Plus supports connections to other networks through interdomain routing, the ability for a network (one routing domain) to connect to a different routing domain.

The IDP of an OSI address provides a unique identifier for the network. The ISO protocols and the OSI addressing scheme enable global multivendor interoperability.

When planning your transition from Phase IV to Phase V, allow for connections to expand to a global network, if appropriate for your enterprise. Also consider your network's accessibility and security needs if it were to become part of a global network.

With interdomain routing, your network can connect either to another network that is based on the DIGITAL Network Architecture (DNA) or to a network with a multivendor routing scheme. The two connected networks remain distinct. Communication takes place:

• Between systems with addresses that you defined in reachable-address tables that reside on level 2 routers.
• Over circuits for which you have set the routing circuit entity characteristic DNA neighbor to false.

Setting DNA neighbor false ensures that your network passes no routing information to the other. However, this configuration may not provide sufficient security for your network, because it does not stop any packets that the other network sends to systems in your network.

For information about setting up connections between networks, see your network management guide.

1.4.2 Level 2 Routing Between Phase IV and Phase V Areas

All level 1 routers within an area must use the same routing protocol. At level 2, however, you can have a mix of routing vector and link state. Level 2 routers running different protocols communicate through interphase links. An interphase link directly connects a level 2 router using routing vector with a level 2 router using link state. DECnet Phase V routers running link state use reachable-address tables to manually configure routing information across the link.

For information about how to use interphase links and reachable-address tables, see your network management guide. For further details, see the router management documentation.

1.4.3 Multivendor Routers

If your network includes multivendor OSI-compliant routers, they might not support one or more of the following DECnet-Plus features:

• Phase IV interoperability
• Autoconfiguration of end-system addresses
• Congestion avoidance
• Management by the Network Control Language (NCL), the network management utility that comes with DECnet-Plus

Therefore, using multivendor routers requires additional management considerations. For example, if the router does not support Phase IV interoperability, your DECnet-Plus systems may not be able to connect to any Phase IV nodes on the network. For details, see the section on coexistence with multivendor routers that do not support backward compatibility in your network management guide.

1.5 Name Services and Time Service Considerations

An important part of planning for migration to DECnet-Plus is planning for your name services and for the DIGITAL Distributed Time Service (DECdts).

The DECdns distributed namespace is no longer a requirement for DECnet-Plus and the Local namespace is not dependent on DECdns. However, the DECdns clerk software is still required on each node. DECnet-Plus provides access to the node name and addressing information stored in one or more name services. DECnet-Plus supports the following name services:

• Local namespace --- A discrete, nondistributed namespace that stores name and address information locally in database files.
• DECdns --- DIGITAL's Distributed Name Service, a distributed, global name service.
• Domain Name System --- The Domain Name System (DNS/BIND) supported for storage of IP addresses.

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.

1.5.1 The Local Namespace

The Local namespace is a discrete, nondistributed namespace that exists on a single node and provides that node with a local database of name and addressing information. Depending on the number of address towers stored, the Local namespace is designed to scale to at least 100,000 nodes.

The prefix LOCAL: (or local:) is reserved to indicate that the information for the node is stored in the Local namespace. 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.

You cannot use the DECdns Control Program (DNSCP) to manage information stored in the Local namespace. Instead, use decnet_register to manage the node name and address information stored in your namespace. The new decnet_register tool is described in your network management guide.

1.5.2 The Name Service Search Path

At configuration time, you will be asked to specify a naming service search path. This search path applies systemwide 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.

The search path contains a list of name service keywords. Each keyword is 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.

1.5.3 Name Service and Time Service Interdependencies

DECdts synchronizes the system clocks in computers connected by a network and, therefore, enables distributed applications to execute in the proper sequence even though they run on different systems.

The DECnet-Plus software, your name service, and DECdts are interdependent:

• DECnet-Plus software requires one or more of the following name services to perform node-name-to-address mapping --- the Local namespace, DECdns, and/or DNS/BIND.
• DECdns servers need DECdts to synchronize system clocks so DECdns servers generate consistent timestamps.
• DECdts uses the namespace as a registry for DECdts global servers that synchronize the time on all systems in the network.

DECnet-Plus for DIGITAL UNIX contains DECdns and DECdts clerk software. If you use the Local namespace, DECdts uses a local configuration script. For DECdns and DECdts planning information, see Chapters 6, 7, 8, 9, and 10.

1.5.4 Mapping Node Names to Addresses

During transition, the network maps node names to addresses in the following ways:

• Phase IV nodes continue to use their permanent node databases.
• All DECnet-Plus systems use either the Local namespace or the DECdns distributed namespace, whether they have:
  • Phase IV-compatible addresses
  • Extended addresses
  • Both
• Domain Name System (DNS/BIND) should be used as a naming service for DECnet-Plus systems that are configured to take advantage of the RFC 1859 and/or RFC 1006 features.

To ensure that Phase IV nodes and DECnet-Plus systems can communicate:

1. Enter the Phase IV-compatible node name and address of each DECnet-Plus system (if the name or address is changing from what it was when the node was a Phase IV node, or if the node is new) into the permanent database of each Phase IV node.
2. If you are using the DECdns namespace and/or local namespace, register each Phase IV node in the namespace.
   Use the decnet_register tool to register all existing Phase IV nodes in the namespace. For complete information about using decnet_register, see the DECnet-Plus for OpenVMS Network Management guide.

To ensure that DECnet-Plus systems can communicate with other DECnet-Plus systems using RFC1006 or RFC1859, enter the Internet Addresses of the nodes in the Domain Name System (DNS/BIND).

1.6 OpenVMS Cluster Systems (OpenVMS Only)

You can combine a single OpenVMS Cluster consisting of both Phase IV and DECnet-Plus nodes with the following restrictions:

• DECnet-Plus nodes must be booted from a different system disk than the Phase IV nodes.
• DECnet-Plus nodes cannot have the same cluster alias as the Phase IV nodes. A single cluster consisting of both Phase IV and DECnet-Plus nodes can have two cluster aliases, one for the Phase IV nodes and one for the DECnet-Plus nodes.
• An OSI router is required on the same LAN as the cluster, adjacent to each DECnet-Plus node joining the alias, for the DECnet-Plus alias to work.
• Currently, the fast configuration option is not supported on a node that is running in an OpenVMS Cluster or on a node that is a DECdns server.

Given these restrictions, you can migrate an existing Phase IV OpenVMS Cluster to a DECnet-Plus OpenVMS Cluster one node at a time. DECnet-Plus no longer requires that at least one node in the cluster be a routing node, but there must be a Phase V router on the network for the alias to work. The DECnet-Plus cluster alias allows a cluster to consist of all end systems. Therefore, using multivendor routers requires additional management considerations. For example, if the router does not support Phase IV interoperability, your DECnet-Plus systems may not be able to connect to any Phase IV nodes on the network. For details, see the section on coexistence with multivendor routers that do not support backward compatibility in your network management guide.

1.7 DECnet Phase IV Applications

DECnet-Plus supports DECnet Phase IV applications as described in the following sections.

1.7.1 DECnet for OpenVMS Phase IV Applications (OpenVMS Only)

DECnet for OpenVMS Phase IV applications that use Queue I/O Request ($QIO) system service calls continue to work in DECnet-Plus without changes. You do not have to change node names to DECnet Phase V format.

DECnet-Plus for OpenVMS offers both the $IPC and $QIO interfaces. OpenVMS Interprocess Communication ($IPC) system service is an operating system interface that is new with DECnet-Plus for OpenVMS. This interface to the Session Control layer lets you use DECnet software to perform interprocess communications.

With $IPC, you can connect to the target application by specifying its full name or its NSAP address, as well as the Phase IV way of specifying node name and application object number and name.

For details about these programming interfaces, refer to DECnet-Plus for OpenVMS Programming.