HP OpenVMS Systems Documentation

By default, DECnet-Plus automatically configures OSI transport to use the Connectionless-Mode Network Service (CLNS). CLNS is a network service that operates according to a datagram model. Each message is routed and delivered to its destination independently of any other. When using CLNS, only transport protocol class TP4 is available in the default configuration.

8.5.2.4.1 Establishing Outbound Connections Using CLNS

To establish an outbound transport connection that uses CLNS as its network service, an application makes a connection request specifying the following:

• The OSI transport address of the destination host.
• The TSAP-ID of the responding application. A TSAP-ID identifies a transport service access point (TSAP). A TSAP is a unique identifier for a single transport user.
• Optionally, other transport connection parameters.

The OSI transport address consists of:

• The name of the OSI transport template for CLNS connections to be used in setting up the transport connection. The specified OSI transport template for CLNS connections must have its network service attribute set to clns.
• An address that uniquely identifies the destination host. The address can be:
  • An NSAP (for a transport connection using CLNS/ES-IS)
  • A LAN address (for a transport connection using CLNS with null internet)

The Routing module selects a routing circuit to be used for the underlying network connection; the basis for this selection is the area address part of the NSAP address.

8.5.2.4.2 Establishing Inbound Connections Using CLNS

To establish an inbound transport connection that uses CLNS:

1. The Routing module passes an incoming transport connection to OSI transport.
   OSI transport must have an OSI transport template for CLNS connections with its inbound attribute set to true. If the transport connection uses null internet, the OSI transport template for CLNS connections must also have its clns inactive area address attribute set to the same area address as the inactive area address attribute of the routing circuit on which the transport connection arrived.
2. If a suitable OSI transport template for CLNS connections is found, an application is found to process the connection. The application can either accept or reject the connection.
3. If the application accepts the connection, the OSI transport template for CLNS connections is used to accept the connection.

A CLNS OSI transport template is configured to use either the CLNS/ES-IS or null internet routing protocol. To configure null internet OSI transport templates, you must configure one outbound-inbound OSI transport template for each inactive area address used.

A CLNS OSI transport template can specify use of the null internet routing protocol (inactive subset of CLNS). The null internet protocol only operates over LAN routing circuits. A CLNS OSI transport template for use with the null internet routing protocol can only use one routing circuit; routing circuit selection is based on its inactive area address.

The Routing module selects a routing circuit to be used for the underlying network connection; the basis for this selection is the area address part of the NSAP address.

8.5.2.4.4 Steps for Configuring the Connectionless-Mode Network Service

The following steps show the commands to configure CLNS. The attributes added or set up for OSI transport in this example are relevant to CLNS. In addition, consider setting some of the more general attributes shown in Section 8.5.2.2.

For the variables, substitute values appropriate to your configuration. DIGITAL recommends that you accept the default settings (used in the example) for the various attributes. Change them only if you need to. Refer to the DECnet-Plus Network Control Language Reference guide for more information about these attributes.

1. The following example creates the OSI Transport module and enables it:

   ncl> create osi transport ncl> set osi transport nsap selector 33 (1) ncl> enable osi transport

   1. nsap selector is used for transport connections using CLNS/ES-IS.
