HP OpenVMS Systems Documentation

A Phase IV end node can have multiple circuits to one or several adjacent nodes, but only one of these circuits can be active at a time. Among Phase IV nodes, only routers have multiple active circuits. DECnet-Plus end systems, on the other hand, can be multicircuited. DECnet-Plus multicircuit end systems can have up to four multiple active circuits to either the same or different subnetworks.

A subnetwork is a communications network, within a group of interconnected networks, of OSI systems that use a common addressing format and that forms an autonomous whole. Examples are

X.25 packet switched networks, HDLC data links and ISO 8802.3 LANs.

These restrictions apply to multicircuit configurations:

• All circuits must be in the same area; the entire set of area addresses for the multicircuit end nodes that correspond to a single network area.
• The circuits must all have the same amount of usable bandwidth.
• All the circuits should provide approximately the same connectivity to other nodes over approximately equivalent paths. Do not use multiple circuits to connect disjointed networks.

Multicircuit end systems do not forward packets to other systems. However, the Routing layer of a DECnet-Plus end system receives information from routers about paths to destinations. The end system gets this information by using the ES-IS protocol to communicate with routers in its area. The routers give the end system information about direct paths to destinations, that is, paths that do not require forwarding the packet. The end system stores the information in a cache and uses it to select an appropriate circuit for sending data to a particular destination. If an end system has no information about a certain destination, it selects a router at random and forwards the data to that router.

Use the following guidelines when you configure multicircuit end systems:

• Configure the circuits to routers with paths that are fairly similar in cost.
  The preferable configuration of end-system circuits is such that information in the cache is on the most efficient paths to a destination. Multicircuit end systems, unlike routers, store no information on path costs. The only decision about paths an end system makes is to choose a direct path, as opposed to an indirect path, to a destination. Multicircuit end systems choose circuits in the following order:
  1. Circuits by which the packet can reach the destination directly, that is, without being forwarded through other systems. The multicircuit end system gets information from routers about direct paths and stores the information in its end-system cache.
     When two or more circuits provide direct paths, the end system selects a circuit on a round-robin (alternating) basis.
  2. Circuits by which the packet can reach the destination indirectly. The end system uses these circuits if it knows of no direct path to the destination.
     Again, when two or more circuits provide indirect paths, the end system selects a circuit on a round-robin (alternating) basis.
• If you plan to change the configuration of the area, first assess the effect it could have on the operation of the circuits of any multicircuit end systems.
  An end-system cache has a timer on its circuit information. When the timer expires, the end system gets new information about paths. If the configuration has changed, the path information may not be similar in cost any more.

DECnet-Plus for OpenVMS and DECnet-Plus for DIGITAL UNIX end systems with multiple active circuits provide redundancy and increased data throughput. An end system with multiple circuits to an Ethernet LAN, for example, provides a guarantee that if one circuit fails, this system still has access to the LAN. There is no gain in data throughput, however, since both circuits go to the same LAN.

You can also configure a multiple-active-circuit end system with its circuits to different LANs. Figure 2-3 shows an end system with circuits to two different Ethernet LANs. This configuration is useful where reliability is critical such as in a network that supports banking applications, for example. This configuration also provides for increased data throughput, since circuits to two different LANs can carry double the number of packets.

Figure 2-3 Multicircuit End System with Circuits to Two Ethernet LANs

Figure 2-4 shows a configuration in which an end system has two active DIGITAL Data Communications Message Protocol (DDCMP) circuits to different routers on a LAN. This configuration could provide redundancy in a situation where, for example, there is concern about disturbances on one of the telephone lines.<>

Figure 2-4 Multicircuit End System with Two DDCMP Circuits

Though you can configure circuits to either the same or a different subnetwork, you can enable the Phase IV address of only one circuit per LAN. To configure a multicircuit end system with a Phase IV address and one or more circuits to the same LAN, take the following steps:

1. If you have not already done so, install the Ethernet hardware necessary for each of the system's connections to the LAN.
2. During the DECnet-Plus configuration process, assign the system a Phase IV address. Also, choose the option that allows the system to autoconfigure its network address.
3. After configuration, on all but one of the Ethernet circuits, set the Routing Circuit entity characteristic enable phase IV address to false . The one circuit with this attribute set to true has its Ethernet address set to a Phase IV Ethernet address. All other circuits retain the address of their Ethernet controller.
   This example sets the enable phase IV address routing characteristic to FALSE on the routing circuit csmacd-1 of the local node:

   ncl> set routing circuit csmacd-1 enable phase iv address=false

