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.