CISCO-VISM-CONN-MIB: View SNMP OID List / Download MIB

The channel configuration table for voice traffic.

An entry for each voice channel. An entry is created when the vismChanRowStatus is set to 'add'. An entry is deleted when the vismChanRowStatus is set to 'del'.

Logical Channel Number for the PVC.

An entry is created by setting this object to 'add (1)' : Adds an entry to the table. 'mod (3)' : This is used to modify an existing entry. 'del (2)' : This is used to delete an existing. 'outOfService (4)': Setting this object to this value takes the channel out of service or brings the channel 'down (2)'. The channel can be brought 'up (1)' again by setting the object to 'mod (3)'. If there is redundant configuration for the channel, an active channel can be deleted only after locking the channel. Enumeration: 'outOfService': 4, 'add': 1, 'del': 2, 'mod': 3.

This refers to the virtual port between VISM and PXM. This number is defaulted to the appropriate number for the shelf, in PXM1 the value is 1 and 255 for PXM1E.

Loopback on cellbus in egress direction. 'enable (1)' : When you enable this option on a connection (channel) then all the cells that are coming from the network side would be looped back toward the network and all the frames coming from the user side would be dropped. 'disable (2)': disables the remote loopback for a channel. Enumeration: 'enable': 1, 'disable': 2.

This object specifies the channel test type on a voice channel connection. 'testcon (1)' : Test Continuity. 'testdelay (2)' : Test Delay. 'notest (3)' : No test, meant for GET only. Enumeration: 'testdelay': 2, 'notest': 3, 'testcon': 1.

This object identifies the state of the test in the object vismChanTestType. 'passed (1)' : Test passed. 'failed (2)' : Test failed. 'inprogress (3)' : Test is in progress. 'notinprogress (4)' : No test in progress. Enumeration: 'failed': 2, 'inprogress': 3, 'notinprogress': 4, 'passed': 1.

This object identifies round trip delay.

This object identifies the PVC type. 'aal-5 (1)' - Indicates the PVC type is AAL5. 'aal-2 (2)' - Indicates the PVC type is AAL2. 'aal-1 (3)' - Indicates the PVC type is AAL1. Enumeration: 'aal-5': 1, 'aal-1': 3, 'aal-2': 2.

This object identifies the connection type. Enumeration: 'pvc': 1.

This object identifies local VPI, together with the local VCI and NSAP represents the local end point in this connection. GET on this object returns value 0.

This object identifies local VCI, together with the local VPI and NSAP represents the local end point in this connection. GET on this object returns the vismCnfChanNum or LCN.

This object identifies the local NSAP address. The NSAP is 20 bytes binary and is encoded as follows: 13 bytes : for prefix(node name) 2 bytes : for Cisco ID 1 byte : Reserved 3 bytes : for logical interface: slot (1 byte) and port number (2 bytes), 1 byte : for SEL(Selector).

This object identifies the remote VPI, together with the remote VCI and NSAP represents the remote end point in this connection. This parameter is required only if vismMastership is set to 'master (1)'.

This object identifies the VCI, together with the remote VPI and NSAP represents the remote end point in this connection. This parameter is required only if vismMastership is set to 'master (1)'.

This object identifies the remote NSAP address. The NSAP is 20 bytes binary and is encoded as follows: 13 bytes : for prefix(node name) 2 bytes : for Cisco ID 1 byte : Reserved 3 bytes : for logical interface: slot (1 byte) and port number (2 bytes), 1 byte : for SEL(Selector). This parameter is required only if vismMastership is set to 'master (1)'. This object contains the NSAP address of the cross-connect (PXM/AUSM).

'master (1)' : indicates the connection on the channel is a master. 'slave (2)' : indicates the connection on the channel is a slave. 'unknown (3)' : indicates the connection on the channel is unknown. Enumeration: 'slave': 2, 'master': 1, 'unknown': 3.

