HP OpenVMS Systems Documentation

ncl> create routing circuit hdlc-0 -
_ncl> reachable address reachable-address - (1)
_ncl> address prefix address-prefix (2)

ncl> set routing circuit hdlc-0 -
_ncl> dte addresses dte-addresses

ncl> enable routing circuit hdlc-0 -
_ncl> reachable address

1. If you configure a dynamic assigned X.25 routing circuit, you must configure one or more reachable addresses to be used to manage the circuit. Each reachable address specifies a mapping of an NSAP address to a DTE address.
2. Specify the address prefix when you create the entity. You cannot modify this characteristic with the set command.

ncl> create x25 access template template-name (1)

ncl> set x25 access template template-name -
_ncl> destination dte address dte-address, -
_ncl> dte class dte-class-name

1. A routing circuit that invokes outbound X.25 calls uses an X25 Access template to supply most of the parameters for setting up the call. A routing circuit that receives inbound X.25 calls uses an X25 Access template to negotiate call parameters.
   Each X.25 routing circuit that you configure names an X25 Access template in its template characteristic. You must therefore configure each of the X25 Access templates named in your X.25 routing circuits.

ncl> create x25 access filter filter-name (1)

ncl> set x25 access filter filter-name -
_ncl> inbound dte class dte-class-name,  -
_ncl> sending dte address dte-address

ncl> enable x25 access filter

1. A routing circuit that receives inbound X.25 calls requires one or more X25 Access filters. An X25 Access filter listens for incoming calls and passes them to the appropriate destination.
   Each X.25 static-incoming or X.25 dynamic-assigned routing circuit that you configure specifies the name of one or more X25 Access filters in its filter characteristic. You must, therefore, configure the specified X25 Access filters.
   When setting up a filter for use with an x.25 static incoming or x.25 da circuits, specify the following X25 Access filter values:
   • call data mask %xff
   • call data value %x81

If you need communication between a VOTS system and an OSI transport system using the full Internet CLNS protocol, you must use an intermediate system (router). OSI transport implements only the Internet protocol. An OSI Transport system has 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 the previous section).

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.

B.4 Manually Configuring OSI Transport Network Applications

This section describes how to configure applications to receive connection requests from remote hosts. One of the attributes of a transport connection request is a transport service access point identifier (TSAP-ID), which uniquely identifies the transport application on the remote host to which the connection request is to be passed.

An application that expects to receive a connection request must therefore associate itself with a particular TSAP-ID, so the transport service knows which application a particular connection request is intended for.

There are two ways in which an application can associate itself with a TSAP-ID: active association or passive association.

Active association is entirely under the control of the transport user, and requires no support from you. Passive association, on the other hand, requires that you configure the osi transport application entities that describe the association between TSAP-IDs and applications.

In active association, the transport application issues a $qio(io$_acpcontrol) system service call in which it requests an association with a specified TSAP-ID. When a connection request arrives with that TSAP-ID, a mailbox message containing details of the connection request is sent to the associated application, which can then process the request, either accepting or rejecting it.

OSI transport dynamically creates the osi transport port entity so that the active association is available by means of network management.

In passive association, you create a osi transport application entity, whose characteristics specify:

• A TSAP-ID.
• The name of an image or command file.
• The user name of an account under which the image or command file is to run.

When a connection request arrives with a TSAP-ID that is associated with a osi transport application entity, the transport service creates a new process in which it runs loginout.exe. loginout.exe validates any access control information and invokes DCL to execute the image or command file associated with that TSAP-ID. Details of the connection request are passed in the logical name sys$net.

The following command example shows the commands to configure an osi transport application entity. For the variables, substitute values appropriate to your configuration. DIGITAL, however, recommends that you accept the default settings (used in the example) for the various attributes and change these only if you need to. Refer to the DECnet-Plus Network Control Language Reference for more information about these attributes.

ncl> create osi transport
ncl> enable osi transport

ncl> create osi transport application application-name

ncl> set osi transport application application-name -
_ncl> called tsels set-of-hex-string, - (1)
_ncl> file name file-spec, user name user-account (2)

ncl> enable osi transport application

1. called tsels specifies the set of TSAP-IDs with which this entity is to be associated.
2. file name specifies the name of the command or image file to be executed when a connection request is received with a TSAP-ID that matches one of the values of the called tsels characteristic.
   user name specifies the user account under which the application is to run.

The network service access points (NSAP) selector determines which transport service is used by a network connection. The default NSAP selector for DIGITAL's OSI transport implementations is 33 (decimal). Other vendors might use different NSAP selectors and might require that the NSAP selectors match.

You can only change the NSAP selector for OSI transport when OSI transport is disabled. Valid NSAP selectors are in the range from 2 to 255, with the exception of 32. In order to maintain interoperability between DNA Phase IV and DECnet-Plus, you cannot use NSP's NSAP selector, 32.

The command to change the NSAP selector for OSI transport is:

ncl> disable osi transport
ncl> set osi transport nsap selector new_selector_number

ncl> enable osi transport

OSI transport can recognize the unavailability of a remote node during connection establishment using CLNS (Routing) error reports.

This feature is disabled for all templates (used by DNA Session Control), but you can enable it by editing the OSI transport NCL initialization script, sys$manager:net$osi_transport_startup.ncl, and using the following command to set the default to true:

ncl> set osi transport template default use clns error reports = true

DECnet-Plus for OpenVMS allows you to run DNA and OSI applications over an IP network backbone. Applications include those supplied by DIGITAL, third-party applications, and user-written applications.

RFC 1006 and RFC 1859 (formerly known as RFC 1006 Extension) are standards of the Internet community. RFC 1006 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.

RFC 1859 defines how to implement ISO 8073 Transport Class 2 Non-use of Explicit Flow Control on top of TCP. Hosts that implement RFC 1859 are expected to listen on TCP port 399.

The DECnet over TCP/IP feature (RFC 1859) allows traditional DECnet applications (such as MAIL, CTERM, and FAL) to accept IP names and addresses. The OSI applications over TCP/IP feature (RFC 1006) allows OSI applications (such as FTAM and VT) to accept IP names and addresses.

B.5.1 Configuring RFC 1006 and/or RFC 1859

If you want to use DECnet over TCP/IP and/or OSI applications over TCP/IP, invoke net$configure.com with the ADVANCED option, and select Option 4 ("Configure Transports") to configure (or reconfigure) the OSI transport. You can then create a new OSI transport NCL script (or replace the old script). You must also include Domain in your Session Control naming search path by selecting Option 2 to rename your node using a Domain secondary node name. This is described in Section 2.2.

For the changes to take effect, either disable the OSI transport entity (if it exists) 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, each element in the set of RFC 1006 listener ports attribute corresponds to a TCP listener port. By default, net$configure sets the OSI transport RFC 1006 listener ports attribute to { 102, 399 }. Port 102 is required for RFC 1006, and port 399 is required for RFC 1859.

B.5.2 Creating Additional OSI Transport Templates for RFC 1006 and RFC 1859

To create RFC 1006 or RFC 1859 templates in addition to the default templates, use Option 4 under the ADVANCED configuration option. When the net$configure.com procedure asks you if you want to create additional OSI templates, answer yes. Then select RFC 1006 as the network service.

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

B.5.3 Disabling DECnet-Plus over TCP/IP

DECnet-Plus only attempts to locate TCP/IP if the RFC 1006 listener ports attribute set of the OSI transport entity is not empty.

To disable RFC 1006 and RFC 1859, issue the following command:

ncl> set osi transport rfc1006 listener ports {}