HP OpenVMS Systems Documentation

Content starts here

DECnet-Plus for OpenVMS
Network Management


Previous Contents Index

8.5 Managing Transport Services

DECnet Phase V nodes support multiple transport protocols. DECnet Phase IV nodes have Network Services Protocol (NSP) as the only transport protocol available. DECnet Phase V nodes have NSP and OSI transport available. DECnet Phase V automatically determines a compatible transport protocol between communicating nodes.

OSI transport on DECnet Phase V systems supports the Connection-Oriented Transport Protocol specification (International Standard ISO 8073) and the Connectionless-Mode Transport Protocol specification (International Standard ISO 8602). The OSI transport can use two types of network services:

  • The Connection-Oriented Network Service (CONS)
  • The Connectionless-Mode Network Service (CLNS)

On OpenVMS systems, the OSI transport implements the RFC 1006 and RFC 1859 specifications, using TCP network services.

The Routing module supports CLNS. The X25 Access module supports CONS.

DECnet-Plus automatically starts with both OSI transport and NSP. If, for any reason, you want to disable either transport protocol, use disable nsp or disable osi transport.

If you do not want session control to use a particular protocol, use one of the following commands:


ncl> delete session control transport service osi


ncl> delete session control transport service nsp

This section explains how to configure and manage:

  • NSP
  • OSI transport protocol
  • DECnet over TCP/IP
  • OSI over TCP/IP

8.5.1 Configuring NSP

This section explains how to configure the Network Services Protocol (NSP). The following example shows the commands to create the nsp entity on your system. DIGITAL 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. Figure 8-5 shows the nsp entity and its subentities.

Figure 8-5 nsp Entity



ncl> create nsp

ncl> set nsp delay factor 2, delay weight 3, - (1)
_ncl> maximum remote nsaps 200, maximum transport connections 200, - (2)
_ncl> maximum window 20, nsap selector 32, - (3)
_ncl> retransmit threshold 5
ncl> enable nsp
  1. The effect of delay factor is to increase the retransmission time by increasing the average round-trip delay time, thus allowing for additional network delay.
    The value of the weighting factor is given by the delay weight attribute. Basically, delay weight determines how quickly the retransmission timer responds to variations in actual round-trip delay times. A low value of delay weight means that the retransmission timer responds quickly to each sample of round-trip delay time; a delay weight of 0 means that an estimate will be nearly the same as the last actual sample of round-trip delay. A high value for delay weight will reduce the impact of recent variations in network delay; the higher the value, the closer each estimate of round-trip delay will be to the average of all estimates.
    The default values of delay factor and delay weight should be suitable for most networks. However, consider increasing these values if wide variations in round-trip delay times exist on your network.
  2. You can save memory resources by reducing the value of maximum remote nsaps. However, you will not have access to the information provided by this entity's counters and status attributes (except through information in event logs). The maximum remote nsaps value must be greater than the value of maximum transport connection.
  3. The NSP Transport receiver's window is controlled by a combination of the maximum transport connections, maximum receive buffers, and the maximum window attributes. The receiver initial quota is determined by dividing the value of maximum receive buffers by the value of maximum transport connections. During the life of the connection, the receiver quota fluctuates, using the value of maximum receive buffers divided by the value of currently active connections. The credit window sent to the remote transmitter may be this quota value, depending on the value of the maximum window attribute. If the value of maximum windowis less than the determined receiver quota, the value of the maximum window is used instead for the credit granted to the remote transmitter.
    The transmitter on an NSP Transport connection uses the credit sent by the remote receiver as its transmit window, unless the value of maximum windowis lower than this value. In that case, the value of maximum windowis used for the transmitter window.
    By controlling the transmitter and receiver windows in this way, a dynamic balance of system resource consumption and network performance can be achieved and maintained.

For some NSP attributes, such as maximum remote nsaps or maximum transport connections, you can raise values at any time, but you cannot lower the value without first disabling NSP.

The following is an example of how to set up NSP:


ncl> create nsp
ncl> set nsp maximum window 8
ncl> set nsp maximum transport connections 200
ncl> enable nsp
ncl> create session control transport service nsp protocol %x04

8.5.2 Configuring and Managing OSI Transport

