vism Conn Service Type

1.3.6.1.4.1.351.110.5.5.3.1.1.1.18

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. DEFVAL { cbr } ::= { vismChanCnfGrpEntry 18 } SYNTAX Integer32 (1..15) MAX-ACCESS read-write STATUS current DESCRIPTION This object is used by PXM to determine how important this connection is when selecting connections to route. DEFVAL { 8 } ::= { vismChanCnfGrpEntry 19 } SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION 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. ::= { vismChanCnfGrpEntry 20 } SYNTAX INTEGER { noresriction (1), terrestrialTrunk (2), sateliteTrunk (3) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { noresriction } ::= { vismChanCnfGrpEntry 21 } SYNTAX Integer32 (1..100000) UNITS "cells-per-second 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. ::= { vismChanCnfGrpEntry 22 } SYNTAX Integer32 (0..100) UNITS "percentage This is the expected long-term utilization of the channel by this end-point. DEFVAL { 100 } ::= { vismChanCnfGrpEntry 23 } SYNTAX Integer32 (1..100000) UNITS "cells-per-second This object indicates bandwidth(Peak Cell Rate) from the other end i.e in the egress direction of the PVC. ::= { vismChanCnfGrpEntry 24 } SYNTAX Integer32 (0..100) UNITS "percentage This is the expected long-term utilization of the channel by the other end-point. DEFVAL { 100 } ::= { vismChanCnfGrpEntry 25 } SYNTAX INTEGER { protected (1), unprotected (2) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { unprotected } ::= { vismChanCnfGrpEntry 26 } SYNTAX INTEGER { primary (1), secondary (2) } MAX-ACCESS read-write STATUS current DESCRIPTION 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)'. DEFVAL { primary } ::= { vismChanCnfGrpEntry 27 } SYNTAX INTEGER { active (1), standby (2), failed (3), unknown (4) } MAX-ACCESS read-only STATUS current DESCRIPTION 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. ::= { vismChanCnfGrpEntry 28 } SYNTAX INTEGER { unlock (1), lock (2) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { unlock } ::= { vismChanCnfGrpEntry 29 } -- The following three objects are defined for VBR -- type connections only. Even though no special -- processing is done for VBR connections on VISM, -- the following parameters are still required for -- making a PVC connection with the AUSM card, which -- is the other end of the PVC in the trunking application. SYNTAX Integer32 (1..100000) UNITS "cells-per-second 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. ::= { vismChanCnfGrpEntry 30 } SYNTAX Integer32 (1..2147483647) UNITS "cells-per-second 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. ::= { vismChanCnfGrpEntry 31 } SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION This object defines the CLR (Cell Loss Ratio) for the PVC in ingress direction. This field is also meaningful for VBR connections only. ::= { vismChanCnfGrpEntry 32 } SYNTAX Integer32 (1..30) MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { 2 } ::= { vismChanCnfGrpEntry 33 } SYNTAX Integer32 (1..100000) UNITS "cells-per-second 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. ::= { vismChanCnfGrpEntry 34 } SYNTAX Integer32 (1..100000) UNITS "cells-per-second 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. ::= { vismChanCnfGrpEntry 35 } SYNTAX Integer32 (1..2147483647) UNITS "cells-per-second This object defines the MBS (Max. Burst Size) for a PVC in egress direction. This object is meaningful for VBR connections only. ::= { vismChanCnfGrpEntry 36 } SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-write STATUS current DESCRIPTION This object defines the CLR (Cell Loss Ratio) for the PVC in egress direction. This field is also meaningful for VBR connections only. ::= { vismChanCnfGrpEntry 37 } SYNTAX INTEGER { control (1), bearer (2), signaling (3) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { bearer } ::= { vismChanCnfGrpEntry 38 } SYNTAX Integer32 (131..510) MAX-ACCESS read-write STATUS current DESCRIPTION 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. ::= { vismChanCnfGrpEntry 39 } SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION 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)'. DEFVAL { false } ::= { vismChanCnfGrpEntry 40 } SYNTAX INTEGER { notapplicable (1), nsap (2), e164 (3), gwid (4), unspecified (5) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { notapplicable } ::= { vismChanCnfGrpEntry 41 } SYNTAX DisplayString (SIZE(1..15)) MAX-ACCESS read-write STATUS current DESCRIPTION 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'. ::= { vismChanCnfGrpEntry 42 } SYNTAX DisplayString (SIZE(1..64)) MAX-ACCESS read-write STATUS current DESCRIPTION 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. ::= { vismChanCnfGrpEntry 43 } SYNTAX OCTET STRING (SIZE(20)) MAX-ACCESS read-write STATUS current DESCRIPTION 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). ::= {vismChanCnfGrpEntry 44 } SYNTAX Integer32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { 0 } ::= { vismChanCnfGrpEntry 45 } SYNTAX INTEGER { up (1), down (2) } MAX-ACCESS read-write STATUS current DESCRIPTION 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. DEFVAL { up } ::= { vismChanCnfGrpEntry 46 } SYNTAX Unsigned32 (0..65535) MAX-ACCESS read-write STATUS current DESCRIPTION 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.