This object specifies the connection type which is used by PXM to setup connection. Enumeration: 'vcc': 2.

This specifies the class of service or service type 'cbr (1)' : Constant Bit Rate. 'vbr-rt (2)' : Variable Bit Rate 1 (Real Time) although, VISM does not do any kind of traffic shaping, the PVC has to be specified as vbr-rt for PXM to treat the connection as a VBR1 connection. Variable Bit Rate is not currently supported. 'vbr-nrt (3)' : Variable Bit Rate 1 (non real time) the service type of the connection cannot be modified once the PVC is added. 'vbr3-rt (4)' : Variable Bit Rate 3 (Real Time) although, VISM does not do any kind of traffic shaping, the PVC has to be specified as vbr3-rt for PXM to treat the connection as a VBR3 connection. Variable Bit Rate is not currently supported. 'vbr2-rt (5)' : Variable Bit Rate 2 (Real Time) although, VISM does not do any kind of traffic shaping, the PVC has to be specified as 'vbr2-rt' for PXM to treat the connection as a VBR2 connection. Variable Bit Rate is not currently supported. 'vbr2-nrt (6)' : Variable Bit Rate 2 (non real time) the service type of the connection cannot be modified once the PVC is added. 'vbr3-nrt (7)' : Variable Bit Rate 3 (non real time) the service type of the connection cannot be modified once the PVC is added. Enumeration: 'vbr2-rt': 5, 'vbr3-nrt': 7, 'vbr2-nrt': 6, 'vbr3-rt': 4, 'cbr': 1, 'vbr-rt': 2, 'vbr-nrt': 3.

This object is used by PXM to determine how important this connection is when selecting connections to route.

Maximum allowed cost. It is related to Cost Based Routing. This is used by PXM so that it won't choose a path with a cost greater than this configured level. This is not necessary to be provided in the connection setup request.

This object specifies trunk type for routing, used by PXM. 'noresriction (1)' : No routing restriction, it can be done on any trunk. 'terrestrialTrunk (2)' : It specifies the connection be routed over terrestrial trunks. 'sateliteTrunk (3)' : It specifies the connection be routed over satellite trunks. Enumeration: 'sateliteTrunk': 3, 'terrestrialTrunk': 2, 'noresriction': 1.

This indicates bandwidth(Peak Cell Rate) in cells per second from the local end i.e in the ingress direction of the PVC. For AAL2 PVCs, the PCR to be specified has to be computed based on: a) The no. of channels multiplexed on an AAL2 PVC b) The Codec (Compression Algorithm) used. c) The VAD factor d) Partial fill factor. For a AAL2 bearer PVC, the max value is 60,000 cps on E1 card and 50,000 cps on T1 card, and for a signaling PVC, the max value is 400 cps. This parameter can not be changed when there are calls active on the PVC. For variable bit rate connections the minimum value of PCR is 15.

This is the expected long-term utilization of the channel by this end-point.

This object indicates bandwidth(Peak Cell Rate) from the other end i.e in the egress direction of the PVC.

This is the expected long-term utilization of the channel by the other end-point.