This section explains how to:

  • Define osi transport entity templates
  • Configure OSI transport to use the Connection-Oriented Network Service (CONS)
  • Configure OSI transport to use the Connectionless-Mode Network Service (CLNS)
  • Configure OSI transport to use RFC 1006 or RFC 1859
  • Test OSI transport
  • Avoid OSI transport connection failures involving systems that do not conform to ISO 8073
  • Avoid congestion in multiprotocol networks

Figure 8-6 shows the osi transport entity and its subentities.

Figure 8-6 osi transport Entity


8.5.2.1 Defining OSI Transport Templates

When DECnet-Plus is configured, templates are set up for the OSI Transport module. Each template is an NCL database entry that manages network access. Each template includes a group of attributes that supply default values for certain parameters that influence the operation of a port on a transport connection. The templates store information and also may reference information located elsewhere.

Each OSI transport template corresponds to a specific type of network service to which OSI transport can direct outbound messages and from which it can receive inbound messages.

OSI transport supports three network services:

  • Connectionless-Mode Network Service (CLNS)
  • Connection-Oriented Network Service (CONS)
  • Null internet (inactive subset of CLNP, the Connectionless Network Protocol)

On OpenVMS systems, OSI transport supports RFC 1006 as a service and template.

Table 8-6 describes the templates that are set up for OSI transport on your system. Note that the null internet does not require a template.

Table 8-6 Templates Set Up for OSI Transport on OpenVMS Systems
Name Network Service Classes
Default CLNS 4
OSIT$LOOP_CONS CONS 0, 2, 4
OSIT$LOOP_CLNS CLNS 4
OSIT$RFC1006 RFC1006 0
OSIT$RFC1006PLUS RFC1859 2

Do not modify listed attributes of the default template. The other templates are defined in the NCL initialization script SYS$MANAGER:NET$OSI_TRANSPORT_STARTUP.NCL.

8.5.2.2 Commands for Configuring General OSI Transport Attributes

The following example shows the nclcommands you can use to create the osi transport entity on your system, setting attributes applicable to all types of services. Section 8.5.2.3 gives examples of commands required to configure CONS support. DIGITAL recommends that you accept the default settings used in the examples for the attributes. Change them only if necessary. For more information on these attributes, refer to the DECnet-Plus Network Control Language Reference.


ncl> create osi transport
ncl> set osi transport delay factor 4, delay weight 5,- (1)
_ncl> maximum remote nsaps 64, - (2)
_ncl> maximum transport connections 33, maximum window 20 (3)

ncl> enable osi transport
  1. The effect of delay factor is to increase the retransmission time by increasing the average round-trip delay time, thus allowing for additional network delay.
    The value of the weighting factor is given by the delay weight attribute. Basically, delay weight determines how quickly the retransmission timer responds to variations in actual round-trip delay times. A low value of delay weight means that the retransmission timer responds very quickly to each sample of round-trip delay time; a delay weight of 0 means that an estimate will be nearly the same as the last actual sample of round-trip delay. A high value for delay weight will reduce the impact of recent variations in network delay; the higher the value, the closer each estimate of round-trip delay will be to the average of all estimates.
    The default values of delay factor and delay weight should be suitable for most networks. However, consider increasing their value if wide variations in round-trip delay times exist on your network.
    For a complete discussion of delay factor and delay weight and how to calculate round-trip delay, refer to Appendix C.
  2. You can save memory resources by reducing the value of maximum remote nsaps. However, you will not have access to the information provided by this entity's counters and status attributes (except through information in event logs). The maximum remote nsaps cannot be lower than the maximum transport connections. In addition, the osi transport entity does not support a value of zero (0) for the maximum remote nsaps attribute.
  3. The OSI transport receiver and transmitter windows are controlled by a combination of the maximum transport connections, maximum receive buffers, and the maximum window attributes. The OSI transport implements several algorithms that help achieve and maintain a dynamic balance of system resource consumption and network performance. You can control this balance by altering the defaults for these attributes.
    The OSI transport determines the receiver initial quota by dividing the value of maximum receive buffers by the value of maximum transport connections. During the life of the connection, the receiver quota fluctuates, using the value of maximum receive buffers divided by the value of currently active connections. The credit window sent to the remote transmitter may be this quota value, depending on the value of the maximum window attribute. If the value of maximum windowis less than the determined receiver quota, the value of the maximum window is used instead for the credit granted to the remote transmitter.
    The transmitter on an OSI transport connection uses the credit sent by the remote receiver as its transmit window, unless the value of maximum windowis lower than this value. In that case, the value of maximum windowis used for the transmitter window.

