A special DECnet device driver allows the MultiNet system manager to configure a DECnet line and circuit between two cooperating MultiNet systems across an arbitrary IP network. This special driver encapsulates DECnet packets in UDP datagrams for transport via the IP protocols, in much the same way as VMS PSI encapsulates DECnet packets in X.25 when doing Data Link Mapping.
MultiNet provides DECNET-CONFIG, the command-line configuration utility invoked with the MULTINET CONFIGURE /DECNET command, for configuring DECnet-over-IP connections:
For details about this utility, see Chapter 2, the DECNET-CONFIG chapter of the MultiNet Administrator's Reference, and the online command reference (invoked with the HELP MULTINET command).
Once configured, a DECnet-over-IP circuit comes up automatically when the hosts on each side of the DECnet connection are rebooted.
When configuring a DECnet-over-IP circuit, you are prompted for:
· The IP address of the host on the opposite side of the connection
· The COST that DECnet assigns to the circuit
· The HELLO TIMER that DECnet should use on this circuit
For proper DECnet operation, the COST and HELLO TIMER must be the same on both sides of the connection.
If you configure a DECnet-over-IP link, and you also run DECnet over another Ethernet interface, you must configure your system as a router as follows:
$ RUN
SYS$SYSTEM:NCP
NCP>DEFINE EXECUTOR TYPE ROUTING IV
Non-routing hosts can only communicate with the hosts reachable via the circuit with the lowest cost. If, for example, your Ethernet circuit has a cost of 4, and your DECnet-over-IP link has a cost of 1 (the default), your system will be unable to communicate with hosts accessible over the Ethernet link.
Full DECnet routing functionality is supported only on VAX systems. This is a Hewlett-Packard restriction, not one imposed by MultiNet. For more information, refer to SPD 48.48.04
The following examples show how to make a connection between two systems, betty.example.edu (IP address 192.0.0.6) and wilma.example.com (IP address 128.0.0.125). The first example shows the circuit configuration on the host "betty":
$ MULTINET
CONFIGURE /DECNET
MultiNet DECNET Circuit Configuration Utility 5.6
[Reading in configuration from MULTINET:DECNET-CIRCUITS.COM]
DECNET-CONFIG>ADD
[Adding new configuration entry for DECnet circuit "TCP-0-0"]
Destination IP Address: [NONE] 128.0.0.125
DECnet circuit cost: [1] 1
DECnet hello timer (in seconds): [300] 300
[TCP-0-0 => 128.0.0.125 (Cost=1, Hello Timer=300)]
DECNET-CONFIG>EXIT
[Writing configuration to MULTINET:DECNET-CIRCUITS.COM]
$
The next example shows the circuit configuration on the host "wilma":
$ MULTINET
CONFIGURE /DECNET
MultiNet DECNET Circuit Configuration Utility 5.6
[Reading in configuration from MULTINET:DECNET-CIRCUITS.COM]
DECNET-CONFIG>ADD
[Adding new configuration entry for DECnet circuit "TCP-0-0"]
Destination IP Address: [NONE] 192.0.0.6
DECnet circuit cost: [1] 1
DECnet hello timer (in seconds): [300] 300
[TCP-0-0 => 192.0.0.6 (Cost=1, Hello Timer=300)]
DECNET-CONFIG>EXIT
[Writing configuration to MULTINET:DECNET-CIRCUITS.COM]
$
Both TCP and DECnet guarantee reliable delivery of data over unreliable networks. This is accomplished through an acknowledgment scheme in which the receiver of the data tells the transmitter of the data that the data has arrived intact. If the acknowledgment is not received within a certain period of time (known as the retransmission timer), the data is resent by the transmitter.
The data transmitter must make a good estimate of the retransmission timer. Too long an interval causes unnecessary waits before retransmission occurs, reducing the usable bandwidth of the network. Too short an interval means the transmitter might retransmit data that was merely delayed in transit, unnecessarily loading the network.
· TCP chooses the retransmission timer as a function of the mean and the variance in the roundtrip time so that a statistically small percentage of packets are unnecessarily retransmitted.
· DECnet chooses the retransmission timer as the product of the round trip time (with a minimum of one second) and the delay factor.
DECnet's scheme (or schema?) does not take into account the variance of the round-trip time and estimated roundtrip times of less than one second.
DECnet uses a very conservative value for the delay factor to avoid any unnecessary retransmissions into congested, low-speed links. A single lost packet results in a delay of at least five seconds in DECnet traffic. Over high-speed, low-latency circuits with any substantial packet loss, this delay results in a severe performance degradation.
If your network has these characteristics, you can substantially increase performance by reducing the delay factor using NCP on each of your nodes. Doing so gives DECnet a more aggressive retransmission strategy which results in shorter delays following a lost packet. Specify the delay factor in units of 1/16th of the mean round-trip time using the NCP EXECUTOR parameter DELAY FACTOR.
Reasonable factors range from 1.5 to 3, or DELAY FACTOR values from 24 to 48. A retransmission factor of 1.5 is very aggressive and about as small as is reasonable before many extra retransmissions occur; a value of 3 more closely mimics TCP's behavior over lines which have typical variances in the roundtrip time.
You can set the DELAY FACTOR to 24/16ths (1.5) using the following NCP commands:
$ MCR NCP
NCP>SET EXECUTOR DELAY FACTOR 24
NCP>DEFINE EXECUTOR DELAY FACTOR 24
NCP>EXIT
$
Use the MULTINET SET/DECNET command to configure the TCPAx: DECnet devices for running DECnet over UDP.
|
Note: You should configure DECnet circuits using DECNET-CONFIG, which invokes MULTINET SET/DECNET as part of network startup to set up the DECnet link. You can use this utility to change the configuration once the network has started.
|