This object is used to configure a PVC protection group (or redundant group) with the PVCs protecting each other. Currently only two PVCs are supported in a protection group. One of them is primary and the other one is secondary. This is intended for PVCs designated to carry control traffic and needs to be protected. However the same PVC may also be used to carry VoIP bearer traffic or other traffic. Channels that are 'protected (1)' share the following characteristics: 1. They are monitored for their health (including emission of traps in case of state changes). 2. An active channel is protected by another protected channel which is standby. This means when an active channel fails, switchover to another channel will happen if one is available. 3. It is also possible to do a forced switchover (through locking). Even in the case of forced switchover, switchover to another channel, which is in standby, will happen. 4. Channels may be locked to force switchover and/or to take the channel out of service in a graceful fashion. This object takes the default value of 'unprotected (2)' during the creation of the table entry. Once the primary and secondary channels have been created as 'unprotected (2)' channels, they can be 'protected (1)' by doing a SET on the primary channel by specifying the vismChanProtection as protected and by specifying the vismChanFallbackLcn as the LCN number of the secondary channel. The sequence of operations for setting up the 'protection (1)' group is: step 1: Add primary channel as unprotected step 2: Add secondary channel as unprotected. The PCR value for the secondary should be the same as that of the primary. step 3: Do a SET on the primary channel with vismChanProtection set to 'protected (1)' and vismChanFallbackLcn set to the LCN number of the secondary channel. This operation sets-up the protection group. The primary channel becomes active and the secondary channel becomes standby. Please note that all the CAC related parameters for the both the PVCs in the protecting group should be same. In other words the vismChanCacMaster, vismChanCarrierLossPolicy, vismChanCacRejectionPolicy, VAD tolerance etc.. should have the same value for the PVCs that are protecting each other, else the set request to protect two channels will be rejected. Once the protection group is setup, if the active channel fails, it automatically switches over to the standby. The standby channel then becomes active. The channels can be removed from the protection group by setting this object to unprotected. Deletion of a 'protected (1)' channel is not allowed. Channels have to be removed from the protection group first before deleting. The sequence of operations for deleting 'protected (1)' channels are: step 1: Remove the channels from the protection group by setting vismChanProtection to unprotected. step 2: Delete secondary channel. step 3: Delete primary channel. Enumeration: 'unprotected': 2, 'protected': 1.

This object is used to identify a PVC as primary or secondary. The primary PVC should be added before the secondary. Similarly secondary should be deleted before deleting the primary. When the protection group is setup, the primary becomes active and secondary becomes standby. The distinction of 'primary (1)' and 'secondary(2)' is meaningful only if the PVC is 'protected (1)'. Enumeration: 'primary': 1, 'secondary': 2.

Indicates whether the PVC is currently used to carry IP traffic or not, and whether it has failed. The possible states are: 'active (1)' : Channel is healthy and is currently designated to carry IP traffic. A channel can only be active if it is also unlocked. 'standby (2)' : Channel is healthy but not designated to carry IP traffic. Switchover to this channel is allowed. 'failed (3)' : Channel is unable to carry any traffic. 'unknown (4)' : Channel is unprotected and hence health of the channel is not monitored. The default value upon creation of the row will be 'standby (2)' for a protected channel and 'unknown (4)' for an unprotected channel. VISM may then transition a 'protected (1)' channel to active if it determines that this channel should be the one carrying the traffic. Enumeration: 'active': 1, 'standby': 2, 'unknown': 4, 'failed': 3.

This object is used to control the switchover of protected channels. 'unlock (1)' : Transition state to unlock. A channel which is in lock state has to be brought to 'unlock (1)' state for it to be available for switchover. Whether a switchover to a channel is allowed or not is dependent on both vismChanActivityState and vismChanLockingState. A switchover is allowed if its vismChanActivityState is standby and its vismChanLockingState is unlock. Changing the vismChanLockingState to unlock does not cause a change in the vismChanActivityState. A channel which is in unlock state may carry traffic depending on its activity state (active or standby). 'lock (2)' : Transition state to 'lock (2)'. If the activity state is active, it transitions to standby and a switchover occurs to another channel which is standby and 'unlocked (1)'. When a channel is in 'lock (2)' state, switchover to this channel is not allowed. A channel which is in 'lock (2)' state, is always in either standby or failed state. Hence it will not carry any traffic. Switchover to a channel which is in 'lock (2)' state is not allowed. This object can be set to 'locked (2)' to force a switchover and/or to perform maintenance operations related to that channel. A channel that is 'unprotected' will always be in 'unlock (1)' state. It can not be set to 'lock (2)' state. Enumeration: 'lock': 2, 'unlock': 1.

