A management station can use this MIB module for the maintenance of persistent topology information of the PNNI network. Previously, a management station had to query the network to retrieve the network topology via an Integrated Local Management Interface (ILMI) link. The nodes that are down or the nodes whose ILMI-enabled links are down will not be included in the topology. To rectify this limitation, the concept of persistent topology is used. The persistent topology feature requires the following: - a node configured to be the gateway node - PNNI links between the nodes - node and feeder database. A Gateway Node, for the purpose of this MIB module, is defined to be a node that is capable of maintaining a persistent topology database based on the PNNI Topology State Elements (PTSEs) sent by the other nodes in the PNNI peer group. The topology database is persistent across reboots. A feeder, in the context of this MIB, is defined as an ATM switch which does not have PNNI feature. It is connected to a node(with PNNI feature, therefore with routing capability) through a physical link. (The provisioning of the feeder and the link are beyond the scope of this MIB.) When a feeder and the link are provisioned, the feeder will update the routing node with its information(for example: feeder name, the feeder's port ifIndex etc.). The routing node will group these feeder information along with its own information(for example: its node identifier, its feeder port's information etc.) and send it to other nodes in the peer group in the PTSE. Upon receiving this PTSE, each node will update its database. The same actions are repeated when some information are modified on the feeder. A network management station can retrieve these information from a Gateway Node's database. In the case of a feeder failure, or a feeder is removed from the network, or the feeder's routing node failure, the feeder's corresponding entry in the database will not be removed. The only way to remove an entry from the database is for the network management station to delete this entry explicitly. A link, in the context of this MIB, is defined as a PNNI link between two PNNI nodes. (a) The nodal information for each node in the peer group stored in the persistent topology database includes: - node id - node name - Primary IP address - Secondary IP address - system object identifier - gateway node flag (a flag which indicates whether the node is configured to be a Gateway Node) Each node in a peer group has its own entry in the database. (b) The feeder information for each feeder in the peer group stored in the persistent topology database includes: - Routing node ID(local node ID) - A local port's 'ifIndex' which identifies the port the feeder is connected to on the routing node. - The feeder's 'shelf, slot, port' numbers which identifies the port on the feeder itself. - The protocol type that is used on the link. - The name of the feeder. - The LAN IP address of the feeder. - The ATM IP address of the feeder. - The model number of the feeder which identifies the type of the feeder. Each feeder in a peer group has its own entry in the database. (c) The link information for each node in the peer group stored in the persistent topology database includes: - local node's id, - local node port's ifIndex and corresponding physical descriptor - remote node's id - remote node port's ifIndex and corresponding physical descriptor Each link in a peer group has its own entry in the database. The concept of peer groups is defined by PNNI, and each peer group contains at least one node. The persistent topology database only contains nodal information for the nodes in a particular peer group, because the Gateway Nodes extract the nodal information from PNNI PTSEs, and the PTSEs are flooded only within a peer group. The persistent topology database is used by a management station to discover the topology of the network irrespective of the state and reachability of the nodes in that network. The information in the topology database will not be deleted automatically. The information can only be deleted by the network operator as an administrative measure. This is to ensure that even if a node has gone down, its information will still be in the topology database until it is deleted by the network operator. An outside link is a link that connects to a lowest-level outside node. In contrast to an inside link (i.e., horizontal link) or an uplink, an outside link does not form part of the PNNI topology, and is therefore not used in path computation.