The top-level entities (and the layers to which they correspond) are:
application _DNS_Clerk
|_DNS_Server
|_DTSS
|_Event_Dispatcher
|_Alias (OpenVMS)
|_Loopback_Application
|_X25_Client (OpenVMS)
|_X25_Access
|_X25_Relay (Alpha)
|_X25_Server
|_DSA
session |_Session_Control
|_OSAK
transport |_NSP
Node---|_OSI_Transport
network |_Routing
|_X25_Protocol
datalink |_XOT (OpenVMS Alpha)
|_LAPB
|_CSMA-CD
|_LLC2
|_MOP
|_HDLC
|_DDCMP (OpenVMS VAX)
|_FDDI
|_Modem_Connect
|_Device
|_Frame (OpenVMS)
|_Token_Ring (Tru64 UNIX)
Select an entity listed below for a description of that particular
module and a listing of its subentities. Or to quickly view the
subentities beneath a particular module while at the NCL> prompt,
type HELP ENTITY <module_name> SUBENTITIES.
1 – Node
The Node module has one entity, the global node entity that crowns
the hierarchy represented in the entity model described by the
Digital Network Architecture. All other modules in DECnet-Plus are
subordinate to the Node module. When enabled, each node is visible
to all other nodes on the network. Access to a node's entities must
be made through the node.
For Tru64 UNIX:
To enable a node, use the command "enable node node-name" with
either the local CMIP listener or the address watcher argument.
For remote nodes with valid names, enabling the address watcher
changes the node state from "off" (service interface disable) to
"on" (service interface enabled). The CMIP listener must be enabled
on that node. If the CMIP listener is not enabled, the node cannot
accept management commands, and therefore cannot be turned on. For
the node on which the director is executing, two enable directives
may be necessary to accomplish the same action. The first enables the
CMIP listener, and the second enables the address watcher, for
example:
ncl> enable node node-name function [=] {cmip listener}
{address watcher}
2 – DNS Clerk
The Digital Distributed Name Service (DECdns) is a network-
wide service that makes it possible to use network resources
without having to know their physical location.
The DNS Clerk is the module of the DNA Naming Service that
interfaces directly with client applications. A clerk module is
required on every DECnet-Plus node whether or not that node also
functions as a DECdns nameserver. The clerk is created during
configuration of the network software.
You can manage the DNS server and DNS clerk modules from either NCL
or the DECdns control program (DNSCP). The commands are the same for
both interfaces and are documented in the DECdns Management manual.
On-line help for DECdns is available from DNSCP only.
2.1 – Subentities
The entity hierarchy for the DNS Clerk module is:
_Known_Namespace
|
Node___DNS_Clerk___|_Remote_Clearinghouse
|
|_Manual_Nameserver
3 – DNS Server
The Digital Distributed Name Service (DECdns) is a network-
wide service that makes it possible to use network resources
without having to know their physical location.
You can manage the DNS server and DNS clerk modules from either NCL
or the DECdns control program (DNSCP). The commands are the same for
both interfaces and are documented in the DECdns Management manual.
On-line help for DECdns is available from DNSCP only.
3.1 – Subentities
The entity hierarchy for the DNS Server module is:
Node___DNS_Server___Clearinghouse
4 – DSA
For information about the DSA entity and its subentities, refer to
HELP DIRECTORY_MODULE.
4.1 – Subentities
The subentities below the X.500 Directory Service (DSA) module are:
_Naming_Context
|
Node___DSA___|_Subordinate_Reference
|
|_Superior_Reference
|
|_Accessor
For more detailed information about the DSA entity and its subentities,
refer to HELP DIRECTORY_MODULE.
5 – DTSS
The Digital Network Architecture (DNA) contains several modules
that each relate to a functional area or product. All Digital
Distributed Time Service (DECdts) management functions are
contained in the DTSS module. The DTSS module has three entities
that enable you to synchronize, adjust, and maintain the system
clocks in a distributed network.
5.1 – Subentities
The entity hierarchy for the DTSS module is:
Node___DTSS_____DECnet_Global_Server
|
|_DECnet_Local_Server
The DTSS entity is the top-level entity in the DTSS module.
The dtss entity provides access to most of the management
functions for the DTSS module and the DECdts product, including
creating and deleting the software, enabling and disabling the
software, setting attributes, adjusting the clock, and forcing
synchronizations.
The DTSS DECNET GLOBAL SERVER entity provides information about
a node's synchronization with one or more servers in the global
set.
The DTSS DECNET LOCAL SERVER entity provides information about
a node's synchronization with one or more servers in the local
set.
6 – Event Dispatcher
The event dispatcher in an integral component of the Digital Network
Architecture that processes events generated by entities in
the network. Each component layer architecture of the Phase V
DNA architecture, such as Routing, NSP, and OSI Transport, may
define certain occurrences, actions, transitions, or conditions
as events that are reported and may be logged to assist network
or system management. The Event Dispatcher module allows these
conditions to be logged and monitored to allow a system manager
to view the state of the network. Individual messages for specific
entities are listed under HELP EVENT_MESSAGES.
6.1 – Subentities
The entity hierarchy for the Event Dispatcher module is:
_Outbound_Stream
|
Node___Event_Dispatcher___|_Relay____________Logging
|
|_Sink_____________Inbound_Stream
The EVENT DISPATCHER entity is the top-level entity in the
hierarchy of entities belonging to the Event Dispatcher module.
Each DNA node must implement an event dispatcher.
An EVENT DISPATCHER OUTBOUND STREAM entity represents an outgoing
connection to a sink on a local or remote node. An outbound
stream entity manages the connection to the sink, and it filters,
processes, and transmits events to the sink. The simple-name
refers to the outbound stream managed by this command.
The EVENT DISPATCHER RELAY entity is used for processing events
from Phase IV DECnet systems. It receives Phase IV format events
and posts them into the DECnet-Plus logging system.
Three EVENT DISPATCHER RELAY LOGGING entities are automatically
created and enabled whenever an event dispatcher relay entity
is enabled. The logging entities (console, file, and monitor)
control the destination of Phase IV events. Each logging entity
can be individually diabled and reenabled. All three logging
entities are automatically deleted when the Phase IV relay entity
is disabled.
An EVENT DISPATCHER SINK entity represents a sink. A sink manages
incoming connections and filters incoming events. Each sink
maintains a filter that is applied to all streams that are
assigned to that sink. The simple-name refers to the sink managed
by this command.
The EVENT DISPATCHER SINK INBOUND STREAM entity is the sink-side
end of communication between an event dispatcher and a sink. An
inbound stream entity is dynamically created, enabled, disabled,
and deleted in tandem with the connection it represents.
7 – Alias (OpenVMS)
The Alias module provides the means to define an alternate network
address which is shared by multiple nodes in the same VMScluster.
This makes it possible to treat a VMScluster, or several nodes
within a VMScluster, as though it were a single node in the network.
The first node in the VMScluster to create an Alias Port for
a particular alias address causes that alias to be created.
Subsequent nodes which create an Alias Port for the same alias
establish connections (Ports) to that alias. The alias becomes
active when the first node enables its Alias Port for that alias.
The port-name refers to the port managed by this command.
NOTE
When a node enables an Alias Port, that node registers
itself with other members of the alias.
7.1 – Subentities
The subentity of the Alias module is:
Node___Alias___Port
The ALIAS entity is the top-level entity in the hierarchy
belonging to the Alias module. The entity is the root from which
Alias Port subentity may be defined.
The ALIAS PORT entity provides the means to define an alternate
network address for this node, which is shared by other nodes
in the same VMScluster. When the alias port entity is enabled,
this node becomes an active member of the VMScluster alias it
specifies.
8 – Session Control
The Session layer implements the user interface to the network.
It is responsible for connection negotiation and establishment.
The Session Control module performs the following functions:
o Manages transport connections on behalf of Session Control
users.
o Enforces access control policies to restrict communication
between users and between Session Control modules.
o Maps from a DNA Naming Service object name to protocols and
addresses.
o Selects from the set of protocols supporting Session Control
to attempt connection establishment.
o Maintains in the namespace the protocol and address
information corresponding to objects that reside in the same
node as the local Session Control module.
8.1 – Subentities
The entity hierarchy for the Session Control module is:
_Application
|_Backtranslation_Softlink
Node___Session_Control___|_Port
|_Tower_Maintenance
|_Proxy (Tru64 UNIX)
|_Transport_Service
The SESSION CONTROL entity is the top-level entity in the
hierarchy of entities belonging to the Session Control module.
A SESSION CONTROL APPLICATION entity stores information about an
end user that is activated for receipt of an incoming connection
request when the request contains that end user's name in its
destination name field. The application-name refers to the
application managed by this command.
A SESSION CONTROL BACKTRANSLATION SOFTLINK entity stores
information about entries in the backtranslation soft link
database. The name is the unique name among the set of
backtranslation soft-link subentities maintained by session
control.
A SESSION CONTROL PORT entity stores Session Control information
about the transport connection. The port-name refers to the port
managed by this command.
A SESSION CONTROL PROXY entity stores the information that
grants remote users proxy access to given application subentity
instances.
A SESSION CONTROL TOWER MAINTENANCE entity stores information
about entries in the tower maintenance data base. A tower
maintenance entity is automatically created when a client issues
a dnaKeepMeHere call, using the programming interface. The name
refers to the tower maintenance entity managed by this command.
A SESSION CONTROL TRANSPORT SERVICE entity stores information
about modules in the Transport layer that support Session
Control. The transport-name refers to the transport service
managed by this command.
9 – OSAK
The OSAK module provides network control and management facilities
for the OSAK software. The OSAK software implements the ACSE
protocol of the Application layer, the Presentation layer, and the
Session layer of the OSI Reference Model.
NOTE: For Tru64 UNIX, you cannot modify any counter, identifier,
or status attributes within the OSAK module.
9.1 – Subentities
The entity hierarchy for the OSAK module is:
Node___OSAK____Application___Invocation
|
|_Port
The OSAK entity is the top-level entity in the OSAK module
hierarchy of entities. The OSAK entity is concerned with address
management for applications that use the OSAK software for their
communications requirements.
An OSAK APPLICATION entity represents an OSI application and is
created each time an OSI application that is running over the
OSAK software opens an initiator or a responder.
The entity also records information about the name and address of
an application.
For OpenVMS, an OSAK APPLICATION entity has zero or more application
entity invocations, each represented by an OSAK APPLICATION
INVOCATION entity (see below). In addition to recording information
about the name and address of an application, it also records
information that controls the way in which inbound association
requests for that application are handled by the OSAK software.
For OpenVMS, you should create an OSAK APPLICATION and an
OSAK APPLICATION INVOCATION for each passive application that you
want to run, identifying the application by its presentation
address. Also, an OSAK APPLICATION entity is created automatically
for an active application and deleted at the end of the connection.
An OSAK APPLICATION INVOCATION entity represents one invocation
of an application.
For Tru64 UNIX, an OSAK APPLICATION INVOCATION entity is created
each time an OSI application that is running over the OSAK software
opens an initiator or a responder. You can use only the show
command with the OSAK APPLICATION INVOCATION entity on Tru64 UNIX
systems, and you cannot modify any of the attributes.
For OpenVMS, an OSAK APPLICATION INVOCATION entity can be created
in two ways:
- Automatically, each time an OSI application that is running
over the OSAK software opens an initiator or a responder (as
for Tru64 UNIX).
- Manually, when you use the create command.
The create command creates a passive application, which becomes
active only when your OpenVMS system receives an OSI call for
that particular application invocation.
Each OSAK PORT entity describes one association opened in an
OSI application. A port is opened each time an application opens
an initiator or a responder.
10 – NSP
The NSP module implements one of the protocols in the Transport
layer described by the Digital Network Architecture.
NSP performs the following functions:
- Enables the creation and destruction of transport connections
used for sending messages within a network node and between
network nodes.
- Manages the movement of expedited and normal data from transmit
buffers to receive buffers, using flow control mechanisms.
- Breaks up normal data messages into segments that can be
transmitted individually, and reassembles these segments into
correct order after they have been received.
- Guarantees the delivery of data and control messages to a
specified destination using an error correction mechanism.
10.1 – Subentities
The entity hierarchy for the NSP module is:
Node___NSP____Local_NSAP___Remote_NSAP
|
|_Port
The NSP entity is the top-level entity in the hierarchy of
entities belonging to the NSP module.
An NSP LOCAL NSAP entity is automatically created for each NSAP
address used by the nsp entity. Local NSAPs are used primarily
to group together remote NSAPs (see the nsp local nsap remote
nsap entity). The nsap-address is the local NSAP managed by this
command.
An NSP LOCAL NSAP REMOTE NSAP entity maintains the transport
counters and generates events resulting from interactions between
its superior local NSAP and a remote transport service. The local
nsap nsap-address is the local NSAP associated with the specified
remote NSAP. The remote nsap nsap-address is the remote NSAP
managed by this command.
An NSP PORT entity represents one end of a transport connection
and maintains status information about that connection. A port
is visible to the network only when it is assigned to a transport
connection. The port-id is the port managed by this command.
11 – OSI Transport
This module implements the OSI Connection-Oriented Transport
Protocol specification (International Standard ISO 8073); and
the Connectionless-Mode Transport Service Protocol (International
Standard ISO 8602) for Tru64 UNIX. For OpenVMS, this module also
implements RFC1006 and RFC1006 Extension. These protocols implement
the OSI Reference Model Transport Layer 4. These protocols, as
well as the NSP protocol, implement the transport protocols in
the Digital Network Architecture.
The OSI Transport Protocol permits communication between
DECnet-Plus systems and other vendors' systems that also implement
the OSI Transport Protocol. You can set up OSI Transport
connections:
o Between two systems on the same ISO 8802-3 LAN.
o Between two systems that are connected, either directly
or via an X.25 connection.
o Between two systems that are connected directly by an X.25
point-to-point link.
o Between two systems on different subnetworks, where the
linking subnetworks might mix technologies.
o Between two systems that are connected via TCP/IP.
Refer to CONNECTION_PHASES below for a description of the three
phases of an OSI Transport connection.
The OSI Transport Protocol conforms to the ISO 8072 Service
Definition and the ISO 8073 Protocol Standard. They define
OSI Transport Protocol classes 0, 2 and 4 (TP 0, TP 2, and TP 4).
This protocol can use two types of ISO Network service:
o Connection-Oriented Network Service (CONS)
o Connectionless-Mode Network Service (CLNS)
The Routing module provides a connectionless network service
(CLNS). The X.25 Access module, if configured into the system,
provides a reliable connection-oriented network service (CONS).
For Tru64 UNIX, any attributes that are specific to CONS will only
be accessible if X.25/CONS has been installed and configured into
the system. See X.25/CONS Configuration for more information. The
Connectionless Transport Service, known as CLTS or CLTP, allows
for the transfer of data between correspondent Transport Service
users on a connectionless basis. The service provides for single-
access data transfer for corresponding Transport Service users,
without the overhead of establishing a connection. This protocol
benefits those applications that require a one-time, one-way
transfer of data toward one Transport Service user. CLTS runs
over CLNS.
The OSI transport conforms to the RFC1006 Standard and to the
RFC1859 Standard. They define how to implement ISO 8073 Transport
Class 0 on top of TCP (RFC1006) and how to implement ISO 8073
Transport Class 2 Non-use of Explicit Flow Control on top of TCP
(RFC1859, once known as 1006 Extension). The network service used
is provided by TCP. These OSI over TCP/IP and DECnet over TCP/IP
features require an installed TCP/IP product that supports the PWIP
interface.
Refer to NETWORK_SERVICES below for a table which shows the
relationship between the transport protocols and the network
services.
Refer to PROTOCOL_CLASSES for a table describing the protocol
classes, their functions, and which network service can be used.
11.1 – Protocol Classes
The following table describes the protocol classes, their functions,
and which Network service can be used.
Protocol Functions Network Service
Class
---------------------------------------------------------------------
TP 0 Provides a basic Transport Service. CONS and RFC1006
TP 2 Provides Provides all functions of CONS and RFC1006 Ext
TP 0. Provides multiplexing of more
than one transport connection over a
Network Connection or TCP connection.
Provides flow control over CONS.
TP 4 Provides all functions of TP 2. CONS and CLNS
Provides error detection and recovery.
Some other differences are that:
o TP 0 relies on the upper layers to do its error correction.
This class is disconnected if the underlying Network layer is
disconnected.
o TP 2 and 4 use disconnect requests.
o TP 4 reassigns the OSI Transport connection to another Network
layer connection if the existing one fails.
When a Transport user sets up a Transport connection, a preferred
protocol class for the connection is specified in the connection
request. The responding Transport user must either agree to this
protocol class, or suggest an alternative protocol class that is
acceptable to the initiating user. If no such agreement is possible,
the Transport connection cannot be set up.
11.2 – Connection Phases
An OSI Transport connection is an end-to-end connection. It is a
reliable two-way, data-transfer path between two OSI Transport
users. An OSI Transport connection has three phases:
o Setting up the connection -- an OSI Transport user (the
initiating user) on one end system (the initiating host) sends a
connection request TPDU to another OSI Transport user (the
responding user) on a second end system (the responding host).
When a successful connection is made, data transfer can take
place in either direction.
o Using the connection to transfer data through -- OSI Transport
connections support two kinds of data transfer:
- Normal data transfer --- for usual message exchange or
- Expedited data transfer --- bypasses any blockage
due to the flow control applied to normal data; only for
sending small amounts of data; has its own type of TPDU
and transmission rules.
o Releasing the connection -- either transport user can release the
OSI transport connection by sending a disconnect TPDU.
11.3 – Network Services
The following table shows the relationship between the transport
protocols and the network services.
Table 1-1 Transport Protocols and Network Services
_______________________________________________________________________
Class 4 Class 4 Class 2 Class 0 CLTS RFC RFC
(COTS) (COTS) (COTS) (COTS) over 1006 1859
Port over over over over CLNS
Att- CLNS CONS CONS CONS (Tru64
ributes UNIX)
_______________________________________________________________________
Acknow- * *
ledgement
delay time
Checksums * *
Client * * * * * *
CONS * * *
template
CR timeout * * * *
Direction * * * * * *
ER timeout * * * *
Expedited * * * *
data
Extended * * *
format
Inactivity * *
time
Initial * *
retransmit
time
Keepalive * *
time
Local DTE
address * * *
Local * *
RFC1006 IP
address
Local nsap * * * * *
Local * * * * * *
Reference
Local * * * * * * *
transport
selector
Maximum nsdu * * * * *
size
Name * * * * * * *
Negotiable * * * *
classes (Tru64 UNIX)
Negotiated * * * * * *
tpdu size
Network port* * * *
Network * * * * * * *
service
Protocol * * * * * *
class
Remote DTE * * *
address
Remote * * * *
identifier
Remote nsap * * * *
Remote
RFC1006 * *
port
number
Remote * *
RFC1006
IP address
Remote * * * * * *
reference
Remote * * * * * *
transport
selector
Request ac- * *
knowledgment
Retransmit * *
threshold
Roundtrip * *
delay
estimate
Type * * * * * * *
UID * * * * * * *
Use clns *
error
reports
Template Attributes
Acknow- * *
ledgment
delay time
Checksums * *
Classes * * * *
CONS * * *
template
CR timeout * * * *
ER timeout * * * *
Expedited * * *
data
Inbound * * * * * * *
Initial * *
retransmit
time
Keepalive * *
time
Local nsap * * * * *
Maximum nsdu * * *
size
Name * * * * *
Network * * * * *
service
Retransmit * *
threshold
RFC1006 * *
port number
Security * * * *
Use clns *
error
reports
11.4 – Subentities
The entity hierarchy for the OSI Transport module is:
_Application (OpenVMS)
|
Node___OSI_Transport___|_Local_NSAP______________Remote_NSAP
|
|_Port
|
|_Template
The OSI TRANSPORT entity is the top-level entity in the hierarchy
of entities belonging to the OSI Transport module.
An OSI TRANSPORT APPLICATION entity stores information about an
end user that is activated for receipt of an incoming connection
request when the request contains that end user's name in its
Destination Name field. The application-name refers to the
application managed by this command.
An OSI TRANSPORT LOCAL NSAP entity is automatically created for
each NSAP address used by the osi transport entity. Local NSAPs
are used primarily to group together remote NSAPs (see the OSI
transport local NSAP remote NSAP entity). The nsap-address refers
to the local NSAP managed by this command.
An OSI TRANSPORT LOCAL NSAP REMOTE NSAP entity maintains
the transport counters and generates events resulting from
interactions between its superior local NSAP and a remote
transport service. The nsap-address refers to the remote NSAP
managed by this command.
An OSI TRANSPORT PORT entity represents one end of a transport
connection and maintains status information about that
connection. Although the connectionless transport protocol
does not create transport connections, ports are still used to
maintain status information.
On Tru64 UNIX, a port can also represent a listener, which is
a passive endpoint awaiting connect requests from the remote
transport service provider. Normally, ports exist only when
OSI transport is enabled. However, the port that represents the
session control listener (local transport selector 'DEC'0'H) is
a special case. This port can exist even when OSI transport is
disabled.
The port attributes type, and for Tru64 UNIX direction, can be
used to distinguish the various uses of ports. The port-name
refers to the name of the port managed by this command.
An OSI TRANSPORT TEMPLATE entity provides a collection of
characteristics that supply default values for certain parameters
that influence the operation of a port on a transport connection.
One template, with the reserved identifier default, is
automatically created when the osi transport entity is created.
This template is used by default when a user does not specify
a template identifier in a call to establish a connection.
The default template is automatically deleted when the osi
transport entity is deleted. Similarly, the initial values of
the attributes in a template are the same as the current values
in the default template. The template-name refers to the template
managed by this command.
For Tru64 UNIX, the only attributes that apply to CLTS are
checksum, network service, and local nsap.
12 – Routing
The Routing module implements the Network Routing layer described
by the Digital Network Architecture. It routes messages in the
network and manages the message packet flow. The Routing module
components provide the following functions:
o Routing-determines packet paths. A path is the sequence
of connected nodes and links between a source node and a
destination node. The combined knowledge of all the network
Routing layer modules of all the nodes in a network is used to
determine the existence of a path, and route the packet to its
destination. The routing component at a routing node has the
following specific functions:
- Extracts and interprets the route header in a packet.
- Performs packet forwarding based on the destination
address.
- Performs packet fragmentation where necessary.
- Manages the characteristics of the path and if a node or
link fails on a path, finds an alternate route.
- Interfaces with the Network Routing Subnetwork Dependent
sublayer to receive reports concerning a circuit or node
that has failed or the subsequent recovery of a circuit or
node.
- Performs packet reassembly at the destination.
- Returns error reports to the source where necessary, for
instance when the destination is unreachable or when the
packet would have needed to be fragmented but segmentation
permitted was not set in the packet. Segmentation permitted
is always set in data packets generated by DNA nodes.
However, non-DNA nodes may do otherwise.
o Congestion control-manages the resources used at each packet
switching node (each node that permits route-through).
o Packet lifetime control-bounds the amount of time a packet can
exist in the network.
o Initialization-identifies the adjacent node and the
adjacent node's network routing layer. It also performs node
verification, if required.
o Dynamic circuit management-determines when to dial calls, when
to hang up calls, and (on dynamically assigned circuits) which
DTE address to dial. It exists only on dynamically established
data links.
12.1 – Subentities
The entity hierarchy for the Routing module is:
_Destination_Area
| _Adjacency
| |_IP_Address_Translation
|_Circuit_______________|_IP_Adjacency
| |_IP_Reachable_Address
| |_Reachable_Address
Node___Routing___|
|_EGP_Group_______________EGP_Neighbor
|_Destination_Node
|_IP_Destination_Address
|_Port
|_Permitted_Neighbor
The ROUTING entity is the top-level entity in the Routing module
hierarchy of entities. The Routing module controls the operation
of network routing within a node.
A ROUTING DESTINATION AREA entity contains information about a
destination area or reachable address prefix. These entities are
created and deleted dynamically by the Routing module.
Destination areas exist only on nodes that are level 2 routers.
The address-prefix is the destination area managed by this
command.
A ROUTING CIRCUIT entity represents a data link to another node.
The circuit-name refers the circuit managed by this command.
A ROUTING CIRCUIT ADJACENCY entity describes an adjacency,
which is a neighboring node that is accessible via a particular
circuit. The circuit-name refers to the circuit associated
with the specified adjacency. The adjacency-name refers to the
adjacency managed by this command.
The create and delete commands are allowed only if circuit
is csma-cd and type is L1router or L2router. In addition, the
delete command is allowed on end systems only for x25 da circuit
adjacencies.
A ROUTING CIRCUIT IP ADDRESS TRANSLATION entity describes the
mapping between the IP address of an IP adjacency on a broadcast
circuit and its LAN address. This entity is supported only
on systems that support dual routing. ip address translation
entities are created automatically, but can be deleted manually.
A ROUTING CIRCUIT IP REACHABLE ADDRESS entity describes a
manually entered subnet address that is accessible by way of
a specified circuit. An IP reachable address allows a level 2
router at the boundary of a routing domain to include information
about the address and reachability of subnetworks outside the
domain. IP reachable addresses exist only on level 2 routers that
support dual routing.
A ROUTING CIRCUIT REACHABLE ADDRESS entity describes information
about a manually entered address prefix accessible over that circuit.
It exists only on L2 routers and end nodes. On L2 routers the
type may be outbound or inbound.
A reachable address of type outbound (default) describes address
prefixes in an external domain that are reachable by outbound
traffic over this circuit. For end systems, the circuit can be
either an X.25 DA circuit or a broadcast circuit on L2 routers.
The routing information contained in the reachable address is
entered directly into the L2 decision process. When
ManualL2Algorithm has the value routing vector, only reachable
addresses with address prefixes corresponding to Phase IV areas are
fed into the decision process.
On an L2 router, an inbound reachable address describes address
prefixes corresponding to Phase IV areas which are reachable
through the local node by inbound traffic over this circuit. The
routing information contained in the reachable address (area and cost)
is entered into a Phase IV routing vector message, which is
transmitted periodically over this circuit.
On an end system the type may be outbound or (for a broadcast
circuit only) filter. A reachable address of type outbound behaves
in a similar way to that on an L2 router except that the routing
information is used to control the operation of the ES cache. A
reachable address of type filter (for a broadcast circuit only)
specifies the permitted LAN addresses of routers on the LAN that
will be used by the cache algorithm.
For either outbound or filter type, the mapping attribute should be
set to manual because the default is X.121.
A ROUTING DESTINATION NODE entity contains information about a
particular destination node within the same area as this node.
These entities are created and deleted automatically by the
Routing module. Destination nodes exist only on nodes that are
level 1 or level 2 routers.
A ROUTING EGP GROUP entity defines a set of systems in the
same autonomous system with which this system may exchange
EGP messages. This entity is supported only on level 2 routers
that support dual routing (and, in particular, the EGP routing
protocol).
A ROUTING EGP GROUP EGP NEIGHBOR entity defines one of the
systems in the autonomous group defined by the owning egp
group entity. This entity is supported only on level 2 routers
that support dual routing (and, in particular, the EGP routing
protocol).
A ROUTING IP DESTINATION ADDRESS entity describes IP routing
information in the shortest paths database. This entity is
supported only on routers that support dual routing.
A ROUTING PERMITTED NEIGHBOR entity represents a neighboring node
on a nonbroadcast circuit that is permitted to connect to this
node. The neighbor-name is the name of the permitted neighbor
managed by this command.
A ROUTING PORT entity represents a client of the Routing module,
and presents information associated with that client. The port-
name refers to the port managed by this command.
13 – X25 Protocol
The X.25 Protocol module resides in the Network layer of the Digital
Network Architecture (DNA). It provides the X.25 Packet Level
interface into the Packet Switching Data Network.
13.1 – Subentities
The entity hierarchy for the X25 Protocol module is:
Node___X25_Protocol____DTE___PVC
|
|_Group
The X25 PROTOCOL entity is the top-level entity in the X.25
Protocol module hierarchy of entities. The X.25 Protocol module
operates the packet-level protocol interface to a PSDN, as
defined by the CCITT and ISO specifications.
An X25 PROTOCOL DTE entity describes a local DTE.
An X25 PROTOCOL DTE PVC entity describes a permanent virtual
circuit (PVC).
An X25 PROTOCOL GROUP entity specifies a number of DTEs that make
up a Closed User Group (CUG).
14 – X25 Access
The X.25 Access module resides in the Application layer of the Digital
Network Architecture (DNA). It interfaces with the X.25 Protocol,
X.25 Client, and X.25 Server modules to provide X.25 services and
functions as described in the DNA X.25 Access Architecture.
14.1 – Subentities
The entity hierarchy for the X25 Access module is:
_DTE_Class
|_Reachable_Address
|_Port
Node___X25_Access___|_Filter
|_Security_DTE_Class___Remote_DTE
|_Security_Filter
|_Template
|_Application
The X25 ACCESS entity is the top-level entity in the X.25 Access
module hierarchy of entities.
An X25 ACCESS DTE CLASS entity defines a named class of DTEs.
The class-name refers to the class managed by this command. A DTE
class may refer to either of the following:
o A group of local DTEs.
o A group of DTEs on a remote gateway system.
An X25 ACCESS FILTER entity defines the criteria by which the
destination of an incoming call is determined.
When the x.25 access entity is created, the network manager must
create an x25 access filter entity with the name osi transport.
This filter is used by the osi transport entity. The filter-name
refers to the filter managed by this command.
An X25 ACCESS PORT entity represents an X.25 virtual circuit.
Ports are created and deleted automatically as circuits are
established and cleared. The port-name refers to the port managed
by this command
An X25 ACCESS REACHABLE ADDRESS entity maps a destination Network
Service Access Point (NSAP) address in an outgoing call to a DTE
class/DTE address pair. The address-name refers to the address
managed by this command.
An X25 ACCESS SECURITY DTE CLASS entity is used to control
inbound and outbound calls. The class-name refers to the class
managed by this command.
An X25 ACCESS SECURITY DTE CLASS REMOTE DTE entity is a
collection of access control attributes that control inbound
calls from and outbound calls to a particular remote DTE.
An X25 ACCESS SECURITY FILTER entity is a collection of access
control attributes that controls access to one or more filters.
The filter-name refers to the filter managed by this command.
An X25 ACCESS TEMPLATE entity is used to supply default values
for call parameters when an outgoing call is made. Values in a
template can be overridden by user-supplied values.
For Tru64 UNIX, two x25 access template entities need to be
created by the network manger: the default and OSI Transport
templates. These templates are generated automatically if you run
either the basic or advanced configurator.
An X25 ACCESS APPLICATION entity defines an application to be
initialized for an incoming call. The application-name refers to
the application managed by this command. An application type may
be one of the following:
o X.25
o X.29
o X.29 Login
15 – X25 Client (OpenVMS)
The X.25 Client module resides in the Application layer of the
Digital Network Architecture. It interfaces with the X.25 Access
module to establish communications with its X.25 Server system over
a DNA Session Control connection using the GAP protocol.
The X.25 Client Module contains no other Entities.
The X25 CLIENT entity describes the X.25 client interface in an
accessing system, through which X.25 clients gain access to a
PSDN via an X.25 server in a gateway system.
15.1 – Subentities
There are no subentities beneath the X25 Client module.
16 – X25 Relay (Alpha)
The X.25 Relay module resides in the application layer of the
Digital Network Architecture (DNA). It interfaces with the X.25
Access module to receive an incoming switched virtual call and then
makes an outgoing call through the X.25 Access module. Facilities
also exist for relaying permanent virtual circuits (PVCs).
The x25 relay entity accepts an incoming call from one client and
redirects it to another client.
16.1 – Subentities
The entity hierarchy of the X25 Relay module is:
Node___X25_Relay____Client
|
|_PVC
An X25 RELAY CLIENT entity provides a set of default values to be
used to set up a relay between an incoming call and an outgoing
call.
An X25 RELAY PVC entity provides a set of default values to
be used to establish a connection to a client over a permanent
virtual circuit.
17 – X25 Server
The X.25 Server module resides in the Application layer of the
Digital Network Architecture (DNA). This module interfaces with the
X.25 Access module to listen for incoming calls for X.25 Client
systems, and to make outgoing calls on behalf of X.25 clients.
17.1 – Subentities
The entity hierarchy of the X25 Server module is:
Node___X25_Server____Client
|
|_Security_Nodes
The X25 SERVER entity represents the X.25 server that runs on a
gateway system. The X.25 server serves X.25 clients on accessing
systems, providing X.25 access to systems that do not have a
direct connection to a PSDN.
An X25 SERVER CLIENT entity provides a set of default values to
be used to establish a session control connection with an X.25
client when an incoming call arrives for that client. You should
create an x25 server client entity for each X.25 client with
which the gateway system is associated.
An X25 SERVER SECURITY NODES entity defines the set of rights
identifiers associated with calls issued by the X.25 Server
module (on behalf of the X.25 Client module at an accessing
system) to the X.25 Access module at the gateway system. These
rights identifiers are used when making access control checks on
the DTE class specified when a call is made.
18 – XOT (OpenVMS Alpha)
The X.25 Over TCP/IP (XOT) component of X.25 enables transmission
of X.25 packets over a wide area network composed of TCP/IP
connections using the methods described in RFC1613.
18.1 – Subentities
The entity hierarchy of the XOT module is:
Node___XOT____Port
|
|_SAP___Link
The XOT entity represents the datalink interface to X.25.
A XOT PORT entity provides information on each active XOT
connection over TCP/IP, showing which X.25 protocol DTE entity is
using a link. Ports are created and deleted dynamically as X.25
connections are requested. There is one Port entity for each PVC
or SVC connection.
A XOT SAP entity specifies the point at which XOT gains access to
the TCP/IP environment for purposes of listening for inbound XOT
connections. There can be a single XOT SAP entity to listen on
any available IP interface; or one or more XOT SAP entities can
be used to listen on specific IP interfaces.
A XOT SAP LINK entity represents a remote system with which XOT is
allowed to communicate. In the case of an inbound XOT connection,
there must be a LINK entity with a matching remote IP address and
remote port number in order for XOT to accept the TCP/IP connection.
In the case of an outbound connection, the LINK specifies the
remote IP address and remote port number of the system with which
to attempt the TCP/IP connection.
19 – LAPB
The LAPB module implements one of the protocols in the Link layer
described by the Digital Network Architecture.
NOTE
For Tru64 UNIX, the WAN Device Drivers are provided as an
installable subset within the product HP Wide Area Network Support
for Tru64 UNIX. You must install this subset before you can refer
to LAPB module entities in an NCL command.
For OpenVMS, you must install the WAN Device Drivers from the
HP X.25 for OpenVMS product before you can refer to the LAPB
module entities in an NCL command.
19.1 – Subentities
The entity hierarchy of the LAPB module is:
Node___LAPB____Link
|
|_Port
The LAPB entity is the top-level entity in the LAPB module
hierarchy of entities. The LAPB module implements the LAPB
link-level protocol which is a variation of the HDLC link-level
protocol.
A LAPB LINK entity is associated with a port of the supporting
Physical layer, and contains attributes that describe local LAPB
operation. The simple-name refers to the link managed by this
command.
A LAPB PORT entity represents an access point for LAPB module
clients to Data Link layer services. The port-name refers to the
port managed by this command.
20 – CSMA-CD
A Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
Local Area Network (LAN) provides high-speed communications channels
for connecting computers and other digital devices located within a
moderate-sized geographic area. Like other LANs, the CSMA/CD LAN
falls between long-distance, low-speed networks that carry data
for hundreds or thousands of kilometers, and specialized, very
high-speed intercommunications that are generally limited to tens
of meters. The CSMA/CD LAN is intended primarily for use in such
areas as office automation, distributed data processing, terminal
access, distributed systems and other situations requiring
economical connection to a local communication medium carrying
sporadic traffic at high-peak data rates.
For Tru64 UNIX, the DNA CSMA/CD module incorporates the functions
and operations defined in the Ethernet Specification V2.0 and the
ISO 8802-3 (IEEE 802.3) CSMA/CD Access Method and Physical Layer
specification as well as parts of the ISO 8802-1 (IEEE 802.1)
Addressing, Internetworking, and Network Management and the ISO
8802-2 (IEEE 802.2) Logical Link Control specifications. To this
the DNA CSMA-CD module adds features often needed by users of the
Data Link. A typical such Data Link user is the Network Layer of
the DNA.
20.1 – Subentities
The subentities below the CSMA-CD module are:
Node___CSMA-CD____Port
|
|_Station
The CSMA-CD entity is the top-level entity in the hierarchy of
entities belonging to the CSMA-CD module.
A CSMA-CD PORT entity represents an access point to the service
offered by the CSMA-CD module. A client transmits and receives
data through a port. Ports are created and deleted by client use
of open and close service interface procedures. The port-name
refers to the port managed by this command.
A CSMA-CD STATION entity manages a CSMA/CD controller. Wherever
Phase IV DECnet manages a line, DECnet-Plus manages a station.
Each station corresponds to a particular logical link control
(LLC), medium access control (MAC), and physical attachment. The
station-name refers to the station managed by this command.
21 – LLC2
The LLC2 module implements one of the protocols in the Data Link
layer described by the Digital Network Architecture.
NOTE
For Tru64 UNIX, the WAN Device Drivers are provided as an
installable subset within the product HP Wide Area Network Support
for Tru64 UNIX. You must install this subset before you can refer
to LLC2 module entities in an NCL command.
For OpenVMS, you must install the WAN Device Drivers from the
HP X.25 for OpenVMS product before you can refer to the LLC2
module entities in an NCL command.
21.1 – Subentities
The entity hierarchy of the LLC2 module is:
Node___LLC2____Port
|
|_SAP___Link
The LLC2 entity is the top-level entity in the LLC2 module
hierarchy of entities. The LLC2 module controls the operation of
the LLC Type 2 data link protocol for local area networks (LANs).
An LLC2 PORT entity represents an access point to the services
offered to clients by the LLC2 module. Each LLC2 PORT entity has
an LLC2 SAP (service access point) entity associated with it.
An LLC2 SAP entity allows links to be multiplexed over its
associated port.
An LLC2 SAP LINK entity represents one of the links operating over a
particular sap (service access point).
22 – MOP
The Maintenance Operations Protocol (MOP) module is located in the
Application layer described by the Digital Network Architecture.
MOP has a direct connection with the Data Link layer; thus, for
certain functions, MOP can bypass the higher layers in the DNA
protocol tower. This is useful for nodes which do not (yet) have
all the higher layers of DNA protocol towers installed. Functions
provided by the MOP module include down-line loading, up-line
dumping, and communications testing.
22.1 – Subentities
The entity hierarchy of MOP module is:
Node___MOP____Circuit____Operation
| |
| |_Station
|_Client
The MOP entity is the top-level entity in the hierarchy of
entities belonging to the MOP module.
A MOP CIRCUIT entity is a data link circuit on which MOP services
are available. The status attribute functions specifies the
services enabled on the circuit. The circuit-name refers to the
circuit managed by this command.
The MOP CIRCUIT OPERATION entities are created automatically
by MOP for all operations, including those initiated by NCL
action directives and those initiated by automatic load and dump
service. They are deleted when the corresponding operation is
complete.
The MOP CIRCUIT STATION entities are created automatically by the
Configuration Monitor. They are deleted when the circuit entity
is deleted. The Configuration Monitor function must be enabled
on the MOP circuit for these entities to be created. For more
information, refer to HELP NETWORK_MANAGEMENT TOOLS
CONFIGURATION_MONITOR.
A MOP CLIENT entity is a set of default characteristics used
by these MOP functions: dump/load server, load requester, loop
requester, and console requester. When a command or a request
for one of these services does not supply all of the required
arguments, the values stored by the client are used to perform
the operation. The client-name refers to the client managed by
this command.
23 – HDLC
The HDLC module implements one of the protocols in the Data Link
layer. The HDLC (High-level Data Link Control) protocol is intended
to cover a wide range of applications; for example, one-way, two-way
alternate or two way simultaneous data communication between
data stations which are usually buffered, including operations on
different types of data circuits; for example multipoint/point-
to-point, duplex/half-duplex, and switched/non-switched. This
implementation uses HDLC to offer reliable communication at the
Data Link layer for point-to-point synchronous data lines over a
wide area network link. The HDLC module typically runs as a Data
Link module under the CLNS Network protocol.
NOTE
For Tru64 UNIX, the WAN Device Drivers are provided as an
installable subset within the product HP Wide Area Network Support
for Tru64 UNIX. You must install this subset before you can refer
to HDLC module entities in an NCL command.
For OpenVMS, you must install the WAN Device Drivers from the
HP X.25 for OpenVMS product before you can refer to the HDLC
module entities in an NCL command.
23.1 – Subentities
The entity hierarchy of the HDLC module is:
Node___HDLC____Link____Logical_Station
|
|_Port
The HDLC entity is the top-level entity in the hierarchy of
entities belonging to the HDLC module.
An HDLC LINK entity is associated with a port of the supporting
physical layer module. It contains attributes common to local
HDLC operations for all logical stations on the line. The link-
name refers to the HDLC link managed by this command.
The HDLC LINK LOGICAL STATION entity controls the characteristics
of an HDLC logical station. There is one station for each remote
termination of a line associated with the HDLC link. The link-
name is the link entity within the HDLC module and the logical-
station-name refers to the logical station managed by this
command.
The HDLC PORT entity represents one end of an HDLC connection.
The entity maintains information about that link. Ports are
created and deleted automatically when a client of HDLC uses the
link. The port-name refers to the port managed by this command.
24 – DDCMP (OpenVMS VAX)
The Digital Data Communications Message Protocol (DDCMP) module is a
data link control procedure that ensures a reliable data communication
path between communication devices connected by data links. DDCMP has
been designed to operate over full- and half-duplex synchronous
and asynchronous channels in both point-to-point and multipoint
modes. It can be used in a variety of applications such as
distributed computer networking, host/front end processing,
remote terminal concentration, and remote job entry-exit system
operation.
24.1 – Subentities
The entity hierarchy for the DDCMP module is:
Node___DDCMP____Link___Logical_Station
|
|_Port
The DDCMP entity is the top-level entity in the hierarchy of
entities belonging to the DDCMP module.
The DDCMP LINK entity defines the attributes of a link to a
communications port that uses the DDCMP protocol. The link-name
refers to the link managed by this command.
The DDCMP LINK LOGICAL STATION entity manages a link to a remote
station. The link-name is the DDCMP link associated with the
logical station and the station-name refers to the logical
station managed by this command.
A DDCMP PORT entity represents an access point to the Data Link
layer service offered by ddcmp. Ports are created and deleted
automatically when a client of ddcmp uses the link. The port-name
refers to the port managed by this command.
25 – FDDI
The FDDI module implements one of multiple possible Link level/-
Network level modules in the OSI layered architecture model.
DNA Fiber Distributed Data Interface (FDDI) is the basis for
the second generation of network interconnect architecture for
Digital. The FDDI module implements one of the multiple possible
Link level/Physical level modules in the OSI layered architecture
model. The FDDI Physical level includes high speed, 125 megabaud,
fiber optic links which may be many kilometers in length. The
FDDI Link level provides a high bandwidth, 100 megabits per
second local area network (LAN), and uses the ANSI standard FDDI
Token Ring.
25.1 – Subentities
The entity hierarchy for the FDDI module is:
Node___FDDI____Station____Link
| |
| |_PHY Port
|_Port
The FDDI module incorporates the functions and operations
defined in the ANSI FDDI Token Ring Media Access Control (MAC),
the ANSI FDDI Token Ring Physical Layer Protocol (PHY), FDDI
Physical Layer Medium Dependent (PMD), Station Management (SMT)
specifications, parts of the ISO 8802-1 (IEEE 802.1) Addressing,
Internetworking and Network Management, and parts of the ISO
8802-2 (IEEE 802.2) Logical Link Control (LLC) specifications.
The FDDI entity is the top-level entity in the hierarchy of
entities belonging to the FDDI module.
An FDDI STATION entity represents an access point to the service
offered by the FDDI module. The FDDI data link can be monitored
and controlled through DNA network management. The station-name
refers to the station managed by this command.
The FDDI STATION LINK entity is a subentity of the FDDI STATION
entity. The fddi station link subentity provides the management
view of LLC and the FDDI MAC. FDDI allows stations to be either
single MAC or dual MAC and therefore there can be up to two link
subentities for each station. In most cases, a station has at
least one link entity. Concentrators may have no link entity and
are not addressable on the FDDI, though they may be using other
communications channels.
An FDDI STATION PHY PORT entity provides the management view of
the fddi station phy port and the fddi pmd. Each station has at
least one phy port and a concentrator is a device that has at
least one phy port of type M. A dual attached station or dual
attached concentrator has a phy port type A and type B. A single
attached station has a phy port of type B.
An FDDI PORT entity represents an access point to the service
offered by the FDDI module. A client transmits and receives data
through a port. Ports are created and deleted by client use of
open and close service interface procedures. The port-name refers
to the port managed by this command.
26 – Modem Connect
The Modem Connect module implements one of the protocols in
the Physical layer described by the Digital Network Architecture.
NOTE
For Tru64 UNIX, the WAN Device Drivers are provided as an
installable subset within the product HP Wide Area Network Support
for Tru64 UNIX. You must install this subset before you can refer
to the modem connect module entities in an NCL command.
For OpenVMS, you must install the WAN Device Drivers from the
HP X.25 for OpenVMS product before you can refer to the modem
connect module entities in an NCL command.
26.1 – Subentities
The entity hierarchy for the Modem Connect module is:
Node___Modem_Connect____Data_Port
|
|_Line
The MODEM CONNECT entity is the top-level entity in the hierarchy
of entities belonging to the Modem Connect module.
The MODEM CONNECT DATA PORT entity is associated with a line and
handles the transfer of data. Data ports are created and deleted
automatically when a client of the Modem Connect module uses a
line. The port-id is the data port managed by this command.
A MODEM CONNECT LINE entity is associated with a physical circuit
on the node. Usually, there is one line entity for each circuit.
The line-id is the line managed by this command. The MODEM
CONNECT LINE entity has an extra set of status attributes
that let you examine the instantaneous status of the interchange
circuits on the line. These circuit attributes are known by different
names in the various interface standards. For instance, the
DATA TERMINAL READY attribute is the name used for the CCITT V.24
circuit 108/2, the EIA-232-D CD circuit, the RS-499 TR circuit,
and so on. For further information, refer to the Network Control
Language Reference manual.
27 – Device
The Device module provides management of physical devices attached
to a network system that must load microcode from a host system
before it is operational.
NOTE
For Tru64 UNIX, the WAN Device Drivers are provided as an
installable subset within the product HP Wide Area Network Support
for Tru64 UNIX. You must install this subset before you can refer
to the device module entities in an NCL command.
For OpenVMS, you must install the WAN Device Drivers from the
HP X.25 for OpenVMS product before you can refer to the device
module entities in an NCL command.
27.1 – Subentities
The entity hierarchy for Device module is:
Node___Device___Unit
The DEVICE entity is the top-level entity in the hierarchy of
entities belonging to the Device module.
The DEVICE UNIT entity controls the loading and dumping of
microcode for a specific communications device. The simple-name
refers to the device unit managed by this command.
28 – Frame (OpenVMS)
The Frame module provides framing functions for a communications
link. It enables those who implement their own level 2 protocols
to manage the links that use those protocols.
NOTE
You must install the WAN Device Drivers from the HP X.25 for
OpenVMS product before you can refer to the frame module entities
in an NCL command.
28.1 – Subentities
The entity hierarchy for the Frame module is:
Node___Frame____Link
|
|_Port
The FRAME entity is the top-level entity in the hierarchy
belonging to the Frame module. The entity provides framing
functions for a communications link. The entity does not provide
any data link protocol capabilities, and is used by those who
want or need to operate their own level 2 protocols.
A FRAME LINK entity is associated with a physical line, and
controls the framing protocol used on that line. There is one
frame link entity for each physical line.
A FRAME PORT entity represents an access point to the data
link service offered by the Frame module. Ports are created and
deleted automatically when a client of DDCMP uses the link.
29 – Token Ring (Tru64 UNIX)
The Token Ring module implements one of multiple possible Link
level/Physical level modules in the OSI layered architecture model.
The DNA IEEE 802.5/Token Ring Data Link provides either a
4 or 16 Mbps local area network (LAN). It provides communication
services for multiple concurrent users. The services provided are
LLC, Mapped Ethernet and Station Management (SMT) services.
The DNA IEEE 802.5/Token Ring module incorporates the
functions and operations defined in the IEEE 802.5 Token Ring
Access Method, parts of the ISO 8802-1 (IEEE 802.1) Addressing,
Internetworking and Network Management, and parts of the
ISO 8802-2 (IEEE 802.2) Logical Link Control (LLC) specifications.
To this, the DNA 802.5/Token Ring Data Link adds features often
needed by users of the data link. A typical such user is the
Network Layer of the Digital Network Architecture (OSI).
29.1 – Subentities
The entity hierarchy of the Token Ring module is:
Node___Token_Ring____Port
|
|_Station____Source_Route
|
|_FA_Map
The TOKEN RING entity is the top-level entity in the hierarchy of
entities belonging to the Token Ring module.
A TOKEN RING PORT entity represents an access point to the service
offered by the Token Ring module. A client transmits and
receives data through a port. Ports are created and deleted by
client use of open and close service interface procedures.
The port-name refers to the port managed by this command.
A TOKEN RING STATION entity manages a Token Ring controller. Each
station corresponds to a particular instance of Logical
Link Control (LLC), Medium Access Control (MAC), and physical
attachment. The Token Ring data link can be monitored and controlled
through DNA network management. The station-name refers to the
station managed by this command.
A TOKEN RING STATION SOURCE ROUTE entity describes an entry in the
Source Routing database. In Transparent Source Routing, the Source
Route entities are typically created and enabled by the parent
Station entity. The sourceroute-id refers to the source route
entity managed by this command.
The TOKEN RING STATION FA MAP (Functional Address Mapping) entities
describe the default Functional Address-Global Address mapping to be
applied to ports that are created with the same protocol identifiers.
The famap-id refers to the FA map entity managed by this command.
30 – Loopback Application
The Loopback Application module allows a network manager to
invoke a loopback test between applications on two nodes,
thus testing all the supporting layers of the Digital Network
Architecture.
The Loopback Application module has two components:
o The loop access module, which initiates the loopback test
o The loop mirror module, which accepts connections from the
remote loop access modules and mirrors any data sent to it
back to the sender.
The Loopback Application module has only one entity: the loopback
application entity. This loopback application entity describes
features of the Loopback Application module which allows you to
run a loopback test between two nodes or itself. The loopback
application entity is created and deleted automatically with the
node entity, and is always enabled.