1 Entity_Hierarchy 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 SUBENTITIES. 2 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. 3 Subentities The entity hierarchy for the DNS Clerk module is: _Known_Namespace | Node___DNS_Clerk___|_Remote_Clearinghouse | |_Manual_Nameserver 2 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 Subentities The entity hierarchy for the DNS Server module is: Node___DNS_Server___Clearinghouse 2 DSA For information about the DSA entity and its subentities, refer to HELP DIRECTORY_MODULE. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 3 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. 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 3 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. 2 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. 3 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. 2 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. 3 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). 2 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. 3 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 2 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. 3 Subentities There are no subentities beneath the X25 Client module. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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). 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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. 3 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. 2 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). 3 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. 2 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.