![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The following steps show how to use NCL commands to configure OSI transport to support CONS. You can configure OSI transport to use X.25 CONS by using the NET$CONFIGURE ADVANCED, X25$CONFIGURE, as well as NCL. For information on this, see Sections 8.8.2.2 and 8.8.2.3.
The attributes added or set up for OSI transport in the following examples are relevant to CONS. For the variables, substitute values appropriate to your configuration.
ncl> create osi transport
ncl> add osi transport cons filters {filter-name}
ncl> set osi transport disconnect holdback 0, -
_ncl> maximum multiplexing 65535, maximum network connections 65535
ncl> enable osi transport
ncl> create osi transport template template-name ncl> set osi transport template template-name - _ncl> acknowledgment delay time 1, - _ncl> checksums false, classes {0,2}, - _ncl> cons template osi transport, cr timeout 30, er timeout 30, - _ncl> inbound true, initial retransmit time 15, loopback false, - _ncl> keepalive time 60, maximum nsdu size 2048, - _ncl> network service cons, retransmit threshold 8 ncl> enable osi transport template template-name
For more information on configuring OSI transport and CONS on OpenVMS systems, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration guide.
Note
If you have not configured OSI transport to use the Connection-Oriented Network Services (which requires the X.25 for OpenVMS product), attempting to use CONS-specific attributes, including cons nsap addressesand cons filters fails with various NCL error messages.You can configure a reachable address to convert OSI NSAPs to DTE addresses, or you can force OSI applications to use DTE addresses instead of NSAPs.
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.
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 consists of:
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.
To establish an inbound transport connection that uses CLNS:
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.
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.
ncl> create osi transport
ncl> set osi transport nsap selector 33
ncl> enable osi transport
ncl> create osi transport template template-name ncl> set osi transport template template-name - _ncl> acknowledgment delay time 1, - _ncl> checksums false, classes {4}, - _ncl> inbound true, initial retransmit time 15, keepalive time 60, - _ncl> loopback false, network service clns, retransmit threshold 8, - _ncl> security empty, use clns error reports false ncl> enable osi transport template
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.
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.
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:
| Network Service Specified by Template | Format of Network Address | Example of Network Address |
|---|---|---|
| CONS | X.25 DTE address | 234273412345 |
| CLNS (Null internet) | LAN address | AA00040001FC |
| CLNS (Internet/ES-IS) | NSAP | 49004008002B56870121 |
| RFC1006 | IP address | 16.20.136.9 or acme.wolf.phil.com |
You can list the OSI transport NSAPs for a system using the following command:
ncl> show osi transport local nsap *
Note
Do not supply a CONS NSAP address to the OSIT$IVP program. If you do, the verification procedure will fail.
As an alternative to specifying a VOTS-address explicitly, you can specify a logical name defined in the table OSIT$NAMES.
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:
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.
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.
# dlogin green
$ set host green
# dlogin orange.toronto.acme.com
$ set host orange.toronto.acme.com
$ set host/telnet red.toronto.acme.com
$ set host/rlogin red.toronto.acme.com
# telnet red.toronto.acme.com
# rlogin red.toronto.acme.com
Figure 8-7 Sample Multiprotocol Network
PROFILE_VMS_011.HTML OSSG Documentation 2-DEC-1996 12:35:03.79
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.