On OpenVMS systems, disable the osi transport entity before modifying attributes that affect operation.

8.5.2.3 Configuring OSI Transport to Use CONS

To configure CONS support on OpenVMS systems, each element in the set of the cons filters attribute of the osi transport entity must have a corresponding X25 Access filter of the same name. By default, the cons filters attribute of the osi transport entity is set to osi transport.

Similarly, the cons template attribute of the osi transport templatesubentity must contain a name that is an X25 Access filter and is contained in the set of cons filters of the OSI Transportentity. The default value of the cons template attribute of an osi transport templatesubentity is osi transport.

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.

  1. The following example shows how to create the OSI Transport module, set its attributes, and enable it:


    ncl> create osi transport
    
    ncl> add osi transport cons filters {filter-name} (1)
    
    ncl> set osi transport disconnect holdback 0, - (2)
    _ncl> maximum multiplexing 65535, maximum network connections 65535 (3)
    
    ncl> enable osi transport
    
    1. Specifies the names of one or more X.25 filters used to listen for incoming transport connection requests. If you do not specify any X.25 filters, a default filter called OSI transport is used.
    2. Set a high value for disconnect holdback if you want to keep idle network connections. This will save the cost of re-establishing network connections. You should be aware, however, that this is unnecessarily costly if the network connection remains idle.
      Set disconnect holdback to 0 if you want to lose idle network connections as soon as possible.
      You can only use disconnect holdback for transport protocol classes 2 and 4.
    3. Sets the value of maximum multiplexing. Increasing the value saves on the cost of network connections but reduces the throughput for each transport connection that uses a multiplexed network connection.
      You can only use maximum multiplexing for transport protocol classes 2 and 4.
      If you set maximum network connections too low, local transport users might be unable to make transport connection requests, particularly if all the active network connections are inbound. For example, if the limit is 7 and there are seven active network connections, all inbound, then local transport users will be unable to make transport connections unless you either increase the value of maximum network connections or one of the network connections is released by a remote host.
  2. The following example shows how to create the OSI transport templates:


    ncl> create osi transport template template-name (1)
    
    ncl> set osi transport template template-name -
    _ncl> acknowledgment delay time 1, -
    _ncl> checksums false, classes {0,2}, - (2)
    _ncl> cons template osi transport, cr timeout 30, er timeout 30, - (3)
    
    _ncl> inbound true, initial retransmit time 15, loopback false, - (4)
    _ncl> keepalive time 60, maximum nsdu size 2048, -
    _ncl> network service cons, retransmit threshold 8 (5)
    
    ncl> enable osi transport template template-name
    
    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 CONS connections:
      • For outbound connections only
        You can configure as many outbound OSI transport templates as you want.
      • For both outbound and inbound connections
        Configure a single outbound--inbound OSI transport template for each X25 Access filter used by inbound transport connections.
    2. Including checksums reduces data throughput but increases reliability of the data transmission.
    3. The default value for cr timeout is adequate for most networks. However, consider increasing the value if you find that a high proportion of transport connection requests are being timed out.
    4. When true, inbound specifies that this OSI transport template for CONS connections can be used for inbound as well as outbound connections.
      The default initial retransmit time value should be suitable for most networks. It is set to a relatively high value to reflect the fact that a transport connection request Transport layer protocol data unit (TPDU) usually has a longer round-trip delay than a data TPDU. Consider increasing the value if transport connection requests frequently time out.
      You can set up different OSI transport templates to provide different values of this attribute for networks with significantly different round-trip delay. For example, round-trip delay on an X.25 PSDN is usually much greater than on an 802.3 LAN.
    5. network service cons indicates that transport connections set up using a specified template will use CONS. An OSI transport template for CONS connections configured with the NET$CONFIGURE procedure will have this attribute set correctly. However, if you create a CONS OSI Transport template directly, you must set this attribute, since the default is CLNS. Note that the network service attribute does not support a value of any. If this attribute is set to any, the OSI transport is established as CLNS. 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.

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.


Previous Next Contents Index