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:
The DECnet Phase IV network-address format consists of 16 bits (2 bytes) of information:
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.
|Phase IV Address||OSI Address|
|2 bytes long||Up to 20 bytes long|
Consists of two parts:
||Consists of two parts:|
|Area = area number (1 to 63)||Area = IDP + preDSP 1 + LocArea fields in DSP|
|Node address = area number + node number||
System address = IDP + preDSP + LocArea + node ID is called the
network entity title (NET).
The NET is the address by which the Network layer is identified. It identifies a particular system in a particular network.
|No transport selection (NSP assumed)||
Provides SEL field for transport selection (NSP or OSI transport).
AN OSI address (NET) that also includes a SEL field other than 00 is a network service access point (NSAP). The NSAP is a global network address. It is the addressable point at which a network entity provides the network service to a network user. It identifies both the particular network system and the transport on that system that is to receive the data.
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:
Use Phase V addresses that are larger than Phase IV limitations if one or more of the following apply to your network:
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.
If you have a multivendor OSI-compliant router adjacent to your end system, do not use autoconfiguration unless you know that the router uses NETs with a selector of 00. This restriction applies even if you have a DECnet Phase V router as well as the multivendor router on the same LAN. Multivendor routers that specify NETs differently can cause incorrect autoconfiguration.
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:
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
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:
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:
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
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:
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
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
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
1.5.4 Mapping Node Names to Addresses
During transition, the network maps node names to addresses in the following ways:
To ensure that Phase IV nodes and DECnet-Plus systems can communicate:
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:
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
1.7 DECnet Phase IV Applications
DECnet-Plus supports DECnet Phase IV applications as described in the
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.