This object identifies the SCR (Sustained Cell Rate) for the PVC in the ingress direction. SCR is used for vbr connection types only. Traffic shaping is not done on the VISM card, this value is useful for setting up the parameters for the end-to-end PVC. This value is expressed in units of cells per second. If the user provides a value that is greater than vismConnPCR then the SET request will be rejected. For vbr connections the allowed range of values of SCR is from 15 - PCR.

This object defines the MBS (Max. Burst Size). This object is meaningful for VBR connections only. This object defines the MBS value for the ingress direction of the PVC. The MBS value cannot be greater than 10 times vismChanScrIngress value.

This object defines the CLR (Cell Loss Ratio) for the PVC in ingress direction. This field is also meaningful for VBR connections only.

This object defines the CDVT (Cell Delay Variation Tolerance) for the connection. CDVT is useful for determining the playout buffer size in the DSPs. This object is applicable only in AAL1 adaptation. For AAL2, the equivalent of this parameter, known as PDVT (Packet Delay Variation Tolerance) is internally derived.

This object defines the PCR (Peak Cell Rate) for the PVC in egress direction. PCR is applicable to all connection service types ie. CBR, RT-VBR and nRT-VBR.

This object defines the SCR (Sustained Cell Rate) for the PVC in the egress direction. SCR is used for VBR connection types only. No traffic shaping is done on the VISM card, this value is useful for setting up the parameters for the end-to-end PVC.

This object defines the MBS (Max. Burst Size) for a PVC in egress direction. This object is meaningful for VBR connections only.

This object defines the CLR (Cell Loss Ratio) for the PVC in egress direction. This field is also meaningful for VBR connections only.

This object defines the application that the LCN is used for. There are 4 types of PVCs known so far: 'control (1)' : Control PVC used for carrying control traffic only (XGCP packets). 'bearer (2)' : Bearer PVC, used for carrying voice payload traffic only. 'signaling(3)' : Signaling PVC, used for carrying the signaling protocol messages. Enumeration: 'control': 1, 'bearer': 2, 'signaling': 3.

This object defines the LCN to be used as a fallback mechanism, in case the primary PVC fails. This is applicable if the PVC is configured for redundancy. The redundancy is applicable for both applications i.e control PVC and bearer PVC. This object is applicable only if the vismChanProtection is set to 'protected'. It is mandatory if the PVC is protected.

This is used by the administrator to trigger the re-routing of the connection. The re-routing takes effect, when this object is set to 'true (1)'. When set to 'false (2)', no action is taken. A get on this object always returns 'false (2)'.

The address type can be one of five types: NSAP, E164, GWID, notapplicable or unspecified. It determines which object contains the scope for the VCCI, i.e. whether the VCCI needs to be unique relative to NSAP, E164 address or GWID. 'notApplicable (1)' : no valid addresses are required and no validation of VCCI uniqueness for a remote address is performed. 'nsap (2)' : object vismFarEndNSAPAddress contains the address. 'e164 (3)' : object vismFarEndE164Address contains the address. 'gwid (4)' : object vismFarEndGWIDAddress contains the address. 'unspecified (5)' : no valid addresses are required but VCCI needs to be unique. While this object is writeable, it is recommended not to change the value of this object once it has been created. However, upon modification to any value other than notapplicable, it will be ensured that the resulting combination of VCCI and remote address is unique. Requests that would result in a non-unique combination will be rejected. If the vismFarEndAddressType is one of 'nsap', 'e164' or 'gwid', the far end address has to be specified. Enumeration: 'notapplicable': 1, 'nsap': 2, 'e164': 3, 'gwid': 4, 'unspecified': 5.