You can set the Routing characteristic enable phase IV address in two ways:

• Answer the installation prompts appropriately.
• Edit the Routing layer initialization script and add the commands to set the characteristic. When you next reboot the system, the initialization process runs the script and enables the Phase IV address on only one circuit.
  For for OpenVMS, the initialization script is:
  sys$manager:net$routing_startup.ncl
  For DIGITAL UNIX, the initialization script is:
  /var/dna/scripts/start_routing.ncl

DECnet-Plus software allows OSI-compliant systems from other vendors to participate as end systems in the DECnet Phase V network. Use the following guidelines when you add other vendors' OSI-compliant systems to your network:

• You can include only OSI-compliant systems.
• You can include OSI end systems in a DECnet Phase V area (or network). You can also include them in a Phase IV area (or network operating in a transition environment) if you can configure their addresses as Phase IV-compatible addresses.
• Phase V routers treat the multivendor OSI end system as they do any DECnet-Plus end system.
• You must have DECnet-Plus paths to the multivendor OSI end systems. This means that the network is configured so every possible connection path to the OSI end system has only Phase V routers, not Phase IV routers.
• Do not register multivendor OSI end systems in the DECdns namespace. Only DNA applications and DNA network management use node-name objects in the namespace; OSI applications use their own private naming databases. Register the multivendor OSI end systems in those OSI databases as directed by your OSI application documentation.
• To include a multivendor OSI end system in the network, check that the system meets one of the following conditions:
  • The end system uses the ES-IS protocol and the end system's address can be configured. See the other vendor's documentation for this information.
  • The end system does not use the ES-IS protocol but resides on a LAN for which there is an OSI router and the NSAP address can be configured.
  • The end system does not use the ES-IS Protocol and you cannot configure its NSAP address; but you can attach the OSI-compliant end system to a level 2 Phase V router system. This router must be running link state if the OSI-compliant end system's address is not Phase IV-compatible.
  • You attach the OSI-compliant end system through an X.25 dynamically assigned circuit.
    On either the router or the end system, you create a routing circuit reachable address entity for the OSI-compliant end system.

DECnet-Plus provides support for the inactive Network layer protocol specified in ISO 8473. The inactive subset bypasses the Network layer, running transport directly over a data link connected to a LAN. You can use this configuration when the source and destination end systems are on the same LAN.

Consider these guidelines before using the inactive Network layer protocol:

• Only one transport module can make use of the inactive subset. By default, this is OSI transport, as specified by the preset routing characteristic inactive selector.
• All end systems using the inactive subset should specify the same inactive area address.

To configure the inactive subset on a circuit, use NCL to set the circuit attribute inactive area address. The area address portion of the NSAP address is placed in this set, as shown in Figure 2-5.

Figure 2-5 Area Address Portion of the NSAP Address

This command configures the inactive subset on circuit-1:

ncl> set routing circuit circuit-1 inactive area address {49::ff-00}

You can assign only one inactive area address to a circuit.

During transmission, when a service data unit (SDU) is passed to an end system's Network layer, transport provides a destination NSAP. If the area address portion of the destination NSAP matches the inactive area address assigned to the circuit, then routing uses the inactive Network layer protocol and passes the SDU directly to the Data Link layer, specifying the ID portion of the destination NSAP as the destination data link address.

If an end system's Network layer receives a protocol data unit (PDU) with the inactive Network layer protocol header on a circuit that has the inactive area address set, then routing passes the SDU up to transport.

In addition, routing calculates the source and destination NSAPs as follows:

• Source NSAP
  Figure 2-6 illustrates a source NSAP.

  Figure 2-6 Source NSAP

  ---

  
• Destination NSAP
  The numerically lowest NSAP in the set of NSAPs assigned to the port for which the SDU is bound.

If an end system's Network layer receives a PDU with an inactive Network layer protocol header on a circuit that does not have the inactive area address set, then the PDU is dropped.

2.3.4 Planning Addressing

When planning your network's addressing scheme, determine the need for unique IDP and DECnet Phase V addresses, which, in turn, depends on the general transition strategy you chose in Step 2.

2.3.4.1 Do You Need a Unique IDP for Your Network?

DECnet-Plus software includes a default IDP, which has the local AFI of 49 and a null IDI. The local AFI and null IDI means that the IDP is intended for use within a private network. Therefore, the local AFI is useful only in a network not connected to any external networks.

As network manager, consider whether the default IDP is sufficient for your network. If you plan to connect your network to other networks, you must obtain a unique IDP. Consider obtaining a unique IDP if there is a possibility that, in the future, you might connect your network to other networks. Otherwise, the default IDP is sufficient.

