SNMP MIB Search

The value of this object determines whether this node
is a Gateway Node or not. A value of `enable' configures
this node to be the Gateway Node, and enables
the generation of the topology database. A value of `disable'
configures this node to not be a Gateway Node, and deletes
the topology database if it exists.

This is the operational status of the Gateway Node.
'disabled' indicates that this node is not a
Gateway Node and no topology database is available
on this node.
'enabled' indicates that this node has been configured
as the Gateway Node and the topology database has been
built.
'disabling' indicates that this node is no longer the
Gateway Node and is in the process of deleting the
topology database.
'enabling' indicates that this node has been configured
as the Gateway Node and is in the process of building
the topology database.
'enabledAndFull' indicates that this node has been
configured as the Gateway Node but its topology database
is full.
The management station should always poll this object
first before taking action to:
a) 'enable' or 'disable' the Gateway Node
b) remove an entry or entries from 'cwtNodeInfoTable' and
its corresponding entries from 'cwtFeederInfoTable'.
If the object returns 'disabled', the management station
can 'enable' the Gateway Node if it desires.
If the object returns 'enabled', the management station
can 'disable' the Gateway Node if it desires.
If the object returns 'enabling' or 'disabling', the
management station should not take any actions.
If the object returns 'enabledAndFull', the management
station can take one of the following actions:
a) remove enties from the cwtNodeInfoTable
b) 'disable' and then 'enable' the Gateway Node, which
would cause the node to delete and then rebuild the
topology database. 

The value of MIB II's sysUpTime object at the time that:
a) the topology database is last changed on this node.
b) the cwtGatewayAdminStatus is last changed.
c) the cwtGatewayNodeOperStatus enters the 'enabledAndFull'
state.

This is a row entry in the topology node info table. Each
entry corresponds to one node in the network.

This is a row entry in the feeder info table. Each
entry corresponds to one 'feeder' in the network.

This is an entry in the 'cwtLinkInfoTable'. Each
entry corresponds to one link in the network.
a) The entries in this table are derived from PNNI
PTSE database or added by a network management
station.
b) The entries in the PNNI PTSE database
time out when no new PTSE is received from a node
after a certain time. However, the corresponding
entries are not removed from this table.
c) Only the network management station can delete
an entry from this table.
d) A network management station cannot modify an
existing entry in this table.

This is the index into the topology database array.
This value should remain persistent while the topology
database exists, which means that it'll be consistent
across boots.  However, if this node is disabled as
the gateway node, and later on enabled (by changing the
value of cwtGatewayAdminStatus), then the cwtIndex may
be different for the same node info entry in the topology
database.

This variable indicates if the corresponding entry
is a Gateway Node or not. If this value contains
'true', the corresponding node is a Gateway Node.
If this value contains 'false', then the corresponding
node is not a Gateway Node.

The unique Id which identifies the node in the entry.
This value is different from cwtIndex because it is a
unique number which identifies a node in the ATM network,
while cwtIndex is an index for an entry in the topology
database.  The same physical node can have different
cwtIndex in different topology databases.

The configured name of the node.

This object specifies the type of interface for the
associated instance of cwtPrimIP.

This object specifies the name of the interface for the
associated instance of cwtPrimIP.

This object specifies the type of address contained in the
associated instance of cwtPrimIP.

Primary IP address of the corresponding node.  This value
is taken from the PNNI Nodal PTSE.  The primary IP address is
used by the NMS to manage the switch.  The type of interface
(i.e. ATM interface, LAN interface, etc) for this IP address
is specified by cwtPrimIPIfType.  The NMS will use this IP
address first, but if it can not connect to the switch on
this address, then it will try to contact the switch using
the secondary IP address instead.

This object specifies the type of interface for the
associated instance of cwtSecIP.

This object specifies the name of the interface for the
associated instance of cwtSecIP.

This object specifies the type of address contained in the
associated instance of cwtSecIP.

Secondary IP address of the corresponding node.  This value
is taken from the PNNI Nodal PTSE.  This value is used by
the NMS to manage the switch.  Please refer to the
Description section of cwtPrimIP for more information.

This variable contains the sysObjectID of the node,
which is used to identify different hardware platforms.
The actual values are defined in CISCO-PRODUCTS-MIB.

This variable indicates if the PTSE of this node
is currently contained in the PNNI PTSE database. The
nodal information in the persistent topology database
is derived from the PTSEs in the PNNI PTSE database.
The entries in the PNNI PTSE database times out if no
new PTSE is received from a node after a certain
time.  If that happens, this object is set to 'false'.
This object would allow the NMS to determine whether
this node currently has connectivity with the rest of
the network.

In our implementation, we'll be supporting 'active',
'createAndGo', and 'destroy'.  The value of this
variable is set to 'active' by the managed system for
each valid entry.  If a management station wants to
delete an entry from the database, this value is set
to 'destroy'.  If a management station wants to create
a new entry, this value is set to 'createAndGo'.

This is the index into the feeder database array.
This value should remain persistent while the feeder
database exists, which means that it'll be consistent
across boots.  However, if this node is disabled as
the gateway node, and later on enabled, then the
'cwtFeederIndex' may be different for the same feeder info
entry in the 'feeder database'.