2. The following example shows how to create the OSI transport template and set its attributes:

   ncl> create osi transport template template-name (1) ncl> set osi transport template template-name - _ncl> acknowledgment delay time 1, - _ncl> checksums false, classes {4}, - (2) _ncl> inbound true, initial retransmit time 15, keepalive time 60, - (3) _ncl> loopback false, network service clns, retransmit threshold 8, - (4) _ncl> security empty, use clns error reports false ncl> enable osi transport template

   1. OSI transport templates are used by OSI transport to supply connection parameters not provided by the requesting OSI transport application.
      An OSI transport template name must contain only alphanumeric characters, underscores (_), hyphens (-), or dollar ($) signs. OSI transport template names should not be more than 16 characters long.
      You can configure two types of OSI transport templates for CLNS connections:
      • For outbound transport connections only
        You can configure as many outbound OSI transport templates for CLNS connections as you want.
      • For both outbound and inbound transport connections
        A CLNS OSI transport template is configured to use either the CLNS/ES-IS or null internet routing protocol.
        If you configure null internet OSI transport templates, you must configure one outbound-inbound OSI transport template for each inactive area address used.
   2. Including checksums reduces data throughput, so you should use checksums only if you have reason to believe that data will be corrupted by the network.
      On OpenVMS systems, you can specify a value for the clns inactive area address attribute.
   3. The inbound true statement is valid only for OpenVMS systems.
      The default initial retransmit time value should be suitable for most networks. It is set to a relatively high value because a transport connection request TPDU usually has a longer round-trip delay than a data TPDU. Consider increasing the value if transport connection requests frequently time out.
   4. The default value for retransmit threshold should be suitable for most networks. However, consider increasing the value for networks with a high probability of losing data.
3. Set up routing and routing circuits for end systems using the Connectionless-Mode network service by following the steps outlined in Section 8.4.2.
4. If you set up one or more X.25 dynamically-assigned routing circuits, configure routing to use the X.25 circuit, as explained in Section 8.8.3.2.

For communication between DECnet-Plus and VOTS using the full Internet CLNS protocol, DECnet-Plus systems must use an intermediate system (router). DECnet-Plus systems have no way of finding another end system that does not support ES-IS without using an intermediate system.

If a DEC WANrouter is used as an intermediate system, it must be configured as a link state router (see Section 8.5.2.4.4).

If the VOTS system and the DEC WANrouter reside on the same LAN subnetwork and the VOTS system is configured with a DNA-compatible NSAP address, the DEC WANrouter need only be configured as a level 1 router.

If the VOTS system does not have a DNA-compatible NSAP address, or if the VOTS system and the DEC WANrouter do not reside on the same LAN subnetwork, the DEC WANrouter must be configured as a level 2 router.

When using a level 1 router, you must create a manual adjacency on the router for the VOTS system. When using a level 2 router, you must create a reachable address on the router for the VOTS system. See the DEC WANrouter configuration and management guides for details about how to configure manual adjacencies and reachable addresses.

OSI transport systems and VOTS systems on the same LAN can communicate without an intermediate system, using the null internet CLNS protocol.

8.5.2.5 Configuring OSI Transport to Use RFC 1006 or RFC 1859

You can configure OSI transport on your OpenVMS system to use RFC 1006, allowing use of OSI applications over TCP/IP, and to use RFC 1859, allowing use of DECnet applications over TCP/IP. For details, see Section 8.5.3.

8.5.2.6 Testing OSI Transport

After configuring OSI transport on an OpenVMS system, you can use the [SYS$TEST]OSIT$IVP OSI transport installation verification procedure to verify correct operation.

This procedure (the test initiator) communicates with the passive OSI transport application OSIT$IVP which invokes OSIT$IVPRESP.COM(the test responder) on the target system. The target system may be either your system or some other system running DECnet-Plus for OpenVMS. (Start the initiator by executing the SYS$TEST:OSIT$IVPINIT.COM file.)

You must supply the VOTS-address of the target system. A VOTS-address has the form template%network address, where:

• template is the name of an osi transport templateentity.
• network address depends on the network service specified by the template, as described in Table 8-7.

You can list the OSI transport NSAPs for a system using the following command:

ncl> show osi transport local nsap *

As an alternative to specifying a VOTS-address explicitly, you can specify a logical name defined in the table OSIT$NAMES.

8.5.2.7 Possible Connection Failure to Non-Conformant Systems Using OSI Transport

By default, DIGITAL's OSI transport sends the preferred maximum tpdu size, request acknowledgment, and implementation idparameters in its CR TPDU (connect request transport protocol data unit).