For information about obtaining a unique IDP for your network, see Section 4.7. If you change your network's IDP, use the decnet_register tool (see your network management guide).

2.3.4.2 Do You Need Extended OSI Addresses?

The general transition strategy you planned in Step 2 determines your decision about the need for OSI addressing that goes beyond Phase IV address limitations:

• If all of your network is moving to the DECnet-Plus environment, you have already decided to use OSI addressing. This strategy requires that routers run the link state protocol. See Section 2.3.4.3 for addressing guidelines.

• If none of your network is moving to the DECnet-Plus environment, then you have already decided to use Phase IV-compatible addressing for all systems. With this strategy, you can use the default IDP that comes with the DECnet-Plus software. In this case, you can ignore the considerations in Section 2.3.4.3 until you are ready to move the network to OSI addressing.
• If part of your network is moving to the DECnet-Plus environment, then you will make address decisions on an area-by-area basis. Whether an area will be a Phase IV or DECnet Phase V area affects the decisions you make as to the area's configuration, addressing, and routing algorithm. See Section 2.3.4.3 for addressing considerations.

A network with one or more DECnet Phase V areas requires well-planned addresses because:

• There are differences between Phase IV and OSI addresses, and communication between Phase IV nodes and DECnet-Plus systems depends on coordinating those addresses (see Section 1.3.1).
• Using extended OSI addresses requires that routers run link state (see Section 2.3.5).

Also use the following guidelines when planning addresses:

• If an area has Phase IV nodes, you must assign Phase IV addresses to all the Phase V routers in the area.
• A network area can use OSI addressing only when all systems are DECnet-Plus systems and all routers run link state or when Phase IV nodes communicate with a small number of DECnet-Plus systems that have Phase IV-compatible addresses.
• For a DECnet-Plus system to communicate with another DECnet-Plus system with an extended address, the path between the systems must be a DECnet-Plus path. A DECnet-Plus path is a routing path on which all routers are running link state.
• In a OSI address, the area address equals the IDP + PreDSP + LOC-AREA fields. Phase IV nodes do not recognize the concept of an IDP. Therefore, they cannot communicate outside of their own network. A Phase IV node cannot connect to any node in another network that has a different IDP, not even another Phase IV node.
• When the network area is ready to use extended OSI addressing, assign these addresses to the Phase V routers, which must be running the link state protocol. Assigning OSI addresses to the Phase V routers makes it possible for end systems in the area to autoconfigure their node addresses.
• If your network has a unique IDP, you must specify that IDP as part of the node address at either of the following times:
  • During the configuration of every router, if you plan that the end nodes will autoconfigure their addresses
  • During the configuration of every system, if you plan that the end nodes will not autoconfigure their addresses

When you plan routing configurations, use the following guidelines:

• Phase V router products can support either the Phase IV routing vector protocol or the DECnet Phase V link state protocol on level 1 and level 2.
• All level 1 routers in an area must run the same routing protocol.
  For example, if one level 1 router runs routing vector which is a DECSA router that cannot migrate to DECnet-Plus, then all routers in the area must run routing vector.
• To use OSI addresses, all level 1 routers must be running link state.
• For end systems to autoconfigure their addresses, all level 1 routers must run link state. Also, during configuration, you must have assigned DECnet Phase V area addresses to the level 1 routers.
• You must have DECnet-Plus routing paths:
  • Among all DECnet-Plus name servers
  • Between each DECnet-Plus system and OSI end system with which it communicates, if they have non-Phase-IV addresses
  • Between two OSI end systems that need to communicate, if they have non-Phase-IV addresses.
• Routers in the level 2 network can run different routing algorithms. To allow for a level 2 router running routing vector to communicate with a level 2 router running link state, the two routers must meet the following requirements:
  • A router running routing vector must be connected directly to a router running link state.
  • A router running link state must have an interphase link entry in its reachable-address table for the router running routing vector.
    See your network management guide for information about interphase routing and how to use the decnet_migrate tool's create ipl_initialization_file command that helps you set up interphase links.
• You can use NCL to set the routing algorithm. For example, the following command sets the routing algorithm to link state on adjacent routing node .ultra.router:

  ncl> set node .ultra.router routing manual L1 algorithm link state algorithm

• When you switch the routing algorithm, for example, in an area where all systems will have OSI addresses, all routers must change algorithms at the same time or you lose connectivity in the area.