The E.164 address of the far end peer. The address is expressed as decimal numbers with up to 15 digits. If the vismFarEndAddressType is different from e164, this object is not applicable and it should be ignored. This object serves as the scope for VCCI identifiers (vismVCCI), if vismFarEndAddressType is equal to e164. In that case, the combination of (vismFarEndE164Address, vismVCCI) will always be unique for any given agent. It thus constitutes a label denoting the scope for a VCCI address space; it has no purpose otherwise. While this object is writeable, it is recommended not to change the value of this object once it has been created. However, upon modification, it will be ensured that the resulting combination of VCCI and remote E164 address is unique (as long as the remote address type is E164). Requests that would result in a non-unique combination will be rejected. Beyond this, there are no other integrity constraints that will be enforced for this object. This includes network-level consistency with the actual address of the remote peer. The value of this object cannot be modified when there are active calls on this PVC. The valid characters allowed are '0..9'.

The gateway ID of the far end peer. The address is expressed as ASCII characters. If the vismFarEndAddressType is different from gwid(4), this object is not applicable and it should be ignored. This object serves as the scope for VCCI identifiers (vismVCCI) if vismFarEndAddressType is equal to gwid(4). In that case, the combination of (vismFarEndGWIDAddress, vismVCCI) will always be unique for any given agent. It thus constitutes a label denoting the scope for a VCCI address space; it has no purpose otherwise. While this object is writeable, it is recommended not to change the value of this object once it has been created. However, upon modification, it will be ensured that the resulting combination of VCCI and far end GWID address is unique (as long as the vismFarEndAddress type is GWID). Requests that would result in a non-unique combination will be rejected. Beyond this, there are no other integrity constraints that will be enforced for this object. This includes network-level consistency with the actual address of the remote peer. The value of this object cannot be modified when there are active calls on this PVC. All ASCII characters are allowed by this object.

This object contains the 20 byte NSAP address of the far end peer. If the vismFarEndAddressType is different from 'nsap', this object is not applicable and it should be ignored. This object serves as the scope for VCCI identifiers (vismVCCI) if vismFarEndAddressType is equal to 'nsap'. In that case, the combination of (vismFarEndNSAPAddress, vismVCCI) will always be unique for any given agent. It thus constitutes a label denoting the scope for a VCCI address space; it has no purpose otherwise. While this object is writeable, it is recommended not to change the value of this object once it has been created. However, upon modification, it will be ensured that the resulting combination of VCCI and far end NSAP address is unique (as long as the far end address type is GWID). Requests that would result in a non-unique combination will be rejected. Beyond this, there are no other integrity constraints that will be enforced for this object. This includes network-level consistency with the actual address of the remote peer. The value of this object cannot be modified when there are active calls on this PVC. When the user adds a connection, by default the value of this object will be set to vismRemoteNSAP, unless the user specifies a value for this object. This object is represented as hex (0 .. 9,A .. F).

The VCCI, or Virtual Circuit Connection Identifier, is a variable that identifies a virtual circuit connection between two nodes. A virtual circuit connection, or VCC, consists of one virtual circuit link or a series of concatenated virtual circuit links. In its most common usage, the value of the VCCI is unique between the nodes at the extremities of the virtual circuit connection, but not on a network-wide basis. Hence, its value needs to be qualified by the ATM addresses of these end nodes. At one of these end nodes, its value needs to be qualified by the ATM address of the far-end node. Some applications can extend this definition to make the VCCI value unique on a network-wide basis. This is specially possible when VCCIs are administered from a management system and not locally assigned by a node. In this MIB, the VCCI serves as a label to be assigned by an external application. VCCIs need to be unique for a given remote peer, however, the same VCCI can be reused for different remote peers. Accordingly, the combination of (remote address, VCCI) will always be unique for any given agent. This allows a controller to refer to a VC by the VCCI and remote peer address, in contrast to VPI/VCI and port. It thus constitutes a convenience feature, providing an alternative identification scheme for a VC which is managed by an outside user, such as a management system. The remote peer address can be specified in NSAP, E.164, or GWID format, as indicated by the address type (vismRemoteAddressType). Depending on the address type specified, uniqueness will be relative to NSAP, E.164 address, or GWID. It is recommended not to change the value of this object once it has been created. However, upon modification, it will be ensured that the resulting combination of VCCI and remote address is unique. Requests that would result in a non-unique combination will be rejected. Beyond this, there are no other integrity constraints that will be enforced for this object. This includes network-level consistency whether the remote peer, or an external controller, use the same VCCI designation for the VC.