The unique Id which identifies the node the feeder is
attached to.

This variable contains the 'ifIndex' of the
local port this feeder is connected to.

The textual name of the interface of the local
port this feeder is connected to. This should
contain the same 'ifName' associated with the
'cwtLocalIfIndex'.
If this interface does not have a
textual name, the value of this object is a zero
length string.

This variable contains the physcial shelf
number of the feeder module.

This variable contains the physical slot
number of the feeder module.

This variable contains the physical port
number of the feeder module.

This object identifies the  'link' type.
feeder(1) is applicable when cwtFeederType contains
a value other than fdrNON(12). xLMI(2) is applicable
only when cwtFeederType contains a value of fdrNON(12).
Both feeder(1) and xLMI(2) are CISCO proprietary
interfaces. xLMI stands for 'extended local management
interface.

This identifies the feeder type. fdrNON(12) is applicable
when cwfLMIType is xLMI(2). Other values are applicable
when cwtFeederLMIType is feeder(1).
The possible values are :
fdrIPX       -- Feeder is an IPX node in a routing network
fdrBPX       -- Feeder is an BPX node in a routing network
fdrIpxAF     -- Feeder is a stand-alone IPX node
fdrBASIS     -- Feeder is a stand-alone BASIS node
fdrUNKNOWN   -- Feeder is unknown
fdrUNI       -- Feeder is a UNI AIT (phase 0)
fdrAPS       -- Feeder is an APS (Adjunct Processor Shelf)
fdrIGX       -- Feeder is an IGX node in a routing network
fdrIgxAF     -- Feeder is a stand-alone IGX node
fdrVSI       -- Feeder is an VSI Controller
fdrPAR       -- Feeder is a PAR
fdrNON       -- This is non-feeder type

The configured name of the feeder.

This object specifies the type of address contained
in the associated instance of cwtFeederLanIP.

This object specifies the LAN IP address of the
'feeder'. The type of this address is specified by
cwtFeederLanIPAddrType.

This object specifies the type of address contained
in the associated instance of cwtFeederAtmIP.

This object identifies the ATM IP address of the
'feeder'. The type of this address is specified by
cwtFeederAtmIP.

This variable contains the 'model number' of the
corresponding feeder.  This is an implementation specific
integer value which is used to differentiate between
feeder platforms.

In our implementation, we'll be supporting 'active',
and 'destroy'.  The value of this
variable is set to 'active' by the managed system for
each valid entry.  If a management station wants to
delete an entry from the database, this value is set
to 'destroy'.

This is the index into the link database array.
This value is of local significance to the gateway
node. As long as a node remains 'enabled' as
a gateway node, this value remains persistent
across boots.  However, if this node is disabled as
the gateway node, and is enabled later on, the
cwtLinkIndex may be different for the same link info
entry in the topology database.

The unique Id which identifies the local node this link
resides on.

The unique Id which identifies the remote node this
link resides on.

The local 'ifIndex' of this link.

The remote 'ifIndex' of this link.

The local physical port identifier of this link.

The remote physcial port identifier of this link.

This variable indicates if the PTSE of this link
is currently contained in the PNNI PTSE database.
If this entry is also contained in the PNNI PTSE
database, the agent sets the value of this variable
to 'true'. If this entry is not contained in the PNNI
PTSE database, the agent set the value of this variable
to 'false'.

This variable indicates if the link is an outside link.

In our implementation, we'll be supporting 'active',
'createAndGo', and 'destroy'.  The value of this
variable is set to 'active' by the managed system for
each valid entry.  If a management station wants to
delete an entry from the database, this value is set
to 'destroy'.  If a management station wants to create
a new entry, this value is set to 'createAndGo'.
The network management station should provide the
intial values of all mib objects when
setting this variable to 'createAndGo'.

A table of node topology information is to be maintained
for the management station. This table contains the
information for the nodes in the peer group.

A table of 'feeder' information to be maintained
for the management station. This table contains the
information for the 'feeders' in this peer group.

A table of 'link' information in the PNNI network.
If a switch is managed by multiple network
management stations, these network management
stations can have a persistent view of links
in the network by retrieving this table.
A link is a PNNI link between two nodes.

This notification is generated when the gateway node
admin status is changed.

This notification is generated when a new topology nodal
info entry is added in the topology database.

This notification is generated when an existing topology nodal
info entry is modified in the topology database.

This notification is generated when an existing topology nodal
info entry is deleted in the topology database.

This notification is generated when the topology database
becomes full.

This notification is generated when a new feeder
info entry is added in the database.

This notification is generated when an existing feeder
info entry is modified in the database.

This notification is generated when an existing feeder
info entry is deleted in the database.

This notification is generated when a new link
info entry is added in the 'link' database.

This notification is generated when an existing link
info entry is modified in the 'link' database.

This notification is generated when an existing link
info entry is deleted in the 'link' database.

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.

This group contains the object which enables a node
to function as a Gateway Node.

This group contains objects which identify a
node in the network.

This group contains objects which identify a
node in the network.

This group contains objects which identify a
link in the network.

A collection of notifications which indicate
changes in the topology database.

A collection of notifications which indicate
changes in the topology database.

A collection of notifications which indicate
changes in the topology database.