For detailed information about DECnet-Plus routing, see the Routing Overview guide in the Phase V router product's documentation set.

2.4 Step 4: Plan for Your Name Services and the DECdts Time Service

The basic planning tasks related to the name services and DECdts are as follows:

• Decide to use the Local namespace, the DECdns distributed namespace, DNS/BIND, or several namespaces to maintain DECnet node name and addressing information. A distributed namespace uses both DECdns clerk and server software.
  Namespace planning for a distributed namespace includes designing the directory structure, planning an access control policy, and deciding on the contents of directories. For more information about planning a distributed namespace, read Chapters 6, 7, 8, 9, and 10.
  Also, if you are considering having multiple namespaces, read Section 2.4.2 and Section 7.1.
• If you choose to use a distributed namespace, plan which nodes become name servers and time servers.
  If your network uses a distributed namespace, every DECnet-Plus system in the network is a DECdns clerk and a DECdts clerk, but not every system should be a name server or a time server. Select your servers carefully based on the guidelines in Section 2.4.1.

You do not need to install a DECdns server if you use a Local namespace on all DECnet-Plus systems. All references to DECdns servers apply to those servers running on DIGITAL UNIX or OpenVMS VAX systems. You need to configure one or more DECdns server systems if you intend to use a distributed namespace on one node or selected nodes. Use the following guidelines when choosing which DECnet-Plus systems will be DECdns and DECdts servers:

• Overall, DIGITAL recommends you choose more time servers than name servers; therefore, the name server nodes can be a subset of the time server nodes. Two name servers and two time servers for every 1,000 nodes are usually sufficient. See your installation and configuration guides for detailed server configuration guidelines in both LAN and WAN environments.
• A DECdns server and a DECdts server must maintain at least one Phase IV-compatible address until no Phase IV nodes exist on the network that need to communicate with these servers. Lack of Phase IV-compatible addresses prevent the servers from communicating with Phase IV nodes.
• DECdns servers must have the NSP transport protocol enabled and should have the OSI transport protocol enabled. For DECnet Phase V networks using a distributed namespace, every system is a DECdns clerk and systems running either protocol must be able to communicate with any name server. If DECdns servers already exist on Phase IV systems, this requirement also ensures that they can talk to your DECnet-Plus DECdns servers in the network.

DIGITAL recommends that you avoid using multiple namespaces. However, if your organization or network has special requirements that justify the use of multiple namespaces, you can create them and they can coexist without harm. See the DECnet-Plus DECdns Management guide for details about the implications of using multiple namespaces.

When multiple namespaces do exist in a network, they are separate and do not share information. You cannot replicate data across namespaces. Users can refer to a name in a namespace other than their own by including the namespace nickname in the full name reference.

If you want namespaces to interoperate, one trade-off is increased administrative overhead to keep track of and maintain entries in each namespace.

• Using multiple namespaces greatly increases the complexity of managing node object entries and soft links.
• Setting up access control to allow users to read entries in both namespaces is also complicated.

The easiest way to avoid the complexity is to limit node object entries and soft links to a single namespace, and use other namespaces for other purposes, such as testing, or building and using client applications.

If you need multiple namespaces in your network, and you want more than one namespace to contain node object entries and soft links, take the following steps after you install and configure new DECnet-Plus systems to ensure that they can communicate across namespaces:

• Decide which nodes each namespace will contain. Ensure that each node is registered in one, and only one, namespace.
• Create the namespaces you have planned. DECdns namespace creation involves configuring at least one server in each namespace.
• Run decnet_register once in each DECdns namespace to create the required DECnet-Plus directories. For instructions on running decnet_register, see your network management guide.
• Use the decnet_register export command to extract the node information from the Phase IV database. Edit the Export/Import file to correctly format the node information for the namespace you intend to use on the node. See your network management guide for more information.
• Use the decnet_register import command on each node to import the edited node information contained in the Export/Import file into the namespace on the node.
• Inform users that they must include a namespace nickname in a node full name when they refer to a node in a namespace other than their own.
• You can also create a soft link in your namespace for each node in another namespace. You can create this soft link in any directory that you consider appropriate.

  
  For example, a user in the IAF namespace could create a synonym soft link named IAF:.sample.Node01 that points to a node whose full name is ABC:.sales.Node01 in the ABC namespace. Then, users in the IAF namespace could refer to the node by the name Node01 and DECnet-Plus would translate the soft link to the node's full name. Make sure you establish adequate cross-namespace access control entries. Keep in mind that cross-namespace node synonym soft links must be manually updated if there is a change in the name of the node.