3.3.4 Becoming Familiar with NCL Commands, Network Management Modules, and Network Management Tasks
Use NCL to manage DECnet-Plus software by specifying entity values. You
can use NCL commands to:
- Create and delete entities
- Enable an entity, which starts the corresponding software module's
- Disable an entity, which halts the corresponding software module's
- Modify attributes, or characteristics, of an entity
- Display attributes of an entity
NCL also provides module-specific functions, for example, loopback
testing within the Modem Connect module.
In addition to its entity-related functions, NCL provides control
functions such as:
- Aborting NCL operations
- Establishing defaults for NCL operations
You can execute NCL commands:
- Interactively at the NCL prompt
- In command files
- In initialization scripts
Initialization scripts are part of
the configuration procedure of DECnet-Plus for OpenVMS, DECnet-Plus for
DIGITAL UNIX, and other DECnet-Plus products, for example, Phase V
- Using the graphical user interface for network management of Phase
sys$system:net$mgmt.exe (for OpenVMS) or
/usr/sbin/dna_mgmt (for UNIX)
Choose Default Actions from
the Options pull-down menu to display the NCL commands performed on
your behalf by the application.
Table 3-4 lists some network management tasks and the related
network management entities that you set or modify using NCL commands
to perform these tasks. You can use this table during transition to
help you learn the modules and entities associated with specific
network management tasks. (A complete version of this table also
appears in your network management guide.)
All required modules are enabled and all required entities are set
during initial configurations, either automatically or by you. Use
interactive NCL commands to change initial settings.
Table 3-4 Management Tasks and Related Network Management Modules
Enable or disable the system for networking
Manage modem connections
call control port,
Manage CSMA-CD connections
Manage synchronous and asynchronous DIGITAL Data Communications Message
Protocol (DDCMP) connections
DDCMP (DIGITAL UNIX only)
link logical station,
Manage synchronous High-level Data Link Control (HDLC) connections
HDLC (DIGITAL UNIX only)
link logical station,
Manage X.25 level 2 protocol to exchange frames between a DTE and a DCE
Manage X.25 level 2 for communications over a LAN
Downline load and upline dump communications servers such as DEC
Manage transport between DECnet-Plus nodes and between DECnet-Plus
nodes and multivendor OSI systems
local nsap remote nsap,
Manage transport between DECnet-Plus nodes and between DECnet-Plus
nodes and Phase IV nodes
local nsap remote nsap,
Manage proxies, applications, and processes using the network
local node synonym,
Invoke loopback tests between applications on two nodes
Log events about network operations
sink inbound stream
3.4 Optional Tasks
Some management tasks related to the transition are required only if
your network operations need them:
- If your initial use of the Local namespace is part of the
transition strategy, move to a distributed namespace when you have
completed planning for a distributed namespace. For complete
information about this procedure, see your network management guide.
Set a consistent network buffer size, if you want to avoid the possible
dropping of packets by Phase IV routers. For background information and
instructions, see Section 3.4.1.
If necessary, change your IDP and preDSP. For efficiency, you might
choose to make the transition, perhaps with only some of your nodes,
using the default IDP. This IDP is not usable for public networks;
therefore, a later transition task in this situation is changing your
IDP and preDSP to a real one obtained at the appropriate authorized
registration agent. For information about registration agents, see
Section 4.7. For instructions on making this change, see
- Choose your main network management tool. An alternative to NCL is
POLYCENTER Framework software, a separately orderable product.
3.4.1 Adjusting Buffer Sizes During Transition
In DECnet-Plus, the Transport layer segments and reassembles user
messages to a size acceptable to the Routing layer on that system. This
method differs from the Phase IV method, in which the Transport layer
segments and reassembles user messages to a size appropriate to the
complete path over which packets must pass.
DECnet-Plus routing has an additional segmentation capability: if a
packet is in the ISO 8473 packet format (the format used between
DECnet-Plus systems), a DECnet-Plus router can segment it to fit the
data-link size. The Routing layer of the destination system reassembles
the segments before delivering the packet to the Transport layer. In
contrast, a Phase IV router cannot segment packets to fit the data-link
size. When forwarding a packet, a Phase IV router drops the packet if
it is too large for the specific data link being used.
For a network in the transition, decide whether to:
- Establish a consistent buffer size throughout the network or,
- Accept that some packets will be discarded because they are too
large for the data link being used.
To set a consistent network buffer size, use one of the following:
- On all DECnet-Plus systems, accept the default value of 570 for the
routing characteristic segment buffer size. Accepting the
default for this routing characteristic on DECnet-Plus systems ensures
that they will not send packets larger than any Phase IV data link can
- On all Phase IV routers, set the parameters executor buffer
size and line buffer size to a value greater than or
equal to the DECnet-Plus segment buffer size. Setting these
parameters ensures that Phase IV routers will be able to forward
packets that DECnet-Plus systems send.
- On all Phase IV systems, set the parameter segment buffer
size to less than or equal to the smallest data-link block size.
As a result, these systems will not create packets that are too big for
the data-link size.
3.4.2 Changing the Network's IDP and preDSP
To change the IDP and preDSP of a network, follow these steps (waiting
at least 24 hours between each step):
- Create the new backtranslation directories, as needed. Use
- Add the new IDP to the routers, using NCL or the appropriate router
configuration program. DECnet-Plus nodes automatically learn the new
IDP from the routers and update their own entries in the namespace.
- Add the new IDP to the information stored in the namespace, using
decnet_register. Do not change the local area values.
updates nodename entries that do not already have the new IDP.
- Remove the old IDP from the routers, using NCL or the appropriate
router configuration program. DECnet-Plus nodes automatically learn
that the old IDP is no longer in use and update their own entries in
- Remove the old IDP from the information stored in the namespace,
using decnet_register. This updates any node-name entries that
have not already had the old IDP removed.
Creating NSAP Addresses
This chapter discusses the format of NSAP addresses for DECnet-Plus
systems and describes how to get unique identification for your DECnet
Phase V network. You need this information to:
- Plan for and complete the transition to DECnet-Plus
- Design or create a namespace
- Register DECnet-Plus systems in the namespace
- Configure DECnet-Plus systems for communications
The DECnet Phase V addressing scheme for DECnet-Plus nodes complies
with the ISO 8348 Addendum 2 addressing standard. This scheme uses the
concepts of global addressing, addressing authorities, and addressing
domains. Global network addressing is an ISO scheme designed to provide
unique network addresses throughout the world.
A global network address is called a network service access
point (NSAP). Because it is used to determine the destination
node for all packets, the NSAP must be unique for each node in a
For more information about addressing and service access points (SAPs),
refer to Chapter 3 of the DECnet-Plus for OpenVMS Introduction and
Some NSAP field values are assigned by an allocation authority, and
some you assign yourself for your organization. Every NSAP has two
- Initial domain part (IDP), which consists of two
- Domain-specific part (DSP), which consists of four
Figure 4-1 shows the parts of an NSAP and network entity title
(NET). To compare these parts with Phase IV addresses, see
Figure 4-1 Parts of an NSAP
4.1 IDP Values
The IDP helps ensure that NSAP values are globally unique. For this
reason, IDP values are assigned by recognized authorities or are based
on another value (such as a Telex number) that has already been
assigned by some authority.
The IDP has two fields:
- Authority and format identifier (AFI)
This field identifies the authority that allocated the globally unique
The AFI value always consists of two decimal digits (from 0 to
9). Table 4-1 lists the recognized values and the corresponding
An AFI value of 49 indicates a
private network, one that is not interconnected with other OSI networks
and, therefore, does not need a globally unique IDP.
shows the NSAP field lengths for each AFI.
Table 4-1 Information for Building Unique NSAPs
||Maximum Digits in IDI
||Use AFI if the Leading Digit of the IDI is:
||Maximum Digits in preDSP
ISO DCC (single-country organizations)
ISO 6523-ICD (international organizations)
X.121 (X.25 address)
F.69 (Telex number)
E.163 (telephone number)
E.164 (ISDN number)
- Initial domain identifier (IDI)
combined with the AFI, makes the IDP globally unique for the allocating
authority. Depending on the allocation authority identified in the AFI,
the IDI value can be explicitly assigned by the authority, or it can be
based on some other value that has already been assigned by that
The IDI value consists of zero or more decimal digits
(from 0 to 9). The actual number of digits depends on the AFI. Some
AFIs specify fixed-length IDIs, where you must enter all the digits in
the IDI. Other AFIs specify variable-length IDIs, where you can enter
up to the specified number of digits. Table 4-1 gives the IDI
lengths for each AFI.
If you are using the private AFI (49), do not specify an IDI.
AFI 49 indicates a private network not interconnected with
other OSI networks.
4.2 DSP Values
The DSP provides unique addresses within a specific IDP value.
Different routing architectures might format and use the DSP in
different ways. The format used by DECnet-Plus IS-IS, based on OSI
IS-IS (ISO 10589), divides the DSP into four fields:
- Prefix to the DSP (preDSP)
Also called the
high-order part of the DSP (HO-DSP), the format of
this field is not defined by DECnet-Plus. If you assign a value to this
field, it becomes part of the area, in conjunction with the IDP and
local area values, and identifies the node's location for level 2
routing. If nodes have the same IDP and local area values, but
different preDSP values, the nodes are in different routing areas.
The preDSP value is zero or more hexadecimal digits (from 0 to F).
The actual number of digits you can enter depends on the AFI.
Table 4-1 gives the preDSP sizes appropriate for each AFI.
The American National Standards Institute (ANSI) is the ISO DCC
allocation authority in the United States. For NSAPs with AFI
39, allocated by the ISO DCC, and AFI 47, allocated
by ISO 6523-ICD, the allocating authorities may assign an additional
value for you to enter into the preDSP field. The reason for this
additional value is that they have available only a limited number of
IDIs, and they may give the same IDI value to different organizations.
When this occurs, the preDSP value ensures global uniqueness.
Allocation authorities other than ANSI may format the preDSP in
other ways. DIGITAL recommends that you do not assign a value to the
preDSP field when you use AFIs other than 39 and 47.
ANSI formats the preDSP into the following subfields:
- DSP Format Identifier (DFI)
The value of this
field is allocated by ANSI and consists of two hexadecimal digits. It
indicates the format used for the rest of the high-order DSP, which is
- Organization ID (ORG)
The value of this field
is allocated by ANSI and consists of six hexadecimal digits. This value
is different for every organization and ensures global uniqueness.
- Reserved (RES)
The value of this field is
allocated by ANSI and consists of four hexadecimal digits. This is a
reserved field, whose value must always be zero.
- Routing Domain (RD)
The value of this field is
allocated by each individual organization and consists of four
hexadecimal digits. This field is used to separate an organization's
network into multiple routing domains. It is defined so that routing
domains can be identified uniquely by intermediate systems using a
single short address prefix, without the necessity of listing multiple
address prefixes, one for each local area within that routing domain.
If your network needs only one routing domain, DIGITAL recommends that
you use the value 0000.
- Local area (LocArea)
This value represents the
local area within the routing domain (the node's local network area).
Use the LocArea value, with the IDP and preDSP values, to identify the
node's location for level 2 routing.
This value is used as the next
four digits (two octets) in the DSP. The local area value is four
hexadecimal digits (from 0 to F). Values 00-01 to 00-3F are
reserved for use as Phase IV-compatible area numbers for areas 1 to 63.
- Node ID
This part of the DSP identifies a node
within an area. It represents the node ID within the local area. Use it
to identify the node for level 1 routing purposes.
Use the node ID
value as the next 12 digits (6 octets) in the DSP. This value is 12
hexadecimal digits (from 0 to F). Node IDs that range from
AA-00-04-00-00-00 to AA-00-04-00-FF-FF are reserved for use as Phase
IV-compatible node IDs (1.1 to 63.1023).
- Selector (SEL)
This part of the DSP indicates the transport protocol you want to
use. The selector value consists of two hexadecimal digits (from 0 to
F). This value is used as the next two digits (one octet) in the DSP.
DECnet-Plus uses these SEL values:
- 20 (for NSAP specifying NSP transport)
- 21 (for NSAP specifying OSI transport)
- 00 (for an NET)
4.3 NSAP Entry and Display Formats
Enter an NSAP using either of two standard formats, DNA format or OSI
format. DNA format consists of:
OSI format consists of:
is the AFI value in decimal
is the IDI value in decimal
is the preDSP value in hexadecimal
is the local area value in hexadecimal
is the node ID value in hexadecimal
is the selector value in hexadecimal
DECnet-Plus always displays NSAPs in DNA format because this format
separates the various fields, making the NSAP easier to read. The
preDSP, local area, and node ID values are punctuated with hyphens
after every two digits.
When you enter an NSAP using DNA format:
- You can type hyphens anywhere.
- You can omit hyphens.
- If the local area or node ID fields start with zeros, you can omit
- You cannot omit leading zeros for the IDI and preDSP values.
Leading zeros in these fields affect the value of the NSAP when it is
used in routing messages.
When you enter an NSAP using OSI format, you must always enter the
proper number of digits because there is no other way to indicate where
one field ends and the next starts, except between the IDP and DSP. The
following examples show NSAPs in both formats.
NSAP with an IDP with the private AFI:
DNA format: 49::00-01:12-34-56-78-9A-BC:21
OSI format: 49+0001123456789ABC21
NSAP with an IDP with an allocated AFI and IDI:
DNA format: 41:23456789:A5:08-00-2B-19-0E-6C:20
OSI format: 4123456789+00A508002B190E6C20
If an NSAP has an unrecognized AFI or does not have the correct number
of digits in the IDP or DSP, it is displayed in binary format. This
format represents the value of the NSAP as a string of hexadecimal
digits, as follows: