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 

(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
- 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 

(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 
- remote node's id
- remote node port's ifIndex and corresponding physical 

Each link in a peer group has its own entry in the 

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.

Imported Objects

InetAddress, InetAddressTypeINET-ADDRESS-MIB
RowStatus, TimeStamp, TruthValue, TEXTUAL-CONVENTIONSNMPv2-TC
ciscoWanTopologyMIBNotifs .
cwtConfigGatewayStatus .
cwtLinkInfoModify .
cwtLinkInfoDelete .
cwtTopoInfoAdd .
cwtTopoInfoModify .
cwtTopoInfoDelete .
cwtTopoDbFull .
cwtFeederInfoAdd .
cwtFeederInfoModify .
cwtFeederInfoDelete .
cwtLinkInfoAdd .
ciscoWanTopologyMIBObjects .
cwtSystemGroup .
cwtGatewayAdminStatus .
cwtGatewayNodeOperStatus .
cwtDBLastChange .
cwtNodalInfoGroup .
cwtNodeInfoTable .
cwtNodeInfoEntry .
cwtIndex .
cwtSecIPIfName .
cwtSecIPAddrType .
cwtSecIP .
cwtSysObjId .
cwtNodeInfoTimeOutFlag .
cwtRowStatus .
cwtGatewayNodeFlag .
cwtNodeId .
cwtNodeName .
cwtPrimIPIfType .
cwtPrimIPIfName .
cwtPrimIPAddrType .
cwtPrimIP .
cwtSecIPIfType .
cwtFeederInfoGroup .
cwtFeederInfoTable .
cwtFeederInfoEntry .
cwtFeederIndex .
cwtFeederName .
cwtFeederLanIPAddrType .
cwtFeederLanIP .
cwtFeederAtmIPAddrType .
cwtFeederAtmIP .
cwtFeederModelNumber .
cwtFeederRowStatus .
cwtLocalNodeId .
cwtLocalIfIndex .
cwtLocalIfName .
cwtFeederShelf .
cwtFeederSlot .
cwtFeederPort .
cwtFeederLMIType .
cwtFeederType .
cwtLinkInfoGroup .
cwtLinkInfoTable .
cwtLinkInfoEntry .
cwtLinkIndex .
cwtLinkRowStatus .
cwtLinkLocalNodeId .
cwtLinkRemoteNodeId .
cwtLinkLocalIfIndex .
cwtLinkRemoteIfIndex .
cwtLinkLocalPhysicalId .
cwtLinkRemotePhysicalId .
cwtLinkInfoTimeOutFlag .
cwtLinkOutsideLink .
cwtMIBConformance .
cwtMIBCompliances .
cwtMIBGroups .