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.
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.
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.
Note
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.
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:
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.
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.
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.
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:
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.
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.
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.
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/OSI 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.
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).
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 management guide.
DECnet-Plus supports DECnet Phase IV applications as described in the following sections.
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.
DECnet/OSI for Digital UNIX supports ported user-written DECnet-ULTRIX Phase IV applications. However, these programs cannot take advantage of certain new features, such as location-independent services (network objects).
Although not required, recoding your custom applications has the following advantages:
DECnet-Plus network management implements a new architectural model, has a new structure, and provides the new NCL command interface. Once you install DECnet-Plus software on a node, you must use DECnet-Plus network management to manage that node. You should consider the following network management issues before you start your transition:
To manage the local DECnet-Plus node and remote DECnet-Plus nodes, use NCL. To manage remote Phase IV nodes, use the Network Control Program (NCP). Refer to DECnet-Plus Network Control Language Reference for information about how to issue NCL and NCP commands on a DECnet-Plus node.
Note
You cannot manage a DECnet-Plus system remotely from a Phase IV node.
DECnet-Plus network management is based on the draft ISO Common Management Information Protocol (CMIP) standard for network management operations. DECnet-Plus, using DNA CMIP, provides local and remote management support with the CMIP requester and listener, CML.
DECnet Phase IV user applications that call in NML or NICE must be modified to use CML and CMIP in order to run on Phase V systems. Refer to DECnet-Plus for OpenVMS Introduction and User's Guide for more information.
DECnet-Plus systems do not support remote management of other vendors' OSI-compliant systems because DNA CMIP is not compliant with OSI CMIP.
DECnet-Plus does not interoperate with Phase III or Phase II implementations of DECnet. However, you can configure Phase III systems, such as a DECnet-RT system and a DECnet-RSX-11M-PLUS system, as end nodes in a Phase IV area if the Phase III system is adjacent to a Phase IV router (not a DECnet Phase V router running routing vector).
If your network has nodes running Phase III software, your migration plan must take this into account. You have the following options:
The following products and functions will not migrate to DECnet-Plus:
For additional product support information for DECnet-Plus, consult the DECnet-Plus for OpenVMS Release Notes, as well as DECnet-Plus for OpenVMS Installation and Basic Configuration and DECnet/OSI for Digital UNIX Installation and Configuration.
You have the following transition options:
You need to decide what to do with these systems and functions during migration and what place, if any, they will eventually have in the configuration of your DECnet Phase V network. You may decide to replace them, either immediately or in the future, with DECnet-Plus products.
This chapter helps you plan for an orderly, efficient transition from a Phase IV network to a DECnet Phase V network.
Whatever the size or complexity of the network, a successful transition requires planning. Planning helps to ensure continued communication throughout the network during migration, with a minimum of disruption to users.
Use the checklist of transition-planning steps in Table 2-1 to draw up your network's transition plan and, later, to coordinate and execute the transition. Before using this checklist, note that:
Step 1: Document the current network configuration: | ||
---|---|---|
[] | Identify the name, address, operating system, and DECnet version of each node. | |
[] | Identify the nodes that are routers, network management stations, load hosts, and name servers. | |
[] | Identify any existing DNS Version 1 servers and DECdns Version 2 servers. | |
[] | Identify the hardware and software that cannot move to DECnet-Plus. | |
[] | Identify the router types and locations. | |
[] | Identify the network topology: show all end nodes, level 1 routers, and level 2 routers. | |
[] | Identify any multivendor routers. | |
[] | Identify the Phase IV applications that use the NICE Protocol. | |
[] | Identify any applications that depend on a particular operating system version. | |
Step 2: Determine your transition strategy: | ||
[] | Decide which DECnet Phase V features the network needs: OSI interoperability and/or OSI addressing. | |
[] | Determine if the network needs DECnet Phase IV areas. | |
[] | Decide which DECnet-Plus software components provide each feature you need, and which optional components to install. | |
Step 3: Develop a new network configuration: | ||
[] | Consider the new network configurations available with DECnet-Plus. | |
[] | Decide if you can use the default IDP, or if you need a unique one. | |
[] | Determine the address scheme: Phase IV-compatible and/or addresses beyond Phase IV limitations. | |
[] | Determine if you will continue to use Phase IV routers. | |
[] | For Phase V routers, determine the type of routing to run: Phase IV and/or Phase V routing algorithm. | |
[] | Determine which nodes go to DECnet-Plus, which stay at Phase IV. | |
[] | Select which nodes will be end systems, routers, and area routers. | |
Step 4: Plan for your name services and DECdts Time Service: | ||
[] | Choose your name services --- Local namespace and/or DECdns distributed namespace, or Domain (DNS/BIND) --- for the network and for individual nodes. | |
[] | If you will use the DECdns distributed namespace, choose the systems that will be name servers and time servers. | |
[] | Plan for converting DNS Version 1 namespaces to DECdns Version 2 namespaces. | |
Step 5: Choose the first end system to migrate: | ||
[] | Examine recommendations and evaluate the available nodes. | |
[] | Select the first node to migrate. |
PLAN_PROFILE_001.HTML OSSG Documentation 2-DEC-1996 12:32:04.13
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.