This object specifies channel administration status. 'up (1)' : Indicates the status channel is up. 'down (2)' : Indicates the channel is down or out of service. Enumeration: 'down': 2, 'up': 1.

This object serves to associate a preferred route with a connection. The value of '0' means no preferred route is associated with this connection. Usage: - If the value of this set to 0, the object vismChanDirectRoute is automatically set to FALSE by the agent. - The preferred route is defined in cwaPrefRouteConfTable object.

This object serves to associate a preferred route as directed route (corresponds to the preferred route object vismChanPrefRouteId). A directed route specifies that the associated preferred route is the only permission route for the connection to take. Should the associated preferred route be unavailable, the connection is failed. The object is not applicable if there is no associated preferred route with the connection or in other words if the object vismChanPrefRouteId has a value of 0.

AIS suppression can be enabled(true) or disabled(false). When AIS suppression is disabled on a PVC, ATM network alarms on that PVC will immediately propagate to the TDM side and cause T1/E1 line alarms. When AIS suppression is enabled on a PVC, ATM network alarms will not propagate to the TDM side and cause T1/E1 line alarms for the duration of the AIS delay time setting. However, if the ATM network alarms persist causing the AIS delay timer to expire, the ATM network alarms will be allowed to propagate onto the TDM side and cause T1/E1 line alarms.

This object defines the duration for which ATM network alarms on this PVC will be prevented from propagating onto the TDM side when AIS suppression is enabled.

This indicates a user configured bandwidth (Peak Cell Rate) in cells per second from the local end i.e in the ingress direction of the PVC. For a VoIP bearer PVC, the max value is 75600 cps. For a VoIP control PVC, the max value is 24400 cps. For AAL2 PVCs, the PCR to be specified has to be computed based on: a) The no. of channels multiplexed on an AAL2 PVC b) The Codec (Compression Algorithm) used. c) The VAD factor d) Partial fill factor. For a AAL2 bearer PVC, the max value is 60,000 cps on E1 card and 50,000 cps on T1 card. For a signaling PVC, the max value is 400 cps. This parameter can not be changed when there are calls active on the PVC. For a VOIP bearer PVC the max allowed value is 80000. For a VOIP control PVC the max allowed value is 20000. increased as we will allow 248 endpoints. For Aal2 the values remain the same 50000/60000. For vbr connections the minimum value of PCR is 15.

This object defines a user configured SCR (Sustained Cell Rate) for the PVC. SCR is used for vbr connection types only. Although, based on the value of SCR, any kind of traffic shaping is not done on the VISM card, this value is useful for setting up the parameters for the end-to-end PVC. This value is expressed in units of cells per second. This object defines the SCR value for the ingress direction of the PVC. For a VOIP bearer PVC the max value is 80000. For a VOIP control PVC the max value is 20000 increased as we will allow 248 endpoints. For Aal2 the values remain the same (50000/60000). If the user provides a value that is greater than vismConnPCR then the SET request will be rejected. For vbr connections the allowed range of values of SCR is from 15 - PCR.

This object defines the user configured MBS (Maximum Burst Size). This object is meaningful for VBR connections only. This object defines the MBS value for the ingress direction of the PVC. The MBS value cannot be greater than 10 times vismChanScrIngress value.

This indicates a user configured minimum number of cells that will be required to keep the connection up.

