 |
DECnet-Plus for OpenVMS Network Management
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
|
- 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.
-
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.
- 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.
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
|
-
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.
-
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.
- 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.
- 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
|
- 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.
- 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.
- 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.
- 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
|
- 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.
- Including checksums reduces data throughput
but increases reliability of the data transmission.
- 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.
- 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.
- 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.
|
|