According to ISO 8073, OSI transport providers should ignore unknown parameters while processing a CR TPDU. However, some vendor implementations do not conform to ISO 8073. Therefore, their OSI transport does not ignore unknown parameters in a CR TPDU. This nonconformance results in a connection failure when unknown parameters are detected (such as the three parameters sent by DIGITAL's OSI transport). The following example provides a way to prevent issuance of these unknown parameters in a CR TPDU:

NCL> set osi transport template template-id -
_NCL> send preferred maximum tpdu size false

NCL> set osi transport template template-id -
_NCL> send request acknowledgment false

NCL> set osi transport template template-id -
_NCL> send implementation id false

One feature of OSI transport is the ability to use the Congestion Experienced field in the Connectionless-Mode Network Service (CLNS) routing header, and to implement a congestion avoidance scheme in heavily congested networks. The CLNS Congestion Experienced field is used by routers that support this feature (such as DECNIS) to give an early indication of congestion. When OSI transport receives data that passed through a network path where the Congestion Experienced bit is set, OSI transport reduces the transmit rate of the sending end system to help alleviate network congestion.

This feature works well in networks where all protocols support congestion avoidance mechanisms. However, in heavily congested multiprotocol networks that include network protocols that do not support the congestion avoidance mechanism, the performance of DECnet can be impaired. DIGITAL recognizes that most of its customers have multiprotocol networks and that not all network protocols have congestion avoidance mechanisms. Therefore, DIGITAL has set the default for this attribute to be disabled.

If you operate in an environment where you can take advantage of congestion avoidance mechanisms, enable this feature.

To change transport congestion avoidance values, invoke NET$CONFIGURE ADVANCED and use Option 4 (Configure Transports). Answer no to the following question:

Is this System operating in a Multi-Protocol Network? [YES] :.

DIGITAL remains committed to providing customers with more networking choices. In this commitment to providing a multiprotocol networking environment, DIGITAL has enabled DECnet-Plus to allow OSI and DECnet applications to run over an IP network backbone. The OSI over TCP/IP (using RFC 1006) software enables OSI applications such as FTAM, Virtual Terminal, and X.400 to run over TCP/IP. The DECnet over TCP/IP (using RFC 1859) feature allows traditional DECnet applications to run over TCP/IP. Examples of traditional DECnet applications are mail, cterm, and fal.

With RFC 1006 and RFC 1859, OSI and DECnet applications can accept IP names and addresses. These names and addresses are translated by BIND servers. The DECnet and OSI applications include those supplied by DIGITAL, third-party applications, and user-written applications.

RFC 1006 is a standard of the Internet community. It defines how to implement ISO 8073 Class 0 on top of TCP. Hosts that implement RFC 1006 are expected to listen on TCP port 102.

DECnet over TCP/IP uses RFC 1859, which defines how to implement ISO 8073, Transport Class 2 Non-Use of Explicit Flow Control on Top of TCP (RFC 1006 Extension). Hosts that implement RFC 1859 are required to listen on well known TCP port 399.

Use DECnet over TCP/IP if you need to:

• Link DECnet nodes using TCP/IP
• Join two existing DECnet networks without renumbering
• Run IP-only traffic in part of the backbone and continue using DECnet applications and user interfaces without extra costs and retraining.

When running DECnet over TCP/IP, you can use an IP host name such as in the following command examples. For more information on making connections using DECnet over TCP/IP, see Section 8.5.3.1.

$ set host remotehst6.acme.com

Both the source and target nodes must support DECnet over TCP/IP for this connection to work. You can configure your system to allow use of synonyms (Phase IV style names) instead of the IP host full name. The explicit use of IP addresses on a command line is not supported.

8.5.3.1 Examples Establishing Network Connections Using DECnet over TCP/IP

The following examples show how you can use DECnet over TCP/IP to connect to any of the remote hosts on the network shown in Figure 8-7, a multiprotocol network that includes OpenVMS and DIGITAL UNIX systems and a PC system.

1. Node green is a DECnet Phase IV OpenVMS node. Node blue is a DECnet-Plus DIGITAL UNIX node. To connect to node green from node blue, issue this command on node blue:

   # dlogin green

2. Node orange is a DECnet-Plus for OpenVMS node. To connect to node green from node orange, issue this command on node orange:

   $ set host green

3. Both node blue and node orange are DECnet-Plus nodes. To connect to node orange from node blue (DIGITAL UNIX), issue this command on node blue:

   # dlogin orange.toronto.acme.com

4. To connect to node blue from node orange (OpenVMS), issue this command on node orange:

   $ set host orange.toronto.acme.com

5. Node red is a TCP/IP node only. To connect to node red from node orange (OpenVMS), issue this command on node orange:

   $ set host/telnet red.toronto.acme.com

   
   As an alternative, you can use this command:

   $ set host/rlogin red.toronto.acme.com

6. To connect to node red from node blue (DIGITAL UNIX), issue this command on node blue:

   # telnet red.toronto.acme.com

   
   As an alternative, you can use this command:

   # rlogin red.toronto.acme.com

Figure 8-7 Sample Multiprotocol Network

8.5.3.2 Configuring DECnet over TCP/IP (RFC 1859) and OSI over TCP/IP (RFC 1006)

The PWIP interface is currently supported in the products listed below. Contact the vendor for the required versions of their product.

• DIGITAL TCP/IP Services for OpenVMS
  DECdirect
  P.O. Box CS2008
  Nashua, NH 03061
  800-282-6672
  www2.service.digital.com/decdirect/index/html
• TCPware
  Process Software Corporation
  959 Concord Street
  Framingham, MA 01701
  800-722-7770
  info@process.com
• MultiNet for OpenVMS
  Cisco Systems, Inc. (formerly TGV, Inc.)
  Internet Business Unit
  101 Cooper Street
  Santa Cruz, CA 95060
  408-457-5200
  sales@tgv.cisco.com
• PathWay for OpenVMS
  PathWay for OpenVMS
  The Attachmate Corp. (formerly the Wollongong Group, Inc.)
  1129 San Antonio Road
  Palo Alto, California 94303
  800-872-8649 (800-962-8649 in CA)
  sales@twg.com

When DECnet over TCP/IP has successfully completed a listen on the defined rfc1006 listener ports, you will see the following OPCOM message in the OPERATOR.LOG file for each TCP Listen Port:

%%%%%%%%%%%  OPCOM  30-MAR-1995 11:25:46.74  %%%%%%%%%%%
Message from user TPCONS on YPP4
-- TPCONS: Listen to PWIP Done

To configure your system so you can use DECnet over TCP/IP or OSI applications over TCP/IP, use Option 4 of the advanced configuration procedure (NET$CONFIGURE.COM ADVANCED), as explained in DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration. You can then create a new OSI transport NCL script (or replace an old script). You must also include Domain in your session control naming search path as described in Section 5.1.1.

Use Option 4 as well for creating templates in addition to the default RFC 1006 template.

You must rename your node using a Domain secondary node name. Use Option 2 of the advanced configuration procedure to do this.

For the changes to take effect, either disable the osi transportentity and invoke the new OSI transport NCL script, or reboot the system.

ncl> disable osi transport
ncl> do sys$manager:net$osi_transport_startup.ncl

When configuring RFC 1006, RFC 1859, or both on OpenVMS systems, each element in the set of rfc1006 listener portsattribute corresponds to a TCP listener port. By default, NET$CONFIGURE sets the osi transport rfc1006 listener portsattribute to { 102, 399 }.

The rfc1006 port numberattribute of the osi transport templatesubentity must contain a TCP port number that is one of the chosen rfc1006 listener ports. The default value for the rfc1006 port number attribute is 102. If you create an osi transport templatesubentity to use with DECnet over TCP/IP (using RFC 1859), then set the rfc1006 port numberattribute to 399.