 |
DECnet-Plus for OpenVMS
Applications Installation
and Advanced Configuration
B.3.1 Transmit and Receive Window
OSI transport receiver's window is controlled by a combination of
Maximum Transport Connections, Maximum Receive Buffers, and Maximum
Window. The receiver initial quota is determined by dividing Maximum
Receive Buffers by Maximum Transport Connections. During the life of
the connection, the receiver quota fluctuates, using the value of
Maximum Receive Buffers divided by Currently Active Connections. The
credit window sent to the remote transmitter may or may not be this
quota value, depending on the value of Maximum Window. If Maximum
Window is set to less than the determined receiver quota, this value 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 Maximum Window is a
lower value. In that case, Maximum Window is used for the transmitter
window.
By controlling the transmitter's and receiver's window as above a
dynamic balance of system resource consumption and network performance
may be achieved and maintained.
The following NCL script creates and sets up OSI transport, including
the Connection-Oriented Network Service (CONS), and the
Connectionless-mode Network Service (CLNS) services.
ncl> create node 0 osi transport
ncl> create node 0 osi transport application osit$ivp
ncl> set node 0 osi transport application osit$ivp file name sys$test:osit$ivpresp.com
ncl> set node 0 osi transport application osit$ivp user name "systest"
ncl> set node 0 osi transport application osit$ivp called tsels {%X564f5453495650}
ncl> create node 0 osi transport template osit$loop_clns
ncl> set node 0 osi transport template osit$loop_clns network service clns, -
_ncl> classes {4}, -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true
ncl> create node 0 osi transport template osit$loop_cons
ncl> set node 0 osi transport template osit$loop_cons network service cons, -
_ncl> classes {4,2,0}, -
_ncl> expedited data true, -
_ncl> checksums false, -
_ncl> inbound false, -
_ncl> loopback true
ncl> create node 0 osi transport template osit$rfc1006
ncl> set node 0 osi transport template osit$rfc1006 network service RFC1006, -
_ncl> classes {0}, -
_ncl> inbound true
ncl> create node 0 osi transport template osit$rfc1006plus
ncl> set node 0 osi transport template osit$rfc1006plus network service RFC1006, -
_ncl> classes {2}, -
_ncl> RFC1006 port number 399, -
_ncl> inbound true
ncl> set osi transport RFC1006 listener ports = { 102, 399 }
ncl> enable node 0 osi transport
|
B.3.2 Configuring the Connection-Oriented Network Service
The following sections describe how to configure the
Connection-Oriented Network Service (CONS). CONS is a network service
that operates according to a connection-oriented model. Before data can
be exchanged, a connection must first be established. X.25 provides
this type of service.
B.3.2.1 Establishing Outbound Connections Using CONS
To establish an outbound transport connection that uses CONS as its
network
service, an application makes a connection request in which it
specifies:
- The OSI transport address of the destination host.
- The OSI transport service access point identifier (TSAP-ID) of the
remote application. A TSAP-ID identifies a 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 to be used in setting up the
transport connection. The specified OSI transport template must have
its network service characteristic set to cons.
- A network address that uniquely identifies the destination host.
The network address for a CONS connection is a DTE address.
OSI transport either creates a new network connection (using either
X.25 or X25 Access), or uses an existing outbound network connection
(provided the transport connection is class 2 or class 4). If a new
connection is to be created, X.25 uses the DTE address from the OSI
transport address and the X25 Access template specified in the OSI
transport template to set up a network connection.
B.3.2.2 Establishing Inbound Connections Using CONS
To establish an inbound transport connection:
- OSI transport must be listening to one or more X25 Access filters.
X.25 or X25 Access passes calls from these filters up to OSI
transport.
- OSI transport must have an OSI transport template for CONS
connections with its inbound characteristic set to TRUE. This
OSI transport template must also specify an X25 Access template with
the same name (including matching case) as the X25 Access filter on
which a call arrives.
- If a suitable OSI transport template for CONS connections is found,
it is used to accept the call, using the X25 Access template specified
in the OSI transport template.
- The incoming transport connection can then be received. If an
application is found to receive the inbound request, the application
can accept or reject the request.
- If the application accepts the inbound request, the OSI transport
template for CONS connections is used for the accept.
For incoming connections to applications that are invoked by passive
TSAP association, you must also configure one or more OSI transport
application entities to represent the passive association between a
TSAP-ID and an application. Refer to the DECnet-Plus for OpenVMS Network Management guide for
information about managing application entities.
B.3.2.3 Manually Configuring Support for CONS
To configure CONS support, 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
template subentity must contain a name that is a PSI filter and is
contained in the set of CONS filters of the OSI transport
entity. The default value of the CONS template attribute of an
OSI transport template subentity is OSI transport.
The following steps list the commands required to configure CONS. The
characteristics added or set up for OSI transport in this
example are relevant to CONS. In addition, consider setting some of the
more general characteristics shown in Section B.3.
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.
- The following example shows how to create the OSI transport module,
set its characteristics, 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 saves
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.
disconnect holdback is supported only 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.
maximum
multiplexing is supported only 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 7 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 {4}, - (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
You should configure
a single outbound--inbound OSI transport template for each X25 Access
filter used by inbound transport connections.
- Including checksums reduces data throughput.
Use checksums only if you have reason to believe that data will be
corrupted by the network.
- 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 characteristic 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 have this characteristic set
correctly. However, if you create a CONS OSI transport template
directly, you must set this characteristic, because the default is 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.
- The following example creates the X25 Access module, and enables it:
ncl> create x25 access
ncl> enable x25 access
|
- The following example shows how to create the x25 access
template and set its characteristics:
ncl> create x25 access template template-name (1)
ncl> set x25 access template template-name -
_ncl> call data hex-string, dte class dte-class-name (2)
|
- Outbound transport connections that use X.25
network connections use X25 Access templates to supply most of the
parameters for setting up the network connection. Inbound transport
connections that use X.25 connections use X25 Access templates to
negotiate network connection parameters.
Each OSI transport
template for CONS connections that you configure names an X25 Access
template in its cons template characteristic. You must,
therefore, configure each of the X25 Access templates named in your OSI
transport templates for CONS connections.
- When you create an X25 Access template for
use with CONS, set the value of the call data characteristic
to %X03010100. The destination host will recognize this value
as indicating that the call should be passed to CONS.
- The following example shows how to create the x25 access
filter:
ncl> create x25 access filter filter-name (1)
ncl> set x25 access filter filter-name -
_ncl> call data mask mask, call data value value, - (2)
_ncl> inbound dte class dte-class-name
|
- If your system is to accept inbound transport
connections over X.25 network connections, you need to configure one or
more X25 Access filters. An X25 Access filter listens for incoming
network connection requests and passes these requests to the
appropriate destination. One or more X25 Access filters are required
for each X25 Access DTE class that CONS wants to use.
Each
outbound-inbound OSI transport template for CONS connections that you
configure specifies the name of an X25 Access template in its cons
template characteristic. This X25 Access template will be used to
accept an inbound network connection. The name of this X25 Access
template must be the same as the name of an X25 Access filter that is
used to receive inbound network connections.
- When you create an X25 Access filter for use
by CONS, set call data mask to %Xffffffff.
When
you create an X25 Access filter for use by CONS, set call data
value to %X03010100.
B.3.3 Manually Configuring the Connectionless-Mode Network Service
The following sections describe how to configure 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 TP4 is available in the default configuration.
B.3.3.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 in which it
specifies:
- The OSI transport address of the destination host.
- The TSAP-ID of the responding application. A TSAP-ID identifies a
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 characteristic 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.
B.3.3.2 Establishing Inbound Connections Using CLNS
To establish an inbound transport connection that uses CLNS:
- 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 characteristic 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 characteristic set to the same area address as the
inactive area address characteristic of the routing circuit on
which the transport connection arrived.
- 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.
- If the application accepts the connection, the OSI transport
template for CLNS connections is used to accept the connection.
B.3.3.3 Steps for Configuring CLNS
The following steps show the commands to configure CLNS. The
characteristic added or set up for OSI transport in this example is
relevant to CLNS. In addition, consider setting some of the more
general characteristics shown in Section B.3.
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.
- 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
|
- nsap selector is used for transport
connections using CLNS/ES-IS.
- The following example shows how to create the OSI transport
template and set its characteristics:
ncl> create osi transport template template-name (1)
ncl> set osi transport template -
_ncl> acknowledgment delay time 1, -
_ncl> checksums false, classes {4}, clns inactive area address {}, - (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
|
- 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.
-
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.
-
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.
-
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.
- The following example shows how to set up routing for end systems
using the Connectionless-mode Network Service.
ncl> create routing type endnode
ncl> set routing dna address format true, lifetime 63, -
_ncl> manual network entity titles {}, probe rate 20
ncl> enable routing
|
- The following example shows how to set up a routing
circuit for end systems using the Connectionless-mode Network
Service.
ncl> create routing circuit hdlc-0 type hdlc (1)
ncl> set routing circuit hdlc-0 data link entity -
_ncl> hdlc link hdlc-0 logical station hdlc-0, - (2)
_ncl> manual data link sdu size 1492, - (3)
_ncl> template template-name (4)
ncl> enable routing circuit hdlc-0
|
|