This indicates which bandwidth value the user has chosen. This value cannot be specified when adding the connection. It can be modified once the connection has been added. If it has a value of userConfiguredMaxBandwidth, it indicates that the bandwidth configured at the time of adding the connection will be used. If it takes a value of userConfiguredMinBandwidth then the minimum bandwidth will be applied as the current PCR value. A derived minimum value, from this value, will be applied for SCR and MBS values. Enumeration: 'userConfiguredMaxBandwidth': 1, 'userConfiguredMinBandwidth': 2.

This object contains the next unused channel number. When channels are available the range is 32..510. This number can be used in channel config table. Value 0 for this object indicates that no more channels are available.

voice connection state table.

An entry for each channel (PVC).

Refers to the channel Number LCN.

This object indicates the channel status. 'notConfigured (1)' : Indicates the channel is not configured. 'okay (2)' : Indicates the channel is healthy, i.e not experiencing error condition. 'alarm (3)' : Indicates the channel is in alarm state. Enumeration: 'alarm': 3, 'okay': 2, 'notConfigured': 1.

This object indicates the transmit state of channel on the ATM side(towards the network). 'other (1)' : Indicates the transmit channel is in unknown state. 'normal (2)' : Indicates the transmit channel is in a normal state. 'sendingAIS (3)' : Indicates the transmit channel is sending AIS alarm toward the network side. 'sendingFERF (4)' : Indicates the transmit channel is sending Far End Receive Failure alarm cells to the network side. Enumeration: 'sendingAIS': 3, 'other': 1, 'sendingFERF': 4, 'normal': 2.

This object indicates the receive state of channel on the ATM side(from the network). 'other (1)' : Indicates the receive channel is in unknown state. 'normal (2)' : Indicates the receive channel is in a normal state. 'receivingAIS (3)' : Indicates the receive channel is receiving AIS alarm cells from the network side. 'receivingFERF (4)' : Indicates the receive channel is receiving Far End Receive Failure alarm cells from the network side. 'oamFailure (5)' : Indicates that the receive channel has failed OAM end-to-end loopback. Enumeration: 'oamFailure': 5, 'receivingAIS': 3, 'other': 1, 'receivingFERF': 4, 'normal': 2.

This object indicates the consolidated bit map of the channel alarm state. Individual bit positions are as defined below, all reserved bits will be set to zero. Bit position Fail/Alarm Reason ------------ ---------- ------ 0 Alarm Reserved 1 Alarm n/w side CC failure/AIS/RDI Rx 2 Fail Conditioned (Abit from n/w) 3 Alarm Reserved 4 Fail Reserved 5 Fail Reserved 6 Alarm Reserved 7 Alarm Reserved Fail bitmap mask : 0x34 Alarm bitmap mask: 0xCB

The MIB module to contains configuration and connection state information the VISM. For VoIP(Voice over IP) support, VISM needs one active AAL5 bearer PVC and one active AAL5 control PVC between the VISM card and the PXM. The redundant PVC feature is supported for AAL5 PVCs. Each redundant PVC pair has one active PVC and one standby PVC. There can be one AAL5 bearer redundant PVC pair and one AAL5 control redundant PVC pair. All PVCs are added on the ATM virtual port=1. For the AAL2 trunking application, there can be multiple AAL2 bearer PVCs. Also, AAL2 bearer PVC in this case, is between the two media gateways, instead of just between the VISM and the PXM. Up to 64 AAL2 bearer PVCs are supported for this application. Terminologies Used: PVC - Permanent Virtual Circuit OR Permanent Virtual Connection. SPVC - Soft Permanent Virtual Circuits. This is a PVC controlled by PNNI Controller. AAL - ATM Adaption Layer. PXM - Processor Switch Module. VC - Virtual Channel. CAC - Connection Admission Control. LCN - Logical Channel Number. VCI - Virtual Channel Identifier.

A collection of objects providing information applicable to connections in VISM Module.

A collection of objects related to state of VISM connections.

A collection of objects providing information applicable to connections in VISM Module.

The compliance statement for SNMP entities which support Connections in VISM Module.

The compliance statement for SNMP entities which support Connections in VISM Module.