[Digital logo]
[HR]

DECnet-Plus for OpenVMS
Network Management


Previous | Contents

When an end system communicates to another node for the first time, the end system cache has no routing information for that node. The end system chooses at random an adjacent router and transmits the data to it, allowing the adjacent router to find a path to the destination node. The end system creates cache entries based on information about the routing path received from incoming data sent by routers and from advertisements sent directly from other end systems.

Cache entries are each assigned a precedence which determines the path chosen when two or more cache entries refer to the same destination. The Routing module assigns precedence as shown in Table 8-5, where 1 is the highest precedence. Direct reachability indicates the path is direct from source to destination without intermediary routers. Indirect indicates the path is through one or more intermediary routers. Reverse reachability implies the directness of the path is indeterminate at the time (whether a direct path exists will be resolved during subsequent communications).

A reverse path cache entry indicates that a data packet was received from an adjacent node on a specific circuit. The adjacent node could be the original sender or the last router that forwarded the packet. Given no other information, the most efficient path for sending response packets is usually the path the original data message followed.


Note

A static routing path that is defined by a reachable address of type outbound has the highest precedence. All other cache entries for the same destination are ignored.

Table 8-5 Cache Entry Precedence Values
Precedence Reachability Blocksize
1 Direct FDDI
2 Indirect FDDI
3 Reverse FDDI
4 Direct not FDDI
5 Indirect not FDDI
6 Reverse not FDDI

The Routing module follows these rules for making a cache entry:

When multiple paths with the same precedence exist for the same destination, the Routing module selects the path based on round robin. This helps balance the load on the paths. On multicircuit end systems, if no direct path to the destination node exists on a broadcast circuit, a duplicate packet is sent periodically, as determined by the probe rate.

The es cache holding time attribute determines how long an entry is held in the end system cache. The default is 600 seconds. The timer is refreshed each time a data packet is successfully received by the destination node over the path defined by the entry. The entry is deleted if no communication occurs between the source and destination nodes within the period defined by the timer. This maximizes the effectiveness of the end system cache.

Displaying Cache Entries

Cache entries are visible as network management entities known as routing destination cache.

On OpenVMS systems, use the System Dump Analyzer (SDA) to show cache entries, as in the following example:

$ analyze/system      
      
OpenVMS (TM) VAX System Analyzer      
      
SDA> net show routing cache      
%SDA-I-READSYM, reading symbol table  SYS$COMMON:[SYSEXE]NET$SYMBOLS.STB;1      
      
      
DECnet-Plus for OpenVMS Routing ES Cache Dump      
--------------------------------------------      
      
%SDA-I-READSYM, reading symbol table  SYS$COMMON:[SYS$LDR]NET$ROUTING_ES.STB;1      
Routing Prefix DataBase Address 816C63A8      
Prefix Table Start: 825D5F0C , End: 825D610C, Size 0      
      
Routing Cache DataBase Address 816C6390      
Cache Table Start: 825D10CC , End: 825D12CC, Size 1      
    Cache Entry at Address 825D256C      
        NSAP:      
                      4900 04AA0004 007F1321      
            OSI Transport - (4.895)      
        Cache Circuit Entry Count : 1,  Probe Count: 992      
        Cache Circuit List: 8260B500      
        Cache Circuit Entry:      
            Type:                 BroadCast      
            Format:               PhaseV      
            Reachability:         Direct      
            Blocksize:            Non-FDDI      
            Remaining LifeTime:   005F      
            Holding Time:         0258      
            Data Link Address:      
                               137F 000400AA ª.....           00000000      
                (4.895)      
      
SDA>        
      

8.4.3.4 Configuring CLNS with Null Internet

DECnet-Plus supports the inactive subset of CLNS, also known as null internet. An inactive subset PDU contains no Network layer addressing information; it is sent directly to the data link address derived from the destination NSAP address. Therefore, it cannot be routed by an intermediate system. This means that only LAN devices can support the inactive subset PDU, and the two communicating nodes must be on the same LAN. The inactive subset of CLNS allows communication with OSI systems that only implement the inactive subset.

Configuring CLNS with null internet is no different from configuring full CLNS, with the following restrictions:

For more information on configuring CLNS OSI transport to use the null internet, see Section 8.5.2.4.3.

You can turn the ability to transmit and receive inactive subset protocol data units (PDUs) on and off on a per circuit basis by defining a value for the circuit attribute inactive area address. The following example uses the default inactive area address attribute on a LAN:

ncl> create routing circuit csmacd-0 -      
_ncl> type csma-cd      
      
ncl> set routing circuit csmacd-0 -      
_ncl> inactive area address {49::FF-00}      
      
ncl> enable routing circuit csmacd-0      

You must do this after the circuit is created, but before you enable it. The value is the address of an otherwise unused area in your network.

If you want to change the transport, modify the Routing module's preset attribute, inactive selector, with the selector of the transport you want to use. Only one transport may use the inactive subset and, by default, this is OSI transport (which has a default selector value of 33). To operate NSP over the inactive subset, before enabling the Routing module (and any circuits) enter the command:

ncl> set routing inactive selector 32      

When using the inactive subset, destination NSAPs must contain the inactive area address followed by the data link address of the remote machine followed by the transport selector. For example:

49::FF-00:08-00-23-00-01-02:21      

8.4.3.5 Reachable Addresses

Reachable addresses allow the system manager to override the automatic routing mechanisms in DECnet-Plus. You can define reachable addresses for each circuit. Two types of reachable addresses are outbound and filter, as described below. (For information about reachable addresses used for OSI transport over X.25 CONS circuits, see Section 8.8.3.1.)

You can use NCL to switch from the default (outbound) to filter by setting the reachable address entity type attribute to the value filter. You must disable the routing reachable address entity before changing the value of the type attribute.


Note

For either the outbound or filter type of reachable address, you must set the mapping attribute to manual (the default is x.121). See the command example below.

The following reachable address attributes are supported by outbound reachable addresses:

The following example shows how to use NCL commands to create an outbound type of reachable address:

ncl> create routing circuit csmacd-0 reachable address to-area4 - 
_ncl> address prefix 49::00-04: 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> mapping manual 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> type outbound 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> data format phaseiv 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> block size 500 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> lan address aa-00-04-00-xx-xx
 

The permitted lan addresses attribute applies to filter reachable addresses for broadcast circuits only. This attribute specifies a set of LAN addresses corresponding to routers that are permitted to forward to this prefix. The default is an empty set. You must specify at least one LAN address. Specify these LAN addresses within a pair of braces, separating the addresses by commas, as in the last command in the following example, which shows how to create a filter reachable address.

ncl> create routing circuit csmacd-0 reachable address to-area4 - 
_ncl> address prefix 49::00-04: 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> mapping manual 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> type filter 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> data format phasev 
 
ncl> set routing circuit csmacd-0 reachable address to-area4 - 
_ncl> permitted lan address {aa-00-04-00-xx-xx, aa-00-04-00-yy-yy} 

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:

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:

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:

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:

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.


Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

[HR]

  PROFILE_VMS_010.HTML
  OSSG Documentation
   2-DEC-1996 12:35:02.11

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal